From harbhanu@huawei.com Sun Mar 1 18:55:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E07C28C1D7 for ; Sun, 1 Mar 2009 18:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.405 X-Spam-Level: X-Spam-Status: No, score=0.405 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQFGiKIRNubE for ; Sun, 1 Mar 2009 18:55:18 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 1D68028C137 for ; Sun, 1 Mar 2009 18:55:18 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFU006FCYSKHX@szxga02-in.huawei.com> for sip@ietf.org; Mon, 02 Mar 2009 10:55:32 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFU00KXHYSKRT@szxga02-in.huawei.com> for sip@ietf.org; Mon, 02 Mar 2009 10:55:32 +0800 (CST) Received: from HARBHANU1517 ([10.18.28.154]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFU00D9XYSIGI@szxml05-in.huawei.com> for sip@ietf.org; Mon, 02 Mar 2009 10:55:32 +0800 (CST) Date: Mon, 02 Mar 2009 08:25:29 +0530 From: harbhanu In-reply-to: To: sip-implementors@lists.cs.columbia.edu, =?iso-8859-1?Q?'I=F1aki_Baz_Castillo'?= , sip@ietf.org Message-id: <00ef01c99ae2$5a123980$9a1c120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcmZo9BKhH7FNz+JSwiDmPoZOY11tQBOnzVA Subject: Re: [Sip] [Sip-implementors] Tel URI query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: harbhanu@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 02:55:19 -0000 I actually wanted to use +3314529!****! as example. But then as per your interpretation too it's not allowed.=20 Also, please refer to the specification below: 3GPP 23003-830: [Section 13.5 Public Service Identity (PSI)] A wildcarded PSI consists of a delimited regular expression located either in the userinfo portion of the SIP URI or in the telephone-subscriber portion of the Tel URI.=20 TISPAN 182 025: [Section 6.1.2 Identification] The wildcarded public user identity consists of a delimited regular expression located in the telephone-subscriber portion of a tel = URI (e.g. tel: +3314529!****!) or in the user portion of a SIP URI = (e.g. sip:*@example.com). Our point of contention is that the TEL Uri is modified as per the text given in above mentioned specifications.=20 So do we have any parallel draft in IETF to apply these modification to = Tel Uri ?? How are we supposed to handle scenarios like this ? Regards, Harbhanu -----Original Message----- From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]=20 Sent: Saturday, February 28, 2009 6:19 PM To: harbhanu@huawei.com Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Tel URI query 2009/2/27 harbhanu : > Example: The following PSI could be stored in the HSS - > "sip:chatlist!.*!@example.com". > > " > > As per the above statements, the same example there would hold true = for tel > uri too. Such as: > > tel:chatlist!*!@example.com > > > > But after referring to the ABNF defined by RFC-3966 I believe the same = is > not supported. The above TEL uri is fully invalid. Basically a TEL uri can be: - Local number: tel: + 0123456789aBCDEF-,() + ;phone-context=3DXXXX - Global number: tel: + "+" 0123456789-,() A tel URI number cannot contain other symbols. Also, note that in case of a local number (so doesn't start by "+") then "phone-context" parameter is mandatory. Regards. --=20 I=F1aki Baz Castillo From HKaplan@acmepacket.com Sun Mar 1 19:21:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D7028C1CB for ; Sun, 1 Mar 2009 19:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJtPskLLq0OJ for ; Sun, 1 Mar 2009 19:21:39 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 27DBF3A6921 for ; Sun, 1 Mar 2009 19:21:39 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 1 Mar 2009 22:22:03 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 1 Mar 2009 22:22:03 -0500 From: Hadriel Kaplan To: Theo Zourzouvillys Date: Sun, 1 Mar 2009 22:22:01 -0500 Thread-Topic: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) Thread-Index: AcmVpDwXZ6RYXb1nTC2wJC4BmRV7ZwFICRDA Message-ID: References: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> <167dfb9b0902221232m604d7969u7a880378d50fa6d7@mail.gmail.com> <167dfb9b0902230249u14daa4f6r54fd904f8fe2826f@mail.gmail.com> In-Reply-To: <167dfb9b0902230249u14daa4f6r54fd904f8fe2826f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP WG Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 03:21:40 -0000 > -----Original Message----- > From: theo@crazygreek.co.uk [mailto:theo@crazygreek.co.uk] On Behalf Of > Theo Zourzouvillys > Sent: Monday, February 23, 2009 5:49 AM > > On Sun, Feb 22, 2009 at 11:55 PM, Hadriel Kaplan > wrote: > > > Essentially what you're proposing seems to me similar in concept to > syncookies, but at the next layer up. > > yeah, it is - in fact probably why i subconsciously called them via > cookies :-) So if the protection mechanism involved requires a change on the proxy and = a change on the UA's, to do the via-cookie mechanism, then why do the chang= e so high in the SIP stack? I mean essentially what you'd want is a *reall= y* efficient response/check mechanism, before even parsing the message (or = parsing it enough to create a legal 4xx response). One way to do that would be to create a fixed-length, binary header as the = first N bytes of the UDP payload, to carry the support indication and the c= hallenge and challenge-response. You could even treat this as a shim-layer= between UDP and the SIP message layer (and below sigcomp if it's there). = That way the client side also doesn't have to process the cookie challenge = at its SIP layer either, because the retransmission with the challenge resp= onse is done by the shim layer. And of course a fixed-length header send-a= ble in the SIP port somewhat already exists: STUN. Obviously in a way you're really just re-creating TCP or SCTP in that regar= d, but that's what the via-cookie is doing anyway, just at a higher layer. -hadriel From shivalk_80@yahoo.co.in Sun Mar 1 21:19:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D253A6A39 for ; Sun, 1 Mar 2009 21:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWTyTUnDZG5C for ; Sun, 1 Mar 2009 21:19:50 -0800 (PST) Received: from n7-vm0.bullet.mail.in.yahoo.com (n7-vm0.bullet.mail.in.yahoo.com [202.86.4.134]) by core3.amsl.com (Postfix) with SMTP id 64A893A68AA for ; Sun, 1 Mar 2009 21:19:50 -0800 (PST) Received: from [202.86.5.126] by n7.bullet.mail.in.yahoo.com with NNFMP; 02 Mar 2009 05:20:14 -0000 Received: from [203.104.18.49] by t6.bullet.mail.in.yahoo.com with NNFMP; 02 Mar 2009 05:20:14 -0000 Received: from [127.0.0.1] by omp110.mail.in2.yahoo.com with NNFMP; 02 Mar 2009 05:20:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 689022.698.bm@omp110.mail.in2.yahoo.com Received: (qmail 71743 invoked by uid 60001); 2 Mar 2009 05:20:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1235971213; bh=hA8wPfsf383TcuKDci9qwmVueLHxsLRz7gB5Tdanatk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zl5kyHreVjBMoMz5oYd5OI0Q9yuMEJGATVMP6VNs6byxAtRbsOKdS0tTMHu1+KldPDr9pgPYrmvSJLfSlWC1Wfzy6gZTi9RWycNZTdYerPtxpQuSEp5lEYVZX7/lT68tFrwvlp5pCHkFjXqMNrJW+4caFMS5EM/RT/8N4EYbEng= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SvOGm2uGMNGGGG9D6mrTAvdLDGxSN0LPj4yw0exrZej2QuzUn2DNaGI0u78XYEbCnf1HyLYdIf91qT5VkGRinWGB0FaDq8mdud60MW5axZIeoajXCwDQr0sWO4fhnJHOhgGCdofmG4Gw1MeR202hWfCl4ZrrYtZqKa/4saFDsDk=; Message-ID: <19120.58285.qm@web95409.mail.in2.yahoo.com> X-YMail-OSG: 1XSLVuAVM1kvgyYHlKw2H5eMMz5wuKWbSJsmV_mifuWks4LU1WJH1h0vYe9o6AK7OLxbzIg1aBsDINlQGcYc7Qt3zNci1T0e5l22I7_pF9oZL_2I5A47nsAi8vSl5DrCBiCWexBJxWbmfWyY4CMs.GoVQYTt7t1iXuLZNi7OmQiqWmR9HIpazGCMMGGMrQGr5ZXxWfXi3Ig7JjIB8lOKFUkNgs8pu9wutFFDsJyswPMwPJOs0c0- Received: from [121.241.96.5] by web95409.mail.in2.yahoo.com via HTTP; Mon, 02 Mar 2009 10:50:12 IST X-Mailer: YahooMailWebService/0.7.289.1 Date: Mon, 2 Mar 2009 10:50:12 +0530 (IST) From: atul garg To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Frequency of Register Message ?? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: shivalk_80@yahoo.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 05:19:51 -0000 Hi, 1) Is register message used as Heartbeat in any scenario??? 2) Can register message be sent after every second??? 3) Is it logical to send register message after every second??? 4) what will be the drawbacks of sending register message after every secon= d??? Regards Atul=0A=0A=0A Add more friends to your messenger and enjoy! Go to http= ://messenger.yahoo.com/invite/ From mahesh.awaradi@globaledgesoft.com Sun Mar 1 22:12:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67FD73A68F6 for ; Sun, 1 Mar 2009 22:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.595 X-Spam-Level: ** X-Spam-Status: No, score=2.595 tagged_above=-999 required=5 tests=[BAYES_60=1, J_CHICKENPOX_35=0.6, RELAY_IS_203=0.994, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfx+KNhC3KaW for ; Sun, 1 Mar 2009 22:12:22 -0800 (PST) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [203.76.137.4]) by core3.amsl.com (Postfix) with ESMTP id 7F4A93A6901 for ; Sun, 1 Mar 2009 22:12:22 -0800 (PST) Received: from MaheshAwaradi (unknown [172.16.7.101]) by gesmail.globaledgesoft.com (Postfix) with SMTP id D13D617B424 for ; Mon, 2 Mar 2009 11:42:43 +0530 (IST) Message-ID: <001801c99afd$9c474690$650710ac@globaledgesoft.com> From: "Mahesh" To: References: Date: Mon, 2 Mar 2009 11:40:34 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [Sip] ACK response X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 06:12:23 -0000 Hi All, what will happen if caller din't get ACK.whats the behaviour of caller. Regards Mahesh From theo@crazygreek.co.uk Mon Mar 2 02:08:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB9C3A6A60 for ; Mon, 2 Mar 2009 02:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkk+XDhderAW for ; Mon, 2 Mar 2009 02:08:25 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with SMTP id 38C5D3A6A5D for ; Mon, 2 Mar 2009 02:08:25 -0800 (PST) Received: from source ([209.85.218.163]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSauwMlUiCaT+XM9I1a/xBSHdwmLAXBCO@postini.com; Mon, 02 Mar 2009 02:08:51 PST Received: by bwz7 with SMTP id 7so2259707bwz.11 for ; Mon, 02 Mar 2009 02:08:50 -0800 (PST) MIME-Version: 1.0 Sender: theo@crazygreek.co.uk Received: by 10.86.60.14 with SMTP id i14mr1523709fga.69.1235988529720; Mon, 02 Mar 2009 02:08:49 -0800 (PST) In-Reply-To: References: <167dfb9b0902212332t5ae3fdbcma49e89bc703358f2@mail.gmail.com> <167dfb9b0902221232m604d7969u7a880378d50fa6d7@mail.gmail.com> <167dfb9b0902230249u14daa4f6r54fd904f8fe2826f@mail.gmail.com> Date: Mon, 2 Mar 2009 10:08:49 +0000 X-Google-Sender-Auth: d571a30a018ec36c Message-ID: <167dfb9b0903020208p49df6bdfwc6407033bdf3198c@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP WG Subject: Re: [Sip] SIP amplification vulnerability -01 (draft-zourzouvillys-sip-via-cookie-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 10:08:26 -0000 On Mon, Mar 2, 2009 at 3:22 AM, Hadriel Kaplan wrote: Hi Hadriel, > So if the protection mechanism involved requires a change on the proxy and a change on the UA's, to do the via-cookie mechanism, then why do the change so high in the SIP stack? only for adoption reasons: First, It seemed to big a change to push and in reality get adopted in the "short" term by people as any other lower change requires more than just a few lines of code for people that want to implement it without caring about performance (for example, a SIP phone or something else that is not worried about high performance). DCCP offers the same features at a level already implemented by most major operating systems, as does DTLS - so we could use either of those and the problem goes away, too with potentially less complexity for implementers (at least in the DCCP case). Second, there are already a scary number of ALGs on DSL/cable routers and deployed out there - any non 3261 compliant method would likely require many of those be updated as well, although with all the SIP diagnostic tools like ethereal/wireshark and monitoring etc. ~ Theo From drage@alcatel-lucent.com Mon Mar 2 02:47:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA473A6BCE for ; Mon, 2 Mar 2009 02:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiof2zBRgHSS for ; Mon, 2 Mar 2009 02:47:13 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id CEF663A6BBD for ; Mon, 2 Mar 2009 02:47:08 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n22AlTaf013700 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Mar 2009 11:47:31 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 2 Mar 2009 11:47:28 +0100 From: "DRAGE, Keith (Keith)" To: SIP List Date: Mon, 2 Mar 2009 11:47:28 +0100 Thread-Topic: WGLC for draft-ietf-sip-ua-privacy Thread-Index: AcmQks5lzLuuTjaiSi+I84Fl0y/8ogKkUBrA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A8D232@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <28B7C3AA2A7ABA4A841F11217ABE78D674A08F78@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A08F78@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "draft-ietf-sip-ua-privacy@tools.ietf.org" , Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 10:47:14 -0000 (As WG cochair) A reminder of the current WGLC on this document which completes today. Please submit your comments as soon as possible. If you are reviewing the document, and you consider there may be a delay in= your comments appearing, then please send a mail to the chairs so they can= ascertain whether more time is needed. regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of DRAGE, Keith (Keith) > Sent: Tuesday, February 17, 2009 12:01 AM > To: SIP List > Cc: draft-ietf-sip-ua-privacy@tools.ietf.org; Dean Willis > Subject: [Sip] WGLC for draft-ietf-sip-ua-privacy >=20 > (As WG cochair) >=20 > This mail is to initiate working group last call on=20 > draft-ietf-sip-ua-privacy which may be found here: >=20 > http://tools.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-05.txt >=20 > Please provide comments to both the authors and to the SIP WG=20 > list by Monday 2nd March 2009. >=20 > The intended status of the document is informational. >=20 > regards >=20 > Keith > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip > = From drage@alcatel-lucent.com Mon Mar 2 02:47:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6604B3A6C14 for ; Mon, 2 Mar 2009 02:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ot2Py+3Gy7J for ; Mon, 2 Mar 2009 02:47:50 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 570833A6BE0 for ; Mon, 2 Mar 2009 02:47:50 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n22Am9Ne014421 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Mar 2009 11:48:09 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 2 Mar 2009 11:48:09 +0100 From: "DRAGE, Keith (Keith)" To: SIP IETF Date: Mon, 2 Mar 2009 11:48:07 +0100 Thread-Topic: WGLC on draft-ietf-sip-info-events Thread-Index: AcmQad8/1+QfM4TFQBavCWEg2uC7xAKum/Jg Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> In-Reply-To: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 10:47:51 -0000 (As WG cochair) A reminder of the current WGLC on this document, which completes Wednesday. Please submit your comments as soon as possible. If you are reviewing the document, and you consider there may be a delay in= your comments appearing, then please send a mail to the chairs so they can= ascertain whether more time is needed. regards Keith=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, February 16, 2009 7:08 PM > To: SIP IETF > Cc: Eric Burger; DRAGE, Keith (Keith) > Subject: WGLC on draft-ietf-sip-info-events >=20 >=20 > I'd like to request the SIP Working Group perform final=20 > review on the INFO Events draft: >=20 >=20 > http://tools.ietf.org/id/draft-ietf-sip-info-events-03.txt >=20 >=20 >=20 > Please review this draft and bring any issues to the mailing=20 > list, copying the author. Please conclude this review=20 > process by March 4, 2009. >=20 > -- > Dean Willis > cp-Chair, SIP WG > = From satyanarayana.t@motorola.com Mon Mar 2 02:58:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36693A6A67 for ; Mon, 2 Mar 2009 02:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYTnhbsGAE7W for ; Mon, 2 Mar 2009 02:58:11 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 6F7A63A6C28 for ; Mon, 2 Mar 2009 02:57:40 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1235991484!24582082!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 14634 invoked from network); 2 Mar 2009 10:58:05 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-15.tower-119.messagelabs.com with AES256-SHA encrypted SMTP; 2 Mar 2009 10:58:05 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n22Avxac012290 for ; Mon, 2 Mar 2009 03:58:04 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n22AvxTD027559 for ; Mon, 2 Mar 2009 04:57:59 -0600 (CST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n22AvweS027548 for ; Mon, 2 Mar 2009 04:57:58 -0600 (CST) 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: Mon, 2 Mar 2009 18:57:54 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E603ACCDFF@ZMY16EXM67.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] Tel URI query thread-index: AcmbFP9QoxCxuuZ8SYqwoka5cLK3mQAD233w References: <00ef01c99ae2$5a123980$9a1c120a@china.huawei.com> From: "T Satyanarayana-A12694" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , X-CFilter-Loop: Reflected Cc: sip@ietf.org, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] Tel URI query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 10:58:12 -0000 There MAY be no violation of specs here. These wildcard chars (! etc) = are used only in the HSS or other nodes (only to optimize handling of = multiple related URIs) and not in a SIP message?. Just a thought, not = sure. Have a look at the following text from 23.003. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The public service identity shall take the form of either a SIP URI (see = IETF RFC 3261 [26]) or a Tel URI (see IETF RFC 3966 [45]). A public = service identity identifies a service, or a specific resource created = for a service on an application server. The domain part is pre-defined = by the IMS operators and the IMS system provides the flexibility to = dynamically create the user part of the PSIs. The PSIs are stored in the HSS either as a distinct PSI or as a = wildcarded PSI. A distinct PSI contains the PSI that is used in routing = , whilst a wildcarded PSI represents a collection of PSIs. Wildcarded = PSIs enable optimisation of the operation and maintenance of the nodes. = A wildcarded PSI consists of a delimited regular expression located = either in the userinfo portion of the SIP URI or in the = telephone-subscriber portion of the Tel URI. The regular expression in = the wildcarded PSI shall take the form of Extended Regular Expressions = (ERE) as defined in chapter 9 in IEEE 1003.1-2004 Part 1 [60]. The = delimiter shall be the exclamation mark character ("!"). If more than = two exclamation mark characters are present in the userinfo portion or = telephone-subscriber portion of a wildcarded PSI then the outside pair = of exclamation mark characters is regarded as the pair of delimiters = (i.e. no exclamation mark characters are allowed to be present in the = fixed parts of the userinfo portion or telephone-subscriber portion). When stored in the HSS, the wildcarded PSI shall include the delimiter = character to indicate the extent of the part of the PSI that is = wildcarded. It is used to separate the regular expression from the = fixed part of the wildcarded PSI. Example: The following PSI could be stored in the HSS - = "sip:chatlist!.*!@example.com". =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Satya T -----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu = [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of = I=F1aki Baz Castillo Sent: Monday, March 02, 2009 2:28 PM To: harbhanu@huawei.com Cc: sip@ietf.org; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Tel URI query 2009/3/2 harbhanu : > I actually wanted to use +3314529!****! as example. > But then as per your interpretation too it's not allowed. Sure it's not allowed per RFC 3966 BNF syntax rules. > TISPAN 182 025: [Section 6.1.2 Identification] > =A0 =A0 =A0 =A0 =A0 =A0 The wildcarded public user identity consists = of a=20 > delimited regular expression located in the telephone-subscriber=20 > portion of a tel URI (e.g. =A0 =A0 =A0 =A0 tel: +3314529!****!) or in = the user portion of a SIP URI (e.g. > sip:*@example.com). This is annoying. It means that this specification violates the grammar = specified in RFC 3966. Theorically RFC 3966 is just updated by RFC 5341. = Sincerelly I can't understand how the above spec can requiere such = aberration in Tel URI. > So do we have any parallel draft in IETF to apply these modification=20 > to Tel Uri ?? > How are we supposed to handle scenarios like this ? Sorry, no idea, this is really confusing. Do people writting = specifications really want TEL URI to be usable?? -- I=F1aki Baz Castillo _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors From root@core3.amsl.com Mon Mar 2 04:15:03 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4C42D3A6858; Mon, 2 Mar 2009 04:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090302121502.4C42D3A6858@core3.amsl.com> Date: Mon, 2 Mar 2009 04:15:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-199-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 12:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sip-199-06.txt Pages : 14 Date : 2009-03-02 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-199-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-199-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-02040051.I-D@ietf.org> --NextPart-- From HKaplan@acmepacket.com Mon Mar 2 04:54:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD5A3A6A2B for ; Mon, 2 Mar 2009 04:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPSXg0Epgv0m for ; Mon, 2 Mar 2009 04:54:58 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B7F203A69DD for ; Mon, 2 Mar 2009 04:54:58 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 2 Mar 2009 07:55:23 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Mar 2009 07:55:23 -0500 From: Hadriel Kaplan To: "shivalk_80@yahoo.co.in" , "sip@ietf.org" Date: Mon, 2 Mar 2009 07:55:22 -0500 Thread-Topic: [Sip] Frequency of Register Message ?? Thread-Index: Acma9pb4JfS/WLTwRJOIYhD/j22BqwAO3Rcg Message-ID: References: <19120.58285.qm@web95409.mail.in2.yahoo.com> In-Reply-To: <19120.58285.qm@web95409.mail.in2.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] Frequency of Register Message ?? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 12:54:59 -0000 Do you mean these questions about whether they're used in an IETF RFC? Thi= s is the sip mailing list for IETF RFC/drafts discussion - you're probably = looking for sip-implementors@lists.cs.columbia.edu - see https://lists.cs.c= olumbia.edu/cucslists/listinfo/sip-implementors. I assume you mean in practice, not theory. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of atu= l > garg > Sent: Monday, March 02, 2009 12:20 AM > > 1) Is register message used as Heartbeat in any scenario??? In an RFC no, but in practice yes. In fact it's widely used as a Heartbeat= in practice. But for a specific case: endpoints or small PBX's to their r= egistrar/proxy. Not for proxy-to-proxy or server-to-server; OPTIONS messag= es are often used for the server-to-server type of Heartbeat in practice. > 2) Can register message be sent after every second??? You mean can it be sent every second? Well technically you could of course= , but in practice that's not a good idea. There are some devices which wil= l blacklist/block your UA if it sends one that frequently, disabling servic= e to your user. It would be considered an attack or at least a broken impl= ementation. Your code would essentially be considered malware. > 3) Is it logical to send register message after every second??? No, not really. There is no real reason to do so. NATs, for example, don'= t expire their bindings nearly that fast. The worst I've seen a NAT do is = about 30 seconds, but some are longer (much longer). So you only need to s= end one every 15 or 20 seconds worst-case. But really you should just use = the Expires header/param in the 200 ok response to the first Register, for = the timer/frequency value for Register messages. (in other words follow RFC= 3261 section 10.2.1 - 10.2.4, and see 10.3) > 4) what will be the drawbacks of sending register message after every > second??? Well, for starters the processing load on your Registrar or proxy will be v= ery high. Your UA is one of potentially hundreds of thousands or millions = of endpoints on a Registrar. If each UA sent a Register every second, it w= ouldn't scale. And if you implement your stack in a full layered model, then your transact= ion layer could also be sending retransmissions while you're trying to send= new ones - resulting in either out of order sending, or at least a possibl= e pile up of retransmissions for multiple Registers if the network's out fo= r a dozen seconds or so. -hadriel From christer.holmberg@ericsson.com Mon Mar 2 04:58:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81923A68AF for ; Mon, 2 Mar 2009 04:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwzsJYtC3adb for ; Mon, 2 Mar 2009 04:58:19 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 30DE23A6A59 for ; Mon, 2 Mar 2009 04:58:19 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0927E208AC for ; Mon, 2 Mar 2009 13:58:44 +0100 (CET) X-AuditID: c1b4fb3c-ae80cbb000001b43-f1-49abd803ba07 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DDD852051E for ; Mon, 2 Mar 2009 13:58:43 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 13:58:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99B36.9DC438F0" Date: Mon, 2 Mar 2009 13:58:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version (-06) of the 199 draft Thread-Index: AcmbNp1ehZfYgPQWQ42zZjrOOn5aHQ== From: "Christer Holmberg" To: X-OriginalArrivalTime: 02 Mar 2009 12:58:43.0744 (UTC) FILETIME=[9DF5CA00:01C99B36] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] New version (-06) of the 199 draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 12:58:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99B36.9DC438F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I received some editorial comments on the security impact chapter of the draft, so I fixed those and submitted a new version of the draft. It can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-06.txt Regards, Christer ------_=_NextPart_001_01C99B36.9DC438F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version (-06) of the 199 draft

Hi,

I received some editorial comments on = the security impact chapter of the draft, so I fixed those and submitted = a new version of the draft.

It can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-= 06.txt

Regards,

Christer


------_=_NextPart_001_01C99B36.9DC438F0-- From brett@broadsoft.com Mon Mar 2 05:19:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D8A3A6BA1 for ; Mon, 2 Mar 2009 05:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml9mjPIWPLny for ; Mon, 2 Mar 2009 05:19:25 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 8EA2D3A6C03 for ; Mon, 2 Mar 2009 05:18:13 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 2 Mar 2009 05:18:38 -0800 From: Brett Tate To: "DRAGE, Keith (Keith)" , SIP IETF Date: Mon, 2 Mar 2009 05:18:37 -0800 Thread-Topic: WGLC on draft-ietf-sip-info-events Thread-Index: AcmQad8/1+QfM4TFQBavCWEg2uC7xAKum/JgAAR7jxA= Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10B1FAA3C1@mbx02.citservers.local> References: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hkaplan@acmepacket.com" , "christer.holmberg@ericsson.com" Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 13:19:25 -0000 > A reminder of the current WGLC on this document, which completes > Wednesday. >=20 > Please submit your comments as soon as possible. >=20 > If you are reviewing the document, and you consider there may be a delay > in your comments appearing, then please send a mail to the chairs so they > can ascertain whether more time is needed. I haven't received a reply concerning my February 16 (archived on 17) email= : "draft-ietf-sip-info-events-03: comments and questions". Thus I'm not su= re if I will have follow-up comments based upon the reply. http://www.ietf.org/mail-archive/web/sip/current/msg26621.html The following is a snapshot of my questions and comments in case the author= s did not see my prior email. Thanks, Brett ---- Section 3.1 paragraph 1: Concerning "MUST advertise" and "provisional 1xx"= , please clarify that the "MUST advertise" is not applicable to the 100 res= ponse. Does the "MUST advertise" and "provisional 1xx" apply to all (first= and subsequent within dialog) INVITE non 101-199 (intentionally indicated = 199)? Concerning ACK for initial INVITE's 2xx, does the "MUST advertise" a= lways apply? Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1 indicates "session pa= rameters" and sentence 2 indicates "dialog parameters" concerning Info Pack= age negotiation, I'm not sure when the negotiation/renegotiation occurs. D= oes it follow SDP offer/answer rules or something else; if something else, = what? I have the same question concerning "dialog refresh" text discussed = later within the same section since incorrect interpretations might trigger= deactivation. Section 4.3: When sending a 489, it indicates "MUST terminate the INVITE di= alog". The "MUST terminate" seems severe even if all the negotiation race = conditions are adequately addressed. The mentioned "protocol failure" reas= on seems contrary to the "strictly send and lenient receive" mantra. Section 5.1 Table 1: The usage of "g" seems potentially outdated or incorre= ctly reference since discussed within RFC 2543 instead of RFC 3261. The sa= me applies to usage Via row concerning "(2)". Section 5.2.2: The "general-header" reference is outdated or incorrectly re= ference since defined within RFC 2543 instead of RFC 3261. RFC 3261 uses "= Message-Header". Section 7.7 paragraph 2: The following potentially could be reworded since = it is okay to return failure responses (401, 503, 500, ...) even when overl= apping occurs: "in the event a UAC issues overlapping INFO requests for an = Info Package, the UAS MUST NOT return an error response". Section 8: Why specifically defining and using "nil"? I'm mainly just curi= ous of the benefit over not having defined "nil" for similar use within the= Supported header. From Mike.Szilagyi@inin.com Mon Mar 2 06:20:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9696228C246 for ; Mon, 2 Mar 2009 06:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PNZ8SKYWQSK for ; Mon, 2 Mar 2009 06:20:38 -0800 (PST) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id 7EA4B28C247 for ; Mon, 2 Mar 2009 06:20:34 -0800 (PST) Received: from ININHUB2 [172.16.1.157] by smtpgw.inin.com - Websense Email Security (6.1.0); Mon, 02 Mar 2009 09:20:59 -0500 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub2.i3domain.inin.com ([172.16.1.157]) with mapi; Mon, 2 Mar 2009 09:20:59 -0500 From: "Szilagyi, Mike" To: "SIP@ietf.org" Date: Mon, 2 Mar 2009 09:20:59 -0500 Thread-Topic: Question regarding conflicting grammar for IPV6 SIP URI and RFC 3986 Thread-Index: AclhKKZwY4gKVSlwSsaS9afKGRk7kA6GM3Rw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B043FD61A001424599674F50FC89C2D71D91390EB9ININMAILi3dom_" MIME-Version: 1.0 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=300718496 X-SEF-Processed: 6_1_0_100__2009_03_02_09_20_59 Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI and RFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 14:20:42 -0000 --_000_B043FD61A001424599674F50FC89C2D71D91390EB9ININMAILi3dom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could someone let me know where this discussion has been moved? Regards, Mike From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Szila= gyi, Mike Sent: Thursday, December 18, 2008 10:53 AM To: SIP@ietf.org Subject: [Sip] Question regarding conflicting grammar for IPV6 SIP URI and = RFC 3986 RFC 3986 defines the following grammar for a URI: URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part =3D "//" authority path-abempty / path-absolute / path-rootless / path-empty A SIP URI falls into the 'path-rootless' rule: path-rootless =3D segment-nz *( "/" segment ) segment-nz =3D 1*pchar pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" pct-encoded =3D "%" HEXDIG HEXDIG unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=3D" path-rootless does not allow "[" or "]" characters, so the SIP-URI grammar = for IPV6 violates RFC 3986 grammar. SIP-URI =3D "sip:" [ userinfo ] hostport uri-parameters [ headers ] hostport =3D host [ ":" port ] host =3D hostname / IPv4address / IPv6reference hostname =3D *( domainlabel "." ) toplabel [ "." ] domainlabel =3D alphanum / alphanum *( alphanum / "-" ) alphanum toplabel =3D ALPHA / ALPHA *( alphanum / "-" ) alphanum IPv4address =3D 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6reference =3D "[" IPv6address "]" <-- *** violates RFC 3986 *** IPv6address =3D hexpart [ ":" IPv4address ] hexpart =3D hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq =3D hex4 *( ":" hex4) hex4 =3D 1*4HEXDIG port =3D 1*DIGIT These, though valid SIP URIs are not valid URIs: Has this already been addressed? Regards, Mike --_000_B043FD61A001424599674F50FC89C2D71D91390EB9ININMAILi3dom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Could someone let me kno= w where this discussion has been moved?

 =

Regards,

Mike

 =

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Szil= agyi, Mike
Sent: Thursday, December 18, 2008 10:53 AM
To: SIP@ietf.org
Subject: [Sip] Question regarding conflicting grammar for IPV6 SIP U= RI and RFC 3986

 

RFC 3986 defines the following grammar for a URI:=

 

   URI           =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ]<= o:p>

 

   hier-part     = =3D "//" authority path-abempty

        =          / path-absolute

        =          / path-rootless

        =          / path-empty

 

A SIP URI falls into the ‘path-rootless’ rule:

 

   pa=
th-rootless =3D segment-nz *( "/" segment )


 



   se=
gment-nz    =3D 1*pchar



 



   pc=
har         =3D unreserved / pct-en=
coded / sub-delims / ":" / "@"



 



   pc=
t-encoded   =3D "%" HEXDIG HEXDIG
 
   unreser=
ved    =3D ALPHA / DIGIT / "-" / "." / &=
quot;_" / "~"



 



   su=
b-delims    =3D "!" / "$" / "&&=
quot; / "'" / "(" / ")"
   &n=
bsp;            =
; / "*" / "+" / "," / ";" / "=
=3D"



 



path-rootless does not allow “[“ or
“]” characters, so the SIP-URI grammar for IPV6 violates RFC 39=
86
grammar.



 



SIP-URI       =
;  
=3D  "sip:" [ userinfo ] hostport



        =
           
uri-parameters [ headers ]



 



hostport      &nbs=
p; 
=3D  host [ ":" port ]



host       &n=
bsp;    
=3D  hostname / IPv4address / IPv6reference



hostname      &nbs=
p; 
=3D  *( domainlabel "." ) toplabel [ "." ]



domainlabel      =3D&nb=
sp;
alphanum



        =
           
/ alphanum *( alphanum / "-" ) alphanum



toplabel      &nbs=
p; 
=3D  ALPHA / ALPHA *( alphanum / "-" ) alphanum



IPv4address    =3D  1*3DIGIT
"." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT



IPv6reference  =3D  "[&=
quot;
IPv6address "]"  <-- *** violates RFC 3986 ***=




IPv6address    =3D  hexpart =
[
":" IPv4address ]



hexpart       =
;
=3D  hexseq / hexseq "::" [ hexseq ] / "::" [ hexs=
eq ]



hexseq       =
 
=3D  hex4 *( ":" hex4)



hex4       &n=
bsp;  
=3D  1*4HEXDIG



port       &n=
bsp;  
=3D  1*DIGIT



 



 



These, though valid SIP URIs are not valid URIs:<=
/o:p>



 



   
<sip:[2001:db8::10]>



   
<sip:caller@[2001:db8::1]>



 



Has this already been addressed?



 



Regards,



Mike
--_000_B043FD61A001424599674F50FC89C2D71D91390EB9ININMAILi3dom_-- From brett@broadsoft.com Mon Mar 2 06:37:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F763A689C for ; Mon, 2 Mar 2009 06:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+yGgGaFpX+G for ; Mon, 2 Mar 2009 06:37:00 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id A8ED03A6818 for ; Mon, 2 Mar 2009 06:37:00 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 2 Mar 2009 06:37:24 -0800 From: Brett Tate To: "Szilagyi, Mike" , "SIP@ietf.org" Date: Mon, 2 Mar 2009 06:37:23 -0800 Thread-Topic: Question regarding conflicting grammar for IPV6 SIP URI and RFC 3986 Thread-Index: AclhKKZwY4gKVSlwSsaS9afKGRk7kA6GM3RwAACMM1A= Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10B1FAA3F8@mbx02.citservers.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9B2A061A1137254BBE4F4B2CD843646A10B1FAA3F8mbx02citserve_" MIME-Version: 1.0 Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI and RFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 14:37:05 -0000 --_000_9B2A061A1137254BBE4F4B2CD843646A10B1FAA3F8mbx02citserve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cullen's reply killed or moved the discussion. http://www.ietf.org/mail-archive/web/sip/current/msg26385.html "WIth my AD hat on ... If you want to update/discuss/change/abuse 3986, probably the best place to= to that would be on the APPS area list at apps-discuss@ietf.org It would be up to the Apps ADs, but I suspect that change to the BNF sugges= ted below is too significant a change to be done with an Errata. Cullen" From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Szila= gyi, Mike Sent: Monday, March 02, 2009 9:21 AM To: SIP@ietf.org Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI = and RFC 3986 Could someone let me know where this discussion has been moved? Regards, Mike From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Szila= gyi, Mike Sent: Thursday, December 18, 2008 10:53 AM To: SIP@ietf.org Subject: [Sip] Question regarding conflicting grammar for IPV6 SIP URI and = RFC 3986 RFC 3986 defines the following grammar for a URI: URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part =3D "//" authority path-abempty / path-absolute / path-rootless / path-empty A SIP URI falls into the 'path-rootless' rule: path-rootless =3D segment-nz *( "/" segment ) segment-nz =3D 1*pchar pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" pct-encoded =3D "%" HEXDIG HEXDIG unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=3D" path-rootless does not allow "[" or "]" characters, so the SIP-URI grammar = for IPV6 violates RFC 3986 grammar. SIP-URI =3D "sip:" [ userinfo ] hostport uri-parameters [ headers ] hostport =3D host [ ":" port ] host =3D hostname / IPv4address / IPv6reference hostname =3D *( domainlabel "." ) toplabel [ "." ] domainlabel =3D alphanum / alphanum *( alphanum / "-" ) alphanum toplabel =3D ALPHA / ALPHA *( alphanum / "-" ) alphanum IPv4address =3D 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6reference =3D "[" IPv6address "]" <-- *** violates RFC 3986 *** IPv6address =3D hexpart [ ":" IPv4address ] hexpart =3D hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq =3D hex4 *( ":" hex4) hex4 =3D 1*4HEXDIG port =3D 1*DIGIT These, though valid SIP URIs are not valid URIs: Has this already been addressed? Regards, Mike --_000_9B2A061A1137254BBE4F4B2CD843646A10B1FAA3F8mbx02citserve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cullen's reply killed or moved the discussion.

 

htt= p://www.ietf.org/mail-archive/web/sip/current/msg26385.html<= /span>

 

 

"WIth my AD hat on ...

 

If you want to update/discuss/change/abuse 3986, pr= obably the best place to to that would be on the APPS area list at apps-discuss@ietf.org<= /p>

 

It would be up to the Apps ADs, but I suspect that = change to the BNF suggested below is too significant a change to be done with an Errata.

 

Cullen"

 

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Szil= agyi, Mike
Sent: Monday, March 02, 2009 9:21 AM
To: SIP@ietf.org
Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 S= IP URI and RFC 3986

 

Could someone let me kno= w where this discussion has been moved?

 =

Regards,

Mike

 =

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Szil= agyi, Mike
Sent: Thursday, December 18, 2008 10:53 AM
To: SIP@ietf.org
Subject: [Sip] Question regarding conflicting grammar for IPV6 SIP U= RI and RFC 3986

 

RFC 3986 defines the following grammar for a URI:=

 

   URI           =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ]<= o:p>

 

   hier-part     = =3D "//" authority path-abempty

        =          / path-absolute

        =          / path-rootless

        =          / path-empty

 

A SIP URI falls into the ‘path-rootless’ rule:

 

   pa=
th-rootless =3D segment-nz *( "/" segment )


 



   se=
gment-nz    =3D 1*pchar



 



   pc=
har         =3D unreserved / pct-en=
coded / sub-delims / ":" / "@"



 



   pc=
t-encoded   =3D "%" HEXDIG HEXDIG
 
   unreser=
ved    =3D ALPHA / DIGIT / "-" / "." / &=
quot;_" / "~"



 



   su=
b-delims    =3D "!" / "$" / "&&=
quot; / "'" / "(" / ")"
   &n=
bsp;            =
; / "*" / "+" / "," / ";" / "=
=3D"



 



path-rootless does not allow “[“ or
“]” characters, so the SIP-URI grammar for IPV6 violates RFC 39=
86
grammar.



 



SIP-URI       =
;  
=3D  "sip:" [ userinfo ] hostport



        =
           
uri-parameters [ headers ]



 



hostport      &nbs=
p; 
=3D  host [ ":" port ]



host       &n=
bsp;    
=3D  hostname / IPv4address / IPv6reference



hostname      &nbs=
p; 
=3D  *( domainlabel "." ) toplabel [ "." ]



domainlabel      =3D&nb=
sp;
alphanum



        =
           
/ alphanum *( alphanum / "-" ) alphanum



toplabel      &nbs=
p; 
=3D  ALPHA / ALPHA *( alphanum / "-" ) alphanum



IPv4address    =3D  1*3DIGIT
"." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT



IPv6reference  =3D  "[&=
quot;
IPv6address "]"  <-- *** violates RFC 3986 ***=




IPv6address    =3D  hexpart =
[
":" IPv4address ]



hexpart       =
;
=3D  hexseq / hexseq "::" [ hexseq ] / "::" [ hexs=
eq ]



hexseq       =
 
=3D  hex4 *( ":" hex4)



hex4       &n=
bsp;  
=3D  1*4HEXDIG



port       &n=
bsp;  
=3D  1*DIGIT



 



 



These, though valid SIP URIs are not valid URIs:<=
/o:p>



 



   
<sip:[2001:db8::10]>



   
<sip:caller@[2001:db8::1]>



 



Has this already been addressed?



 



Regards,



Mike
--_000_9B2A061A1137254BBE4F4B2CD843646A10B1FAA3F8mbx02citserve_-- From john.elwell@siemens.com Mon Mar 2 09:24:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D1A3A6C17 for ; Mon, 2 Mar 2009 09:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgG4lfUU5l7I for ; Mon, 2 Mar 2009 09:24:13 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1BAD83A6BC5 for ; Mon, 2 Mar 2009 09:23:01 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KFW00J3O2Z21R@siemenscomms.co.uk> for SIP@ietf.org; Mon, 02 Mar 2009 17:23:26 +0000 (GMT) Date: Mon, 02 Mar 2009 17:23:25 +0000 From: "Elwell, John" In-reply-to: A <28B7C3AA2A7ABA4A841F11217ABE78D674A8D232@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" , SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001983DA0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] WGLC for draft-ietf-sip-ua-privacy Thread-Index: AcmQks5lzLuuTjaiSi+I84Fl0y/8ogKkUBrAAAlreBA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <28B7C3AA2A7ABA4A841F11217ABE78D674A08F78@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> A <28B7C3AA2A7ABA4A841F11217ABE78D674A8D232@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Cc: draft-ietf-sip-ua-privacy@tools.ietf.org, Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:24:17 -0000 1. In 4.1: "If revealing the domain name in the Contact header field is a concern, usage of a third-party GRUU server to obtain a temp-gruu that is irrelevant to users' domain, which is outside the scope of this document SHOULD be considered." "SHOULD be considered" is not a testable normative statement. It is not the user's domain that is outside the scope, but usage of a third-party GRUU server. The word "irrelevant" in inappropriate here. To take care of these concerns, I think it should say: "If revealing the domain name in the Contact header field is a concern, use of a third party GRUU server is a possible solution, but this is outside the scope of this document."=20 2. In 5.1.1: "For out-of-dialog request, anonymous URI MAY be set when anonymization is required." What is the purpose of this statement? I assume out-of-dialog does not include dialog-forming (which is covered earlier in the paragraph). For a completely out-of-dialog request such as a MESSAGE request, why would one include Contact? For REGISTER, one certainly cannot use an anonymous URI. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of DRAGE, Keith (Keith) > Sent: 02 March 2009 10:47 > To: SIP List > Cc: draft-ietf-sip-ua-privacy@tools.ietf.org; Dean Willis > Subject: Re: [Sip] WGLC for draft-ietf-sip-ua-privacy >=20 > (As WG cochair) >=20 > A reminder of the current WGLC on this document which completes today. >=20 > Please submit your comments as soon as possible. >=20 > If you are reviewing the document, and you consider there may=20 > be a delay in your comments appearing, then please send a=20 > mail to the chairs so they can ascertain whether more time is needed. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > > Behalf Of DRAGE, Keith (Keith) > > Sent: Tuesday, February 17, 2009 12:01 AM > > To: SIP List > > Cc: draft-ietf-sip-ua-privacy@tools.ietf.org; Dean Willis > > Subject: [Sip] WGLC for draft-ietf-sip-ua-privacy > >=20 > > (As WG cochair) > >=20 > > This mail is to initiate working group last call on=20 > > draft-ietf-sip-ua-privacy which may be found here: > >=20 > >=20 > http://tools.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-05.txt > >=20 > > Please provide comments to both the authors and to the SIP WG=20 > > list by Monday 2nd March 2009. > >=20 > > The intended status of the document is informational. > >=20 > > regards > >=20 > > Keith > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > Use sipping@ietf.org for new developments on the application of sip > >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From Bala_Neelakantan@Quintum.com Mon Mar 2 10:09:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C2F28C271 for ; Mon, 2 Mar 2009 10:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INMoPzxpFC+b for ; Mon, 2 Mar 2009 10:09:44 -0800 (PST) Received: from mx03.net.com (mx03.net.com [134.56.3.133]) by core3.amsl.com (Postfix) with ESMTP id E512728C20F for ; Mon, 2 Mar 2009 10:09:41 -0800 (PST) Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx03.net.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id n22I9rAU025427; Mon, 2 Mar 2009 10:09:54 -0800 (PST) Received: from fmt-ex01.net.com (fmt-ex01.net.com [134.56.112.251]) by mx02-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id n22I9qK2015835; Mon, 2 Mar 2009 10:09:52 -0800 (PST) Received: from fmt-ex07.net.com ([134.56.113.16]) by fmt-ex01.net.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 2 Mar 2009 10:16:04 -0800 Received: from fmt-qex01.quintum.com (134.56.116.12) by fmt-ex07.net.com (134.56.113.16) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 2 Mar 2009 10:09:52 -0800 Received: from fmt-qex01.quintum.com ([134.56.116.12]) by fmt-qex01.quintum.com ([134.56.116.12]) with mapi; Mon, 2 Mar 2009 10:09:52 -0800 From: Neelakantan Balasubramanian To: Mahesh , "sip@ietf.org" Date: Mon, 2 Mar 2009 10:09:49 -0800 Thread-Topic: [Sip] ACK response Thread-Index: Acma/exerQfoM1ddSlOCp7h+1RzBTgAY/mvQ Message-ID: <87278613D061664392F2161B99567B870EF2A4FA30@fmt-qex01.quintum.com> References: <001801c99afd$9c474690$650710ac@globaledgesoft.com> In-Reply-To: <001801c99afd$9c474690$650710ac@globaledgesoft.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-OriginalArrivalTime: 02 Mar 2009 18:16:04.0904 (UTC) FILETIME=[F3603A80:01C99B62] Subject: Re: [Sip] ACK response X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:09:45 -0000 Please read RFC 3261. The caller generates INVITE. The caller on receipt = of final response, generates ACK. Please direct questions like this on SIP implementers list Sip-implementors= @lists.cs.columbia.edu > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Mahesh > Sent: Monday, March 02, 2009 12:11 AM > To: sip@ietf.org > Subject: [Sip] ACK response > > Hi All, > what will happen if caller din't get ACK.whats the behaviour of caller. > > Regards > Mahesh > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From dean.willis@softarmor.com Mon Mar 2 12:04:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6552028C25A for ; Mon, 2 Mar 2009 12:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOFNXYP2cIuo for ; Mon, 2 Mar 2009 12:04:58 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 77F5E3A6A01 for ; Mon, 2 Mar 2009 12:04:58 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id n22K40Gc018290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Mar 2009 14:04:02 -0600 Message-Id: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> From: Dean Willis To: SIP WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 14:03:55 -0600 X-Mailer: Apple Mail (2.930.3) Cc: Cullen Jennings , Keith Drage Subject: [Sip] Connection Reuse draft to focus on TLS connections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:04:59 -0000 We intend to slightly rescope the Connection Reuse draft: http://tools.ietf.org/id/draft-ietf-sip-connect-reuse-12.txt Based on input from our ADs, the WG chairs and the editor of the have agreed to eliminate the part of the draft that discusses the implementation of reusing non-TLS connections. The stage for this is set in the abstract of the current draft, from which I quote: > From the security perspective, it is bad practice to reuse a single > connection for the TCP or SCTP transport between two peers, and this > document provides specific insights into why this is the case. As a > remedy, it suggests using two TCP connections (or two SCTP > associations), each opened pro-actively towards the recipient by the > sender. We may discuss at a later date the idea of developing a draft for connection reuse in the absence of TLS. I'm really not expecting anybody to object strongly to this approach, but am bringing this to the list to avoid surprises down the road. If you have major issues with doing it this way, please bring them up now. -- Dean Willis (as chair, ten years and counting . . .) From christer.holmberg@ericsson.com Mon Mar 2 12:12:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D103A6803 for ; Mon, 2 Mar 2009 12:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8iu9QdnzjK1 for ; Mon, 2 Mar 2009 12:12:30 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6C01F3A6C40 for ; Mon, 2 Mar 2009 12:12:30 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 421FB20649; Mon, 2 Mar 2009 21:12:55 +0100 (CET) X-AuditID: c1b4fb3c-af80ebb000001b43-f8-49ac3dc77c87 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 16FBF203DD; Mon, 2 Mar 2009 21:12:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 21:12:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 21:12:53 +0100 Message-ID: In-Reply-To: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connection Reuse draft to focus on TLS connections Thread-Index: AcmbckALQbZCb+TYT2aGuod3ve71bgAAM3gA References: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "SIP WG" X-OriginalArrivalTime: 02 Mar 2009 20:12:54.0989 (UTC) FILETIME=[45B64FD0:01C99B73] X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , Keith Drage Subject: Re: [Sip] Connection Reuse draft to focus on TLS connections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:12:33 -0000 Hi, Just a question: does this rescope affect chapter 8 (Overlap with connection reuse) of the keep draft (http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-keep-03.txt)? Regards, Christer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, March 02, 2009 10:04 PM To: SIP WG Cc: Cullen Jennings; Keith Drage Subject: [Sip] Connection Reuse draft to focus on TLS connections We intend to slightly rescope the Connection Reuse draft: http://tools.ietf.org/id/draft-ietf-sip-connect-reuse-12.txt Based on input from our ADs, the WG chairs and the editor of the have agreed to eliminate the part of the draft that discusses the implementation of reusing non-TLS connections. The stage for this is set in the abstract of the current draft, from which I quote: > From the security perspective, it is bad practice to reuse a single=20 > connection for the TCP or SCTP transport between two peers, and this=20 > document provides specific insights into why this is the case. As a=20 > remedy, it suggests using two TCP connections (or two SCTP=20 > associations), each opened pro-actively towards the recipient by the=20 > sender. We may discuss at a later date the idea of developing a draft for connection reuse in the absence of TLS. I'm really not expecting anybody to object strongly to this approach, but am bringing this to the list to avoid surprises down the road. If you have major issues with doing it this way, please bring them up now. -- Dean Willis (as chair, ten years and counting . . .) _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From rjsparks@nostrum.com Mon Mar 2 12:19:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFC33A683E for ; Mon, 2 Mar 2009 12:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+emh+t7rEHk for ; Mon, 2 Mar 2009 12:19:15 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id CF07228C22D for ; Mon, 2 Mar 2009 12:18:44 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-52-41.dllstx.fios.verizon.net [173.71.52.41]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n22KJ9pi081237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Mar 2009 14:19:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: SIP List Content-Type: multipart/alternative; boundary=Apple-Mail-57-19910779 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 14:19:08 -0600 References: <20090302143002.149F73A6821@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 173.71.52.41 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9061/Mon Mar 2 03:28:18 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-norm-ref-status-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:19:16 -0000 --Apple-Mail-57-19910779 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I split this out of the steps-to-draft document for separate tracking Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 2, 2009 8:30:02 AM CST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-sparks-sip-3261-norm-ref-status-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Status of Normative References in RFC3261 > Author(s) : R. Sparks > Filename : draft-sparks-sip-3261-norm-ref-status-00.txt > Pages : 6 > Date : 2009-03-02 > > This document captures the current status of the normative references > in RFC3261. It is intended to inform continuing discussions on how > to maintain the SIP protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-norm-ref-status-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-57-19910779 Content-Type: multipart/mixed; boundary=Apple-Mail-58-19910779 --Apple-Mail-58-19910779 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I split this out of the = steps-to-draft document for separate tracking

Begin = forwarded message:

Date: March 2, 2009 8:30:02 AM = CST
To: i-d-announce@ietf.org
Subject: = I-D = Action:draft-sparks-sip-3261-norm-ref-status-00.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

Title =           : Status of = Normative References in RFC3261
Author(s) =       : R. Sparks
Filename =        : = draft-sparks-sip-3261-norm-ref-status-00.txt
Pages =           : 6
Date =            : = 2009-03-02

This document captures the current status of the = normative references
in RFC3261.  It is intended to inform = continuing discussions on how
to maintain the SIP protocol.

A = URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-= norm-ref-status-00.txt

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

Below is = the data which will enable a MIME compliant mail = reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-58-19910779 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-03-02062600.I-D@ietf.org>

--Apple-Mail-58-19910779 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-58-19910779-- --Apple-Mail-57-19910779-- From rjsparks@nostrum.com Mon Mar 2 12:19:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AABCA28C21B for ; Mon, 2 Mar 2009 12:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxnV2Zlzz8Tx for ; Mon, 2 Mar 2009 12:19:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B609028C259 for ; Mon, 2 Mar 2009 12:19:03 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-52-41.dllstx.fios.verizon.net [173.71.52.41]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n22KJ9pj081237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Mar 2009 14:19:28 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> From: Robert Sparks To: SIP List Content-Type: multipart/alternative; boundary=Apple-Mail-59-19930078 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 14:19:27 -0600 References: <20090302143002.24E643A694C@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 173.71.52.41 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9061/Mon Mar 2 03:28:18 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:19:18 -0000 --Apple-Mail-59-19930078 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Also split out of steps-to-draft Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 2, 2009 8:30:02 AM CST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : RFC3261 Interop Statement > Author(s) : R. Sparks > Filename : draft-sparks-sip-3261-interop-statement-00.txt > Pages : 9 > Date : 2009-03-02 > > This document captures an outline of the interoperability statements > that will be collected to construct an interoperability report for > RFC 3261. The outline is stil under review and should not be treated > as complete, but will drive data collection at upcoming > interoperability events. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statement-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-59-19930078 Content-Type: multipart/mixed; boundary=Apple-Mail-60-19930079 --Apple-Mail-60-19930079 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Also split out of = steps-to-draft

Begin forwarded message:

Date: March 2, 2009 8:30:02 AM = CST
To: i-d-announce@ietf.org
Subject: = I-D = Action:draft-sparks-sip-3261-interop-statement-00.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

Title =           : RFC3261 = Interop Statement
Author(s) =       : R. Sparks
Filename =        : = draft-sparks-sip-3261-interop-statement-00.txt
Pages =           : 9
Date =            : = 2009-03-02

This document captures an outline of the = interoperability statements
that will be collected to construct an = interoperability report for
RFC 3261.  The outline is stil under = review and should not be treated
as complete, but will drive data = collection at upcoming
interoperability events.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-326= 1-interop-statement-00.txt

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

Below = is the data which will enable a MIME compliant mail = reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-60-19930079 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-03-02062606.I-D@ietf.org>

--Apple-Mail-60-19930079 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-60-19930079-- --Apple-Mail-59-19930078-- From vkg@alcatel-lucent.com Mon Mar 2 12:19:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BC63A659C for ; Mon, 2 Mar 2009 12:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ja0KE3h3brO for ; Mon, 2 Mar 2009 12:19:34 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 68F8C3A683E for ; Mon, 2 Mar 2009 12:19:32 -0800 (PST) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n22KJufu022417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 14:19:56 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n22KJu9D007284; Mon, 2 Mar 2009 14:19:56 -0600 (CST) Message-ID: <49AC3F6B.4030808@alcatel-lucent.com> Date: Mon, 02 Mar 2009 14:19:55 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg References: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> In-Reply-To: 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 Cc: SIP WG Subject: Re: [Sip] Connection Reuse draft to focus on TLS connections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:19:35 -0000 Christer Holmberg wrote: > Hi, > > Just a question: does this rescope affect chapter 8 (Overlap with > connection reuse) of the keep draft > (http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-keep-03.txt)? Christer: I believe the text you have in keep-03 stays as it is. When we start work on a new draft for connection oriented non-TLS transports, we may have to update that section with one more reference to the new draft. That should be the extent of impact on keep-03. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From rjsparks@nostrum.com Mon Mar 2 12:19:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1873628C112 for ; Mon, 2 Mar 2009 12:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVv+3cG5ZlUr for ; Mon, 2 Mar 2009 12:19:45 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7691528C259 for ; Mon, 2 Mar 2009 12:19:44 -0800 (PST) Received: from [192.168.2.2] (pool-173-71-52-41.dllstx.fios.verizon.net [173.71.52.41]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n22KJ9pk081237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Mar 2009 14:20:08 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <2F9C3E56-3810-450D-B700-DB9048349875@nostrum.com> From: Robert Sparks To: SIP List Content-Type: multipart/alternative; boundary=Apple-Mail-62-19971108 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 14:20:08 -0600 References: <20090302144501.AB1473A68B8@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 173.71.52.41 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9061/Mon Mar 2 03:28:18 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-invfix-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:19:46 -0000 --Apple-Mail-62-19971108 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit This got a fairly big touch due to better handling of transport error conditions. Please review this carefully. RjS Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 2, 2009 8:45:01 AM CST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-sparks-sip-invfix-03.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Correct transaction handling for 200 responses to > Session Initiation Protocol INVITE requests > Author(s) : R. Sparks > Filename : draft-sparks-sip-invfix-03.txt > Pages : 20 > Date : 2009-03-02 > > This document normatively updates RFC 3261, the Session Initiation > Protocol (SIP), to address an error in the specified handling of > success (200 class) responses to INVITE requests. Elements following > RFC 3261 exactly will misidentify retransmissions of the request as a > new, unassociated, request. The correction involves modifying the > INVITE transaction state machines. The correction also changes the > way responses that cannot be matched to an existing transaction are > handled to address a security risk. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-62-19971108 Content-Type: multipart/mixed; boundary=Apple-Mail-63-19971108 --Apple-Mail-63-19971108 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable This got a fairly big touch due = to better handling of transport error conditions. Please review this = carefully.

RjS

Begin = forwarded message:

Date: March 2, 2009 8:45:01 AM = CST
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-sparks-sip-invfix-03.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

Title =           : Correct = transaction handling for 200 responses to Session Initiation Protocol = INVITE requests
Author(s) =       : R. Sparks
Filename =        : = draft-sparks-sip-invfix-03.txt
Pages =           : = 20
= Date =            : = 2009-03-02

This document normatively updates RFC 3261, the = Session Initiation
Protocol (SIP), to address an error in the = specified handling of
success (200 class) responses to INVITE = requests.  Elements following
RFC 3261 exactly will misidentify = retransmissions of the request as a
new, unassociated, request. =  The correction involves modifying the
INVITE transaction state = machines.  The correction also changes the
way responses that = cannot be matched to an existing transaction are
handled to address a = security risk.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-03.txt
Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-63-19971108 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-03-02063639.I-D@ietf.org>

--Apple-Mail-63-19971108 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-63-19971108-- --Apple-Mail-62-19971108-- From HKaplan@acmepacket.com Mon Mar 2 12:58:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621953A67D7 for ; Mon, 2 Mar 2009 12:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vPhGkA0cJky for ; Mon, 2 Mar 2009 12:58:41 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E51C428C21A for ; Mon, 2 Mar 2009 12:58:21 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 2 Mar 2009 15:58:47 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Mar 2009 15:58:47 -0500 From: Hadriel Kaplan To: Dean Willis , SIP WG Date: Mon, 2 Mar 2009 15:58:45 -0500 Thread-Topic: [Sip] Connection Reuse draft to focus on TLS connections Thread-Index: AcmbclT+s2Yp68vjScKC9E9VshNl3AAAE6Zw Message-ID: References: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> In-Reply-To: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cullen Jennings , Keith Drage Subject: Re: [Sip] Connection Reuse draft to focus on TLS connections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 20:58:42 -0000 One should note it's not applicable to just "TLS" - it's only applicable to= mutual-TLS. I don't mean to sound negative, but really you might as well = limit it's applicability to IPv6 as well at this rate. :( Can this draft at least remove the statement in section 8.1 that the client= SHOULD NOT add an alias parameter to TCP/SCTP transports? There's actual= ly nothing wrong with adding one - it's the server side of the connection t= hat needs to not use/honor it based on its policy. (and if you think adding= one would be malicious, then trust me malicious devices will simply add on= e and ignore this draft's SHOULD NOT statement) All the parameter says is = effectively: "I am willing to accept requests on this connection I created,= if you wish to send them to me over it". -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Monday, March 02, 2009 3:04 PM > To: SIP WG > Cc: Cullen Jennings; Keith Drage > Subject: [Sip] Connection Reuse draft to focus on TLS connections > > > We intend to slightly rescope the Connection Reuse draft: > > http://tools.ietf.org/id/draft-ietf-sip-connect-reuse-12.txt > > Based on input from our ADs, the WG chairs and the editor of the have > agreed to eliminate the part of the draft that discusses the > implementation of reusing non-TLS connections. The stage for this is > set in the abstract of the current draft, from which I quote: > > > From the security perspective, it is bad practice to reuse a single > > connection for the TCP or SCTP transport between two peers, and this > > document provides specific insights into why this is the case. As a > > remedy, it suggests using two TCP connections (or two SCTP > > associations), each opened pro-actively towards the recipient by the > > sender. > > > We may discuss at a later date the idea of developing a draft for > connection reuse in the absence of TLS. > > I'm really not expecting anybody to object strongly to this approach, > but am bringing this to the list to avoid surprises down the road. If > you have major issues with doing it this way, please bring them up now. > > -- > Dean Willis (as chair, ten years and counting . . .) > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From HKaplan@acmepacket.com Mon Mar 2 13:11:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAED928C256 for ; Mon, 2 Mar 2009 13:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJal0zSm7TBM for ; Mon, 2 Mar 2009 13:11:50 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CD77228C0E3 for ; Mon, 2 Mar 2009 13:11:49 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 2 Mar 2009 16:12:14 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Mar 2009 16:12:14 -0500 From: Hadriel Kaplan To: Robert Sparks , SIP List Date: Mon, 2 Mar 2009 16:12:09 -0500 Thread-Topic: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt Thread-Index: AcmbdF5cEkqgyU8yS6ujQ9HccjaeDgABgYhA Message-ID: References: <20090302143002.24E643A694C@core3.amsl.com> <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> In-Reply-To: <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@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 Subject: Re: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:11:50 -0000 Nice list. Thanks for putting this together! I propose you delete " - Demonstrate successful exchange of S/MIME protecte= d entities". I further propose the answer to "Right now there is nothing covering sips:.= What do those statements need to look like?" is an empty line. And I propose the answer to "How do we make a statement that captures we've= found two implementations that discover their registrar through configurat= ion rather than using URI resolution." Is we don't need to - the real world= has done it for us. And I like your bullet point in the middle of the Application-level feature= s. :) -hadriel ________________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Rober= t Sparks Sent: Monday, March 02, 2009 3:19 PM To: SIP List Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.t= xt Also split out of steps-to-draft Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 2, 2009 8:30:02 AM CST To: i-d-announce@ietf.org Subject: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : RFC3261 Interop Statement Author(s) : R. Sparks Filename : draft-sparks-sip-3261-interop-statement-00.txt Pages : 9 Date : 2009-03-02 This document captures an outline of the interoperability statements that will be collected to construct an interoperability report for RFC 3261. The outline is stil under review and should not be treated as complete, but will drive data collection at upcoming interoperability events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statement= -00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From dworley@nortel.com Mon Mar 2 13:16:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC7428C26F for ; Mon, 2 Mar 2009 13:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMp-+2imc5jm for ; Mon, 2 Mar 2009 13:16:43 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 211BA28C268 for ; Mon, 2 Mar 2009 13:16:43 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n22LH6N19476; Mon, 2 Mar 2009 21:17:06 GMT Received: from [47.141.31.216] ([47.141.31.216]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 16:17:03 -0500 From: "Dale Worley" To: Mahesh In-Reply-To: <001801c99afd$9c474690$650710ac@globaledgesoft.com> References: <001801c99afd$9c474690$650710ac@globaledgesoft.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 02 Mar 2009 16:17:02 -0500 Message-Id: <1236028622.5885.71.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2009 21:17:04.0186 (UTC) FILETIME=[3C0329A0:01C99B7C] Cc: sip@ietf.org Subject: Re: [Sip] ACK response X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:16:44 -0000 On Mon, 2009-03-02 at 11:40 +0530, Mahesh wrote: > what will happen if caller din't get ACK.whats the behaviour of caller. See RFC 3261 section 17.2.1, especially figure 7. If the UAS does not receive an ACK, it re-sends the final response to the INVITE. If Timer H fires before an ACK arrives, the UAS deletes the dialog. Dale From vkg@alcatel-lucent.com Mon Mar 2 13:21:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A6C3A6855 for ; Mon, 2 Mar 2009 13:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6MIIVKE8qjW for ; Mon, 2 Mar 2009 13:21:29 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 1E9213A6849 for ; Mon, 2 Mar 2009 13:21:28 -0800 (PST) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n22LLpI0027920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 15:21:51 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n22LLoZv001472; Mon, 2 Mar 2009 15:21:51 -0600 (CST) Message-ID: <49AC4DED.7080004@alcatel-lucent.com> Date: Mon, 02 Mar 2009 15:21:49 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hadriel Kaplan References: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> In-Reply-To: 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 Cc: SIP WG Subject: Re: [Sip] Connection Reuse draft to focus on TLS connections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:21:30 -0000 Hadriel Kaplan wrote: > One should note it's not applicable to just "TLS" - it's only > applicable to mutual-TLS. I don't mean to sound negative, but really > you might as well limit it's applicability to IPv6 as well at this > rate. :( > > Can this draft at least remove the statement in section 8.1 that the > client SHOULD NOT add an alias parameter to TCP/SCTP transports? Hadriel: I have had discussions with the AD on TCP/SCTP connection reuse and their impact on the current TLS connection reuse draft. The AD is of the opinion that it will be hard to progress the current connect-reuse draft in IESG while allowing TCP/SCTP connection reuse in the big-I Internet. Obviously, the fact remains that people will use TCP connection reuse, whether or not this draft prohibits it or not. The question boils down to how to best move *this* work ahead (i.e., TLS connection reuse), and then deal with TCP connection reuse. The best way forward is to excise any text relating to TCP/SCTP connection reuse, and focus this draft on TLS only (the original motivation for the draft.) This allows us to get the TLS connect-reuse draft out (it has been pending now for four arduous, laborious, suspenseful, pondering, brutal, intemperate, and exacting years.) In parallel, right after the -00 deadline for IETF 74 is over, I will put out a new draft on TCP/SCTP connection reuse that allows reuse for these transports when certain assumptions are met. I have been assured by the AD that a milestone can be quickly added to SIP/DISPATCH/SIPCORE WG to allow the new work to progress expeditiously. Is that a workable solution for you? Please let me know. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From HKaplan@acmepacket.com Mon Mar 2 13:25:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7263A68BA for ; Mon, 2 Mar 2009 13:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzHyR0kQUvDB for ; Mon, 2 Mar 2009 13:25:49 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4D2673A690D for ; Mon, 2 Mar 2009 13:25:49 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 2 Mar 2009 16:26:14 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Mar 2009 16:26:14 -0500 From: Hadriel Kaplan To: "Vijay K. Gurbani" Date: Mon, 2 Mar 2009 16:26:07 -0500 Thread-Topic: [Sip] Connection Reuse draft to focus on TLS connections Thread-Index: AcmbfO9VSUDMhVbtTtqSS6LY4qNoMAAAD3WA Message-ID: References: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> <49AC4DED.7080004@alcatel-lucent.com> In-Reply-To: <49AC4DED.7080004@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP WG Subject: Re: [Sip] Connection Reuse draft to focus on TLS connections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:25:50 -0000 Ahhh, so you'd like to end your misery. That sounds fair. Ignore my comme= nt. -hadriel p.s. but you're a glutton for punishment if you submit another I-D for non-= TLS connect-reuse. ;) > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Monday, March 02, 2009 4:22 PM > To: Hadriel Kaplan > Cc: SIP WG > Subject: Re: [Sip] Connection Reuse draft to focus on TLS connections > > Hadriel Kaplan wrote: > > One should note it's not applicable to just "TLS" - it's only > > applicable to mutual-TLS. I don't mean to sound negative, but really > > you might as well limit it's applicability to IPv6 as well at this > > rate. :( > > > > Can this draft at least remove the statement in section 8.1 that the > > client SHOULD NOT add an alias parameter to TCP/SCTP transports? > > Hadriel: I have had discussions with the AD on TCP/SCTP connection > reuse and their impact on the current TLS connection reuse draft. > The AD is of the opinion that it will be hard to progress > the current connect-reuse draft in IESG while allowing TCP/SCTP > connection reuse in the big-I Internet. > > Obviously, the fact remains that people will use TCP connection > reuse, whether or not this draft prohibits it or not. The > question boils down to how to best move *this* work ahead > (i.e., TLS connection reuse), and then deal with TCP connection > reuse. > > The best way forward is to excise any text relating to TCP/SCTP > connection reuse, and focus this draft on TLS only (the original > motivation for the draft.) This allows us to get the TLS > connect-reuse draft out (it has been pending now for four > arduous, laborious, suspenseful, pondering, brutal, intemperate, > and exacting years.) > > In parallel, right after the -00 deadline for IETF 74 is over, > I will put out a new draft on TCP/SCTP connection reuse that > allows reuse for these transports when certain assumptions > are met. I have been assured by the AD that a milestone can > be quickly added to SIP/DISPATCH/SIPCORE WG to allow the new > work to progress expeditiously. > > Is that a workable solution for you? Please let me know. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ From vkg@alcatel-lucent.com Mon Mar 2 13:30:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AAAE3A6849 for ; Mon, 2 Mar 2009 13:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbrl9j2V6Ra2 for ; Mon, 2 Mar 2009 13:30:18 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 3115E3A690D for ; Mon, 2 Mar 2009 13:30:18 -0800 (PST) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n22LUfPx002565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 15:30:41 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n22LUf7R008748; Mon, 2 Mar 2009 15:30:41 -0600 (CST) Message-ID: <49AC5001.5050502@alcatel-lucent.com> Date: Mon, 02 Mar 2009 15:30:41 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hadriel Kaplan References: <7CDFD441-A190-4BC9-8BAA-7821A12FF4FF@softarmor.com> <49AC4DED.7080004@alcatel-lucent.com> In-Reply-To: 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 Cc: SIP WG Subject: Re: [Sip] Connection Reuse draft to focus on TLS connections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:30:19 -0000 Hadriel Kaplan wrote: > Ahhh, so you'd like to end your misery. That sounds fair. Ignore my > comment. Ending my connect-reuse induced misery is one part, yes. > -hadriel p.s. but you're a glutton for punishment if you submit > another I-D for non-TLS connect-reuse. ;) Aha, but I can have you co-edit the TCP/SCTP connect-reuse draft and make sure that the punishment is equitably shared between us ;-) But seriously, as long as the need to do TCP/SCTP connection reuse is there, I don't mind spending time doing that effort, with you or anyone else (in fact, I have an editor in mind for the new draft ... ;-) ) - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From lists@ohlmeier.org Mon Mar 2 14:29:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AF33A68CB for ; Mon, 2 Mar 2009 14:29:29 -0800 (PST) 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.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyOdeZXdGxnZ for ; Mon, 2 Mar 2009 14:29:27 -0800 (PST) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id BC36F3A6403 for ; Mon, 2 Mar 2009 14:29:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 920467F82; Mon, 2 Mar 2009 23:29:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-3EWdKBGtGh; Mon, 2 Mar 2009 23:29:52 +0100 (CET) Received: from Nils-MacBook-2.local (unknown [78.52.228.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bespin.rfc3261.net (Postfix) with ESMTPSA id 36A087F55; Mon, 2 Mar 2009 23:29:52 +0100 (CET) Message-ID: <49AC5DDF.2090705@ohlmeier.org> Date: Mon, 02 Mar 2009 23:29:51 +0100 From: Nils Ohlmeier User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Robert Sparks References: <20090302143002.24E643A694C@core3.amsl.com> <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> In-Reply-To: <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List Subject: Re: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 22:29:29 -0000 Hi Robert, would appreciate it if you could add to the "URI specific features" (or to the "Extensibility mechanism"?) from my interop experience at SIPit: - Demonstrate the correct usage of URIs with known and unknown parameters in Route URIs and Request-URI Cheers Nils Am 02.03.2009 21:19 Uhr, schrieb Robert Sparks: > Also split out of steps-to-draft > > Begin forwarded message: > >> *From: *Internet-Drafts@ietf.org >> *Date: *March 2, 2009 8:30:02 AM CST >> *To: *i-d-announce@ietf.org >> *Subject: **I-D Action:draft-sparks-sip-3261-interop-statement-00.txt * >> *Reply-To: *internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : RFC3261 Interop Statement >> Author(s) : R. Sparks >> Filename : draft-sparks-sip-3261-interop-statement-00.txt >> Pages : 9 >> Date : 2009-03-02 >> >> This document captures an outline of the interoperability statements >> that will be collected to construct an interoperability report for >> RFC 3261. The outline is stil under review and should not be treated >> as complete, but will drive data collection at upcoming >> interoperability events. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statement-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > > ------------------------------------------------------------------------ > >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From dworley@nortel.com Mon Mar 2 15:44:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F9728C0FC for ; Mon, 2 Mar 2009 15:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8vMr7kWon4E for ; Mon, 2 Mar 2009 15:44:54 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 07CD428C0D6 for ; Mon, 2 Mar 2009 15:44:52 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n22Nj4G10413 for ; Mon, 2 Mar 2009 23:45:04 GMT Received: from [47.141.31.216] ([47.141.31.216]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 18:45:16 -0500 From: "Dale Worley" To: "DRAGE, Keith (Keith)" In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A8CB09@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <28B7C3AA2A7ABA4A841F11217ABE78D674A8CB09@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 02 Mar 2009 18:45:14 -0500 Message-Id: <1236037514.5885.98.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2009 23:45:16.0632 (UTC) FILETIME=[F052BD80:01C99B90] Cc: "sip@ietf.org" Subject: Re: [Sip] FW: Initial Version I-D Submission Deadline Extended to March 4, 2009 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 23:44:55 -0000 Although please note that the Internet Draft Submission Tool does not know that the deadline has been extended. Dale From christer.holmberg@ericsson.com Mon Mar 2 22:23:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7E728C0F1 for ; Mon, 2 Mar 2009 22:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.815 X-Spam-Level: X-Spam-Status: No, score=-5.815 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyYuJPnYL15k for ; Mon, 2 Mar 2009 22:23:29 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D8AF33A69D7 for ; Mon, 2 Mar 2009 22:23:28 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5DD57212B8; Tue, 3 Mar 2009 07:23:29 +0100 (CET) X-AuditID: c1b4fb3e-ab098bb0000023da-0d-49accce1ea16 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F00D2006D; Tue, 3 Mar 2009 07:23:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 07:23:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99BC8.90F8A128" Date: Tue, 3 Mar 2009 07:23:27 +0100 Message-ID: In-Reply-To: <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt Thread-Index: AcmbdFWmjsXku25lStmElvSmwsKrZgAB+5dA References: <20090302143002.24E643A694C@core3.amsl.com> <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" , "SIP List" X-OriginalArrivalTime: 03 Mar 2009 06:23:28.0903 (UTC) FILETIME=[9139F970:01C99BC8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 06:23:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99BC8.90F8A128 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 A couple of questions: =20 1. The draft says "Demonstrate successful offer/answer exchange". Offer/answer is one of the biggest interop issues, so I think we would need to be a little more specific than that. We should probably have a complete separate interop-statement on offer/answer... =20 2. For the things that shall be demonstrated, should there be references to where the correct behavior is specified? It's difficult to demonstrate correct behavior if you don't know what that correct behavior is :) =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Monday, March 02, 2009 10:19 PM To: SIP List Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt Also split out of steps-to-draft Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 2, 2009 8:30:02 AM CST To: i-d-announce@ietf.org Subject: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. =09 Title : RFC3261 Interop Statement Author(s) : R. Sparks Filename : draft-sparks-sip-3261-interop-statement-00.txt Pages : 9 Date : 2009-03-02 =09 This document captures an outline of the interoperability statements that will be collected to construct an interoperability report for RFC 3261. The outline is stil under review and should not be treated as complete, but will drive data collection at upcoming interoperability events. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statem ent-00.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 ------_=_NextPart_001_01C99BC8.90F8A128 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A couple of questions:
 
1. The draft says "Demonstrate successful = offer/answer=20 exchange". Offer/answer is one of the biggest interop issues, so I think = we=20 would need to be a little more specific than that. We should probably = have a=20 complete separate interop-statement on = offer/answer...
 
2. For the things that shall be demonstrated, = should there=20 be references to where the correct behavior is specified? It's difficult = to=20 demonstrate correct behavior if you don't know what that correct = behavior is=20 :)
 
Regards,
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Robert = Sparks
Sent:=20 Monday, March 02, 2009 10:19 PM
To: SIP = List
Subject: [Sip]=20 Fwd: I-D=20 Action:draft-sparks-sip-3261-interop-statement-00.txt

Also split out of steps-to-draft

Begin forwarded message:

From: Internet-Drafts@ietf.org
Date: March 2, 2009 = 8:30:02 AM=20 CST
To: i-d-announce@ietf.org
Subject: I-D=20 Action:draft-sparks-sip-3261-interop-statement-00.txt 
Reply-To: = internet-drafts@ietf.org

A New Internet-Draft is available from the on-line = Internet-Drafts=20 directories.

Title=20           : RFC3261 = Interop=20 Statement
Author(s)=20       : R. Sparks
Filename=20        :=20 draft-sparks-sip-3261-interop-statement-00.txt
Pages=20           : = 9
Date=20            :=20 2009-03-02

This document captures an outline of the = interoperability=20 statements
that will be collected to construct an interoperability = report=20 for
RFC 3261.  The outline is stil under review and should not = be=20 treated
as complete, but will drive data collection at=20 upcoming
interoperability events.

A URL for this = Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-3= 261-interop-statement-00.txt

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

Below is the data = which will=20 enable a MIME compliant mail reader
implementation to automatically = retrieve the ASCII version of=20 the
Internet-Draft.
------_=_NextPart_001_01C99BC8.90F8A128-- From dean.willis@softarmor.com Mon Mar 2 23:59:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640273A6966 for ; Mon, 2 Mar 2009 23:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXKcSpHtWSgO for ; Mon, 2 Mar 2009 23:59:04 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 22DA43A69C4 for ; Mon, 2 Mar 2009 23:59:02 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n237xLio004376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Mar 2009 01:59:22 -0600 Message-Id: From: Dean Willis To: SIP WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 01:59:15 -0600 References: X-Mailer: Apple Mail (2.930.3) Cc: Keith Drage , Christer Holmberg Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 07:59:06 -0000 We didn't get any real answers due to a bit of confusion between this and keepalive. So, let's ask the question again. Is 199 ready for WGLC? -- dean On Feb 19, 2009, at 5:12 AM, Christer Holmberg wrote: > > Hi, > > I've submitted a new version of draft-ietf-sip-199. I have done > changes and updates based on feedback and discussions (please let me > know if you think I've forgotten something), and I've also added > text to the security chapter. > > I propose that we start the WGLC process for the draft. > > The draft can also be found at: > > http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-05.txt > > Regards, > > Christer > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From munakata.mayumi@lab.ntt.co.jp Tue Mar 3 00:13:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7AC28C0F2 for ; Tue, 3 Mar 2009 00:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNayT5Bs2mH1 for ; Tue, 3 Mar 2009 00:13:10 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 975FB3A6857 for ; Tue, 3 Mar 2009 00:12:48 -0800 (PST) Received: (qmail 14943 invoked by alias); 3 Mar 2009 08:13:14 -0000 Received: from gwall1.bb.ntt-at.co.jp (192.168.5.201) by subgate.bb.ntt-at.co.jp with SMTP; 3 Mar 2009 08:13:14 -0000 Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id n238ChKf006100; Tue, 3 Mar 2009 17:12:43 +0900 Received: from suez.bb.ntt-at.co.jp [192.168.2.9] by gwall1.bb.ntt-at.co.jp with ESMTP id TAA06099; Tue, 3 Mar 2009 17:12:43 +0900 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id n238Cgfs009889; Tue, 3 Mar 2009 17:12:42 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n238CfQj012708; Tue, 3 Mar 2009 17:12:41 +0900 (JST) (envelope-from munakata.mayumi@lab.ntt.co.jp) Received: from [127.0.0.1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 6AA8220807E; Tue, 3 Mar 2009 17:12:41 +0900 (JST) Message-ID: <49ACE672.5050309@lab.ntt.co.jp> Date: Tue, 03 Mar 2009 17:12:34 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Elwell, John" References: <28B7C3AA2A7ABA4A841F11217ABE78D674A08F78@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> A <28B7C3AA2A7ABA4A841F11217ABE78D674A8D232@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D001983DA0@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001983DA0@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , draft-ietf-sip-ua-privacy@tools.ietf.org, "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 08:13:11 -0000 Hi John, Thank you for the comments. See inline. > 1. In 4.1: > "If revealing the domain name in the > Contact header field is a concern, usage of a third-party GRUU server > to obtain a temp-gruu that is irrelevant to users' domain, which is > outside the scope of this document SHOULD be considered." > "SHOULD be considered" is not a testable normative statement. It is not > the user's domain that is outside the scope, but usage of a third-party > GRUU server. The word "irrelevant" in inappropriate here. To take care > of these concerns, I think it should say: > "If revealing the domain name in the Contact header field is a concern, > use of a third party GRUU server is a possible solution, but this is > outside the scope of this document." I agree and will replace the text with the one you proposed. > > 2. In 5.1.1: > "For out-of-dialog > request, anonymous URI MAY be set when anonymization is required." > What is the purpose of this statement? I assume out-of-dialog does not > include dialog-forming (which is covered earlier in the paragraph). For > a completely out-of-dialog request such as a MESSAGE request, why would > one include Contact? For REGISTER, one certainly cannot use an anonymous > URI. The out-of-dialog request indeed meant the MESSAGE request. I checked the RFC and found that MESSAGE requests don't include the Contact header as you pointed out. I will delete the sentence. Thank you! Mayumi > > John From john.elwell@siemens.com Tue Mar 3 02:23:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2773A6C20 for ; Tue, 3 Mar 2009 02:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss1r0+J8udmq for ; Tue, 3 Mar 2009 02:23:41 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D744728C28A for ; Tue, 3 Mar 2009 02:22:55 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KFX0096WE6RRX@siemenscomms.co.uk> for sip@ietf.org; Tue, 03 Mar 2009 10:23:19 +0000 (GMT) Date: Tue, 03 Mar 2009 10:23:22 +0000 From: "Elwell, John" In-reply-to: A To: Christer Holmberg , Robert Sparks , SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001983F83@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C99BEA.104C2D4B" Thread-Topic: [Sip] Fwd: I-DAction:draft-sparks-sip-3261-interop-statement-00.txt Thread-Index: AcmbdFWmjsXku25lStmElvSmwsKrZgAB+5dAABtrSSA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20090302143002.24E643A694C@core3.amsl.com> <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> A Subject: Re: [Sip] Fwd: I-DAction:draft-sparks-sip-3261-interop-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 10:23:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99BEA.104C2D4B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 03 March 2009 06:23 To: Robert Sparks; SIP List Subject: Re: [Sip] Fwd: I-DAction:draft-sparks-sip-3261-interop-statement-00.txt =09 =09 Hi, =20 A couple of questions: =20 1. The draft says "Demonstrate successful offer/answer exchange". Offer/answer is one of the biggest interop issues, so I think we would need to be a little more specific than that. We should probably have a complete separate interop-statement on offer/answer... [JRE] Yes, I agree with this. I guess we need to draw a line between SIP and SDP, but I think we should try to cover RFC 3264 aspects to a reasonable degree. =20 John =20 =20 2. For the things that shall be demonstrated, should there be references to where the correct behavior is specified? It's difficult to demonstrate correct behavior if you don't know what that correct behavior is :) =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Monday, March 02, 2009 10:19 PM To: SIP List Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt =09 =09 Also split out of steps-to-draft Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 2, 2009 8:30:02 AM CST To: i-d-announce@ietf.org Subject: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. =09 Title : RFC3261 Interop Statement Author(s) : R. Sparks Filename : draft-sparks-sip-3261-interop-statement-00.txt Pages : 9 Date : 2009-03-02 =09 This document captures an outline of the interoperability statements that will be collected to construct an interoperability report for RFC 3261. The outline is stil under review and should not be treated as complete, but will drive data collection at upcoming interoperability events. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statem ent-00.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 ------_=_NextPart_001_01C99BEA.104C2D4B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: 03 March 2009 06:23
To: Robert = Sparks; SIP=20 List
Subject: Re: [Sip] Fwd:=20 = I-DAction:draft-sparks-sip-3261-interop-statement-00.txt

Hi,
 
A couple of questions:
 
1. The draft says "Demonstrate successful = offer/answer=20 exchange". Offer/answer is one of the biggest interop issues, so I = think we=20 would need to be a little more specific than that. We should probably = have a=20 complete separate interop-statement on offer/answer...
[JRE] Yes, I agree=20 with this. I guess we need to draw a line between SIP and SDP, but I = think we=20 should try to cover RFC 3264 aspects to a reasonable=20 degree.
 
John
 
 
2. For the things that shall be demonstrated, = should=20 there be references to where the correct behavior is specified? It's = difficult=20 to demonstrate correct behavior if you don't know what that correct = behavior=20 is :)
 
Regards,
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Robert=20 Sparks
Sent: Monday, March 02, 2009 10:19 PM
To: = SIP=20 List
Subject: [Sip] Fwd: I-D=20 = Action:draft-sparks-sip-3261-interop-statement-00.txt

Also split out of steps-to-draft

Begin forwarded message:

From: Internet-Drafts@ietf.org
Date: March 2, = 2009 8:30:02 AM=20 CST
To: i-d-announce@ietf.org
Subject: = I-D=20 Action:draft-sparks-sip-3261-interop-statement-00.txt 
Reply-To: = internet-drafts@ietf.org

A New Internet-Draft is available from the on-line = Internet-Drafts=20 directories.

Title=20           : = RFC3261=20 Interop Statement
Author(s)=20       : R. Sparks
Filename=20        :=20 draft-sparks-sip-3261-interop-statement-00.txt
Pages=20           : = 9
Date=20            :=20 2009-03-02

This document captures an outline of the = interoperability=20 statements
that will be collected to construct an = interoperability report=20 for
RFC 3261.  The outline is stil under review and should = not be=20 treated
as complete, but will drive data collection at=20 upcoming
interoperability events.

A URL for this = Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-3= 261-interop-statement-00.txt

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

Below is the data = which=20 will enable a MIME compliant mail reader
implementation to = automatically=20 retrieve the ASCII version of=20 = the
Internet-Draft.
------_=_NextPart_001_01C99BEA.104C2D4B-- From christer.holmberg@ericsson.com Tue Mar 3 04:58:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E997B28C27A for ; Tue, 3 Mar 2009 04:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.842 X-Spam-Level: X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3MIjZ-5gyUa for ; Tue, 3 Mar 2009 04:58:10 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E81253A6C42 for ; Tue, 3 Mar 2009 04:57:50 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B0DEC20657; Tue, 3 Mar 2009 13:58:16 +0100 (CET) X-AuditID: c1b4fb3c-ab005bb000001b43-9b-49ad2968e7c7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A14EF207BC; Tue, 3 Mar 2009 13:58:16 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 13:58:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Mar 2009 13:58:14 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version (-05) of the 199 draft - ready for WGLC? Thread-Index: Acmb1f1GnD/VM+7fQn6irRO8zvR9RQAKZoBg References: From: "Christer Holmberg" To: "Dean Willis" , "SIP WG" X-OriginalArrivalTime: 03 Mar 2009 12:58:16.0490 (UTC) FILETIME=[B820E8A0:01C99BFF] X-Brightmail-Tracker: AAAAAA== Cc: Keith Drage Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 12:58:11 -0000 Please note that the latest version is -06. Regards, Christer=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 3. maaliskuuta 2009 9:59 > To: SIP WG > Cc: Keith Drage; Christer Holmberg > Subject: Re: [Sip] New version (-05) of the 199 draft - ready=20 > for WGLC? >=20 >=20 > We didn't get any real answers due to a bit of confusion=20 > between this and keepalive. So, let's ask the question again. >=20 > Is 199 ready for WGLC? >=20 > -- > dean >=20 >=20 > On Feb 19, 2009, at 5:12 AM, Christer Holmberg wrote: >=20 > > > > Hi, > > > > I've submitted a new version of draft-ietf-sip-199. I have done=20 > > changes and updates based on feedback and discussions=20 > (please let me=20 > > know if you think I've forgotten something), and I've also=20 > added text=20 > > to the security chapter. > > > > I propose that we start the WGLC process for the draft. > > > > The draft can also be found at: > > > > http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-05.txt > > > > Regards, > > > > Christer > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 From brett@broadsoft.com Tue Mar 3 06:10:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB743A6966 for ; Tue, 3 Mar 2009 06:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg-4lCG2Q5W2 for ; Tue, 3 Mar 2009 06:10:35 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id CB48F3A69F0 for ; Tue, 3 Mar 2009 06:10:35 -0800 (PST) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 3 Mar 2009 06:10:56 -0800 From: Brett Tate To: Dean Willis , SIP WG Date: Tue, 3 Mar 2009 06:10:56 -0800 Thread-Topic: [Sip] New version (-05) of the 199 draft - ready for WGLC? Thread-Index: Acmb1gPsp9sqPxRsScKti9H3c4XsNAAMzzVg Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10B4A04426@mbx02.citservers.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Keith Drage , Christer Holmberg Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 14:10:36 -0000 Yes; I think draft-ietf-sip-199-06 is ready for WGLC. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Tuesday, March 03, 2009 2:59 AM > To: SIP WG > Cc: Keith Drage; Christer Holmberg > Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? >=20 >=20 > We didn't get any real answers due to a bit of confusion between this > and keepalive. So, let's ask the question again. >=20 > Is 199 ready for WGLC? >=20 > -- > dean From drage@alcatel-lucent.com Tue Mar 3 06:59:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2923B3A6948 for ; Tue, 3 Mar 2009 06:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iT0P8tQflEm for ; Tue, 3 Mar 2009 06:59:26 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 036843A6929 for ; Tue, 3 Mar 2009 06:59:24 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n23Exfnu027911 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Mar 2009 15:59:43 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 3 Mar 2009 15:59:41 +0100 From: "DRAGE, Keith (Keith)" To: Brett Tate , SIP IETF Date: Tue, 3 Mar 2009 15:59:40 +0100 Thread-Topic: WGLC on draft-ietf-sip-info-events Thread-Index: AcmQad8/1+QfM4TFQBavCWEg2uC7xAKum/JgAAR7jxAAFprsUA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674AD4D71@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <9B2A061A1137254BBE4F4B2CD843646A10B1FAA3C1@mbx02.citservers.local> In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A10B1FAA3C1@mbx02.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "hkaplan@acmepacket.com" , "christer.holmberg@ericsson.com" Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 14:59:27 -0000 Frequently the editor's wait until the end of the WGLC before processing th= e comments, so I am sure that it has not been forgotten. It does have the advantage of making sure that we do not swap and change wh= en we get conflicting comments. regards Keith=20 > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com]=20 > Sent: Monday, March 02, 2009 1:19 PM > To: DRAGE, Keith (Keith); SIP IETF > Cc: hkaplan@acmepacket.com; christer.holmberg@ericsson.com;=20 > eburger@standardstrack.com > Subject: RE: WGLC on draft-ietf-sip-info-events >=20 > > A reminder of the current WGLC on this document, which completes=20 > > Wednesday. > >=20 > > Please submit your comments as soon as possible. > >=20 > > If you are reviewing the document, and you consider there may be a=20 > > delay in your comments appearing, then please send a mail to the=20 > > chairs so they can ascertain whether more time is needed. >=20 > I haven't received a reply concerning my February 16=20 > (archived on 17) email: "draft-ietf-sip-info-events-03:=20 > comments and questions". Thus I'm not sure if I will have=20 > follow-up comments based upon the reply. >=20 > http://www.ietf.org/mail-archive/web/sip/current/msg26621.html >=20 > The following is a snapshot of my questions and comments in=20 > case the authors did not see my prior email. >=20 > Thanks, > Brett >=20 > ---- >=20 > Section 3.1 paragraph 1: Concerning "MUST advertise" and=20 > "provisional 1xx", please clarify that the "MUST advertise"=20 > is not applicable to the 100 response. Does the "MUST=20 > advertise" and "provisional 1xx" apply to all (first and=20 > subsequent within dialog) INVITE non 101-199 (intentionally=20 > indicated 199)? Concerning ACK for initial INVITE's 2xx,=20 > does the "MUST advertise" always apply? >=20 > Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1=20 > indicates "session parameters" and sentence 2 indicates=20 > "dialog parameters" concerning Info Package negotiation, I'm=20 > not sure when the negotiation/renegotiation occurs. Does it=20 > follow SDP offer/answer rules or something else; if something=20 > else, what? I have the same question concerning "dialog=20 > refresh" text discussed later within the same section since=20 > incorrect interpretations might trigger deactivation. >=20 > Section 4.3: When sending a 489, it indicates "MUST terminate=20 > the INVITE dialog". The "MUST terminate" seems severe even=20 > if all the negotiation race conditions are adequately=20 > addressed. The mentioned "protocol failure" reason seems=20 > contrary to the "strictly send and lenient receive" mantra. >=20 > Section 5.1 Table 1: The usage of "g" seems potentially=20 > outdated or incorrectly reference since discussed within RFC=20 > 2543 instead of RFC 3261. The same applies to usage Via row=20 > concerning "(2)". >=20 > Section 5.2.2: The "general-header" reference is outdated or=20 > incorrectly reference since defined within RFC 2543 instead=20 > of RFC 3261. RFC 3261 uses "Message-Header". >=20 > Section 7.7 paragraph 2: The following potentially could be=20 > reworded since it is okay to return failure responses (401,=20 > 503, 500, ...) even when overlapping occurs: "in the event a=20 > UAC issues overlapping INFO requests for an Info Package, the=20 > UAS MUST NOT return an error response". >=20 > Section 8: Why specifically defining and using "nil"? I'm=20 > mainly just curious of the benefit over not having defined=20 > "nil" for similar use within the Supported header. >=20 > = From vkg@alcatel-lucent.com Tue Mar 3 07:02:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0223A6AA5 for ; Tue, 3 Mar 2009 07:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mblLuSUfwjbr for ; Tue, 3 Mar 2009 07:02:02 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 7FAEE3A6948 for ; Tue, 3 Mar 2009 07:02:02 -0800 (PST) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n23F2PbR002466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 09:02:26 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n23F2PKP017405; Tue, 3 Mar 2009 09:02:25 -0600 (CST) Message-ID: <49AD4681.8090403@alcatel-lucent.com> Date: Tue, 03 Mar 2009 09:02:25 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: SIP WG , Christer Holmberg Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:02:03 -0000 Dean Willis wrote: > We didn't get any real answers due to a bit of confusion between this > and keepalive. So, let's ask the question again. > > Is 199 ready for WGLC? Yes; it is well written (I had looked at a much earlier version and just re-read -06.) One question for Christer: - Does 199 carry a message/sipfrag MIME type that conveys the nature of the final non-2xx response? This may have been discussed in the past, and if so, please let me know. I do note that rfc3420 is specified in the draft as a normative reference, but it is not referred to anywhere in the body of the draft. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From john.elwell@siemens.com Tue Mar 3 08:46:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD513A679C for ; Tue, 3 Mar 2009 08:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0OA7syeCGN5 for ; Tue, 3 Mar 2009 08:46:14 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id C01213A67D6 for ; Tue, 3 Mar 2009 08:46:13 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KFX0098HVXRMG@siemenscomms.co.uk> for sip@ietf.org; Tue, 03 Mar 2009 16:46:39 +0000 (GMT) Date: Tue, 03 Mar 2009 16:46:39 +0000 From: "Elwell, John" To: SIP List , Cullen Jennings , Jon Peterson Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001984302@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Seeking consensus on draft-elwell-sip-e2e-identity-important Thread-Index: AcmcH5+5Xxh3VXbTSpu8lr6IdUjryQ== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:46:15 -0000 Draft 03: http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 includes for the first time an analysis of changes to SIP requests by B2BUAs (section 8). Also the Conclusions (section 9) have been extended. I and a number of people who have assisted in revising this draft would like to seek consensus on a number of the points. We aim to ask these questions in San Francisco, but obviously it would help to get opinions from the list in advance. 1. Tolerance to changes of certain elements as a SIP request is forwarded through intermediate domains. Section 8 analyses a number of elements of SIP messages that are signed by the present RFC 4474 solution to end-to-end (or near end-to-end) authenticated identification. For some elements it claims that any solution for end-to-end authenticated identification needs to be tolerant of changes by intermediate domains, since there appear to be valid reasons why B2BUAs (including but not limited to SBCs) change these elements. Picking on some of these: A) Is there agreement that a solution needs to be tolerant of changes to IP addresses and ports in c- and m-lines in SDP? In other words, that intermediate domains can legitimately modify these fields (e.g., for media steering) and a solution is needed for end-to-end authenticated identification in such circumstances? B) Is there agreement that a solution needs to be tolerant of changes to Contact (addr-spec), Call-Id (call-id) and CSeq (digit) header fields? In other words, that intermediate domains can legitimately modify these fields (e.g., for topology hiding) and a solution is needed for end-to-end authenticated identification in such circumstances? C) Is there agreement that a solution does not need to be tolerant of changes to the addr-spec of From and To header fields? In other words, that intermediate domains should not modify these fields and can expect to break end-to-end authenticated identification if they do so? 2. Are people in broad agreement with the conclusions in section 9 concerning the importance of end-to-end identification and in particular end-to-end authenticated identification? John From rjsparks@nostrum.com Tue Mar 3 08:51:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4CE3A6911 for ; Tue, 3 Mar 2009 08:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEeuYcTzTydy for ; Tue, 3 Mar 2009 08:51:11 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 42DAD3A6A16 for ; Tue, 3 Mar 2009 08:51:09 -0800 (PST) Received: from dn3-232.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 n23GpScW084204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Mar 2009 10:51:35 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <2ADC40A5-09A7-48AE-BA21-386697E80010@nostrum.com> From: Robert Sparks To: SIP List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 10:51:31 -0600 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9065/Tue Mar 3 04:43:41 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] Registration for SIPit 24 is open X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:51:12 -0000 Registration for SIPit 24 is open! SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan hosted by JPNIC and NICT. Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/ From christer.holmberg@ericsson.com Tue Mar 3 09:07:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC8728C2D7 for ; Tue, 3 Mar 2009 09:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdvx1YHrBkbE for ; Tue, 3 Mar 2009 09:07:24 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2783528C2D6 for ; Tue, 3 Mar 2009 09:07:24 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 52F3B21F50; Tue, 3 Mar 2009 18:07:50 +0100 (CET) X-AuditID: c1b4fb3c-ad009bb000001b43-27-49ad63e64543 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3CFDB2072C; Tue, 3 Mar 2009 18:07:50 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 18:07:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Mar 2009 18:07:49 +0100 Message-ID: In-Reply-To: <49AD4681.8090403@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version (-05) of the 199 draft - ready for WGLC? Thread-Index: AcmcERVZ34WPvYepReikTSdxzxhlcQAEUQrg References: <49AD4681.8090403@alcatel-lucent.com> From: "Christer Holmberg" To: "Vijay K. Gurbani" , "Dean Willis" X-OriginalArrivalTime: 03 Mar 2009 17:07:50.0114 (UTC) FILETIME=[951A9C20:01C99C22] X-Brightmail-Tracker: AAAAAA== Cc: SIP WG Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:07:25 -0000 Hi Vijay,=20 >One question for Christer: > >- Does 199 carry a message/sipfrag MIME type that conveys the > nature of the final non-2xx response? This may have been > discussed in the past, and if so, please let me know. I > do note that rfc3420 is specified in the draft as a normative > reference, but it is not referred to anywhere in the body > of the draft. We discussed it quite much, and the outcome was a compromise: we don't say anything :) So, if someone wants to carry message/sipfrag in the 199 it is allowed, but the base 199 draft does not require it. Regards, Christer From BPenfield@acmepacket.com Tue Mar 3 09:11:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEF83A679C for ; Tue, 3 Mar 2009 09:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHPAkdgJfztT for ; Tue, 3 Mar 2009 09:11:21 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 793BC3A6911 for ; Tue, 3 Mar 2009 09:11:21 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 3 Mar 2009 12:11:47 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 3 Mar 2009 12:11:48 -0500 From: Bob Penfield To: "DRAGE, Keith (Keith)" , SIP IETF Date: Tue, 3 Mar 2009 12:11:46 -0500 Thread-Topic: WGLC on draft-ietf-sip-info-events Thread-Index: AcmQad8/1+QfM4TFQBavCWEg2uC7xAKum/JgAD+YguA= Message-ID: References: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:11:22 -0000 Here are some comments on the INFO draft: Section 2 says: Each UA enumerates which Info Packages it can receive. If the far end indicates it can receive a package offered by the near end, the near end can send INFO methods containing the payload for that package. "offered" needs to changed to "supported" since an INFO sender does not indicate what packages it can send. Section 3 is called "Info Package Negotiation", but since we removed Send-Info, it is not a negotiation since there is no feedback from the peer UA. It is simply a declaration of receive capability. At first read, I was totally confused by section 3.1 because I was expecting some actual negotiation given the above statement in Section 2. There are a few other places in the document that mentions "negotiation" that also might need to be changed. I think the usage of UAC/UAS terminology in Section 3.1 is still confusing. I would prefer to see something like: A UA supporting this document MUST advertise the set of Info Packages it is willing to receive in Recv-Info header(s) in all "INVITE dialog usage" requests and responses (101-199 and 2xx only) for dialog establishment or target refresh. This includes INVITE, UPDATE, PRACK and ACK and their non-failure responses. A UA MUST NOT send INFO requests for a given INFO package until the UA has received an "INVITE dialog usage" request or response (for dialog establishment or target refresh) with a Recv-Info header listing the given Info Package. A UA MUST cease sending INFO requests for a given INFO package when the UA receives an "INVITE dialog usage" request or response (for dialog establishment or target refresh) that does not contain a Recv-Info header listing the given Info Package. Section 3.1 - "the target UA may not send form package P" s/form/from/ Section 3.1 - "... the other UA in the dial will assume the ..." s/dial/dialog/ Section 3.1 - "server MAY terminate the session with a CANCEL or BYE" When the "server" is the UAS of the request, CANCEL is not appropriate, and BYE would not be appropriate if it is an initial INVITE. In this case, the request would need to be rejected. When the "server" is the UAC, I don't think CANCEL is appropriate since it is the far-end UA of a specific dialog that the UAC has an issue with, not all possible UAs in the case of an initial INVITE. Section 7 - Can Info Packages strengthen "MAY" to "SHOULD"? Section 8 - Why is the separator between Info-package-name and Info-package-param a DOT? Shouldn't it be a SEMI? I don't think that Info-package-param is similar to event-template in 3265. Its more like event-param. From sdoken@qualcomm.com Tue Mar 3 09:19:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47093A6818 for ; Tue, 3 Mar 2009 09:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU-GD9efeO6W for ; Tue, 3 Mar 2009 09:19:28 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A254328C2DD for ; Tue, 3 Mar 2009 09:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1236100779; x=1267636779; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 "Vijay=20K.=20Gurbani"=20,=0D=0A =20=20=20=20=20=20=20=20Dean=20Willis=0D=0A=09|CC:=20SIP=20WG=20,=20Chris ter=20Holmberg=20|Date: =20Tue,=203=20Mar=202009=2009:19:20=20-0800|Subject:=20RE :=20[Sip]=20New=20version=20(-05)=20of=20the=20199=20draf t=20-=20ready=20for=20WGLC?|Thread-Topic:=20[Sip]=20New =20version=20(-05)=20of=20the=20199=20draft=20-=20ready =20for=20WGLC?|Thread-Index:=20AcmcERkM2XfWD+pFRTOJDEgmyz MkKwAEProg|Message-ID:=20|References:=20=0D=0A=09=0D=0A=20<49AD4681.8090403@alcatel-lucent .com>|In-Reply-To:=20<49AD4681.8090403@alcatel-lucent.com >|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5541"=3B=20a=3D"15935810"; bh=z5rzOjK03FqgLFeImBe4FjaUBQrA1Hbp8UFFT2F1fjI=; b=rRq7VJrBpsJl+ovaIbAv8yiTC1U1kpot0parXLBovt+PVenEguDUs+9a eBxHwZHlfs+zvx9ltyvZ6meLq49YdKxUD5rd5f3XvnjFvtjUgbC+ldW8T 5ohgBYNEAsr/ubG044M33MpwmqyHnFIcboPJLxIGdcgQokMQmZEI3K1P5 o=; X-IronPort-AV: E=McAfee;i="5300,2777,5541"; a="15935810" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2009 09:19:23 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n23HJNww016634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2009 09:19:23 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n23HJLZR012795 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Mar 2009 09:19:22 -0800 (PST) Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.121]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Tue, 3 Mar 2009 09:19:21 -0800 From: "Doken, Serhad" To: "Vijay K. Gurbani" , Dean Willis Date: Tue, 3 Mar 2009 09:19:20 -0800 Thread-Topic: [Sip] New version (-05) of the 199 draft - ready for WGLC? Thread-Index: AcmcERkM2XfWD+pFRTOJDEgmyzMkKwAEProg Message-ID: References: <49AD4681.8090403@alcatel-lucent.com> In-Reply-To: <49AD4681.8090403@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP WG , Christer Holmberg Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:19:29 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Vijay K. Gurbani > Sent: Tuesday, March 03, 2009 7:02 AM > To: Dean Willis > Cc: SIP WG; Christer Holmberg > Subject: Re: [Sip] New version (-05) of the 199 draft - ready for WGLC? >=20 > Dean Willis wrote: > > We didn't get any real answers due to a bit of confusion between this > > and keepalive. So, let's ask the question again. > > > > Is 199 ready for WGLC? >=20 > Yes; it is well written (I had looked at a much earlier version > and just re-read -06.) >=20 > One question for Christer: >=20 > - Does 199 carry a message/sipfrag MIME type that conveys the > nature of the final non-2xx response? This may have been > discussed in the past, and if so, please let me know. I > do note that rfc3420 is specified in the draft as a normative > reference, but it is not referred to anywhere in the body > of the draft. There was discussion around 199 carrying information about why the fork/dia= log was terminated and sipfrag was mentioned to be used to convey that. How= ever, later on Reason header within 199 is agreed to be used for that purpo= se. Hence, mention of 3420 might be obsolete by now. Thanks, Serhad=20 >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From dworley@nortel.com Tue Mar 3 10:26:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318E53A6AF9 for ; Tue, 3 Mar 2009 10:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyOV7ToiWW4y for ; Tue, 3 Mar 2009 10:26:26 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 14C493A69CE for ; Tue, 3 Mar 2009 10:26:25 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n23IQbi07630 for ; Tue, 3 Mar 2009 18:26:37 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 13:26:48 -0500 From: "Dale Worley" To: SIP Content-Type: text/plain Organization: Nortel Networks Date: Tue, 03 Mar 2009 13:26:47 -0500 Message-Id: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2009 18:26:48.0465 (UTC) FILETIME=[9D619810:01C99C2D] Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:26:27 -0000 I would like to resume the discussion of the problem of IPv6 host addresses in SIP URIs. To abbreviate my previous message, SIP URIs appear to be intended to be a subset of RFC 3986 "path-rootless" URIs (as are mailto: URIs). Of the characters that RFC 3261 permits in the user/host part of the URI, which corresponds to the "hier-part" of RFC 3986, the following characters are not allowed by the syntax of RFC 3986: ? (permitted in user-parts) / (permitted in user-parts) [ (permitted as part of an IPv6 address) ] (permitted as part of an IPv6 address) In order to straighten out this problem, I propose that we modify the RFC 3261 definition to bring it into line with RFC 3986. Specifically, we should: 1. Remove "?" and "/" from the user-unreserved set. (These characters can still be used in their escaped form, which is equivalent to their unescaped form under the current rules.) 2. Replace "[" and "]" in host-addresses by their escaped forms, "%5B" and "%5D" (as is done in mailto: URIs). This will inconvenience any implementation currently using the two characters in user-names, or using IPv6 addresses. But it avoids having to change the master URI syntax of RFC 3986, which is a task of much broader scope. Comments? Dale From adam@nostrum.com Tue Mar 3 14:56:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E353A6984 for ; Tue, 3 Mar 2009 14:56:00 -0800 (PST) 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.038, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5xRP-t6rr+E for ; Tue, 3 Mar 2009 14:55:59 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E16443A68BC for ; Tue, 3 Mar 2009 14:55:58 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n23MuOd1028631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Mar 2009 16:56:24 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <49ADB598.9000102@nostrum.com> Date: Tue, 03 Mar 2009 16:56:24 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: SIP 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) X-Virus-Scanned: ClamAV 0.94.2/9065/Tue Mar 3 04:43:41 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] RFC3265bis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 22:56:00 -0000 After 6 years of testing at SIPits and other experience in the field, it feels like time to fix some of the known bugs in RFC 3265. I've put together a 3265bis that addresses most of the bugs that have been reported to date (although some are called out as known issues): http://www.ietf.org/internet-drafts/draft-roach-sipcore-rfc3265bis-00.txt If you're already familiar with RFC 3265, I would suggest using Appendix C as your roadmap to navigating the changes. The areas I know I need feedback on are the open issues listed in Appendix B. Of course, it's always possible that the new document will prompt people to share implementation experience that hasn't yet been captured -- I'm happy to hear about that too. /a From eburger@standardstrack.com Tue Mar 3 15:10:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F853A6891 for ; Tue, 3 Mar 2009 15:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db9wC+ZxP9K3 for ; Tue, 3 Mar 2009 15:10:12 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 7639A3A67E9 for ; Tue, 3 Mar 2009 15:10:12 -0800 (PST) Received: from [64.186.172.180] (port=35532 helo=[192.168.200.208]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Ledkt-0002ER-8q; Tue, 03 Mar 2009 15:10:31 -0800 Message-Id: From: Eric Burger To: Brett Tate In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674AD4D71@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: multipart/signed; boundary=Apple-Mail-12-116596284; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 15:10:33 -0800 References: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <9B2A061A1137254BBE4F4B2CD843646A10B1FAA3C1@mbx02.citservers.local> <28B7C3AA2A7ABA4A841F11217ABE78D674AD4D71@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIP IETF Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 23:10:13 -0000 --Apple-Mail-12-116596284 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit It absolutely has not been forgotten: I was hoping to get more comments, but I'll get back with comments to the comments by the end of the week. Thanks for your read of the document! On Mar 3, 2009, at 6:59 AM, DRAGE, Keith (Keith) wrote: > Frequently the editor's wait until the end of the WGLC before > processing the comments, so I am sure that it has not been forgotten. > > It does have the advantage of making sure that we do not swap and > change when we get conflicting comments. > > regards > > Keith > >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] >> Sent: Monday, March 02, 2009 1:19 PM >> To: DRAGE, Keith (Keith); SIP IETF >> Cc: hkaplan@acmepacket.com; christer.holmberg@ericsson.com; >> eburger@standardstrack.com >> Subject: RE: WGLC on draft-ietf-sip-info-events >> >>> A reminder of the current WGLC on this document, which completes >>> Wednesday. >>> >>> Please submit your comments as soon as possible. >>> >>> If you are reviewing the document, and you consider there may be a >>> delay in your comments appearing, then please send a mail to the >>> chairs so they can ascertain whether more time is needed. >> >> I haven't received a reply concerning my February 16 >> (archived on 17) email: "draft-ietf-sip-info-events-03: >> comments and questions". Thus I'm not sure if I will have >> follow-up comments based upon the reply. >> >> http://www.ietf.org/mail-archive/web/sip/current/msg26621.html >> >> The following is a snapshot of my questions and comments in >> case the authors did not see my prior email. >> >> Thanks, >> Brett >> >> ---- >> >> Section 3.1 paragraph 1: Concerning "MUST advertise" and >> "provisional 1xx", please clarify that the "MUST advertise" >> is not applicable to the 100 response. Does the "MUST >> advertise" and "provisional 1xx" apply to all (first and >> subsequent within dialog) INVITE non 101-199 (intentionally >> indicated 199)? Concerning ACK for initial INVITE's 2xx, >> does the "MUST advertise" always apply? >> >> Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1 >> indicates "session parameters" and sentence 2 indicates >> "dialog parameters" concerning Info Package negotiation, I'm >> not sure when the negotiation/renegotiation occurs. Does it >> follow SDP offer/answer rules or something else; if something >> else, what? I have the same question concerning "dialog >> refresh" text discussed later within the same section since >> incorrect interpretations might trigger deactivation. >> >> Section 4.3: When sending a 489, it indicates "MUST terminate >> the INVITE dialog". The "MUST terminate" seems severe even >> if all the negotiation race conditions are adequately >> addressed. The mentioned "protocol failure" reason seems >> contrary to the "strictly send and lenient receive" mantra. >> >> Section 5.1 Table 1: The usage of "g" seems potentially >> outdated or incorrectly reference since discussed within RFC >> 2543 instead of RFC 3261. The same applies to usage Via row >> concerning "(2)". >> >> Section 5.2.2: The "general-header" reference is outdated or >> incorrectly reference since defined within RFC 2543 instead >> of RFC 3261. RFC 3261 uses "Message-Header". >> >> Section 7.7 paragraph 2: The following potentially could be >> reworded since it is okay to return failure responses (401, >> 503, 500, ...) even when overlapping occurs: "in the event a >> UAC issues overlapping INFO requests for an Info Package, the >> UAS MUST NOT return an error response". >> >> Section 8: Why specifically defining and using "nil"? I'm >> mainly just curious of the benefit over not having defined >> "nil" for similar use within the Supported header. >> >> --Apple-Mail-12-116596284 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDMyMzEwMzRaMCMGCSqGSIb3 DQEJBDEWBBSMrTyDNWM/8gCn/DA+6n7Vd5FsXzCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBG8bVaY16nzR5vHOuMLospSPea1piynjNd4dPL+CGdwwFU fWcuVhYEHsbBezY4NSCfeknc+2CGMI2M8KwN2zTtgkg6f/J29mshv7BB5G4qdUvFuWw2Zytp+9uc KYT7PMeKLzXN6gXhaGgjPb19G07RIZHSj6fhrSumFd+7hCYGFiJu4QFf1NwbnzrzjQYLX2sZ0exI 5YVkjijVcNYsMaE1yEhG2JoH5aK4oB+sWxzH3hlvqDHrrx50FSMtiQggGfaYO0Npyy+lSob0wl6z gYLy860took98MepJ/ThMfsSiKncqmU4BWZlCuh6EhFpxbpLqEmzNfbwp5/R/0Bc2n7YAAAAAAAA --Apple-Mail-12-116596284-- From BPenfield@acmepacket.com Tue Mar 3 16:57:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DCD28C15E for ; Tue, 3 Mar 2009 16:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtaPBLZaosp5 for ; Tue, 3 Mar 2009 16:57:28 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 59EE628C118 for ; Tue, 3 Mar 2009 16:57:28 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 3 Mar 2009 19:57:54 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 3 Mar 2009 19:57:54 -0500 From: Bob Penfield To: Christer Holmberg Date: Tue, 3 Mar 2009 19:57:53 -0500 Thread-Topic: [Sip] I-D Action:draft-ietf-sip-199-06.txt Thread-Index: AcmbMKe+xsFi6kj+QB+gB2v3KJUGbABMpvRQ Message-ID: References: <20090302121502.4C42D3A6858@core3.amsl.com> In-Reply-To: <20090302121502.4C42D3A6858@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] I-D Action:draft-ietf-sip-199-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:57:29 -0000 Hi Christer, I have few comments on draft-ietf-sip-199-06.txt. I apologize if any of the= se are duplicates. Section 6. The statement requiring the proxy to keep track of early dialogs= : A proxy which supports generating of 199 response codes MUST keep track of early dialogs, in order to determine whether to generate a 199 response when the proxy receives a non-2xx final response. In addition, the proxy MUST keep track on which early dialogs it has received and forwarded 199 responses, in order to not generate additional 199 responses for those early dialogs. Should precede the statement: If the forking proxy generates a 199 response, and if the forking proxy is able to identify additional early dialogs which are terminated by the same non-2xx final response, it MUST also generate and send a 199 response upstream for each of those early dialogs, In fact, if the proxy is keeping track of early dialogs, under what circumstances would it not be "able to identify additional early dialogs which are terminated by the same non-2xx final response"? Section 8 (199 Early Dialog Terminated) seems out of place. Shouldn't this be in the introduction? or in an "Overview Of Operation" between sections 3 and 4? The text in Section 9 (Usage with SDP offer/answer) should be in section 5 (User Agent Server behavior). The statement in section 10 recommending that the UAS send 199 unreliably should be in section 5. The statement in section 10 forbidding proxies from sending 199 reliably should be in section 6 (Proxy behavior). Cheers, (-:bob From john.elwell@siemens.com Wed Mar 4 00:46:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA11928C349 for ; Wed, 4 Mar 2009 00:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQoeZSRXd5SY for ; Wed, 4 Mar 2009 00:46:50 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1187F28C33C for ; Wed, 4 Mar 2009 00:46:49 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KFZ00KA14ES6W@siemenscomms.co.uk> for sip@ietf.org; Wed, 04 Mar 2009 08:47:16 +0000 (GMT) Date: Wed, 04 Mar 2009 08:47:15 +0000 From: "Elwell, John" In-reply-to: To: Bob Penfield , "DRAGE, Keith (Keith)" , SIP IETF Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019843F6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] WGLC on draft-ietf-sip-info-events Thread-Index: AcmQad8/1+QfM4TFQBavCWEg2uC7xAKum/JgAD+YguAAH+TDwA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 08:46:51 -0000 I agree with Bob that the use of UAC and UAS terminology is confusing. I cite some particular examples below. 1. In 3 it defines the two terms, but early in 3.1 it states "The initiating UA (UAC of the INVITE)", which uses "UAC" in a sense different from what is defined. 2. "the UAC MUST NOT send INFO requests for a given Info Package until the UAS lists the given Info Package in a Recv-Info header." According to the definition of UAC, a UAC is the sender of an INFO request. So while waiting to receive Recv-Info it is not a UAC. Similarly, the other end is not a UAS by virtue of sending "Recv-Info" - it only becomes a UAS when it receives an INFO request. Don't forget that a UA is a UAC or a UAS only in the context of a particular transaction, and before that transaction takes place and after that transaction has finished it is just a UA. Any attempt to change the meaning of UAC or UAS would be a departure from RFC 3261. 3. "A UAS lists multiple packages by enumerating the package name(s), separated by commas, as values for the Recv-Info header in the session establishment exchange. A UAS can also list multiple packages by including multiple Recv-Info headers...." We are talking about sending Recv-Info - nothing to do with an INFO transaction, so the term UAS is inappropriate. 4. "This initial dialog establishment phase is the only time the UAS need be prepared to receive multiple INFO requests, as we require post-session-establishment negotiation to fully complete before a UAC can send an INFO request." followed shortly afterwards by: "A UAC MAY send an INFO request on both an early and confirmed dialog." Either these are conflicting statements or there is some mix-up of terms UAC and UAS. 5. In "Conventions Used in this Document" it states: "Since this document strictly follows RFC 3261, we refer to the UA that issues the INVITE as the "initiating UA" and the UA that responds to the INVITE as the "target UA" to remove any confusion." I don't think this is good practice, and I would even say that by doing this we no longer strictly follow RFC 3261 terminology. If it is clear we are talking about an INVITE transaction we should be free to use UAC and UAS. So in general, where it is clear which transaction we are talking about (e.g., because it has appeared earlier in the paragraph concerned), we should just use UAC or UAS. Otherwise we should use expressions like "the UAC for the XXX transaction" or "the UA that sends the XXX request". John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Bob Penfield > Sent: 03 March 2009 17:12 > To: DRAGE, Keith (Keith); SIP IETF > Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events >=20 >=20 > Here are some comments on the INFO draft: >=20 > Section 2 says: >=20 > Each UA enumerates which Info Packages it can receive. If the far > end indicates it can receive a package offered by the near end, the > near end can send INFO methods containing the payload for that > package. >=20 > "offered" needs to changed to "supported" since an INFO sender does > not indicate what packages it can send. >=20 > Section 3 is called "Info Package Negotiation", but since we removed > Send-Info, it is not a negotiation since there is no feedback from the > peer UA. It is simply a declaration of receive capability. At first > read, I was totally confused by section 3.1 because I was expecting > some actual negotiation given the above statement in Section 2. There > are a few other places in the document that mentions "negotiation" > that also might need to be changed. >=20 > I think the usage of UAC/UAS terminology in Section 3.1 is still > confusing. I would prefer to see something like: >=20 > A UA supporting this document MUST advertise the set of Info > Packages it is willing to receive in Recv-Info header(s) in all > "INVITE dialog usage" requests and responses (101-199 and 2xx only) > for dialog establishment or target refresh. This includes INVITE, > UPDATE, PRACK and ACK and their non-failure responses. >=20 > A UA MUST NOT send INFO requests for a given INFO package until the > UA has received an "INVITE dialog usage" request or response (for > dialog establishment or target refresh) with a Recv-Info header > listing the given Info Package. >=20 > A UA MUST cease sending INFO requests for a given INFO package when > the UA receives an "INVITE dialog usage" request or response (for > dialog establishment or target refresh) that does not contain a > Recv-Info header listing the given Info Package. >=20 > Section 3.1 - "the target UA may not send form package P" >=20 > s/form/from/ >=20 > Section 3.1 - "... the other UA in the dial will assume the ..." >=20 > s/dial/dialog/ >=20 > Section 3.1 - "server MAY terminate the session with a CANCEL or BYE" >=20 > When the "server" is the UAS of the request, CANCEL is not > appropriate, and BYE would not be appropriate if it is an initial > INVITE. In this case, the request would need to be rejected. When > the "server" is the UAC, I don't think CANCEL is appropriate since > it is the far-end UA of a specific dialog that the UAC has an issue > with, not all possible UAs in the case of an initial INVITE. >=20 > Section 7 - Can Info Packages strengthen "MAY" to "SHOULD"? >=20 > Section 8 - Why is the separator between Info-package-name and > Info-package-param a DOT? Shouldn't it be a SEMI? I don't think that > Info-package-param is similar to event-template in 3265. Its more like > event-param. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From rco@iptel.org Wed Mar 4 02:36:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337483A6A88 for ; Wed, 4 Mar 2009 02:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+Zh7aQA7nWo for ; Wed, 4 Mar 2009 02:36:11 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 3EBE53A684A for ; Wed, 4 Mar 2009 02:36:11 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id 18A201811CFE; Wed, 4 Mar 2009 11:34:42 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 0AFAA1811CF9 for ; Wed, 4 Mar 2009 11:34:39 +0100 (CET) Message-ID: <49AE593F.6080807@iptel.org> Date: Wed, 04 Mar 2009 11:34:39 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 10:36:12 -0000 Hello, a new internet draft has been published concerning the relay attack on digest authentication and SIP. The attack itself has been first disclosed 2 years ago by the maydnes team from the french INRIA. Until now, no document has been pushlished that documents the attack and provides guidance to SIP operators or handset manufacturers. http://tools.ietf.org/html/draft-state-sip-relay-attack-00 The appropriate mitigations of problem resolutions are still not 100% clear. We hope that this draft can help start a discussion on how to best resolve this problem. Regards, Raphael Coeffic. (on behalf of all the authors of this draft) --------------------------------------------------------------------------------------------------- Filename: draft-state-sip-relay-attack Version: 00 Staging URL: http://www3.ietf.org/proceedings/staging/draft-state-sip-relay-attack-00.txt Title: SIP digest authentication relay attack Creation_date: 2009-03-02 WG ID: Indvidual Submission Number_of_pages: 18 Abstract: The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism for creating, modifying, and terminating sessions with one or more participants. This document describes a vulnerability of SIP combined with HTTP Digest Access Authentication [RFC2617] through which an attacker can leverage the victim's credentials to send authenticated requests on his behalf. This attack is different from the man-in-the-middle (MITM) attack and does not require any eavesdropping, DNS or IP spoofing. From theo@crazygreek.co.uk Wed Mar 4 04:34:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C9F3A6C66 for ; Wed, 4 Mar 2009 04:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UeR+E90p4pp for ; Wed, 4 Mar 2009 04:34:33 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with SMTP id E2BF63A67A1 for ; Wed, 4 Mar 2009 04:34:32 -0800 (PST) Received: from source ([209.85.220.173]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSa51dBbcaRGYxHQKnrIOu6GNA5ZVAfUU@postini.com; Wed, 04 Mar 2009 04:35:01 PST Received: by fxm21 with SMTP id 21so4674040fxm.31 for ; Wed, 04 Mar 2009 04:35:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.50.8 with SMTP id x8mr46854fgx.14.1236170099915; Wed, 04 Mar 2009 04:34:59 -0800 (PST) In-Reply-To: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> References: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> Date: Wed, 4 Mar 2009 12:34:59 +0000 Message-ID: <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> From: Theo Zourzouvillys To: Dale Worley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 12:34:34 -0000 On Tue, Mar 3, 2009 at 6:26 PM, Dale Worley wrote: > But it avoids having > to change the master URI syntax of RFC 3986, which is a task of much > broader scope. Both are going to require change (although we don't need world AND dog to agree with a 3261 update), but seems to me that updating 3986 seems like a far more appropriate path to take given the number of other affected URI schemes as Hadriel pointed out. I have no objection to the removal of '/' and '?' from the user part, but the replacing of '[' and ']' seems quiet urgh. ... i've just quickly scanned through apps-discuss and haven't seen any discussion on it there, should we perhaps test the water to see what sort of reaction there would be to suggesting such an update if it's the right thing to do? ~ Theo From gshaham@juniper.net Wed Mar 4 06:35:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1421A3A6C50 for ; Wed, 4 Mar 2009 06:35:56 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gRD9sa7mUb7 for ; Wed, 4 Mar 2009 06:35:55 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id DA2053A68AD for ; Wed, 4 Mar 2009 06:35:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSa6Rzz40c1NQ1bhujl8KLZuRqfxC9U6V@postini.com; Wed, 04 Mar 2009 06:36:23 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 4 Mar 2009 06:32:43 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 06:32:43 -0800 Received: from emailfeemea2.jnpr.net ([172.26.192.142]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 06:32:43 -0800 Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 14:32:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 14:32:08 +0000 Message-ID: <0E48B768805E4D44A70709C8AE092090030C671B@EMAILEMEA3.jnpr.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001984302@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important Thread-Index: AcmcH5+5Xxh3VXbTSpu8lr6IdUjryQAsxR9Q References: <0D5F89FAC29E2C41B98A6A762007F5D001984302@GBNTHT12009MSX.gb002.siemens.net> From: Gilad Shaham To: "Elwell, John" , "SIP List" , "Cullen Jennings" , "Jon Peterson" X-OriginalArrivalTime: 04 Mar 2009 14:32:07.0801 (UTC) FILETIME=[FF108690:01C99CD5] Subject: Re: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:35:56 -0000 Hi John, I personally think your conclusions are correct. One comment I have is regarding From and To headers. It's possible that the comment is a bit ahead of time as this draft is not yet aimed at the solutions, but I believe that when we come to a solution, the endpoints themselves should enforce some rules on the From and To headers if they want to support end-to-end identity. For example, the endpoints should not (or MUST not) place an IP address in these fields if they request end-to-end identity to be enabled. Making this a requirement on the endpoint behalf would help coping with the dilemma of the intermediate device as to whether or not it should break the identity. Thanks, Gilad -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Tuesday, March 03, 2009 6:47 PM To: SIP List; Cullen Jennings; Jon Peterson Subject: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important Draft 03: http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 includes for the first time an analysis of changes to SIP requests by B2BUAs (section 8). Also the Conclusions (section 9) have been extended. I and a number of people who have assisted in revising this draft would like to seek consensus on a number of the points. We aim to ask these questions in San Francisco, but obviously it would help to get opinions from the list in advance. 1. Tolerance to changes of certain elements as a SIP request is forwarded through intermediate domains. Section 8 analyses a number of elements of SIP messages that are signed by the present RFC 4474 solution to end-to-end (or near end-to-end) authenticated identification. For some elements it claims that any solution for end-to-end authenticated identification needs to be tolerant of changes by intermediate domains, since there appear to be valid reasons why B2BUAs (including but not limited to SBCs) change these elements. Picking on some of these: A) Is there agreement that a solution needs to be tolerant of changes to IP addresses and ports in c- and m-lines in SDP? In other words, that intermediate domains can legitimately modify these fields (e.g., for media steering) and a solution is needed for end-to-end authenticated identification in such circumstances? B) Is there agreement that a solution needs to be tolerant of changes to Contact (addr-spec), Call-Id (call-id) and CSeq (digit) header fields? In other words, that intermediate domains can legitimately modify these fields (e.g., for topology hiding) and a solution is needed for end-to-end authenticated identification in such circumstances? C) Is there agreement that a solution does not need to be tolerant of changes to the addr-spec of From and To header fields? In other words, that intermediate domains should not modify these fields and can expect to break end-to-end authenticated identification if they do so? 2. Are people in broad agreement with the conclusions in section 9 concerning the importance of end-to-end identification and in particular end-to-end authenticated identification? John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From dean.willis@softarmor.com Wed Mar 4 10:04:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C003A6BAC for ; Wed, 4 Mar 2009 10:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ7l-QoEH-P4 for ; Wed, 4 Mar 2009 10:04:20 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9B38D3A696D for ; Wed, 4 Mar 2009 10:03:20 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n24I3Zxk021924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2009 12:03:37 -0600 Message-Id: <6EF7E0CD-58D2-4218-9408-1FC584DE7C04@softarmor.com> From: Dean Willis To: Theo Zourzouvillys In-Reply-To: <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 12:03:29 -0600 References: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:04:20 -0000 On Mar 4, 2009, at 6:34 AM, Theo Zourzouvillys wrote: > On Tue, Mar 3, 2009 at 6:26 PM, Dale Worley > wrote: > >> But it avoids having >> to change the master URI syntax of RFC 3986, which is a task of much >> broader scope. > > Both are going to require change (although we don't need world AND dog > to agree with a 3261 update), but seems to me that updating 3986 seems > like a far more appropriate path to take given the number of other > affected URI schemes as Hadriel pointed out. > > I have no objection to the removal of '/' and '?' from the user part, > but the replacing of '[' and ']' seems quiet urgh. > > ... i've just quickly scanned through apps-discuss and haven't seen > any discussion on it there, should we perhaps test the water to see > what sort of reaction there would be to suggesting such an update if > it's the right thing to do? I'm afraid I have to concur with Theo. 3986 is just broken. -- Dean From dworley@nortel.com Wed Mar 4 10:28:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E5E3A6C87 for ; Wed, 4 Mar 2009 10:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB859nEo3oac for ; Wed, 4 Mar 2009 10:28:08 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DC9513A67DF for ; Wed, 4 Mar 2009 10:28:07 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n24ISKg13802 for ; Wed, 4 Mar 2009 18:28:20 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 13:28:33 -0500 From: "Dale Worley" To: SIP Content-Type: text/plain Organization: Nortel Networks Date: Wed, 04 Mar 2009 13:28:33 -0500 Message-Id: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2009 18:28:33.0594 (UTC) FILETIME=[0674C1A0:01C99CF7] Subject: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:28:08 -0000 I wrote up the "170" trace proposal as an I-D: A new version of I-D, draft-worley-trace-00.txt has been successfuly submitted by Dale Worley and posted to the IETF repository. Filename: draft-worley-trace Revision: 00 Title: SIP Tracing Facility Creation_date: 2009-03-03 WG ID: Independent Submission Number_of_pages: 18 Abstract: This document defines a SIP option tag, "trace", to be used within SIP messages to request that SIP elements (both proxies and UASs) that receive the message reflect to the UAC the request they received and the response they gave by encapsulating the request and response in a provisional response. A new provisional response code "170" is defined to carry the request and response. This option tag is expected to be used solely for diagnostic purposes. From drage@alcatel-lucent.com Wed Mar 4 10:32:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D043A6BA4 for ; Wed, 4 Mar 2009 10:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7CGXt0f2HMR for ; Wed, 4 Mar 2009 10:32:10 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 02A563A69EE for ; Wed, 4 Mar 2009 10:32:08 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n24IWZpk008546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Mar 2009 19:32:35 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 4 Mar 2009 19:32:35 +0100 From: "DRAGE, Keith (Keith)" To: SIP IETF Date: Wed, 4 Mar 2009 19:32:32 +0100 Thread-Topic: Agenda call for SIP Thread-Index: Acmc95PIXAO60xmTRC6NcZ2/OjUvzA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674AD52CC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: Dean Willis Subject: [Sip] Agenda call for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:32:11 -0000 (As WG co chair) If you wish to have time allocated to a particular discussion in the SIP se= ssions in San Francisco, and have not already submitted a request, then ple= ase do so. Please include information like: - name(s) of any draft(s) to be discussed. - proposed name of presenter - what is/are the key question(s) to put to the WG as a result of the discu= ssion. - how much time you think you will need. Note that in addressing the third bullet we would like a bit more detail th= an "WG item?", for example give us some help in identifying the text for th= e milestone you actually want in the SIP charter, which is the problem you = want to solve, rather than the solution. Please do this now as we will be putting the preliminary agenda together to= morrow (Thursday). Agendas are always subject to change but would prefer no= t to have any late surprises. regards Keith From dean.willis@softarmor.com Wed Mar 4 10:51:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BD928C1AF for ; Wed, 4 Mar 2009 10:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aean4weuAtwz for ; Wed, 4 Mar 2009 10:51:42 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CA30D3A6BA4 for ; Wed, 4 Mar 2009 10:51:41 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n24Iq4ha022770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2009 12:52:05 -0600 Message-Id: From: Dean Willis To: SIP IETF In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674AD52CC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 12:51:58 -0600 References: <28B7C3AA2A7ABA4A841F11217ABE78D674AD52CC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.930.3) Cc: Keith Drage Subject: Re: [Sip] Agenda call for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:51:43 -0000 Note that I'm accumulating agenda requests at our (yes, Henry, we one) wiki: http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_Requests_IETF_74 If your request doesn't show up there fairly quickly (48 hours), I've probably lost it. -- Dean From john.elwell@siemens.com Wed Mar 4 12:43:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C04A3A6844 for ; Wed, 4 Mar 2009 12:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajIaEzysr35G for ; Wed, 4 Mar 2009 12:43:47 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 6552E3A684E for ; Wed, 4 Mar 2009 12:43:47 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KG000H4J1LP5Y@siemenscomms.co.uk> for sip@ietf.org; Wed, 04 Mar 2009 20:44:13 +0000 (GMT) Date: Wed, 04 Mar 2009 20:44:11 +0000 From: "Elwell, John" In-reply-to: <0E48B768805E4D44A70709C8AE092090030C671B@EMAILEMEA3.jnpr.net> To: Gilad Shaham , SIP List , Cullen Jennings , Jon Peterson Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019BFF6F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important Thread-Index: AcmcH5+5Xxh3VXbTSpu8lr6IdUjryQAsxR9QAA2z13A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001984302@GBNTHT12009MSX.gb002.siemens.net> <0E48B768805E4D44A70709C8AE092090030C671B@EMAILEMEA3.jnpr.net> Subject: Re: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 20:43:49 -0000 =20 > -----Original Message----- > From: Gilad Shaham [mailto:gshaham@juniper.net]=20 > Sent: 04 March 2009 14:32 > To: Elwell, John; SIP List; Cullen Jennings; Jon Peterson > Subject: RE: [Sip] Seeking consensus on=20 > draft-elwell-sip-e2e-identity-important >=20 > Hi John, >=20 > I personally think your conclusions are correct. One comment I have is > regarding From and To headers. It's possible that the comment is a bit > ahead of time as this draft is not yet aimed at the solutions, but I > believe that when we come to a solution, the endpoints=20 > themselves should > enforce some rules on the From and To headers if they want to support > end-to-end identity. > For example, the endpoints should not (or MUST not) place an=20 > IP address > in these fields if they request end-to-end identity to be enabled. > Making this a requirement on the endpoint behalf would help=20 > coping with > the dilemma of the intermediate device as to whether or not it should > break the identity. [JRE] That would be good, but on the other hand this sort of fix-up can in practice be done in the originating domain prior to the authentication service. In fact replacing an IP address with a domain name must be done before the authentication service. John >=20 > Thanks, > Gilad >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Tuesday, March 03, 2009 6:47 PM > To: SIP List; Cullen Jennings; Jon Peterson > Subject: [Sip] Seeking consensus on > draft-elwell-sip-e2e-identity-important >=20 > Draft 03: > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > includes for the first time an analysis of changes to SIP requests by > B2BUAs (section 8). Also the Conclusions (section 9) have=20 > been extended. >=20 > I and a number of people who have assisted in revising this=20 > draft would > like to seek consensus on a number of the points. We aim to ask these > questions in San Francisco, but obviously it would help to=20 > get opinions > from the list in advance. >=20 > 1. Tolerance to changes of certain elements as a SIP request is > forwarded through intermediate domains. >=20 > Section 8 analyses a number of elements of SIP messages that=20 > are signed > by the present RFC 4474 solution to end-to-end (or near end-to-end) > authenticated identification. For some elements it claims that any > solution for end-to-end authenticated identification needs to be > tolerant of changes by intermediate domains, since there appear to be > valid reasons why B2BUAs (including but not limited to SBCs) change > these elements. Picking on some of these: >=20 > A) Is there agreement that a solution needs to be tolerant of=20 > changes to > IP addresses and ports in c- and m-lines in SDP? In other words, that > intermediate domains can legitimately modify these fields (e.g., for > media steering) and a solution is needed for end-to-end authenticated > identification in such circumstances? >=20 > B) Is there agreement that a solution needs to be tolerant of=20 > changes to > Contact (addr-spec), Call-Id (call-id) and CSeq (digit) header fields? > In other words, that intermediate domains can legitimately=20 > modify these > fields (e.g., for topology hiding) and a solution is needed for > end-to-end authenticated identification in such circumstances? >=20 > C) Is there agreement that a solution does not need to be tolerant of > changes to the addr-spec of From and To header fields? In other words, > that intermediate domains should not modify these fields and=20 > can expect > to break end-to-end authenticated identification if they do so? >=20 >=20 > 2. Are people in broad agreement with the conclusions in section 9 > concerning the importance of end-to-end identification and in=20 > particular > end-to-end authenticated identification? >=20 > John >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From dworley@nortel.com Wed Mar 4 13:08:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D707928C2BD for ; Wed, 4 Mar 2009 13:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Tk2mBeyalpP for ; Wed, 4 Mar 2009 13:08:00 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D30243A67A7 for ; Wed, 4 Mar 2009 13:07:59 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n24L8Bg21136; Wed, 4 Mar 2009 21:08:11 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 16:08:24 -0500 From: "Dale Worley" To: Theo Zourzouvillys In-Reply-To: <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> References: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 04 Mar 2009 16:08:23 -0500 Message-Id: <1236200903.3771.43.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2009 21:08:24.0183 (UTC) FILETIME=[5AE48070:01C99D0D] Cc: SIP Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 21:08:04 -0000 On Wed, 2009-03-04 at 12:34 +0000, Theo Zourzouvillys wrote: > Both are going to require change (although we don't need world AND dog > to agree with a 3261 update), but seems to me that updating 3986 seems > like a far more appropriate path to take given the number of other > affected URI schemes as Hadriel pointed out. As far as I can see, all the schemes that Hadriel pointed out have exactly the same problem as sip:, they permit "mailbox"-style components but do not specify how they are to be encoded if the characters in question are not valid by RFC 3986. > I have no objection to the removal of '/' and '?' from the user part, > but the replacing of '[' and ']' seems [quite] urgh. It's "urgh" only if you've implemented IPv6, I suppose. Conveniently, our project hasn't. Dale From dworley@nortel.com Wed Mar 4 13:09:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEFB3A6AE5 for ; Wed, 4 Mar 2009 13:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2WhUTttS9-I for ; Wed, 4 Mar 2009 13:09:29 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A44183A6A63 for ; Wed, 4 Mar 2009 13:09:29 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n24L9fg21387; Wed, 4 Mar 2009 21:09:41 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 16:09:51 -0500 From: "Dale Worley" To: Dean Willis In-Reply-To: <6EF7E0CD-58D2-4218-9408-1FC584DE7C04@softarmor.com> References: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> <6EF7E0CD-58D2-4218-9408-1FC584DE7C04@softarmor.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 04 Mar 2009 16:09:51 -0500 Message-Id: <1236200991.3771.45.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2009 21:09:52.0123 (UTC) FILETIME=[8F4F14B0:01C99D0D] Cc: SIP Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 21:09:30 -0000 On Wed, 2009-03-04 at 12:03 -0600, Dean Willis wrote: > I'm afraid I have to concur with Theo. 3986 is just broken. Perhaps so, given that the different URI formats have different sets of acceptable characters -- why would that be? But what is the plan for going forward? Dale From dwing@cisco.com Wed Mar 4 13:20:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A741428C4C3 for ; Wed, 4 Mar 2009 13:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t+EsNvE6XSs for ; Wed, 4 Mar 2009 13:20:00 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8C2B928C4C4 for ; Wed, 4 Mar 2009 13:20:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,302,1233532800"; d="scan'208";a="150928710" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2009 21:20:29 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n24LKTQl028461; Wed, 4 Mar 2009 13:20:29 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n24LKTKs007482; Wed, 4 Mar 2009 21:20:29 GMT From: "Dan Wing" To: "'Raphael Coeffic'" , References: <49AE593F.6080807@iptel.org> Date: Wed, 4 Mar 2009 13:20:29 -0800 Message-ID: <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <49AE593F.6080807@iptel.org> Thread-Index: AcmctR8BnOtCTkBUSD2RENZm/vZwvAAWb6Zg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2409; t=1236201629; x=1237065629; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20draft-state-sip-relay-attack-00 |Sender:=20; bh=+wKnRDI/xw/7SJ8dyLdcatoICFNA83s6Q4GVluJ1s3c=; b=RMQ2dDPgNdXAHvyVermD/wW09p8OfOAt7KZXHNtWReOZIsUfPYtXpLhlZz Ko6X8K8w0Gt/VE7pPsd2p6dNlx9KvxqDP7+fU43hGK+HiDAz4MONbdfbJISJ KWRPzjusRuFVcPLSmOL1yJXIVTLinQh14XdGKPPy8yfR5iaK52bYM=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 21:20:02 -0000 Thanks for publishing that attack. It has similarities with the attack described by Hadriel in http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack. -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Raphael Coeffic > Sent: Wednesday, March 04, 2009 2:35 AM > To: sip@ietf.org > Subject: [Sip] draft-state-sip-relay-attack-00 > > Hello, > > a new internet draft has been published concerning the relay > attack on > digest authentication and SIP. The attack itself has been first > disclosed 2 years ago by the maydnes team from the french > INRIA. Until > now, no document has been pushlished that documents the attack and > provides guidance to SIP operators or handset manufacturers. > > http://tools.ietf.org/html/draft-state-sip-relay-attack-00 > > The appropriate mitigations of problem resolutions are still not 100% > clear. We hope that this draft can help start a discussion on how to > best resolve this problem. > > > Regards, > > Raphael Coeffic. > (on behalf of all the authors of this draft) > > -------------------------------------------------------------- > ------------------------------------- > > Filename: draft-state-sip-relay-attack > Version: 00 > Staging URL: > http://www3.ietf.org/proceedings/staging/draft-state-sip-relay > -attack-00.txt > Title: SIP digest authentication relay attack > Creation_date: 2009-03-02 > WG ID: Indvidual Submission > Number_of_pages: 18 > Abstract: > The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism > for creating, modifying, and terminating sessions with one or more > participants. This document describes a vulnerability of SIP > combined with HTTP Digest Access Authentication [RFC2617] through > which an attacker can leverage the victim's credentials to send > authenticated requests on his behalf. This attack is different from > the man-in-the-middle (MITM) attack and does not require any > eavesdropping, DNS or IP spoofing. > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From HKaplan@acmepacket.com Wed Mar 4 14:54:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B426B3A691A for ; Wed, 4 Mar 2009 14:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ma5RkH0xlMX for ; Wed, 4 Mar 2009 14:54:25 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D4F373A68DA for ; Wed, 4 Mar 2009 14:54:24 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 4 Mar 2009 17:54:52 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 4 Mar 2009 17:54:52 -0500 From: Hadriel Kaplan To: Dale Worley , Dean Willis Date: Wed, 4 Mar 2009 17:54:51 -0500 Thread-Topic: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 Thread-Index: AcmdDZZKcZmraz8kTMW7s74mWeQLcQADhbyg Message-ID: References: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> <6EF7E0CD-58D2-4218-9408-1FC584DE7C04@softarmor.com> <1236200991.3771.45.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1236200991.3771.45.camel@victoria-pingtel-com.us.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 22:54:25 -0000 How about: ignorance is bliss? :) Seriously, what does RFC 3986 do?? How does it affect anything for common = URI formats not to comply with it? (or really, for *it* not to comply with = common URI formats) -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dal= e > Worley > Sent: Wednesday, March 04, 2009 4:10 PM > To: Dean Willis > Cc: SIP > Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP UR= I > andRFC 3986 > > On Wed, 2009-03-04 at 12:03 -0600, Dean Willis wrote: > > I'm afraid I have to concur with Theo. 3986 is just broken. > > Perhaps so, given that the different URI formats have different sets of > acceptable characters -- why would that be? > > But what is the plan for going forward? > > Dale > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From theo@crazygreek.co.uk Wed Mar 4 15:22:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FEB28C285 for ; Wed, 4 Mar 2009 15:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdFq4EgLz9bG for ; Wed, 4 Mar 2009 15:22:33 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id D68E628C19B for ; Wed, 4 Mar 2009 15:22:32 -0800 (PST) Received: from source ([209.85.218.165]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSa8NVW+fKTQTdn1BngytDKGYzh5x125u@postini.com; Wed, 04 Mar 2009 15:23:02 PST Received: by bwz9 with SMTP id 9so3028433bwz.12 for ; Wed, 04 Mar 2009 15:23:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.181.24.14 with SMTP id b14mr135273bkj.104.1236208980792; Wed, 04 Mar 2009 15:23:00 -0800 (PST) In-Reply-To: <49AE593F.6080807@iptel.org> References: <49AE593F.6080807@iptel.org> Date: Wed, 4 Mar 2009 23:23:00 +0000 Message-ID: <167dfb9b0903041523y43a2f987ua88c8c6645e62341@mail.gmail.com> From: Theo Zourzouvillys To: Raphael Coeffic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:22:34 -0000 On Wed, Mar 4, 2009 at 10:34 AM, Raphael Coeffic wrote: > The appropriate mitigations of problem resolutions are still not 100% clear. > We hope that this draft can help start a discussion on how to best resolve > this problem. Hi Raphael, Thanks for documenting this! page 10: It is worth noting that the protection provided on the request URI is purely theoretical, as [RFC3261] introduces an exception to the request URI checking required by [RFC2617] in section 22.4: Another important consideration to keep in mind while thinking about solutions is that the Contact header in the dialog creating request can be pretty much anything bob likes if he also adds a Record-Route header in, leading to the dialog target URI at alice's UA being whatever bob wants, and thus the Authentication header can be manipulated to contain whatever the attacker wants in the uri parameter. To explain - consider Figure 1 in the draft F1 could be sent by bob@rouge.com as: INVITE sip:alice@proxy.com SIP/2.0 Contact: Record-Route: thus, when alice creates the dialog, the remote URI will indeed be +1-900-xxx@proxy.com, and your in-dialog F10 message will be: F10 INVITE Alice -> Bob INVITE sip:+1-900-xxx@proxy.com SIP/2.0 Route: Proxy-Authorization: Digest username="alice", realm="proxy.com", uri="sip:+1-900-xxx@proxy.com", nonce="f84f1cec41e6cbe5aea9c8e88d359543", response="3bea678acef9875433487f23a567d876", opaque="", algorithm=MD5 Content-Type: application/sdp Content-Length:... presto - the authentication header now even contains the URI you want to call. note that a re-INVITE could also be done to change the target URI a few times to get different Authentication headers with different URIs in, all legitimate. As to the potential solutions: both only accepting from registered contact or any attempt at avoiding sending re-INVITE [1] are in my opinion unfeasible and broken - i'll have some thought on others, though :-) ~ Theo 1 - REFER is another in-dialog method that could be abused - an OOD REFER may be accepted with authentication by - for example - a PSTN gateway. Social engineering of alice could result in alice's UA sending a REFER that could then be used. From hsinnrei@adobe.com Wed Mar 4 15:27:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7643428C407 for ; Wed, 4 Mar 2009 15:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEm6mdND8Q8h for ; Wed, 4 Mar 2009 15:27:52 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by core3.amsl.com (Postfix) with ESMTP id C2F4328C40E for ; Wed, 4 Mar 2009 15:27:40 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKSa8OiFjFzldvwmNBTi/eMUkijCARWbbg@postini.com; Wed, 04 Mar 2009 15:28:11 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n24NMjeM019982; Wed, 4 Mar 2009 15:22:45 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n24NS8iq020799; Wed, 4 Mar 2009 15:28:08 -0800 (PST) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 4 Mar 2009 15:28:08 -0800 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 4 Mar 2009 15:28:07 -0800 From: Henry Sinnreich To: Dean Willis , SIP IETF Date: Wed, 4 Mar 2009 15:28:06 -0800 Thread-Topic: [Sip] Agenda call for SIP Thread-Index: Acmc+l2bcZV711ItR9y5iNd2rsxa3wAJoE+j Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5D46AA6BDB1hsinnreiadobecom_" MIME-Version: 1.0 Cc: Keith Drage Subject: Re: [Sip] Agenda call for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:27:53 -0000 --_000_C5D46AA6BDB1hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I suppose this is the 1st wiki in RAI? If so, it is a good start. Congratulations! Henry On 3/4/09 12:51 PM, "Dean Willis" wrote: Note that I'm accumulating agenda requests at our (yes, Henry, we one) wiki: http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_Requests_IETF_74 If your request doesn't show up there fairly quickly (48 hours), I've probably lost it. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --_000_C5D46AA6BDB1hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] Agenda call for SIP I suppose this is the 1st wiki in RAI?
If so, it is a good start.
Congratulations!

Henry


On 3/4/09 12:51 PM, "Dean Willis" <dean.willis@softarmor.com> wrote:




Note that I'm accumulating agenda requests at our (yes, Henry, we one)
wiki:

http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_Requests_= IETF_74

If your request doesn't show up there fairly quickly (48 hours), I've
probably lost it.

--
Dean



_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columb= ia.edu for questions on current sip
Use sipping@ietf.org for new developments = on the application of sip

--_000_C5D46AA6BDB1hsinnreiadobecom_-- From HKaplan@acmepacket.com Wed Mar 4 16:28:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62EF93A68C8 for ; Wed, 4 Mar 2009 16:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpQTT7B44fyk for ; Wed, 4 Mar 2009 16:28:15 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 68EB03A684D for ; Wed, 4 Mar 2009 16:28:15 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 4 Mar 2009 19:28:43 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 4 Mar 2009 19:28:43 -0500 From: Hadriel Kaplan To: SIP Date: Wed, 4 Mar 2009 19:28:37 -0500 Thread-Topic: I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmdKVN6VC4AVHKUQf2H8rHvdLSL3A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 00:28:16 -0000 Howdy, In an effort to avoid endless thrashing, I will be updating the Session-ID = draft to only be about troubleshooting use. For dialog matching issues, I have followed Adam's advice and submitted a s= eparate draft to update RFC 3261, linked below. This issue will only get worse, and the code changes to do this should be f= airly small for most folks, I would think. And it's only 6 pages, so we should be able to agree on this in about 3 yea= rs. :) A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Secure Call-ID for the Session Initiation Proto= col (SIP) Author(s) : H. Kaplan Filename : draft-kaplan-sip-secure-call-id-00.txt Pages : 6 Date : 2009-03-04 Many SIP devices generate Call-ID values which contain their system IP Addr= ess, due to examples and normative text in RFC 3261. This has led to some = middleboxes, such as SBC's, to change the Call-ID for security reasons. Th= is draft updates RFC 3261 to require SIP User Agents to generate benign Cal= l-IDs, in such a manner that they can be detected as secure and not need to= be changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-sip-secure-call-id-00.txt -hadriel From dean.willis@softarmor.com Wed Mar 4 18:49:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84AEF3A6872 for ; Wed, 4 Mar 2009 18:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKEZ8LSy-AXi for ; Wed, 4 Mar 2009 18:49:29 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C232D3A6807 for ; Wed, 4 Mar 2009 18:49:29 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n252npRB027574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2009 20:49:52 -0600 Message-Id: From: Dean Willis To: Henry Sinnreich In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 20:49:46 -0600 References: X-Mailer: Apple Mail (2.930.3) Cc: SIP IETF , Keith Drage Subject: [Sip] SIP WIKI: was Re: Agenda call for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 02:49:30 -0000 On Mar 4, 2009, at 5:28 PM, Henry Sinnreich wrote: > I suppose this is the 1st wiki in RAI? > If so, it is a good start. > Congratulations! Actually, we have been using it since IETF 69. And the IETF tools team has also made a WIKI available to each working group, but so far we haven't put it into use. -- Dean From john.elwell@siemens.com Wed Mar 4 23:31:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1031D3A68DE for ; Wed, 4 Mar 2009 23:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1gvs7XGbC5M for ; Wed, 4 Mar 2009 23:31:37 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3D7083A68D1 for ; Wed, 4 Mar 2009 23:31:37 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KG00090TVGN9Q@siemenscomms.co.uk> for sip@ietf.org; Thu, 05 Mar 2009 07:29:12 +0000 (GMT) Date: Thu, 05 Mar 2009 07:29:09 +0000 From: "Elwell, John" To: SIP List , Mayumi Munakata Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019BFF92@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: New text for ua-privacy Thread-Index: AcmdZBK3sSlj0ZE0RhG9m7TnfbV4BA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] New text for ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 07:31:38 -0000 I previously commented on the last sentence of the following text in 5.1.1 (Contact header field) of draft-ietf-sip-ua-privacy-05: " When using this header field in a dialog-forming request or response or in a mid-dialog request or response, the user agent MUST anonymize the Contact header field using an anonymous URI ("temp-gruu") obtained through the GRUU mechanism, unless an equivalent functional anonymous URI is provided by some other means. For out-of-dialog request, anonymous URI MAY be set when anonymization is required." The reason for my comment was that I wasn't certain where the last sentence would apply. Of course, a REGISTER request or 200 response is "out of dialog", but clearly an anonymized Contact URI is inappropriate. In addition I have identified the following requests: - OPTIONS - Contact MAY be included. - PUBLISH - Contact, if present, doesn't have any meaning in the context of event publication. - MESSAGE - Contact not allowed. Furthermore, non-dialog-forming responses to things like INVITE and SUBSCRIBE do not require Contact, with the exception of 3xx where the URI clearly cannot be anonymized. So how to cover this concisely? I would propose replacing the last sentence above with the following: "For other requests and responses, with the exception of 3xx responses, REGISTER requests and REGISTER 200 responses, the UA MUST either omit the Contact header field or use an anonymous URI." Would this be acceptable? Have I captured all exceptions? John From munakata.mayumi@lab.ntt.co.jp Thu Mar 5 00:15:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A96A28C10E for ; Thu, 5 Mar 2009 00:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43-GNOnYtwiy for ; Thu, 5 Mar 2009 00:15:07 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 51BF63A67DB for ; Thu, 5 Mar 2009 00:15:07 -0800 (PST) Received: (qmail 83419 invoked by alias); 5 Mar 2009 08:15:36 -0000 Received: from gwall1.bb.ntt-at.co.jp (192.168.5.201) by subgate.bb.ntt-at.co.jp with SMTP; 5 Mar 2009 08:15:36 -0000 Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id n258FDIG032445; Thu, 5 Mar 2009 17:15:13 +0900 Received: from suez.bb.ntt-at.co.jp [192.168.2.9] by gwall1.bb.ntt-at.co.jp with ESMTP id TAA32444; Thu, 5 Mar 2009 17:15:13 +0900 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id n258FBfs028825; Thu, 5 Mar 2009 17:15:11 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n258FBB2088264; Thu, 5 Mar 2009 17:15:11 +0900 (JST) (envelope-from munakata.mayumi@lab.ntt.co.jp) Received: from [127.0.0.1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id C7A4F20807E; Thu, 5 Mar 2009 17:15:11 +0900 (JST) Message-ID: <49AF8A00.2010107@lab.ntt.co.jp> Date: Thu, 05 Mar 2009 17:14:56 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D0019BFF92@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0019BFF92@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List Subject: Re: [Sip] New text for ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 08:15:08 -0000 John, See inline. > I previously commented on the last sentence of the following text in > 5.1.1 (Contact header field) of draft-ietf-sip-ua-privacy-05: > " When using this header field in a dialog-forming request or response > or in a mid-dialog request or response, the user agent MUST anonymize > the Contact header field using an anonymous URI ("temp-gruu") > obtained through the GRUU mechanism, unless an equivalent functional > anonymous URI is provided by some other means. For out-of-dialog > request, anonymous URI MAY be set when anonymization is required." > > The reason for my comment was that I wasn't certain where the last > sentence would apply. The original intent of the sentence was to anonymize the Contact except for the REGISTER requests and 3xx responses, as you pointed out in November, but I agree that it is hard to tell from the current sentence. > > Of course, a REGISTER request or 200 response is "out of dialog", but > clearly an anonymized Contact URI is inappropriate. > > In addition I have identified the following requests: > - OPTIONS - Contact MAY be included. > - PUBLISH - Contact, if present, doesn't have any meaning in the context > of event publication. > - MESSAGE - Contact not allowed. The Contact header is not allowed in PUBLISH request, I believe. Therefore, the Contact in OPTIONS is the only case we should care as out-of-dialog request. > > Furthermore, non-dialog-forming responses to things like INVITE and > SUBSCRIBE do not require Contact, with the exception of 3xx where the > URI clearly cannot be anonymized. > > So how to cover this concisely? I would propose replacing the last > sentence above with the following: > > "For other requests and responses, with the exception of 3xx responses, > REGISTER requests and REGISTER 200 responses, the UA MUST either omit > the Contact header field or use an anonymous URI." > > Would this be acceptable? Have I captured all exceptions? This text is much clearer than the original text. I think this captures all the exceptions. If there is no more exceptions, I will replace the last sentence with your text. Thank you! Mayumi > > John > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From christer.holmberg@ericsson.com Thu Mar 5 01:10:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573EE28C1F3 for ; Thu, 5 Mar 2009 01:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.73 X-Spam-Level: X-Spam-Status: No, score=-5.73 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2E0sKQauwtg for ; Thu, 5 Mar 2009 01:10:28 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3746E28C1E4 for ; Thu, 5 Mar 2009 01:10:28 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0F87E20454; Thu, 5 Mar 2009 10:10:56 +0100 (CET) X-AuditID: c1b4fb3e-b00a2bb0000023da-44-49af971f5322 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DF9232019E; Thu, 5 Mar 2009 10:10:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 10:10:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 10:10:54 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-199-06.txt Thread-Index: AcmbMKe+xsFi6kj+QB+gB2v3KJUGbABMpvRQAEOYpKA= References: <20090302121502.4C42D3A6858@core3.amsl.com> From: "Christer Holmberg" To: "Bob Penfield" X-OriginalArrivalTime: 05 Mar 2009 09:10:55.0505 (UTC) FILETIME=[4A4B4810:01C99D72] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-ietf-sip-199-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 09:10:29 -0000 Hi Bob, =20 >I have few comments on draft-ietf-sip-199-06.txt. I apologize=20 >if any of these are duplicates. >=20 >Section 6. The statement requiring the proxy to keep track of=20 >early dialogs: >=20 > A proxy which supports generating of 199 response codes MUST keep > track of early dialogs, in order to determine whether to generate a > 199 response when the proxy receives a non-2xx final response. In > addition, the proxy MUST keep track on which early dialogs it has > received and forwarded 199 responses, in order to not generate > additional 199 responses for those early dialogs. >=20 >Should precede the statement: >=20 > If the forking proxy generates a 199 response, and if the > forking proxy is able to identify additional early dialogs=20 > which are terminated by the same non-2xx final response, it MUST=20 > also generate and send a 199 response upstream for each of those early dialogs, >=20 >In fact, if the proxy is keeping track of early dialogs,=20 >under what circumstances would it not be "able to identify=20 >additional early dialogs which are terminated by the same=20 >non-2xx final response"? Just because the proxy keeps track of early dialogs, it doesn't necessarily know that an error response on early dialog X also terminates early dialog Y. In order to know that, the forking proxy needs to know that early dialogs X and Y come from the same forking proxy further down the path. >Section 8 (199 Early Dialog Terminated) seems out of place.=20 >Shouldn't this be in the introduction? or in an "Overview Of=20 >Operation" between sections 3 and 4? I have tried to use other similar drafts as "template". >The text in Section 9 (Usage with SDP offer/answer) should be=20 >in section 5 (User Agent Server behavior). I think it is good to have a separate chapter. Of course, I could refer to chapter 9 from chapter 5. >The statement in section 10 recommending that the UAS send=20 >199 unreliably should be in section 5. >=20 >The statement in section 10 forbidding proxies from sending=20 >199 reliably should be in section 6 (Proxy behavior). Same as for offer/answer. Since the 199 procedures related to offer/answer and reliable responses are special, I think it is good to have specific chapters for it. Regards, Christer From rco@iptel.org Thu Mar 5 01:47:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CCF28C2F3 for ; Thu, 5 Mar 2009 01:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDhiLXb1RBcx for ; Thu, 5 Mar 2009 01:47:25 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 0556D28C1F5 for ; Thu, 5 Mar 2009 01:47:25 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id 65C281810C12; Thu, 5 Mar 2009 10:47:53 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id C55C21810C10; Thu, 5 Mar 2009 10:47:52 +0100 (CET) Message-ID: <49AF9FC8.2020200@iptel.org> Date: Thu, 05 Mar 2009 10:47:52 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing , sip@ietf.org References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> In-Reply-To: <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 09:47:25 -0000 Dan Wing wrote: > Thanks for publishing that attack. It has similarities with the attack > described by Hadriel in > http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack. > > Yes, it also modifies part of the request which are not signed by the authentication/signature algorithm. I should mention this draft in a later version. However, the goal is not the same. Hadriel's draft is focused on impersonation, whereby the other draft is focused on breaking the authentication done at the proxy. The second difference is that it works right now with any publicly reachable SIP provider. Raphael. From michael@voip.co.uk Thu Mar 5 01:55:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1295028C285 for ; Thu, 5 Mar 2009 01:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rsJr0-PKHwD for ; Thu, 5 Mar 2009 01:55:42 -0800 (PST) Received: from voip.co.uk (smtp.sov.voip.co.uk [80.249.108.49]) by core3.amsl.com (Postfix) with ESMTP id 275E93A690A for ; Thu, 5 Mar 2009 01:55:42 -0800 (PST) Message-ID: <49AFA1BB.2040602@voip.co.uk> Date: Thu, 05 Mar 2009 09:56:11 +0000 From: Michael Procter User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Raphael Coeffic References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> In-Reply-To: <49AF9FC8.2020200@iptel.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 09:55:43 -0000 Raphael Coeffic wrote: > Dan Wing wrote: >> Thanks for publishing that attack. It has similarities with the attack >> described by Hadriel in >> http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack. >> >> > Yes, it also modifies part of the request which are not signed by the > authentication/signature algorithm. I should mention this draft in a > later version. > > However, the goal is not the same. Hadriel's draft is focused on > impersonation, whereby the other draft is focused on breaking the > authentication done at the proxy. The second difference is that it > works right now with any publicly reachable SIP provider. > I'm intrigued by the variation in fig2. How often are you finding two proxies in different administrative domains that use the same credentials? Or is the attack more focussed towards Alice using multiple sets of credentials? I think that the variation in fig3 can be addressed to some degree by using GRUU, but I don't think that completely solves the problem. Regards, Michael From rco@iptel.org Thu Mar 5 01:59:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01EB28C372 for ; Thu, 5 Mar 2009 01:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8xlxHOwXQK4 for ; Thu, 5 Mar 2009 01:59:16 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id B835A3A69D0 for ; Thu, 5 Mar 2009 01:59:16 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id 356CC1810C12; Thu, 5 Mar 2009 10:59:45 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 2F9C51810C10; Thu, 5 Mar 2009 10:59:44 +0100 (CET) Message-ID: <49AFA28F.2030809@iptel.org> Date: Thu, 05 Mar 2009 10:59:43 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Michael Procter References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <49AFA1BB.2040602@voip.co.uk> In-Reply-To: <49AFA1BB.2040602@voip.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 09:59:17 -0000 Michael Procter wrote: > Raphael Coeffic wrote: > >> Dan Wing wrote: >> >>> Thanks for publishing that attack. It has similarities with the attack >>> described by Hadriel in >>> http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack. >>> >>> >>> >> Yes, it also modifies part of the request which are not signed by the >> authentication/signature algorithm. I should mention this draft in a >> later version. >> >> However, the goal is not the same. Hadriel's draft is focused on >> impersonation, whereby the other draft is focused on breaking the >> authentication done at the proxy. The second difference is that it >> works right now with any publicly reachable SIP provider. >> >> > > I'm intrigued by the variation in fig2. How often are you finding two > proxies in different administrative domains that use the same > credentials? Or is the attack more focussed towards Alice using > multiple sets of credentials? > > They are not using the same credentials, which is the reason why 'proxy.com' won't remove Alice's credentials from the request, and thus enable the attack. > I think that the variation in fig3 can be addressed to some degree by > using GRUU, but I don't think that completely solves the problem. > > I am not quite sure that I understand how this helps: could you develop your thoughts a little bit more? Regards, Raphael. From rco@iptel.org Thu Mar 5 02:03:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF8D28C37B for ; Thu, 5 Mar 2009 02:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[AWL=-1.681, BAYES_00=-2.599, FRT_INTEREST=3.579] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gojYK-vSTZze for ; Thu, 5 Mar 2009 02:03:31 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 6F7FF28C324 for ; Thu, 5 Mar 2009 02:03:31 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id 6AD571810C13; Thu, 5 Mar 2009 11:04:00 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 335371810C12; Thu, 5 Mar 2009 11:03:58 +0100 (CET) Message-ID: <49AFA38D.2000605@iptel.org> Date: Thu, 05 Mar 2009 11:03:57 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <28B7C3AA2A7ABA4A841F11217ABE78D674AD52CC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674AD52CC@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP IETF , Dean Willis Subject: Re: [Sip] Agenda call for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:03:32 -0000 Hello, Radu and I would like to present the relay attack draft recently published (http://tools.ietf.org/html/draft-state-sip-relay-attack-00). From the small feedback we became until now, it seems that there is some interrest in finding solutions, whereby the problem is clear. I think we need only 10 to 15 minutes. The question we'd like to ask is whether or not this is something we want to work on. We also had a discussion (between the authors, not on the list) whether the document should address both the issue and a possible solution, or whether this should be split into 2 separate documents. I tend to think that one document is enough. Regards Raphael Coeffic. DRAGE, Keith (Keith) wrote: > (As WG co chair) > > If you wish to have time allocated to a particular discussion in the SIP sessions in San Francisco, and have not already submitted a request, then please do so. > > Please include information like: > > - name(s) of any draft(s) to be discussed. > - proposed name of presenter > - what is/are the key question(s) to put to the WG as a result of the discussion. > - how much time you think you will need. > > Note that in addressing the third bullet we would like a bit more detail than "WG item?", for example give us some help in identifying the text for the milestone you actually want in the SIP charter, which is the problem you want to solve, rather than the solution. > > Please do this now as we will be putting the preliminary agenda together tomorrow (Thursday). Agendas are always subject to change but would prefer not to have any late surprises. > > regards > > Keith > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From jan@ryngle.com Thu Mar 5 02:59:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD123A6B26 for ; Thu, 5 Mar 2009 02:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6viU1p6NjLa for ; Thu, 5 Mar 2009 02:59:31 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id E15113A6AC9 for ; Thu, 5 Mar 2009 02:59:30 -0800 (PST) Received: by fxm24 with SMTP id 24so3287762fxm.37 for ; Thu, 05 Mar 2009 02:59:59 -0800 (PST) Received: by 10.223.112.130 with SMTP id w2mr815686fap.65.1236250799119; Thu, 05 Mar 2009 02:59:59 -0800 (PST) Received: from x61s.janakj ([213.192.30.143]) by mx.google.com with ESMTPS id 35sm13117687fkt.3.2009.03.05.02.59.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Mar 2009 02:59:58 -0800 (PST) Received: by x61s.janakj (Postfix, from userid 1000) id 9BEC14402C9; Thu, 5 Mar 2009 11:59:57 +0100 (CET) Date: Thu, 5 Mar 2009 11:59:57 +0100 From: Jan Janak To: Michael Procter Message-ID: <20090305105957.GA3991@x61s.janakj.ryngle.net> References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <49AFA1BB.2040602@voip.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49AFA1BB.2040602@voip.co.uk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:59:32 -0000 On 05-03 09:56, Michael Procter wrote: > Raphael Coeffic wrote: > > Dan Wing wrote: > >> Thanks for publishing that attack. It has similarities with the attack > >> described by Hadriel in > >> http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack. > >> > >> > > Yes, it also modifies part of the request which are not signed by the > > authentication/signature algorithm. I should mention this draft in a > > later version. > > > > However, the goal is not the same. Hadriel's draft is focused on > > impersonation, whereby the other draft is focused on breaking the > > authentication done at the proxy. The second difference is that it > > works right now with any publicly reachable SIP provider. > > > > I'm intrigued by the variation in fig2. How often are you finding two > proxies in different administrative domains that use the same > credentials? Or is the attack more focussed towards Alice using > multiple sets of credentials? Yes. The scenario in fig2 shows that such attack is possible even if Alice can receive SIP requests from its outbound proxy only (or one of its outbound proxies), either because her phone is configured so or because it is behind NAT. Even if the outbound proxy removes digest credentials that belong to its administrative domain before forwarding SIP requests downstream, you can still obtain digest credentials for another administrative domain through this outbound proxy from Alice if her phone is configured with multiple sets of credentials. If you have a phone which is configured to use two different ITSPs and has two sets of digest credentials then it is most likely vulnerable to this kind of attack. Jan. From michael@voip.co.uk Thu Mar 5 03:04:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDB53A69FA for ; Thu, 5 Mar 2009 03:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNudF-O4Qu4I for ; Thu, 5 Mar 2009 03:04:26 -0800 (PST) Received: from voip.co.uk (smtp.sov.voip.co.uk [80.249.108.49]) by core3.amsl.com (Postfix) with ESMTP id 53C0C3A6A83 for ; Thu, 5 Mar 2009 03:04:26 -0800 (PST) Message-ID: <49AFB1DA.6090108@voip.co.uk> Date: Thu, 05 Mar 2009 11:04:58 +0000 From: Michael Procter User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Raphael Coeffic References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <49AFA1BB.2040602@voip.co.uk> <49AFA28F.2030809@iptel.org> In-Reply-To: <49AFA28F.2030809@iptel.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 11:04:27 -0000 Raphael Coeffic wrote: > Michael Procter wrote: >> I'm intrigued by the variation in fig2. How often are you finding two >> proxies in different administrative domains that use the same >> credentials? Or is the attack more focussed towards Alice using >> multiple sets of credentials? >> >> > They are not using the same credentials, which is the reason why > 'proxy.com' won't remove Alice's credentials from the request, and > thus enable the attack. I see - it wasn't entirely clear from your text which case you were addressing. So that scenario is essentially the normal MITM digest attack. Whenever you receive a challenge, you can't really authenticate the server that is challenging you to determine whether you should issue a valid response or not. >> I think that the variation in fig3 can be addressed to some degree by >> using GRUU, but I don't think that completely solves the problem. >> > I am not quite sure that I understand how this helps: could you > develop your thoughts a little bit more? Sorry - I mistyped! What I meant to say was that 'outbound' addresses the problem to some degree. To expand on that a little, the key in fig3 is for Bob to be able to send a response directly to Alice, without going through the proxy. In the hosted scenario (which I considered first), Alice is typically behind a NAT/FW and uses outbound to maintain flows to proxy.com. As a consequence of this, Alice should only act upon responses received over these flows. This would defeat the attack in fig3, since Bob's altered response would probably not even reach Alice, let alone be acted upon. In the non-hosted scenario, where Alice and proxy.com are on the same network (i.e. without NAT/FW issues) such as might be the case in a typical enterprise deployment, then outbound wouldn't be used. But in this case, I would expect the enterprise firewall to prevent communications from Bob to Alice, except when mediated by an appropriate device (such as proxy.com). Again, the scenario in fig3 would be defeated. That isn't to say that the attack in fig3 isn't a real attack, only that I wouldn't expect most deployed networks to suffer from it. Regards, Michael From rco@iptel.org Thu Mar 5 03:12:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6D928C474 for ; Thu, 5 Mar 2009 03:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGS4UhNF5HIz for ; Thu, 5 Mar 2009 03:12:15 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id B052428C41F for ; Thu, 5 Mar 2009 03:12:14 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id ADA53181294A; Thu, 5 Mar 2009 12:12:42 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 05F741810C15; Thu, 5 Mar 2009 12:12:40 +0100 (CET) Message-ID: <49AFB3A8.2020506@iptel.org> Date: Thu, 05 Mar 2009 12:12:40 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Michael Procter References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <49AFA1BB.2040602@voip.co.uk> <49AFA28F.2030809@iptel.org> <49AFB1DA.6090108@voip.co.uk> In-Reply-To: <49AFB1DA.6090108@voip.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 11:12:16 -0000 Hello Michael, Michael Procter wrote: > Raphael Coeffic wrote: > >> Michael Procter wrote: >> >>> I'm intrigued by the variation in fig2. How often are you finding two >>> proxies in different administrative domains that use the same >>> credentials? Or is the attack more focussed towards Alice using >>> multiple sets of credentials? >>> >>> >>> >> They are not using the same credentials, which is the reason why >> 'proxy.com' won't remove Alice's credentials from the request, and >> thus enable the attack. >> > > I see - it wasn't entirely clear from your text which case you were > addressing. So that scenario is essentially the normal MITM digest > attack. Whenever you receive a challenge, you can't really authenticate > the server that is challenging you to determine whether you should issue > a valid response or not. > > That's true. The novelty is that such a MITM attack can be induced by SIP means, without to much interventions into the network topology (no DNS or ARP spoofing for example). >>> I think that the variation in fig3 can be addressed to some degree by >>> using GRUU, but I don't think that completely solves the problem. >>> >>> >> I am not quite sure that I understand how this helps: could you >> develop your thoughts a little bit more? >> > > Sorry - I mistyped! What I meant to say was that 'outbound' addresses > the problem to some degree. To expand on that a little, the key in fig3 > is for Bob to be able to send a response directly to Alice, without > going through the proxy. In the hosted scenario (which I considered > first), Alice is typically behind a NAT/FW and uses outbound to maintain > flows to proxy.com. As a consequence of this, Alice should only act > upon responses received over these flows. This would defeat the attack > in fig3, since Bob's altered response would probably not even reach > Alice, let alone be acted upon. > > In the non-hosted scenario, where Alice and proxy.com are on the same > network (i.e. without NAT/FW issues) such as might be the case in a > typical enterprise deployment, then outbound wouldn't be used. But in > this case, I would expect the enterprise firewall to prevent > communications from Bob to Alice, except when mediated by an appropriate > device (such as proxy.com). Again, the scenario in fig3 would be defeated. > > Imho, not necessarily. It is very easy to forge an IP (that of the proxy) if you only need one-way communication, which is the case for the 200 reply. This means that it should be quite easy to get this reply directly to Alice. The question is what Alice and the outbound proxy will do after that. > That isn't to say that the attack in fig3 isn't a real attack, only that > I wouldn't expect most deployed networks to suffer from it. > > You may be right. Best regards, Raphael. From lists@ohlmeier.org Thu Mar 5 05:40:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC483A68E3 for ; Thu, 5 Mar 2009 05:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-VTFZlbytx7 for ; Thu, 5 Mar 2009 05:40:28 -0800 (PST) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 92B923A679C for ; Thu, 5 Mar 2009 05:40:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 1F9107F97; Thu, 5 Mar 2009 14:40:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciAKwjDAVMtM; Thu, 5 Mar 2009 14:40:54 +0100 (CET) Received: from www.ohlmeier.com (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 96E2C7F82; Thu, 5 Mar 2009 14:40:54 +0100 (CET) Received: from 192.100.130.229 (SquirrelMail authenticated user lando) by www.ohlmeier.com with HTTP; Thu, 5 Mar 2009 14:40:54 +0100 (CET) Message-ID: In-Reply-To: <49AE593F.6080807@iptel.org> References: <49AE593F.6080807@iptel.org> Date: Thu, 5 Mar 2009 14:40:54 +0100 (CET) From: "Nils Ohlmeier" To: "Raphael Coeffic" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 13:40:29 -0000 Hello, first of all I agree that the draft describes a potential problem. One thing which is not that obvious but is implictly a requirement for the attack: the proxies has to challenge in-dialog requests. I do not see a big benefit in challeging in-dialog requests as these are hopefully rejected by the remote side if no matching dialog exists. If the UA would know that his proxy does not challenge in-dialog requests it could simply ignore the challenge :-) Some more comments: Figure 1: - As the draft already states this direct attack becomes inpossible if Alice UA accepts incoming requests only from one of its proxys (we have to keep in mind that we rely here on pure IP layer security which is weak as we all know). - Additionally Alice UA should notice that the call got established without a route set. And without any Route set I would not see why the UA should get a challenge at all. But I admit that such a check most likely does not exist in UA today. Figure 2: - If p2.com uses a different realm then proxy.com you should mention in your draft that Bob needs to know that Alice has accounts configured for both servers in her UA. - I never unterstood why a proxy should pass through the authentication request from a foreign domain. In which scenario do I have credentials for two different domains, but the traffic including authentication is passed through only one of them? Sure I could have a call forwarding from p2.com to proxy.com. Again only if p2.com challenges in-dialog requests the problem arrises with this call forwarding. - Another possible improvement for an UA would be to strictly bind the credentials to one proxy. Which means it would only answer challenges for proxy.com if the request came IP wise from proxy.com and it would not answer challenges for other proxies if they arrive IP wise from proxy.com. This improvement does not work if you use daisy chained proxy with authentication for outbound calls (but I have never seen or heard of such a setup), or if the proxy with active call forwarding challenges in-dialog requests. - If we admit that this authentication pass through is of no real use, either Alice UA could ignore it, or proxy.com could simply strip the authentication from the foreign domain p2.com. - If we still need authentication pass through proxy.com could at least check that it does not pass through challenges with the same realm as its own one (which brakes daisy chains of challenging proxy with identical realms - which is hopefully not too comon). I admit that my comments are no real solution for the problem itself and some of them would first need to be implemented. But hopefully they help to improve the situation. Regards Nils Ohlmeier VoIP Freelancer > Hello, > > a new internet draft has been published concerning the relay attack on > digest authentication and SIP. The attack itself has been first > disclosed 2 years ago by the maydnes team from the french INRIA. Until > now, no document has been pushlished that documents the attack and > provides guidance to SIP operators or handset manufacturers. > > http://tools.ietf.org/html/draft-state-sip-relay-attack-00 > > The appropriate mitigations of problem resolutions are still not 100% > clear. We hope that this draft can help start a discussion on how to > best resolve this problem. > > > Regards, > > Raphael Coeffic. > (on behalf of all the authors of this draft) > > --------------------------------------------------------------------------------------------------- > > Filename: draft-state-sip-relay-attack > Version: 00 > Staging URL: > http://www3.ietf.org/proceedings/staging/draft-state-sip-relay-attack-00.txt > Title: SIP digest authentication relay attack > Creation_date: 2009-03-02 > WG ID: Indvidual Submission > Number_of_pages: 18 > Abstract: > The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism > for creating, modifying, and terminating sessions with one or more > participants. This document describes a vulnerability of SIP > combined with HTTP Digest Access Authentication [RFC2617] through > which an attacker can leverage the victim's credentials to send > authenticated requests on his behalf. This attack is different from > the man-in-the-middle (MITM) attack and does not require any > eavesdropping, DNS or IP spoofing. > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > From theo@crazygreek.co.uk Thu Mar 5 06:30:39 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F17128C185 for ; Thu, 5 Mar 2009 06:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.345 X-Spam-Level: X-Spam-Status: No, score=-5.345 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIBRwJAJOS5H for ; Thu, 5 Mar 2009 06:30:37 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id D62A828C1E6 for ; Thu, 5 Mar 2009 06:30:36 -0800 (PST) Received: from source ([72.14.220.154]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSa/iKjkMRw3ZdY0wSfmhtaeeyu0HkK8s@postini.com; Thu, 05 Mar 2009 06:31:07 PST Received: by fg-out-1718.google.com with SMTP id 13so375215fge.20 for ; Thu, 05 Mar 2009 06:31:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.76.20 with SMTP id y20mr993782fga.62.1236263465434; Thu, 05 Mar 2009 06:31:05 -0800 (PST) In-Reply-To: <49AE593F.6080807@iptel.org> References: <49AE593F.6080807@iptel.org> Date: Thu, 5 Mar 2009 14:31:05 +0000 Message-ID: <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> From: Theo Zourzouvillys To: Raphael Coeffic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 14:30:39 -0000 On Wed, Mar 4, 2009 at 10:34 AM, Raphael Coeffic wrote: > The appropriate mitigations of problem resolutions are still not 100% clear. > We hope that this draft can help start a discussion on how to best resolve > this problem. After more thinking about this, I don't think this document presents anything other than there are poorly implemented SIP endpoints and proxies out there - as there is nothing wrong with SIP itself [1] in these attacks: It all boils down to UA vendors currently giving credentials to anyone who asks for them, even if they shouldn't be. All of the scenarios you mention in this document apply directly to proxy authentication in the case where a UA would use outbound authentication with it's proxy. A UA only ever sending proxy credentials to it's proxy seems like a dead simple and sensible thing to do (and although i'm not really surprised UAs don't do this, i'll pretend to be), and makes all the attacks you list just go away. The only issue i see is in fig 3, how to identify a next hop is actually proxy.com and not bob, as a proxy will commonly RR with a URI such as node-01.proxy.com instead of proxy.com, or even use an IP address in it. The first, and most and correct way is use TLS or DTLS with mutual auth, and you can verify that the next hop is really your proxy and thus it's ok to send credentials to it. The second way is to always send requests to proxy.com (i.e, using outboind), even in dialog ones (and indeed many UAs have a "send in-dialog requests via outbound proxy" option,which makes this attack go away) - although this might breaks some broken SBCs out there that SPs deploy today. The third option (and most ickly and hacky) it to build and keep a whitelist of IP addresses that proxy.com is, and ensure the SP only ever record-routes using an IP address that a forward lookup on proxy.com would resolve to. crappy but in reality mostly works today, as long as devices are sensible and do things like refresh after TTLs expire on RRsets. So, what does need to be done is beat UA vendors and SIP operators with a great big security clue stick (how that's done i'd love to know. My stick is almost broken, and even when applied directly, mostly ineffective.) - perhaps a BCP to highlight the issues? However, you don't cover the more interesting cases of multi-hop proxy authentication or end-to-end WWW authentication: these are the harder ones to deal with, and may result in some "real" issues in SIP itself rather than shoddy implementations and insecure proxies. ~ Theo 1 - heh. sarcasm. From rco@iptel.org Thu Mar 5 06:41:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401BC3A6964 for ; Thu, 5 Mar 2009 06:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0Cf7OhwbP4F for ; Thu, 5 Mar 2009 06:41:24 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E92503A6A14 for ; Thu, 5 Mar 2009 06:41:23 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id 52B481812D5B; Thu, 5 Mar 2009 15:41:52 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 3C2A21812D3F; Thu, 5 Mar 2009 15:41:51 +0100 (CET) Message-ID: <49AFE4AE.5020109@iptel.org> Date: Thu, 05 Mar 2009 15:41:50 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Theo Zourzouvillys References: <49AE593F.6080807@iptel.org> <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> In-Reply-To: <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 14:41:25 -0000 Hi Theo, I really think that mutual authentication is the way to go. Unfortunatly, there is nothing deployed in this direction right now. Most providers (at least in germany) try to tackle those issues by separating networks. The SIP phones are then jailed into things like dedicated virtual circuits (on the DSL level). On the provider-side, they use the full panel of firewalls to get the full control of everything. This is definitely not the way to go. Having the BCP gathered into this document (or another one, I don't care) would be a good thing to do. If you let people think by themselves, you might end-up with the situation we have right now. Theo Zourzouvillys wrote: > On Wed, Mar 4, 2009 at 10:34 AM, Raphael Coeffic wrote: > >> The appropriate mitigations of problem resolutions are still not 100% clear. >> We hope that this draft can help start a discussion on how to best resolve >> this problem. >> > > After more thinking about this, I don't think this document presents > anything other than there are poorly implemented SIP endpoints and > proxies out there - as there is nothing wrong with SIP itself [1] in > these attacks: It all boils down to UA vendors currently giving > credentials to anyone who asks for them, even if they shouldn't be. > > > All of the scenarios you mention in this document apply directly to > proxy authentication in the case where a UA would use outbound > authentication with it's proxy. A UA only ever sending proxy > credentials to it's proxy seems like a dead simple and sensible thing > to do (and although i'm not really surprised UAs don't do this, i'll > pretend to be), and makes all the attacks you list just go away. > > The only issue i see is in fig 3, how to identify a next hop is > actually proxy.com and not bob, as a proxy will commonly RR with a URI > such as node-01.proxy.com instead of proxy.com, or even use an IP > address in it. The first, and most and correct way is use TLS or DTLS > with mutual auth, and you can verify that the next hop is really your > proxy and thus it's ok to send credentials to it. The second way is > to always send requests to proxy.com (i.e, using outboind), even in > dialog ones (and indeed many UAs have a "send in-dialog requests via > outbound proxy" option,which makes this attack go away) - although > this might breaks some broken SBCs out there that SPs deploy today. > The third option (and most ickly and hacky) it to build and keep a > whitelist of IP addresses that proxy.com is, and ensure the SP only > ever record-routes using an IP address that a forward lookup on > proxy.com would resolve to. crappy but in reality mostly works today, > as long as devices are sensible and do things like refresh after TTLs > expire on RRsets. > > So, what does need to be done is beat UA vendors and SIP operators > with a great big security clue stick (how that's done i'd love to > know. My stick is almost broken, and even when applied directly, > mostly ineffective.) - perhaps a BCP to highlight the issues? > > However, you don't cover the more interesting cases of multi-hop proxy > authentication or end-to-end WWW authentication: these are the harder > ones to deal with, and may result in some "real" issues in SIP itself > rather than shoddy implementations and insecure proxies. > > If you provide me with the input, I'd be very happy to document those issues. Regards Raphael. From dworley@nortel.com Thu Mar 5 07:25:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF793A68B0 for ; Thu, 5 Mar 2009 07:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iojJNLfFLzgY for ; Thu, 5 Mar 2009 07:25:13 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 94FAB3A6899 for ; Thu, 5 Mar 2009 07:25:13 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n25FPPA03220; Thu, 5 Mar 2009 15:25:25 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 10:25:39 -0500 From: "Dale Worley" To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0019BFFA2@GBNTHT12009MSX.gb002.siemens.net> References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0019BFFA2@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 05 Mar 2009 10:25:36 -0500 Message-Id: <1236266736.3730.4.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2009 15:25:39.0371 (UTC) FILETIME=[A3B8F7B0:01C99DA6] Cc: SIP Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:25:16 -0000 On Thu, 2009-03-05 at 08:16 +0000, Elwell, John wrote: > What about non-INVITEs? Provisional responses are designed for INVITEs > and I am not certain about their applicability to non-INVITEs. Yes, provisional responses to non-INVITEs may be slightly out of specification, but I don't expect any SIP element to malfunction if it receives a provisional response to a non-INVITE request. OTOH, I would expect most uses of 'trace' to be attached to INVITEs, although that makes me think that tracing an OPTIONS might be a useful test tool. (Which leads to an unexpected observation: RFC 3261 presupposes that all non-INVITE responses are processed promptly, but in the face of transport errors, this is not always so. In sipX, we've adjusted transaction handling so that if a re-send of a non-INVITE message is seen the recipient sends a 100 to quench further re-sends. It seems to work exactly as expected, and noticeably reduces re-sends in situations with transport errors.) > In the case of INVITE, what about Contact? Is it permissible to send a > 1xx (other than 100) without a Contact URI? RFC 3261 seems to indicate > it is optional in a 1xx, but that might be solely to cater for omission > in 100. The Contact value of a 170 should never be used, so it doesn't really matter if one is provided, or if it is usable. OTOH, every SIP element should be able to create a usable Contact URI. Dale From BPenfield@acmepacket.com Thu Mar 5 07:30:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F393A69D6 for ; Thu, 5 Mar 2009 07:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i-vuwINhVc6 for ; Thu, 5 Mar 2009 07:30:14 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C99543A697D for ; Thu, 5 Mar 2009 07:30:13 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 5 Mar 2009 10:30:41 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 5 Mar 2009 10:30:42 -0500 From: Bob Penfield To: Christer Holmberg Date: Thu, 5 Mar 2009 10:30:40 -0500 Thread-Topic: [Sip] I-D Action:draft-ietf-sip-199-06.txt Thread-Index: AcmbMKe+xsFi6kj+QB+gB2v3KJUGbABMpvRQAEOYpKAADKsk4A== Message-ID: References: <20090302121502.4C42D3A6858@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] I-D Action:draft-ietf-sip-199-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:30:15 -0000 inline >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Thursday, March 05, 2009 4:11 AM >To: Bob Penfield >Cc: sip@ietf.org >Subject: RE: [Sip] I-D Action:draft-ietf-sip-199-06.txt > > >Hi Bob, > >>I have few comments on draft-ietf-sip-199-06.txt. I apologize >>if any of these are duplicates. >> >>Section 6. The statement requiring the proxy to keep track of >>early dialogs: >> >> A proxy which supports generating of 199 response codes MUST keep >> track of early dialogs, in order to determine whether to generate a >> 199 response when the proxy receives a non-2xx final response. In >> addition, the proxy MUST keep track on which early dialogs it has >> received and forwarded 199 responses, in order to not generate >> additional 199 responses for those early dialogs. >> >>Should precede the statement: >> >> If the forking proxy generates a 199 response, and if the >> forking proxy is able to identify additional early dialogs >> which are terminated by the same non-2xx final response, it MUST >> also generate and send a 199 response upstream for each of those >> early dialogs, >> >>In fact, if the proxy is keeping track of early dialogs, >>under what circumstances would it not be "able to identify >>additional early dialogs which are terminated by the same >>non-2xx final response"? > >Just because the proxy keeps track of early dialogs, it doesn't >necessarily know that an error response on early dialog X also >terminates early dialog Y. In order to know that, the forking proxy >needs to know that early dialogs X and Y come from the same forking >proxy further down the path. > Of course it can. If the proxy forwarded the request to Z, and Z forked to X and Y, the provisional responses from X and Y that created the early dialogs would have the same branch-id. The error response from Z would have that same branch-id. The proxy would know that all early dialogs created by a 1xx with that branch-id would have terminated (i.e. both X and Y). > >>Section 8 (199 Early Dialog Terminated) seems out of place. >>Shouldn't this be in the introduction? or in an "Overview Of >>Operation" between sections 3 and 4? > >I have tried to use other similar drafts as "template". > > >>The text in Section 9 (Usage with SDP offer/answer) should be >>in section 5 (User Agent Server behavior). > >I think it is good to have a separate chapter. Of course, I could refer >to chapter 9 from chapter 5. My point is that all too often behavior requirements (MUST, SHOULD, MAY, etc.) get buried is separate sections and folks can miss them. If all the requirements are in the applicable "behavior" section, they are easy to find and developers are less likely to miss them. If you want it to be a separate section, make it 5.1. All UAS requirements should be in section 5 or a subsection thereof. > >>The statement in section 10 recommending that the UAS send >>199 unreliably should be in section 5. >> >>The statement in section 10 forbidding proxies from sending >>199 reliably should be in section 6 (Proxy behavior). > >Same as for offer/answer. > >Since the 199 procedures related to offer/answer and reliable responses >are special, I think it is good to have specific chapters for it. > The requirements/restrictions for reliable provisional responses are very important. They could easily be missed by having them in a separate chapter in the back of the document. Again, all UAS behavior requirements should be in section 5 (or sub-section) and all proxy behavior requirements should be in chapter 6 (or sub-section). >Regards, > >Christer > cheers, (-:bob From dwing@cisco.com Thu Mar 5 07:35:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D78C3A6923 for ; Thu, 5 Mar 2009 07:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGQ0ViwUe6qA for ; Thu, 5 Mar 2009 07:35:52 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B95EA3A6899 for ; Thu, 5 Mar 2009 07:35:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,307,1233532800"; d="scan'208";a="151322814" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Mar 2009 15:36:22 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n25FaMLU021308; Thu, 5 Mar 2009 07:36:22 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n25FaMWL020059; Thu, 5 Mar 2009 15:36:22 GMT From: "Dan Wing" To: "'Raphael Coeffic'" , References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> Date: Thu, 5 Mar 2009 07:36:22 -0800 Message-ID: <0e1301c99da8$22fea4b0$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <49AF9FC8.2020200@iptel.org> Thread-Index: Acmdd4G7g2a4/PiNRnSBEPng0ErZSQAMCMnQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=839; t=1236267382; x=1237131382; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20draft-state-sip-relay-attack-00 |Sender:=20; bh=m+HeG6raVnQSnl5gwUKD/O5DQJEjbkPBmoinb4a9Us0=; b=uRkq/4QsX0VGKnKlbPgPIphUNBffEiFumNNNuFzw5zQguArHu5lyiYpgRt gLgsEcfwhE+3vR+o5Yah30A0SjiT81F7NSirCB/lSuMlKUriZ+TDtvzXnYNX WbJ/UbmF5i; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:35:53 -0000 > Dan Wing wrote: > > Thanks for publishing that attack. It has similarities > > with the attack described by Hadriel in > > http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack. > > Yes, it also modifies part of the request which are not signed by the > authentication/signature algorithm. I should mention this draft in a > later version. > > However, the goal is not the same. Hadriel's draft is focused on > impersonation, whereby the other draft is focused on breaking the > authentication done at the proxy. By breaking the authentication the attacker can impersonate another user. For example, that proxy might create an RFC4474 signature. > The second difference is that it works right now with any > publicly reachable SIP provider. Yes, I agree that makes it much more interesting. -d From rco@iptel.org Thu Mar 5 07:45:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5C03A68B0 for ; Thu, 5 Mar 2009 07:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvkNWZJYAN+y for ; Thu, 5 Mar 2009 07:45:25 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 6AA0E3A6899 for ; Thu, 5 Mar 2009 07:45:25 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id 247731812D3F; Thu, 5 Mar 2009 16:45:54 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 57FE61812D3D; Thu, 5 Mar 2009 16:45:53 +0100 (CET) Message-ID: <49AFF3B0.4060501@iptel.org> Date: Thu, 05 Mar 2009 16:45:52 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Wing References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <0e1301c99da8$22fea4b0$c2f0200a@cisco.com> In-Reply-To: <0e1301c99da8$22fea4b0$c2f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:45:26 -0000 Dan Wing wrote: >> Dan Wing wrote: >> >>> Thanks for publishing that attack. It has similarities >>> with the attack described by Hadriel in >>> http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack. >>> >> Yes, it also modifies part of the request which are not signed by the >> authentication/signature algorithm. I should mention this draft in a >> later version. >> >> However, the goal is not the same. Hadriel's draft is focused on >> impersonation, whereby the other draft is focused on breaking the >> authentication done at the proxy. >> > > By breaking the authentication the attacker can impersonate > another user. For example, that proxy might create an RFC4474 > signature. > > Another interresting application indeed! As it looks like, a lot of people on the list have very good ideas that we will have to document in version 01 (if it is the will of the WG, of course!). Regards Raphael. >> The second difference is that it works right now with any >> publicly reachable SIP provider. >> > > Yes, I agree that makes it much more interesting. > > -d > > From theo@crazygreek.co.uk Thu Mar 5 08:01:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA793A6809 for ; Thu, 5 Mar 2009 08:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+MsY7Sjz56k for ; Thu, 5 Mar 2009 08:01:19 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id 79C7228C1A0 for ; Thu, 5 Mar 2009 08:01:19 -0800 (PST) Received: from source ([72.14.220.153]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSa/3bZ3tHJy3zlc6kXxar44/x6Jzw0zF@postini.com; Thu, 05 Mar 2009 08:01:49 PST Received: by fg-out-1718.google.com with SMTP id d23so438642fga.26 for ; Thu, 05 Mar 2009 08:01:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.98.18 with SMTP id v18mr1110635fgb.46.1236268908151; Thu, 05 Mar 2009 08:01:48 -0800 (PST) In-Reply-To: <49AFE4AE.5020109@iptel.org> References: <49AE593F.6080807@iptel.org> <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> <49AFE4AE.5020109@iptel.org> Date: Thu, 5 Mar 2009 16:01:47 +0000 Message-ID: <167dfb9b0903050801h4d48f0q253daf7a6c1ee391@mail.gmail.com> From: Theo Zourzouvillys To: Raphael Coeffic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:01:20 -0000 On Thu, Mar 5, 2009 at 2:41 PM, Raphael Coeffic wrote: > I really think that mutual authentication is the way to go. MTLS is indeed a good way to go for so many reasons, but it's not the only way this can be fixed. For the fig 3 attack, receiving the response down the same stream oriented connection indicates it came form the proxy, not the attacker. In the case of datagram, an adjustment to draft-zourzouvillys-via-cookies to get the proxy to re-add the cookie value in the response would solve the direct-to-source response scenario without having the evil DNS lookup hacks in place. > Having the BCP gathered into this document (or another one, I don't care) > would be a good thing to do. If you let people think by themselves, you > might end-up with the situation we have right now. We'll end up with insecure implementations whatever we do - although education is the key to minimising them. > If you provide me with the input, I'd be very happy to document those > issues. i'll see if i can find time :-) ~ Theo From HKaplan@acmepacket.com Thu Mar 5 08:32:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65953A6940 for ; Thu, 5 Mar 2009 08:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaWFpwzPfWX0 for ; Thu, 5 Mar 2009 08:32:36 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D39793A697D for ; Thu, 5 Mar 2009 08:32:35 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 5 Mar 2009 11:33:04 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 5 Mar 2009 11:33:04 -0500 From: Hadriel Kaplan To: Raphael Coeffic , Dan Wing , "sip@ietf.org" Date: Thu, 5 Mar 2009 11:33:00 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: Acmdd4w6EPMUR4CtQUGDmHG4eYyssAANZOJw Message-ID: References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> In-Reply-To: <49AF9FC8.2020200@iptel.org> 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: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:32:36 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Raphael Coeffic > Sent: Thursday, March 05, 2009 4:48 AM > > The second difference is that it works > right now with any publicly reachable SIP provider. I think I know what you mean by this statement, but maybe I don't. I think= you mean it "works" right now only on a publicly reachable SIP provider th= at accepts INVITE requests from non-Registered Contacts. No? Or do you me= an you've done testing of all publicly reachable SIP providers and found th= is to be an issue for all of them, right now? Since the REGISTERs are almost always challenged, this attack is not an iss= ue for providers which reject INVITEs from non-Registered Contacts. Since = SBC's have offered that restriction policy for at least the past 5 years, a= nd presumably outbound-proxies do too (because it's a very popular policy),= then you're really only talking about a theoretical subset of publicly rea= chable SIP Providers right now. And this is not to say the attack isn't interesting, or that publicly reach= able SIP providers actually *use* such security policies. I've been surpri= sed before about how some of them don't actually employ the security mechan= isms they have at their disposal. But not using available mechanisms is ve= ry different from not having a way to do them. -hadriel From HKaplan@acmepacket.com Thu Mar 5 08:43:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760C13A6A50 for ; Thu, 5 Mar 2009 08:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsHfYVcfDF8f for ; Thu, 5 Mar 2009 08:43:43 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7D3D03A6861 for ; Thu, 5 Mar 2009 08:43:43 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 5 Mar 2009 11:44:12 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 5 Mar 2009 11:44:12 -0500 From: Hadriel Kaplan To: Theo Zourzouvillys , Raphael Coeffic Date: Thu, 5 Mar 2009 11:44:11 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmdnxAGpRTlhGCWTWK1YvhupwYycwAES1zA Message-ID: References: <49AE593F.6080807@iptel.org> <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> In-Reply-To: <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:43:44 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of The= o > Zourzouvillys > Sent: Thursday, March 05, 2009 9:31 AM > > The only issue i see is in fig 3, how to identify a next hop is > actually proxy.com and not bob, as a proxy will commonly RR with a URI > such as node-01.proxy.com instead of proxy.com, or even use an IP > address in it. ... The second way is > to always send requests to proxy.com (i.e, using outboind), even in > dialog ones (and indeed many UAs have a "send in-dialog requests via > outbound proxy" option,which makes this attack go away) - although > this might breaks some broken SBCs out there that SPs deploy today. Ummm... in what way? The SBC *is* the outbound proxy. And figure-3 isn't = possible since clearly SBC's remove Alice's Via and Contact URI's, such tha= t Bob won't know how to bypass the SBC to reach Alice. And if the SBC does= n't do that, then you're right it's broken, and technically not an SBC but = more like a 3GPP P-CSCF. (And I heave heard some "SBC's" are really inline= as ALG's, but the ALG model is known to be broken in real-world SIP use) -hadriel From theo@crazygreek.co.uk Thu Mar 5 08:49:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754CC3A6A79 for ; Thu, 5 Mar 2009 08:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.673 X-Spam-Level: X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqvemVIW3Qyy for ; Thu, 5 Mar 2009 08:48:59 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with SMTP id 009133A6A50 for ; Thu, 5 Mar 2009 08:48:57 -0800 (PST) Received: from source ([72.14.220.157]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSbACl5whP1Is/5TYpx1PGYxfuWABHhY/@postini.com; Thu, 05 Mar 2009 08:49:28 PST Received: by fg-out-1718.google.com with SMTP id l26so421272fgb.27 for ; Thu, 05 Mar 2009 08:49:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.74.15 with SMTP id w15mr637087fga.1.1236271766270; Thu, 05 Mar 2009 08:49:26 -0800 (PST) In-Reply-To: References: <49AE593F.6080807@iptel.org> <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> Date: Thu, 5 Mar 2009 16:49:26 +0000 Message-ID: <167dfb9b0903050849p169e609bs4aaaf6d9af9894a8@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:49:00 -0000 On Thu, Mar 5, 2009 at 4:44 PM, Hadriel Kaplan wro= te: > And if the SBC doesn't do that, > then you're right it's broken, and technically not an SBC but more like a= 3GPP P-CSCF. =A0(And I heave heard some "SBC's" are really inline as ALG's= , but the ALG model is known to be broken in real-world SIP use) Indeed this is what i was referring too - although i'm sure there are other types that are just as broken, not *all* vendors make SBCs that work well. if only we had a name for our rhinos, giraffes and gazelle, then we'd be able to call them by their names, rather than just "aniamls". :-) ~ Theo From john.elwell@siemens.com Thu Mar 5 09:14:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C530928C29E for ; Thu, 5 Mar 2009 09:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZHc1v9iE4cn for ; Thu, 5 Mar 2009 09:14:04 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id C91E43A6A50 for ; Thu, 5 Mar 2009 09:14:04 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KG100K7XMK9RY@siemenscomms.co.uk> for sip@ietf.org; Thu, 05 Mar 2009 17:14:33 +0000 (GMT) Date: Thu, 05 Mar 2009 17:14:30 +0000 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , SIP Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019C04BD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmdKVN6VC4AVHKUQf2H8rHvdLSL3AAjB6vw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:14:05 -0000 Hadriel, Should we specify something that would make life easier for proxies/B2BUAs to detect compliance with this, e.g., a magic string at the start of the call-ID, rather than simply the absence of "@"? John=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: 05 March 2009 00:29 > To: SIP > Subject: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt >=20 > Howdy, > In an effort to avoid endless thrashing, I will be updating=20 > the Session-ID draft to only be about troubleshooting use. > For dialog matching issues, I have followed Adam's advice and=20 > submitted a separate draft to update RFC 3261, linked below. > This issue will only get worse, and the code changes to do=20 > this should be fairly small for most folks, I would think. > And it's only 6 pages, so we should be able to agree on this=20 > in about 3 years. :) >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : A Secure Call-ID for the Session=20 > Initiation Protocol (SIP) > Author(s) : H. Kaplan > Filename : draft-kaplan-sip-secure-call-id-00.txt > Pages : 6 > Date : 2009-03-04 >=20 > Many SIP devices generate Call-ID values which contain their=20 > system IP Address, due to examples and normative text in RFC=20 > 3261. This has led to some middleboxes, such as SBC's, to=20 > change the Call-ID for security reasons. This draft updates=20 > RFC 3261 to require SIP User Agents to generate benign=20 > Call-IDs, in such a manner that they can be detected as=20 > secure and not need to be changed. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-sip-secure-ca > ll-id-00.txt >=20 >=20 > -hadriel > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From HKaplan@acmepacket.com Thu Mar 5 15:43:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998A13A69EA for ; Thu, 5 Mar 2009 15:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hdDRQpLGGii for ; Thu, 5 Mar 2009 15:43:49 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BA5283A69AB for ; Thu, 5 Mar 2009 15:43:49 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 5 Mar 2009 18:44:18 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 5 Mar 2009 18:44:18 -0500 From: Hadriel Kaplan To: "Elwell, John" , SIP Date: Thu, 5 Mar 2009 18:44:17 -0500 Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmdKVN6VC4AVHKUQf2H8rHvdLSL3AAjB6vwAAuCEAA= Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D0019C04BD@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0019C04BD@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 23:43:50 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Thursday, March 05, 2009 12:15 PM > > Should we specify something that would make life easier for > proxies/B2BUAs to detect compliance with this, e.g., a magic string at > the start of the call-ID, rather than simply the absence of "@"? At one point I was thinking of just making it either be an "invalid" host: Call-ID: randomstuffheregibberish@invalid Or a fixed-length hex-ascii type thing (like Session-ID). But then someone= pointed out to me that some devices already don't put their IP/host in it,= so there's no reason to go make them change their implementation, nor repl= ace their call-id until they do. The thing is I think that a proxy/b2bua which cares about this for security= properties, would need/want to scan the whole call-id for something which = looks like a host/IP anyway, to make a dynamic decision. So having a magic= string won't help them. And B2BUA's which change it for non-security reas= ons will change it no matter what, because it's not the privacy property th= ey care about. -hadriel From theo@crazygreek.co.uk Thu Mar 5 16:35:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3312B28C0FC for ; Thu, 5 Mar 2009 16:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O3EMwXyGh-d for ; Thu, 5 Mar 2009 16:35:58 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with SMTP id 23A703A67B6 for ; Thu, 5 Mar 2009 16:35:58 -0800 (PST) Received: from source ([72.14.220.153]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSbBwDLfxQ53k6ViaADhY58fYMbms8pGh@postini.com; Thu, 05 Mar 2009 16:36:28 PST Received: by fg-out-1718.google.com with SMTP id l26so529460fgb.39 for ; Thu, 05 Mar 2009 16:36:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.31.18 with SMTP id e18mr1445748fge.72.1236299787404; Thu, 05 Mar 2009 16:36:27 -0800 (PST) In-Reply-To: References: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> <6EF7E0CD-58D2-4218-9408-1FC584DE7C04@softarmor.com> <1236200991.3771.45.camel@victoria-pingtel-com.us.nortel.com> Date: Fri, 6 Mar 2009 00:36:27 +0000 Message-ID: <167dfb9b0903051636j1d491aaep47ce2893938bbc7e@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIP , Dean Willis Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 00:35:59 -0000 On Wed, Mar 4, 2009 at 10:54 PM, Hadriel Kaplan wr= ote: > How about: ignorance is bliss? =A0:) > > Seriously, what does RFC 3986 do?? The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. > How does it affect anything for common URI formats not to comply with it? We'd be saying that a SIP URI is no longer guaranteed to be compatible with the generic URI syntax, and there in lies dragons. While it would unlikely have any direct effect on SIP elements themselves, there are a whole bunch of assumptions made (and we should be able to continue to make) around a SIP URI being compatible with the syntax of a URI, notably in 3rd party tools. some things that spring to mind that would be affected are: - XML Schema syntax for a URI - in - i.e, any hyperlink on a HTML page. - PHP (or any other language) parse_uri() - draft-roach-sip-http-subscribe Link header values - subjectAltName URI in a SSL certificate - a RDBMS "URI" data type ... being able to put a SIP URI anywhere that there is a "URI" field is a fairly useful thing for developers when it comes to re-usability even worse, anything that presumes they are a URI will work most the time, until an IPv6 address is used. > (or really, for *it* not to comply with common URI formats) i'm not sure how many other common URI formats have notably been affected by the missing IPv6 yet: the lack of universal IPv6 deployment along with SIP being fairly likely to want to include literal IPv6 addresses in the URI makes it more obvious for us to notice other other schemes, so perhaps we're just ahead of the game? ~ Theo From munakata.mayumi@lab.ntt.co.jp Thu Mar 5 16:56:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE8C28C1BC for ; Thu, 5 Mar 2009 16:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdX+3TFro5tn for ; Thu, 5 Mar 2009 16:56:31 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 5064228C1F7 for ; Thu, 5 Mar 2009 16:56:31 -0800 (PST) Received: (qmail 41762 invoked by alias); 6 Mar 2009 00:57:00 -0000 Received: from gwall1.bb.ntt-at.co.jp (192.168.5.201) by subgate.bb.ntt-at.co.jp with SMTP; 6 Mar 2009 00:57:00 -0000 Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id n260uT5R024151 for sip@ietf.org; Fri, 6 Mar 2009 09:56:29 +0900 Received: from suez.bb.ntt-at.co.jp [192.168.2.9] by gwall1.bb.ntt-at.co.jp with ESMTP id KAA24148; Fri, 6 Mar 2009 09:56:29 +0900 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id n260uSfs019853 for ; Fri, 6 Mar 2009 09:56:29 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id n260uTex059367 for ; Fri, 6 Mar 2009 09:56:29 +0900 (JST) (envelope-from munakata.mayumi@lab.ntt.co.jp) Received: from [127.0.0.1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 1C9E520807E; Fri, 6 Mar 2009 09:56:29 +0900 (JST) Message-ID: <49B074BD.4000102@lab.ntt.co.jp> Date: Fri, 06 Mar 2009 09:56:29 +0900 From: Mayumi Munakata User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Sip] Update of draft-ietf-sip-ua-privacy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 00:56:32 -0000 All; I have just updated the ua-privacy draft to incorporate all the WGLC comments. http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-06.txt Changes from the previous version are as follows: 1) In Section 4.1, changed the text in the last paragraph to make it clear that usage of a third-party GRUU server is a possible solution but out of scope. 2) In Section 5.1.1, changed the text in the second paragraph in order not to anonymize the Contact in 3xx responses, REGISTER requests and REGISTER 200 responses. 3) In Section 6, added a paragraph to the Security Considerations section that explains the concern of 'reg' event package [RFC3680]. The editors believe that all the WGLC comments are solved and incorporated into the document. Thanks, Mayumi From rfc-editor@rfc-editor.org Thu Mar 5 16:57:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A239828C368; Thu, 5 Mar 2009 16:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.9 X-Spam-Level: X-Spam-Status: No, score=-16.9 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFFANnKtHCSc; Thu, 5 Mar 2009 16:57:20 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id EE64628C25F; Thu, 5 Mar 2009 16:57:19 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 8E615240567; Thu, 5 Mar 2009 16:56:18 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090306005618.8E615240567@bosco.isi.edu> Date: Thu, 5 Mar 2009 16:56:18 -0800 (PST) Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 5478 on IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 00:57:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5478 Title: IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces Author: J. Polk Status: Standards Track Date: March 2009 Mailbox: jmpolk@cisco.com Pages: 6 Characters: 12810 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-rph-new-namespaces-04.txt URL: http://www.rfc-editor.org/rfc/rfc5478.txt This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From root@core3.amsl.com Thu Mar 5 17:00:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6122B3A6B26; Thu, 5 Mar 2009 17:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306010001.6122B3A6B26@core3.amsl.com> Date: Thu, 5 Mar 2009 17:00:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-ua-privacy-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 01:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : UA-Driven Privacy Mechanism for SIP Author(s) : M. Munakata, et al. Filename : draft-ietf-sip-ua-privacy-06.txt Pages : 11 Date : 2009-03-05 This document defines a guideline for a user agent to generate an anonymous SIP message by utilizing mechanisms such as GRUU (Globally Routable User Agent URIs) and TURN (Traversal Using Relays around NAT) without the need for a privacy service defined in RFC 3323. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-ua-privacy-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-05164550.I-D@ietf.org> --NextPart-- From HKaplan@acmepacket.com Thu Mar 5 18:27:47 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1F528C11C for ; Thu, 5 Mar 2009 18:27:47 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDyO332MPHym for ; Thu, 5 Mar 2009 18:27:46 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A52E928C146 for ; Thu, 5 Mar 2009 18:27:46 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 5 Mar 2009 21:28:14 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 5 Mar 2009 21:28:15 -0500 From: Hadriel Kaplan To: Theo Zourzouvillys Date: Thu, 5 Mar 2009 21:28:13 -0500 Thread-Topic: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 Thread-Index: Acmd86RdU2dHSTm1S2W2WnOnqRPHjgAAQVdg Message-ID: References: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com> <167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com> <6EF7E0CD-58D2-4218-9408-1FC584DE7C04@softarmor.com> <1236200991.3771.45.camel@victoria-pingtel-com.us.nortel.com> <167dfb9b0903051636j1d491aaep47ce2893938bbc7e@mail.gmail.com> In-Reply-To: <167dfb9b0903051636j1d491aaep47ce2893938bbc7e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP , Dean Willis Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 02:27:47 -0000 OK, sounds useful enough - in a previous email from Cullen on this topic (w= ith his AD hat), he suggested emailing the APPS Area list (apps-disucss@iet= f.org) since rfc3986 is in their camp. -hadriel > -----Original Message----- > From: Theo Zourzouvillys [mailto:theo@crazygreek.co.uk] > Sent: Thursday, March 05, 2009 7:36 PM > > > How does it affect anything for common URI formats not to comply with > it? > > We'd be saying that a SIP URI is no longer guaranteed to be compatible > with the generic URI syntax, and there in lies dragons. > > While it would unlikely have any direct effect on SIP elements > themselves, there are a whole bunch of assumptions made (and we should > be able to continue to make) around a SIP URI being compatible with > the syntax of a URI, notably in 3rd party tools. some things that > spring to mind that would be affected are: > > - XML Schema syntax for a URI > - in - i.e, any hyperlink on a HTML page. > - PHP (or any other language) parse_uri() > - draft-roach-sip-http-subscribe Link header values > - subjectAltName URI in a SSL certificate > - a RDBMS "URI" data type > > ... being able to put a SIP URI anywhere that there is a "URI" field > is a fairly useful thing for developers when it comes to re-usability > > even worse, anything that presumes they are a URI will work most the > time, until an IPv6 address is used. > > > (or really, for *it* not to comply with common URI formats) > > i'm not sure how many other common URI formats have notably been > affected by the missing IPv6 yet: the lack of universal IPv6 > deployment along with SIP being fairly likely to want to include > literal IPv6 addresses in the URI makes it more obvious for us to > notice other other schemes, so perhaps we're just ahead of the game? > > ~ Theo From ernst.horvath@siemens.com Fri Mar 6 00:28:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0ED03A6B69 for ; Fri, 6 Mar 2009 00:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90UK3neSYlg0 for ; Fri, 6 Mar 2009 00:28:07 -0800 (PST) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 9DC9F3A69DE for ; Fri, 6 Mar 2009 00:28:06 -0800 (PST) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id n268SSKb014960; Fri, 6 Mar 2009 09:28:28 +0100 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id n268SRxt023975; Fri, 6 Mar 2009 09:28:27 +0100 Received: from atnets15pa.ww300.siemens.net ([158.226.250.54]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 09:28:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 09:28:25 +0100 Message-ID: <5AB8CA778E49D149B6EAEC3B864C7A8C02255E0C@atnets15pa.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 Thread-Index: Acmd86RdU2dHSTm1S2W2WnOnqRPHjgAAQVdgAA7mWgA= References: <1236104807.3740.48.camel@victoria-pingtel-com.us.nortel.com><167dfb9b0903040434x4b76e3fex83f94358e64a085@mail.gmail.com><6EF7E0CD-58D2-4218-9408-1FC584DE7C04@softarmor.com><1236200991.3771.45.camel@victoria-pingtel-com.us.nortel.com><167dfb9b0903051636j1d491aaep47ce2893938bbc7e@mail.gmail.com> From: "Horvath, Ernst" To: "Hadriel Kaplan" , "Theo Zourzouvillys" X-OriginalArrivalTime: 06 Mar 2009 08:28:26.0547 (UTC) FILETIME=[8568E830:01C99E35] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::090306092828-0B9D6BA0-077E6A4B/0-0/0-15 X-purgate-size: 3012/0 Cc: SIP , Dean Willis Subject: Re: [Sip] Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 08:28:08 -0000 I would also think the problem should be solved within RFC3986, for a pure economic reason.=20 On a quick scan through registered URI schemes I identified the following schemes having the same problem as sip/sips:=20 mailto, im, pres, h323, iax, xmpp. and I may have missed some. Makes more than have a dozen RFCs to be updated against one (RFC3986). Regards, Ernst > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: Friday, March 06, 2009 3:28 AM > To: Theo Zourzouvillys > Cc: SIP; Dean Willis > Subject: Re: [Sip] Question regarding conflicting grammar for=20 > IPV6 SIP URI andRFC 3986 >=20 >=20 > OK, sounds useful enough - in a previous email from Cullen on=20 > this topic (with his AD hat), he suggested emailing the APPS=20 > Area list (apps-disucss@ietf.org) since rfc3986 is in their camp. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Theo Zourzouvillys [mailto:theo@crazygreek.co.uk] > > Sent: Thursday, March 05, 2009 7:36 PM > > > > > How does it affect anything for common URI formats not to=20 > comply with > > it? > > > > We'd be saying that a SIP URI is no longer guaranteed to be=20 > compatible > > with the generic URI syntax, and there in lies dragons. > > > > While it would unlikely have any direct effect on SIP elements > > themselves, there are a whole bunch of assumptions made=20 > (and we should > > be able to continue to make) around a SIP URI being compatible with > > the syntax of a URI, notably in 3rd party tools. some things that > > spring to mind that would be affected are: > > > > - XML Schema syntax for a URI > > - in - i.e, any hyperlink on a HTML page. > > - PHP (or any other language) parse_uri() > > - draft-roach-sip-http-subscribe Link header values > > - subjectAltName URI in a SSL certificate > > - a RDBMS "URI" data type > > > > ... being able to put a SIP URI anywhere that there is a "URI" field > > is a fairly useful thing for developers when it comes to=20 > re-usability > > > > even worse, anything that presumes they are a URI will work most the > > time, until an IPv6 address is used. > > > > > (or really, for *it* not to comply with common URI formats) > > > > i'm not sure how many other common URI formats have notably been > > affected by the missing IPv6 yet: the lack of universal IPv6 > > deployment along with SIP being fairly likely to want to include > > literal IPv6 addresses in the URI makes it more obvious for us to > > notice other other schemes, so perhaps we're just ahead of the game? > > > > ~ Theo > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From root@core3.amsl.com Fri Mar 6 06:45:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B729B3A69E7; Fri, 6 Mar 2009 06:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306144501.B729B3A69E7@core3.amsl.com> Date: Fri, 6 Mar 2009 06:45:01 -0800 (PST) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-record-route-fix-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Addressing Record-Route issues in the Session Initiation Protocol (SIP) Author(s) : T. Froment, et al. Filename : draft-ietf-sip-record-route-fix-06.txt Pages : 24 Date : 2009-03-06 A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPv4 or IPv6 addresses, and URI parameters that could influence the routing such as the transport parameter (for example transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching or IPv4 to IPv6 scenarios...), the question arises on what should be put in Record-Route header(s). It is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-record-route-fix-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06063820.I-D@ietf.org> --NextPart-- From HKaplan@acmepacket.com Fri Mar 6 09:04:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4E53A6A0A for ; Fri, 6 Mar 2009 09:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEpmrBeTOPPQ for ; Fri, 6 Mar 2009 09:04:51 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D51983A685C for ; Fri, 6 Mar 2009 09:04:50 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 6 Mar 2009 12:05:20 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 6 Mar 2009 12:05:20 -0500 From: Hadriel Kaplan To: Dale Worley , "Elwell, John" Date: Fri, 6 Mar 2009 12:05:19 -0500 Thread-Topic: [Sip] SIP Tracing Facility Thread-Index: AcmdprQ9sKllOeCfQUSbiXbux01HHAA1ZvDg Message-ID: References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0019BFFA2@GBNTHT12009MSX.gb002.siemens.net> <1236266736.3730.4.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1236266736.3730.4.camel@victoria-pingtel-com.us.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:04:51 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dal= e > Worley > Sent: Thursday, March 05, 2009 10:26 AM > > On Thu, 2009-03-05 at 08:16 +0000, Elwell, John wrote: > > What about non-INVITEs? Provisional responses are designed for INVITEs > > and I am not certain about their applicability to non-INVITEs. > > Yes, provisional responses to non-INVITEs may be slightly out of > specification, but I don't expect any SIP element to malfunction if it > receives a provisional response to a non-INVITE request. OTOH, I would > expect most uses of 'trace' to be attached to INVITEs, although that > makes me think that tracing an OPTIONS might be a useful test tool. OPTIONS doesn't always get routed through the same path as INVITE, fwiw. > (Which leads to an unexpected observation: RFC 3261 presupposes that > all non-INVITE responses are processed promptly, but in the face of > transport errors, this is not always so. In sipX, we've adjusted > transaction handling so that if a re-send of a non-INVITE message is > seen the recipient sends a 100 to quench further re-sends. It seems to > work exactly as expected, and noticeably reduces re-sends in situations > with transport errors.) I agree for most methods, but we've seen problems with 100 for the OPTIONS.= Some devices use the OPTIONS as a reachability ping/test, so sometimes th= e 100 makes them think the far-end is reachable even if they get a 408 late= r; in other cases some devices look for specific response codes to detect a= dministrative out-of-service, for example a 500/503 to an OPTIONS sometimes= is used for that, and sometimes they didn't code for the 100 Trying as bei= ng a possibility, so they see it and assume it's not out-of-service, and th= e 503 sent later doesn't get processed the same. I consider these bugs/bro= ken implementations, but just noting sending the 100 is not bug-free. -hadriel From HKaplan@acmepacket.com Fri Mar 6 09:51:47 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9247A3A6B20 for ; Fri, 6 Mar 2009 09:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w13EFqa2tgcX for ; Fri, 6 Mar 2009 09:51:46 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 97C153A6AD0 for ; Fri, 6 Mar 2009 09:51:46 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 6 Mar 2009 12:52:15 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 6 Mar 2009 12:52:15 -0500 From: Hadriel Kaplan To: Dale Worley , SIP Date: Fri, 6 Mar 2009 12:52:14 -0500 Thread-Topic: [Sip] SIP Tracing Facility Thread-Index: Acmc9xSBdkejAoZHRPe/x7JtYWFn1wBhqrow Message-ID: References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:51:47 -0000 Hi Dale, I appreciate that doing troubleshooting of SIP in SIP is very appealing, bu= t I'm worried about it. There are some real security issues with this, eve= n if we don't want to admit it. The reality is that if this trace mechanis= m is actually adopted by any sizeable measure, then middleboxes will be for= ced to munge the messages more than they already do, to prevent it from bei= ng used/work. In other words it's a self-defeating mechanism. Today you can do incrementing Max-Forwards traceroute, similar to the ICMP = traceroute TTL trick, and even that's gotten some folks worried enough to m= ake us munge the Max-Forwards value (despite the obvious dangers in doing s= o). But anyway why isn't that type of trace enough for your needs? Also, a couple specific questions/comments regarding this draft: 1) You use the term "final response" a couple times as being sent in the 17= 0's body. How would a final response be sent in a 170 response, since the = 170 would be before a final response? 2) You state that a UAC should not create an early-dialog for the 170, but = for any B2BUA in the path which did not know about this new trace mechanism= , wouldn't it create early dialogs on the b2bua since it would treat it as = a 183? -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dal= e > Worley > Sent: Wednesday, March 04, 2009 1:29 PM > To: SIP > Subject: [Sip] SIP Tracing Facility > > I wrote up the "170" trace proposal as an I-D: > > A new version of I-D, draft-worley-trace-00.txt has been successfuly > submitted by Dale Worley and posted to the IETF repository. > > Filename: draft-worley-trace > Revision: 00 > Title: SIP Tracing Facility > Creation_date: 2009-03-03 > WG ID: Independent Submission > Number_of_pages: 18 > > Abstract: > This document defines a SIP option tag, "trace", to be used within > SIP messages to request that SIP elements (both proxies and UASs) > that receive the message reflect to the UAC the request they received > and the response they gave by encapsulating the request and response > in a provisional response. A new provisional response code "170" is > defined to carry the request and response. This option tag is > expected to be used solely for diagnostic purposes. > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From eburger@standardstrack.com Fri Mar 6 09:59:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093803A6B20 for ; Fri, 6 Mar 2009 09:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k7gz+YrjuJb for ; Fri, 6 Mar 2009 09:59:11 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 2D5943A6AD0 for ; Fri, 6 Mar 2009 09:59:11 -0800 (PST) Received: from [208.54.7.188] (port=54141 helo=154.10.242.10.in-addr.arpa) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LfeKf-0004d2-RD; Fri, 06 Mar 2009 09:59:38 -0800 Message-Id: From: Eric Burger To: Dale Worley In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-72-357140502; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 12:59:38 -0500 References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIP IETF Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:59:12 -0000 --Apple-Mail-72-357140502 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Wouldn't SIP-CLF be a better way to go? On Mar 6, 2009, at 12:52 PM, Hadriel Kaplan wrote: > Hi Dale, > > I appreciate that doing troubleshooting of SIP in SIP is very > appealing, but I'm worried about it. There are some real security > issues with this, even if we don't want to admit it. The reality is > that if this trace mechanism is actually adopted by any sizeable > measure, then middleboxes will be forced to munge the messages more > than they already do, to prevent it from being used/work. In other > words it's a self-defeating mechanism. > > Today you can do incrementing Max-Forwards traceroute, similar to > the ICMP traceroute TTL trick, and even that's gotten some folks > worried enough to make us munge the Max-Forwards value (despite the > obvious dangers in doing so). But anyway why isn't that type of > trace enough for your needs? > > > Also, a couple specific questions/comments regarding this draft: > > 1) You use the term "final response" a couple times as being sent in > the 170's body. How would a final response be sent in a 170 > response, since the 170 would be before a final response? > > 2) You state that a UAC should not create an early-dialog for the > 170, but for any B2BUA in the path which did not know about this new > trace mechanism, wouldn't it create early dialogs on the b2bua since > it would treat it as a 183? > > -hadriel > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >> Of Dale >> Worley >> Sent: Wednesday, March 04, 2009 1:29 PM >> To: SIP >> Subject: [Sip] SIP Tracing Facility >> >> I wrote up the "170" trace proposal as an I-D: >> >> A new version of I-D, draft-worley-trace-00.txt has been successfuly >> submitted by Dale Worley and posted to the IETF repository. >> >> Filename: draft-worley-trace >> Revision: 00 >> Title: SIP Tracing Facility >> Creation_date: 2009-03-03 >> WG ID: Independent Submission >> Number_of_pages: 18 >> >> Abstract: >> This document defines a SIP option tag, "trace", to be used within >> SIP messages to request that SIP elements (both proxies and UASs) >> that receive the message reflect to the UAC the request they received >> and the response they gave by encapsulating the request and response >> in a provisional response. A new provisional response code "170" is >> defined to carry the request and response. This option tag is >> expected to be used solely for diagnostic purposes. >> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-72-357140502 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDYxNzU5MzhaMCMGCSqGSIb3 DQEJBDEWBBQJVfF4optuaN7CGhvVTiU1cw1NFTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBgQBxNM/lZ+SfCfLEcyJH3tNLxEvPmYmWHD4Y02expy9q9 edyh/cRz+c0BbkOa/lNnNjP3HOCrqyT5qlmOy+gWrNkUTqQFzURa7qJyRZBpCa5EViS+AWSIzyAc c//79GBqzB1F9wOSruvJndvjEAF1XmvRsuaqFxLN6b6WS/v9e2ahe82r0gFR3k4oAhSjWirPCT91 7pVnVOez+2Z+1v6ZfhZwrjfWOPzxOfQ7tRvkUTA3Wcdd6ezZG0CAd+pYozyGLcnvMnrdFyMOUG9i RqsCl5RTwxd7/J+ExjBWYR7sviDpjvvUw1KAgZftF9lPCeZ+3juHWf/R0qn9OVHHeFY2AAAAAAAA --Apple-Mail-72-357140502-- From HKaplan@acmepacket.com Fri Mar 6 10:08:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084223A67F3 for ; Fri, 6 Mar 2009 10:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpj9kJutj50W for ; Fri, 6 Mar 2009 10:08:54 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F38AF3A6BDF for ; Fri, 6 Mar 2009 10:08:53 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 6 Mar 2009 13:09:23 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 6 Mar 2009 13:09:23 -0500 From: Hadriel Kaplan To: Eric Burger , Dale Worley Date: Fri, 6 Mar 2009 13:09:22 -0500 Thread-Topic: [Sip] SIP Tracing Facility Thread-Index: AcmehWMULkuOzmK/TlqfpwRfkOWcBAAAC1TA Message-ID: References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP IETF Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:08:55 -0000 Yes that's what I was thinking too - for basic connectivity check type thin= gs, do SIP ping/traceroute. To troubleshoot actual proxy and UA behavior i= ssues, retargeting issues, perform any type of root-cause, etc., you need l= ogs and there's just no getting away from that. And only the authoritative= administrator of each SIP device can (and *should*) be able to get such in= fo. The real question is whether we can (or could) provide standardized ways of= helping admin's get the info they need. And I think that is actually a really good topic for a BOF, or at least a d= iscussion on RAI-DISPATCH. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eri= c > Burger > Sent: Friday, March 06, 2009 1:00 PM > > Wouldn't SIP-CLF be a better way to go? From vkg@alcatel-lucent.com Fri Mar 6 10:27:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930703A6C3B for ; Fri, 6 Mar 2009 10:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWNvlQfo9FdV for ; Fri, 6 Mar 2009 10:27:12 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 7EC5C3A6A87 for ; Fri, 6 Mar 2009 10:27:12 -0800 (PST) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n26IRgNv007007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Mar 2009 12:27:42 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n26IRgBk025843 for ; Fri, 6 Mar 2009 12:27:42 -0600 (CST) Message-ID: <49B16B1F.1070009@alcatel-lucent.com> Date: Fri, 06 Mar 2009 12:27:43 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: SIP IETF References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: 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 Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:27:13 -0000 Eric Burger wrote: > Wouldn't SIP-CLF be a better way to go? Hadriel Kaplan wrote: > Yes that's what I was thinking too - for basic connectivity check > type things, do SIP ping/traceroute. To troubleshoot actual proxy > and UA behavior issues, retargeting issues, perform any type of > root-cause, etc., you need logs and there's just no getting away from > that. And only the authoritative administrator of each SIP device > can (and *should*) be able to get such info. > > The real question is whether we can (or could) provide standardized > ways of helping admin's get the info they need. And I think that is > actually a really good topic for a BOF, or at least a discussion on > RAI-DISPATCH. Funny you should mention a BoF. Eric has also suggested that we hold a Bar BoF to discuss sipping-clf. I am modifying sipping-clf based on Dale's extensive comments from the last round and from other comments received. It will be submitted before the Monday deadline and we can think of holding at least a Bar BoF on this. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From dworley@nortel.com Fri Mar 6 11:41:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E16F28C22B for ; Fri, 6 Mar 2009 11:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOl4EoBXcc4Y for ; Fri, 6 Mar 2009 11:41:33 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4FDC828C149 for ; Fri, 6 Mar 2009 11:41:33 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n26Jg1A21832; Fri, 6 Mar 2009 19:42:01 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 14:41:59 -0500 From: "Dale Worley" To: Nils Ohlmeier In-Reply-To: References: <49AE593F.6080807@iptel.org> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 06 Mar 2009 14:41:59 -0500 Message-Id: <1236368519.3762.20.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2009 19:41:59.0844 (UTC) FILETIME=[9D9CA640:01C99E93] Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 19:41:34 -0000 On Thu, 2009-03-05 at 14:40 +0100, Nils Ohlmeier wrote: > One thing which is not that obvious but is implictly a requirement for the > attack: the proxies has to challenge in-dialog requests. I do not see a > big benefit in challeging in-dialog requests as these are hopefully > rejected by the remote side if no matching dialog exists. If the UA would > know that his proxy does not challenge in-dialog requests it could simply > ignore the challenge :-) Except that there are legitimate uses for challenging in-dialog requests: sipX uses it to allow a phone to transfer a caller to any destination that the executing phone has permission to call. The first step of this process is that when the executing phone sends a REFER, the proxy challenges the REFER so that the executing phone attaches its credentials to the REFER. The proxy then analyzes these credentials to determine the user that is responsible for the transfer operation, etc. Without the in-dialog challenge, there is no way for the proxy to determine the user that is responsible for transfer operation. Dale From lists@ohlmeier.org Fri Mar 6 14:21:01 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9713A68AA for ; Fri, 6 Mar 2009 14:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApcxVJxrut48 for ; Fri, 6 Mar 2009 14:21:00 -0800 (PST) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 673C03A6825 for ; Fri, 6 Mar 2009 14:21:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id EC89F7F82; Fri, 6 Mar 2009 23:21:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFVFNdZt8-h0; Fri, 6 Mar 2009 23:21:28 +0100 (CET) Received: from Nils-MacBook-2.local (unknown [78.52.228.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bespin.rfc3261.net (Postfix) with ESMTPSA id 675527F55; Fri, 6 Mar 2009 23:21:28 +0100 (CET) Message-ID: <49B1A1E1.8070007@ohlmeier.org> Date: Fri, 06 Mar 2009 23:21:21 +0100 From: Nils Ohlmeier User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Dale Worley References: <49AE593F.6080807@iptel.org> <1236368519.3762.20.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1236368519.3762.20.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 22:21:01 -0000 Am 06.03.2009 20:41 Uhr, schrieb Dale Worley: > On Thu, 2009-03-05 at 14:40 +0100, Nils Ohlmeier wrote: >> One thing which is not that obvious but is implictly a requirement for the >> attack: the proxies has to challenge in-dialog requests. I do not see a >> big benefit in challeging in-dialog requests as these are hopefully >> rejected by the remote side if no matching dialog exists. If the UA would >> know that his proxy does not challenge in-dialog requests it could simply >> ignore the challenge :-) > > Except that there are legitimate uses for challenging in-dialog > requests: sipX uses it to allow a phone to transfer a caller to any > destination that the executing phone has permission to call. The first > step of this process is that when the executing phone sends a REFER, the > proxy challenges the REFER so that the executing phone attaches its > credentials to the REFER. The proxy then analyzes these credentials to > determine the user that is responsible for the transfer operation, etc. > Without the in-dialog challenge, there is no way for the proxy to > determine the user that is responsible for transfer operation. Good point. Except that a REFER is not relevant for this replay attack. So would re-phrase it: I do not see a big benefit in challeging in-dialog INVITE requests. :-) Greetings Nils From theo@crazygreek.co.uk Fri Mar 6 14:29:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95243A6917 for ; Fri, 6 Mar 2009 14:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.713 X-Spam-Level: X-Spam-Status: No, score=-5.713 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4125zQ5NJgqw for ; Fri, 6 Mar 2009 14:29:03 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with SMTP id A09023A6911 for ; Fri, 6 Mar 2009 14:29:02 -0800 (PST) Received: from source ([72.14.220.158]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSbGjzU3ly0Q+OFjZbae7KXHAE4xWQ6/m@postini.com; Fri, 06 Mar 2009 14:29:34 PST Received: by fg-out-1718.google.com with SMTP id 19so586938fgg.9 for ; Fri, 06 Mar 2009 14:29:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.27.9 with SMTP id a9mr2313018fga.49.1236378572724; Fri, 06 Mar 2009 14:29:32 -0800 (PST) In-Reply-To: <49B1A1E1.8070007@ohlmeier.org> References: <49AE593F.6080807@iptel.org> <1236368519.3762.20.camel@victoria-pingtel-com.us.nortel.com> <49B1A1E1.8070007@ohlmeier.org> Date: Fri, 6 Mar 2009 22:29:32 +0000 Message-ID: <167dfb9b0903061429r635e3a64i2353a8900fbace37@mail.gmail.com> From: Theo Zourzouvillys To: Nils Ohlmeier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 22:29:03 -0000 On Fri, Mar 6, 2009 at 10:21 PM, Nils Ohlmeier wrote: > Except that a REFER is not relevant for this replay attack an authenticated OOD REFER may be used to initiate a call with some SIP devices. ~ Theo From lists@ohlmeier.org Fri Mar 6 14:51:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0FA3A6923 for ; Fri, 6 Mar 2009 14:51:44 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdRpdt6A7bdB for ; Fri, 6 Mar 2009 14:51:43 -0800 (PST) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 6EC813A681C for ; Fri, 6 Mar 2009 14:51:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 94A2A7F82; Fri, 6 Mar 2009 23:52:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAAdOg6COxjs; Fri, 6 Mar 2009 23:52:12 +0100 (CET) Received: from Nils-MacBook-2.local (unknown [78.52.228.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bespin.rfc3261.net (Postfix) with ESMTPSA id 1D3007F55; Fri, 6 Mar 2009 23:52:12 +0100 (CET) Message-ID: <49B1A91B.9060308@ohlmeier.org> Date: Fri, 06 Mar 2009 23:52:11 +0100 From: Nils Ohlmeier User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Theo Zourzouvillys References: <49AE593F.6080807@iptel.org> <1236368519.3762.20.camel@victoria-pingtel-com.us.nortel.com> <49B1A1E1.8070007@ohlmeier.org> <167dfb9b0903061429r635e3a64i2353a8900fbace37@mail.gmail.com> In-Reply-To: <167dfb9b0903061429r635e3a64i2353a8900fbace37@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 22:51:44 -0000 Am 06.03.2009 23:29 Uhr, schrieb Theo Zourzouvillys: > On Fri, Mar 6, 2009 at 10:21 PM, Nils Ohlmeier wrote: > >> Except that a REFER is not relevant for this replay attack > > an authenticated OOD REFER may be used to initiate a call with some SIP devices. Sure, but that is totally different story (of another bad UA implementation) which is not related to this auth relay attack. Nils From eburger@standardstrack.com Sat Mar 7 06:46:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2723A680F for ; Sat, 7 Mar 2009 06:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD-Se6SFGDvh for ; Sat, 7 Mar 2009 06:46:32 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 424163A6784 for ; Sat, 7 Mar 2009 06:46:32 -0800 (PST) Received: from [75.68.112.157] (port=60456 helo=[192.168.45.100]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lfxno-00007m-9l; Sat, 07 Mar 2009 06:47:00 -0800 Message-Id: From: Eric Burger To: Brett Tate In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A0FD7115231@mbx02.citservers.local> Content-Type: multipart/signed; boundary=Apple-Mail-88-371296520; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 16:55:34 -0500 References: <9B2A061A1137254BBE4F4B2CD843646A0FD7115231@mbx02.citservers.local> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIP IETF Subject: Re: [Sip] draft-ietf-sip-info-events-03: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 14:46:33 -0000 --Apple-Mail-88-371296520 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Inline. On Feb 16, 2009, at 7:18 PM, Brett Tate wrote: > Howdy, > > The following are a few comments and questions concerning draft-ietf- > sip-info-events-03. > > Thanks, > Brett > > ------------- > > Section 3.1 paragraph 1: Concerning "MUST advertise" and > "provisional 1xx", please clarify that the "MUST advertise" is not > applicable to the 100 response. Does the "MUST advertise" and > "provisional 1xx" apply to all (first and subsequent within dialog) > INVITE non 101-199 (intentionally indicated 199)? Concerning ACK > for initial INVITE's 2xx, does the "MUST advertise" always apply? I would offer "MUST advertise" is appropriate. What is the rationale to not require it? We are expecting "early INFO," so no reason to screw up UACs by having random appearances and disappearances of Recv- Info headers. > Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1 indicates > "session parameters" and sentence 2 indicates "dialog parameters" > concerning Info Package negotiation, I'm not sure when the > negotiation/renegotiation occurs. Does it follow SDP offer/answer > rules or something else; if something else, what? I have the same > question concerning "dialog refresh" text discussed later within the > same section since incorrect interpretations might trigger > deactivation. Should be dialog parameters everywhere. Would that clear up the confusion? > Section 4.3: When sending a 489, it indicates "MUST terminate the > INVITE dialog". The "MUST terminate" seems severe even if all the > negotiation race conditions are adequately addressed. The mentioned > "protocol failure" reason seems contrary to the "strictly send and > lenient receive" mantra. Maybe living in New Hampshire has made me more conservative. A lot of folks will today say that while "Be conservative in what you send and liberal in what you receive" may have been the greatest mistake we ever made in protocol design. Let us look at this from a practical perspective. If you are a bad implementor and send a 489 you didn't mean to, who knows what else you will get wrong. Conversely, if you are a bad implementor and forget to tear down a 489-ed INFO, bad things probably will not happen. I will defer to the WG on this one. Any other opinions? > Section 5.1 Table 1: The usage of "g" seems potentially outdated or > incorrectly reference since discussed within RFC 2543 instead of RFC > 3261. The same applies to usage Via row concerning "(2)". Poor cutting & pasting. Will fix. > Section 5.2.2: The "general-header" reference is outdated or > incorrectly reference since defined within RFC 2543 instead of RFC > 3261. RFC 3261 uses "Message-Header". Ditto. > Section 7.7 paragraph 2: The following potentially could be reworded > since it is okay to return failure responses (401, 503, 500, ...) > even when overlapping occurs: "in the event a UAC issues overlapping > INFO requests for an Info Package, the UAS MUST NOT return an error > response". Good idea. Will do. > Section 8: Why specifically defining and using "nil"? I'm mainly > just curious of the benefit over not having defined "nil" for > similar use within the Supported header. That is a good one. since we go to the trouble of registering "nil", it is just an Info-package-type. Will fix. --Apple-Mail-88-371296520 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDYyMTU1MzRaMCMGCSqGSIb3 DQEJBDEWBBTzUyJlnZ2zUa0lydsmsyVZoKu5rDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQCPvgx6XTa33jG+sCnBwVsbaOtH1AcadAIVptoAt+3TuQRO vQVtWAe0ja+Nj8TOoeG0pLSshJBSmvoMRYHU4uMF5vPojOaJ6FfBKFs+hFiXqb32qjNWXx7GLIzo 9Yj9MJUMDEiKicryQ9AcOZXx28CzqywQ182B2mZEN3H0Ary3iD4QdPsI+mHXkRHRRH6Ly7y9iBXA pTzmWsQ2C7+G61q24IjoNns3X9biT0w85jAmzY6dKKMs3MNylNNkNFrr+cNomZYPcp78xgOhRkpW M2fCteBBQr+mreJ/utXOfu5S5oBKXiCjHQ9KTUp4fowuVVo41S0ybERa0OiDYAsqjpJ9AAAAAAAA --Apple-Mail-88-371296520-- From eburger@standardstrack.com Sat Mar 7 06:46:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830B63A68B8 for ; Sat, 7 Mar 2009 06:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTG7NaCmlA3o for ; Sat, 7 Mar 2009 06:46:40 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 8E8D43A68C7 for ; Sat, 7 Mar 2009 06:46:40 -0800 (PST) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157]:60456 helo=[192.168.45.100]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lfxnw-00007m-O9; Sat, 07 Mar 2009 06:47:09 -0800 Message-Id: <82069650-08EA-4786-A3BD-51DE93F9467A@standardstrack.com> From: Eric Burger To: Bob Penfield In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-89-371749125; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 17:03:06 -0500 References: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIP IETF Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 14:46:41 -0000 --Apple-Mail-89-371749125 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Inline. On Mar 3, 2009, at 12:11 PM, Bob Penfield wrote: > > Here are some comments on the INFO draft: > > Section 2 says: > > Each UA enumerates which Info Packages it can receive. If the far > end indicates it can receive a package offered by the near end, the > near end can send INFO methods containing the payload for that > package. > > "offered" needs to changed to "supported" since an INFO sender does > not indicate what packages it can send. Correct. Editing shrapnel. It is really in Section 1 (this is a note for me). > Section 3 is called "Info Package Negotiation", but since we removed > Send-Info, it is not a negotiation since there is no feedback from the > peer UA. It is simply a declaration of receive capability. At first > read, I was totally confused by section 3.1 because I was expecting > some actual negotiation given the above statement in Section 2. There > are a few other places in the document that mentions "negotiation" > that also might need to be changed. How about "Info Package Behavior"? > I think the usage of UAC/UAS terminology in Section 3.1 is still > confusing. I would prefer to see something like: > > A UA supporting this document MUST advertise the set of Info > Packages it is willing to receive in Recv-Info header(s) in all > "INVITE dialog usage" requests and responses (101-199 and 2xx only) > for dialog establishment or target refresh. This includes INVITE, > UPDATE, PRACK and ACK and their non-failure responses. > > A UA MUST NOT send INFO requests for a given INFO package until the > UA has received an "INVITE dialog usage" request or response (for > dialog establishment or target refresh) with a Recv-Info header > listing the given Info Package. > > A UA MUST cease sending INFO requests for a given INFO package when > the UA receives an "INVITE dialog usage" request or response (for > dialog establishment or target refresh) that does not contain a > Recv-Info header listing the given Info Package. Sounds good to me. > Section 3.1 - "the target UA may not send form package P" > > s/form/from/ > > Section 3.1 - "... the other UA in the dial will assume the ..." > > s/dial/dialog/ Got it. > Section 3.1 - "server MAY terminate the session with a CANCEL or BYE" > > When the "server" is the UAS of the request, CANCEL is not > appropriate, and BYE would not be appropriate if it is an initial > INVITE. In this case, the request would need to be rejected. When > the "server" is the UAC, I don't think CANCEL is appropriate since > it is the far-end UA of a specific dialog that the UAC has an issue > with, not all possible UAs in the case of an initial INVITE. Whoops - clearly we are talking about the UAC in this case. > Section 7 - Can Info Packages strengthen "MAY" to "SHOULD"? In the real world, MAY = SHOULD. This would not add any value. The value of the wording here is to encourage more MUSTS :-) > Section 8 - Why is the separator between Info-package-name and > Info-package-param a DOT? Shouldn't it be a SEMI? I don't think that > Info-package-param is similar to event-template in 3265. Its more like > event-param. Hmmm. That is one for my co-authors. I would offer semicolon is the way to go. --Apple-Mail-89-371749125 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDYyMjAzMDdaMCMGCSqGSIb3 DQEJBDEWBBT15RavljKEriyxHBhRAnlI+Nx0GzCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQC4A95k/CM1hQoMFfPs/2e4OZ6X7tdkGBCiArasb+gEqRMg +7JSnp7OcCGw3+X6ZQYvNLmIfFQVIGvKAyw/XvaIXVXI2EJF0trC/d1fkbc3Efq5E8O4yrhRd1rL 1X5rxQhV7Cg+FM5bogVB0phPWd1AIO6KwohUa6qKVPT3i362KXRrACpuTKyrEY5cH0GpzhY/fQHS jkfZUo+MTBUmQGlVjRiWWMFMTv6c2D66kgB2YAnFqUa/DfsZzACQRnyIhOg0jH0I7xpYEKRIuaHh KGoRo+BdpC9BvN1JNYgdxYYEII7ZoO4MBRtwNXddWTCCJsiVDM131h1oBXGBxLwhD7dDAAAAAAAA --Apple-Mail-89-371749125-- From eburger@standardstrack.com Sat Mar 7 06:46:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3B83A691A for ; Sat, 7 Mar 2009 06:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP1TbUXG4X4u for ; Sat, 7 Mar 2009 06:46:42 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 42C963A68A6 for ; Sat, 7 Mar 2009 06:46:42 -0800 (PST) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157]:60456 helo=[192.168.45.100]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lfxny-00007m-J2; Sat, 07 Mar 2009 06:47:11 -0800 Message-Id: <12FFED84-22F5-4346-AEED-0F00A1B9AB00@standardstrack.com> From: Eric Burger To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0019843F6@GBNTHT12009MSX.gb002.siemens.net> Content-Type: multipart/signed; boundary=Apple-Mail-90-371796356; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 17:03:53 -0500 References: <3FAF6CCD-612A-4F74-AC3B-2090BE2B4544@softarmor.com> <28B7C3AA2A7ABA4A841F11217ABE78D674A8D234@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0019843F6@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIP IETF Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 14:46:43 -0000 --Apple-Mail-90-371796356 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Sounds sensible. On Mar 4, 2009, at 3:47 AM, Elwell, John wrote: > I agree with Bob that the use of UAC and UAS terminology is > confusing. I > cite some particular examples below. > > 1. In 3 it defines the two terms, but early in 3.1 it states "The > initiating UA (UAC of the INVITE)", which uses "UAC" in a sense > different from what is defined. > > 2. "the UAC MUST NOT send > INFO requests for a given Info Package until the UAS lists the given > Info Package in a Recv-Info header." > According to the definition of UAC, a UAC is the sender of an INFO > request. So while waiting to receive Recv-Info it is not a UAC. > Similarly, the other end is not a UAS by virtue of sending "Recv- > Info" - > it only becomes a UAS when it receives an INFO request. Don't forget > that a UA is a UAC or a UAS only in the context of a particular > transaction, and before that transaction takes place and after that > transaction has finished it is just a UA. Any attempt to change the > meaning of UAC or UAS would be a departure from RFC 3261. > > 3. "A UAS lists multiple packages by enumerating the package name(s), > separated by commas, as values for the Recv-Info header in the > session establishment exchange. A UAS can also list multiple > packages by including multiple Recv-Info headers...." > We are talking about sending Recv-Info - nothing to do with an INFO > transaction, so the term UAS is inappropriate. > > 4. "This initial dialog establishment > phase is the only time the UAS need be prepared to receive multiple > INFO requests, as we require post-session-establishment negotiation > to fully complete before a UAC can send an INFO request." > followed shortly afterwards by: > "A UAC MAY send an INFO > request on both an early and confirmed dialog." > Either these are conflicting statements or there is some mix-up of > terms > UAC and UAS. > > 5. In "Conventions Used in this Document" it states: "Since this > document strictly follows RFC 3261, we refer to the UA > that issues the INVITE as the "initiating UA" and the UA that > responds to the INVITE as the "target UA" to remove any confusion." > I don't think this is good practice, and I would even say that by > doing > this we no longer strictly follow RFC 3261 terminology. If it is clear > we are talking about an INVITE transaction we should be free to use > UAC > and UAS. > > So in general, where it is clear which transaction we are talking > about > (e.g., because it has appeared earlier in the paragraph concerned), we > should just use UAC or UAS. Otherwise we should use expressions like > "the UAC for the XXX transaction" or "the UA that sends the XXX > request". > > John > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Bob Penfield >> Sent: 03 March 2009 17:12 >> To: DRAGE, Keith (Keith); SIP IETF >> Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events >> >> >> Here are some comments on the INFO draft: >> >> Section 2 says: >> >> Each UA enumerates which Info Packages it can receive. If the far >> end indicates it can receive a package offered by the near end, the >> near end can send INFO methods containing the payload for that >> package. >> >> "offered" needs to changed to "supported" since an INFO sender does >> not indicate what packages it can send. >> >> Section 3 is called "Info Package Negotiation", but since we removed >> Send-Info, it is not a negotiation since there is no feedback from >> the >> peer UA. It is simply a declaration of receive capability. At first >> read, I was totally confused by section 3.1 because I was expecting >> some actual negotiation given the above statement in Section 2. There >> are a few other places in the document that mentions "negotiation" >> that also might need to be changed. >> >> I think the usage of UAC/UAS terminology in Section 3.1 is still >> confusing. I would prefer to see something like: >> >> A UA supporting this document MUST advertise the set of Info >> Packages it is willing to receive in Recv-Info header(s) in all >> "INVITE dialog usage" requests and responses (101-199 and 2xx only) >> for dialog establishment or target refresh. This includes INVITE, >> UPDATE, PRACK and ACK and their non-failure responses. >> >> A UA MUST NOT send INFO requests for a given INFO package until the >> UA has received an "INVITE dialog usage" request or response (for >> dialog establishment or target refresh) with a Recv-Info header >> listing the given Info Package. >> >> A UA MUST cease sending INFO requests for a given INFO package when >> the UA receives an "INVITE dialog usage" request or response (for >> dialog establishment or target refresh) that does not contain a >> Recv-Info header listing the given Info Package. >> >> Section 3.1 - "the target UA may not send form package P" >> >> s/form/from/ >> >> Section 3.1 - "... the other UA in the dial will assume the ..." >> >> s/dial/dialog/ >> >> Section 3.1 - "server MAY terminate the session with a CANCEL or BYE" >> >> When the "server" is the UAS of the request, CANCEL is not >> appropriate, and BYE would not be appropriate if it is an initial >> INVITE. In this case, the request would need to be rejected. When >> the "server" is the UAC, I don't think CANCEL is appropriate since >> it is the far-end UA of a specific dialog that the UAC has an issue >> with, not all possible UAs in the case of an initial INVITE. >> >> Section 7 - Can Info Packages strengthen "MAY" to "SHOULD"? >> >> Section 8 - Why is the separator between Info-package-name and >> Info-package-param a DOT? Shouldn't it be a SEMI? I don't think that >> Info-package-param is similar to event-template in 3265. Its more >> like >> event-param. >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-90-371796356 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDYyMjAzNTRaMCMGCSqGSIb3 DQEJBDEWBBRvRwDzRIgZGUqao6UPrfixqF+w8zCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQCah+vOuI4PPfK+fRxykB6ox9p9B08nP9fQjmLn/hw1x20t TsIqOp+3VgKsFa0OpdSWPcqpgkaLoF71fbM0ZUQpqBYc4i7VilVFzJIfX9C9aSN7P3bcFDUc+FrI xTjGWYJl4u2HLvNSVcRStTrB3JDkDmP5xjuUQvHO++B3MaQy+vmww8Z/EndAKpyNMjcKKWCEDUrf maDDwXt9zcOd8e5PHhJyGrBirm0rKLxSjPMnURJEz2MnOI7je5CLfhmi7X+7z3G6k3/NrHz3rJ1B je7i8RnvHaHUOT9ObnAgOyZCKSTjhGaiF1+v/gRdjwBuujfL101FVJbzvqtKJlKAQ0V5AAAAAAAA --Apple-Mail-90-371796356-- From BPenfield@acmepacket.com Sat Mar 7 07:09:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A645B3A6784 for ; Sat, 7 Mar 2009 07:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSF-nLnpAZwP for ; Sat, 7 Mar 2009 07:09:22 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BB3803A6818 for ; Sat, 7 Mar 2009 07:09:22 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 10:09:53 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 10:09:53 -0500 From: Bob Penfield To: Eric Burger , Brett Tate Date: Sat, 7 Mar 2009 10:09:46 -0500 Thread-Topic: [Sip] draft-ietf-sip-info-events-03: comments and questions Thread-Index: AcmfM6SfFPhZ2WDUT2mJOv6HSLsBwQAAb/iw Message-ID: References: <9B2A061A1137254BBE4F4B2CD843646A0FD7115231@mbx02.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP IETF Subject: Re: [Sip] draft-ietf-sip-info-events-03: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 15:09:23 -0000 inline >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric= Burger >Sent: Friday, March 06, 2009 4:56 PM > >On Feb 16, 2009, at 7:18 PM, Brett Tate wrote: > >> Section 4.3: When sending a 489, it indicates "MUST terminate the >> INVITE dialog". The "MUST terminate" seems severe even if all the >> negotiation race conditions are adequately addressed. The mentioned >> "protocol failure" reason seems contrary to the "strictly send and >> lenient receive" mantra. > >Maybe living in New Hampshire has made me more conservative. A lot of >folks will today say that while "Be conservative in what you send and >liberal in what you receive" may have been the greatest mistake we >ever made in protocol design. Let us look at this from a practical >perspective. If you are a bad implementor and send a 489 you didn't >mean to, who knows what else you will get wrong. Conversely, if you >are a bad implementor and forget to tear down a 489-ed INFO, bad >things probably will not happen. > >I will defer to the WG on this one. Any other opinions? RFC 5057 indicates that a 489 should destroy the dialog usage. However, it also says: (12) 489 Bad Event: In our example scenario, [5] declares that the subscription usage in which the NOTIFY is sent is terminated. This response is only valid in the context of SUBSCRIBE and NOTIFY. UAC behavior for receiving this response to other methods is not specified, but treating it as an unknown 4xx is a reasonable practice. I'm inclined to say that since the INFO is not suppose to change dialog state, a 489 response to an INFO should not destroy the INVITE dialog usage. With SUBSCRIBE/NOTIFY its a failure of the dialog establishing/target-refresh request which is essential to the dialog usage. But INFO is not essential to the INVITE dialog usage, so applying the last sentence above makes sense to me. cheers, (-:bob From jan@ryngle.com Sat Mar 7 10:32:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9856B28C0F5 for ; Sat, 7 Mar 2009 10:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju3Y8m4NTjz0 for ; Sat, 7 Mar 2009 10:32:46 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 80F3C3A68ED for ; Sat, 7 Mar 2009 10:32:45 -0800 (PST) Received: by bwz26 with SMTP id 26so733591bwz.37 for ; Sat, 07 Mar 2009 10:33:16 -0800 (PST) Received: by 10.103.252.17 with SMTP id e17mr1710735mus.14.1236450796293; Sat, 07 Mar 2009 10:33:16 -0800 (PST) Received: from x61s.janakj (r9ea97.net.upc.cz [78.102.130.97]) by mx.google.com with ESMTPS id e8sm4132306muf.48.2009.03.07.10.33.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Mar 2009 10:33:15 -0800 (PST) Received: by x61s.janakj (Postfix, from userid 1000) id B5DF44403F8; Sat, 7 Mar 2009 19:33:13 +0100 (CET) Date: Sat, 7 Mar 2009 19:33:13 +0100 From: Jan Janak To: Nils Ohlmeier Message-ID: <20090307183313.GA4364@x61s.janakj.ryngle.net> References: <49AE593F.6080807@iptel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 18:32:57 -0000 Nils, On 05-03 14:40, Nils Ohlmeier wrote: > Hello, > > first of all I agree that the draft describes a potential problem. > > One thing which is not that obvious but is implictly a requirement for the > attack: the proxies has to challenge in-dialog requests. It is not the proxy who challenges the in-dialog request, it is the attacker (Bob). Even if the proxy is configured not to challenge in-dialog requests, or even if digest authentication is not used at all on the proxy, as long as it forwards the 407 from the attacker, the attack would still be possible. The proxy (in figure 2) is only used to make sure that the 407 generated by Bob makes it to Alice. See figure 2 in the I-D, the 407 is generated by Bob based on the 407 he received from p2.com. And the 407 from p2.com is a response to an out-of-dialog INVITE. So a requirement to make the attack possible is that the user agent responds to challenges generated for in-dialog requests. > I do not see a > big benefit in challeging in-dialog requests as these are hopefully > rejected by the remote side if no matching dialog exists. Yes, hopefully :-). But what if not? What if you deploy a poorly implemented PSTN gateway which would happily process an in-dialog request with no matching dialog? Of course you can test the gateway before you deploy it if it is under your control. There are other cases where you know nothing about the target UA implementation, such as when the users of your proxy call other users and you have no control over the UA implementation they use. > - I never unterstood why a proxy should pass through the authentication > request from a foreign domain. Because this is how it is specified in section 22.3 of RFC3261. > In which scenario do I have credentials for > two different domains, but the traffic including authentication is passed > through only one of them? One such scenario is that you have a UA configured with credentials for two different ITSPs and the UA uses another proxy server as the outbound proxy for both of them. This outbound proxy could be your corporate proxy sitting on a firewall, NAT conditioning proxy, SBC, etc.. Jan. From jan@ryngle.com Sat Mar 7 11:08:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B69D28C12F for ; Sat, 7 Mar 2009 11:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIDROxIxyh2A for ; Sat, 7 Mar 2009 11:08:53 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 73B2C3A6A2B for ; Sat, 7 Mar 2009 11:08:53 -0800 (PST) Received: by bwz26 with SMTP id 26so740622bwz.37 for ; Sat, 07 Mar 2009 11:09:24 -0800 (PST) Received: by 10.102.228.10 with SMTP id a10mr1722226muh.26.1236452964213; Sat, 07 Mar 2009 11:09:24 -0800 (PST) Received: from x61s.janakj (r9ea97.net.upc.cz [78.102.130.97]) by mx.google.com with ESMTPS id u9sm4133153muf.55.2009.03.07.11.09.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Mar 2009 11:09:23 -0800 (PST) Received: by x61s.janakj (Postfix, from userid 1000) id 21BE24403F8; Sat, 7 Mar 2009 20:09:22 +0100 (CET) Date: Sat, 7 Mar 2009 20:09:22 +0100 From: Jan Janak To: Theo Zourzouvillys Message-ID: <20090307190922.GB4364@x61s.janakj.ryngle.net> References: <49AE593F.6080807@iptel.org> <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 19:08:54 -0000 On 05-03 14:31, Theo Zourzouvillys wrote: > However, you don't cover the more interesting cases of multi-hop proxy > authentication or end-to-end WWW authentication: these are the harder > ones to deal with, and may result in some "real" issues in SIP itself > rather than shoddy implementations and insecure proxies. Yes, after reading the discussion here I agree, perhaps the next revision of the ID (if there is going to be any) should describe more difficult cases, such as multi-hop authentication and challenging proxies reachable through one common proxy. These are much harder cases to deal with. Jan. From HKaplan@acmepacket.com Sat Mar 7 11:18:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751BF3A692F for ; Sat, 7 Mar 2009 11:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJrTC1KJrhpV for ; Sat, 7 Mar 2009 11:18:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 898803A6893 for ; Sat, 7 Mar 2009 11:18:31 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 14:19:02 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 14:19:02 -0500 From: Hadriel Kaplan To: Jan Janak , Nils Ohlmeier Date: Sat, 7 Mar 2009 14:18:43 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmfU1PoLkKPRRb1R8yqgkkqjeBonwAAKyPQ Message-ID: References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> In-Reply-To: <20090307183313.GA4364@x61s.janakj.ryngle.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 19:18:32 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jan > Janak > Sent: Saturday, March 07, 2009 1:33 PM > > So a requirement to make the attack possible is that the user agent > responds > to challenges generated for in-dialog requests. Right, and that the attacked domain accepts INVITEs from its AoR's with non= -registered Contacts; or accepts INVITEs from its static AoR's to come in f= rom unknown locations. That's pretty rare in my world, but ymmv. > > I do not see a > > big benefit in challeging in-dialog requests as these are hopefully > > rejected by the remote side if no matching dialog exists. > > Yes, hopefully :-). But what if not? What if you deploy a poorly > implemented > PSTN gateway which would happily process an in-dialog request with no > matching > dialog? Of course you can test the gateway before you deploy it if it is > under your control. At that point you're describing something that is fundamentally broken. Al= l bets are off, including any preventative security measures you could take= , etc. I mean at that point you could just say "what if the user/password = is published on a web site?" > There are other cases where you know nothing about the target UA > implementation, such as when the users of your proxy call other users and > you > have no control over the UA implementation they use. Then get yourself a box that enforces the protocol rules in the middle. :) > > - I never unterstood why a proxy should pass through the authentication > > request from a foreign domain. > > Because this is how it is specified in section 22.3 of RFC3261. And it would have to continue to do so. There are actual use-cases for thi= s. I think there's even a reasonable use-case for challenging in-dialog re= quests: connected-identity, for example. But you don't even need to challenge in-dialog requests for this form of at= tack: if the victim calls you, then you can challenge the initial INVITE. -hadriel From jan@ryngle.com Sat Mar 7 11:50:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB6D28C1B4 for ; Sat, 7 Mar 2009 11:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kr1AuiUqaST for ; Sat, 7 Mar 2009 11:50:17 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 9338D28C1B1 for ; Sat, 7 Mar 2009 11:50:16 -0800 (PST) Received: by bwz26 with SMTP id 26so748241bwz.37 for ; Sat, 07 Mar 2009 11:50:47 -0800 (PST) Received: by 10.103.249.19 with SMTP id b19mr1726730mus.86.1236455447490; Sat, 07 Mar 2009 11:50:47 -0800 (PST) Received: from x61s.janakj (r9ea97.net.upc.cz [78.102.130.97]) by mx.google.com with ESMTPS id 14sm4267249muo.20.2009.03.07.11.50.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Mar 2009 11:50:46 -0800 (PST) Received: by x61s.janakj (Postfix, from userid 1000) id 60A324403F8; Sat, 7 Mar 2009 20:50:45 +0100 (CET) Date: Sat, 7 Mar 2009 20:50:45 +0100 From: Jan Janak To: Hadriel Kaplan Message-ID: <20090307195045.GC4364@x61s.janakj.ryngle.net> References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "sip@ietf.org" , Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 19:50:19 -0000 On 05-03 11:33, Hadriel Kaplan wrote: > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > > Raphael Coeffic > > Sent: Thursday, March 05, 2009 4:48 AM > > > > The second difference is that it works > > right now with any publicly reachable SIP provider. > > I think I know what you mean by this statement, but maybe I don't. I think you mean it "works" right now only on a publicly reachable SIP provider that accepts INVITE requests from non-Registered Contacts. No? Or do you mean you've done testing of all publicly reachable SIP providers and found this to be an issue for all of them, right now? I am not sure I understand how accepting/not-accepting INVITEs from non-registered contacts makes it different, could you elaborate? Roughly, as long as the attacker can establish a call with the victim and make him/her respond to 407 within the session (for example by forcing the UA to generate a re-INVITE), the attacker can get access to the victims credentials. In some cases (if the victim UA is only reachable through a proxy and the proxy removes its own credentials), the attacker would not be able to get the credentials for that proxy, but might be able to get credentials for another domain if the victim's UA is configured with multiple sets of credentials. I don't want to put words in Raphael's mouth, but he probably mentioned publicly reachable SIP providers because they typically place no restrictions on incoming calls for their users and thus this kind of attack can be easily tried with them. > And this is not to say the attack isn't interesting, or that publicly > reachable SIP providers actually *use* such security policies. I've been > surprised before about how some of them don't actually employ the security > mechanisms they have at their disposal. But not using available mechanisms > is very different from not having a way to do them. Yes, I agree, in this case it would be interesting to know how many of them actually remove used digest credentials before they forward SIP requests. Jan. From HKaplan@acmepacket.com Sat Mar 7 11:51:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F221128C1C1 for ; Sat, 7 Mar 2009 11:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W9F3WYzJ1Te for ; Sat, 7 Mar 2009 11:51:27 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1A50628C1B1 for ; Sat, 7 Mar 2009 11:51:27 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 14:51:58 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 14:51:56 -0500 From: Hadriel Kaplan To: Jan Janak , Theo Zourzouvillys Date: Sat, 7 Mar 2009 14:51:54 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmfWEPUSoOsIsl/SCOKhQ2+t4Po8wAAVFng Message-ID: References: <49AE593F.6080807@iptel.org> <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> <20090307190922.GB4364@x61s.janakj.ryngle.net> In-Reply-To: <20090307190922.GB4364@x61s.janakj.ryngle.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 19:51:28 -0000 Another question is whether an attacker can create special nonce's for one = or more challenges it sends, that will help it figure out the password. Fo= r example can they help a rainbow-table type of password cracking, and how = much the cnonce can prevent that. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jan > Janak > Sent: Saturday, March 07, 2009 2:09 PM > > On 05-03 14:31, Theo Zourzouvillys wrote: > > However, you don't cover the more interesting cases of multi-hop proxy > > authentication or end-to-end WWW authentication: these are the harder > > ones to deal with, and may result in some "real" issues in SIP itself > > rather than shoddy implementations and insecure proxies. > > Yes, after reading the discussion here I agree, perhaps the next revision > of > the ID (if there is going to be any) should describe more difficult cases= , > such as multi-hop authentication and challenging proxies reachable throug= h > one > common proxy. These are much harder cases to deal with. > > Jan. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From victor.pascual.avila@gmail.com Sat Mar 7 12:44:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A3E3A6996 for ; Sat, 7 Mar 2009 12:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBMEfpAg7GzI for ; Sat, 7 Mar 2009 12:44:02 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id BD8BD3A6AA6 for ; Sat, 7 Mar 2009 12:44:01 -0800 (PST) Received: by ewy25 with SMTP id 25so471297ewy.37 for ; Sat, 07 Mar 2009 12:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ABFsj6XuvDLSX/XGSOweLjH7h7LtwOcLjccbNQA+2X8=; b=MbWL55B67KLKGKImpQrtlOAyvJYjwjRX8Ide7VVL7FIybUaLnzABN7bTm7FN0VRCUL srgPX1gs75se1pSNVWm0TtyfgscGJYoja2XhKj9Idi/jJzSr2PVSSVDvluE1ouK8O90G /uLG7t0KkBf5ABT6nGi2RBlGeFTGIq9letj7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Trel092bBV1E1Jg/OiC3gjfB17HGTJCsFf9/lIeg/0l8NEkgDunUMixEzixIWccuMN xlvi7ZuGDGTXFeltW7Yqb4lr2TckjaUcrfgykQfm/UCLBu+KyASYaf1HGK8hh9+qco6u pwiTKqhgrOGSLL86k9zqJuGfP4WxGbY2o13Ow= MIME-Version: 1.0 Received: by 10.210.91.7 with SMTP id o7mr2165278ebb.61.1236458673066; Sat, 07 Mar 2009 12:44:33 -0800 (PST) In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D0019C04BD@GBNTHT12009MSX.gb002.siemens.net> Date: Sat, 7 Mar 2009 21:44:33 +0100 Message-ID: <618e24240903071244n32821877qe9782854e12cb08a@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 20:44:03 -0000 On Fri, Mar 6, 2009 at 12:44 AM, Hadriel Kaplan wr= ote: > > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Thursday, March 05, 2009 12:15 PM >> >> Should we specify something that would make life easier for >> proxies/B2BUAs to detect compliance with this, e.g., a magic string at >> the start of the call-ID, rather than simply the absence of "@"? > > At one point I was thinking of just making it either be an "invalid" host= : > Call-ID: randomstuffheregibberish@invalid > > Or a fixed-length hex-ascii type thing (like Session-ID). =C2=A0But then = someone pointed out to me that some devices already don't put their IP/host= in it, so there's no reason to go make them change their implementation, n= or replace their call-id until they do. > > The thing is I think that a proxy/b2bua which cares about this for securi= ty properties, would need/want to scan the whole call-id for something whic= h looks like a host/IP anyway, to make a dynamic decision. =C2=A0So having = a magic string won't help them. =C2=A0And B2BUA's which change it for non-s= ecurity reasons will change it no matter what, because it's not the privacy= property they care about. IMO the UAS shall be able to know whether or not the call-id is end-to-end (e.g. INVITE-Initiated Dialog Event Package: a B2BUA can't fix the call-id if the return-routed subscribe request gets routed along a different path). --=20 Victor Pascual =C3=81vila From HKaplan@acmepacket.com Sat Mar 7 12:45:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C899528C1A1 for ; Sat, 7 Mar 2009 12:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJGVvrRIFuCe for ; Sat, 7 Mar 2009 12:45:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CF6E828C1A4 for ; Sat, 7 Mar 2009 12:45:30 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 15:46:01 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 15:45:59 -0500 From: Hadriel Kaplan To: Jan Janak Date: Sat, 7 Mar 2009 15:45:57 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmfXg0GObaIYznBRaOok2Fsz4+v+AAAVIDw Message-ID: References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <20090307195045.GC4364@x61s.janakj.ryngle.net> In-Reply-To: <20090307195045.GC4364@x61s.janakj.ryngle.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" , Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 20:45:31 -0000 > -----Original Message----- > From: Jan Janak [mailto:jan@ryngle.com] > Sent: Saturday, March 07, 2009 2:51 PM > > I am not sure I understand how accepting/not-accepting INVITEs from > non-registered contacts makes it different, could you elaborate? Assume Bob is bad, Alice is the victim. The setup for the attack is such that Bob sends an INVITE to/through Alice'= s domain, pretending to be Alice. Alice's domain challenges the INVITE, wh= ich Bob passes on to Alice, and using her challenge-response Bob challenge-= responds to Alice's domain. Right? I am arguing that in common practice (in my particular market space, anyway= ), Alice's domain wouldn't accept Bob's spoofed INVITE to begin with. Beca= use it requires Bob's UA to actually be Registered as Alice in order to sen= d in an INVITE pretending to be Alice. Since REGISTER requests are challen= ged, and the digest-challenge mechanism includes the Method name in the cal= culation, Bob can't try to REGISTER into Alice's domain and use a challenge= -response from her INVITE to do so. Ergo, no problem. Even for cases where they accept INVITE's from non-registering UA's (e.g, b= ig IP-PBX SIP Trunks), my particular customer types often restrict what AoR= can be claimed or allowed to make calls in from that trunk. On the peering side, it's a different story - but the model they currently = employ is a chain-of-trust, so they trust the peer to authenticate and cont= rol things in a similar fashion. Whether that's a good idea or not is a di= fferent story, but that's the current model. There are protection mechanis= ms available to prevent or at least mitigate this particular issue for peer= ing, but I have less confidence that people use them in practice. > I don't want to put words in Raphael's mouth, but he probably mentioned > publicly reachable SIP providers because they typically place no > restrictions > on incoming calls for their users and thus this kind of attack can be > easily > tried with them. Not in my experience. They place *many* restrictions on incoming calls. B= ut then those are my customers, which are just a subset, and obviously my v= iew is undoubtedly myopic because those are the types of providers that wou= ld be talking to me to begin with. And again, whether they actually use th= e tools at hand I don't know. -hadriel From HKaplan@acmepacket.com Sat Mar 7 13:08:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77AF3A6A2A for ; Sat, 7 Mar 2009 13:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDuhl7JsvV3n for ; Sat, 7 Mar 2009 13:08:11 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AB6BF3A6A7F for ; Sat, 7 Mar 2009 13:08:05 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 16:08:36 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 16:08:36 -0500 From: Hadriel Kaplan To: =?iso-8859-1?Q?Victor_Pascual_=C1vila?= Date: Sat, 7 Mar 2009 16:08:35 -0500 Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmfZZMWXREDdBb2TWmE1wqMtxJrgQAAGCGQ Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D0019C04BD@GBNTHT12009MSX.gb002.siemens.net> <618e24240903071244n32821877qe9782854e12cb08a@mail.gmail.com> In-Reply-To: <618e24240903071244n32821877qe9782854e12cb08a@mail.gmail.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 Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 21:08:11 -0000 > -----Original Message----- > From: Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com] > Sent: Saturday, March 07, 2009 3:45 PM > > IMO the UAS shall be able to know whether or not the call-id is > end-to-end (e.g. INVITE-Initiated Dialog Event Package: a B2BUA can't > fix the call-id if the return-routed subscribe request gets routed > along a different path). Are you suggesting that be added to this draft's goals, or just that we sho= uld tackle that problem (separately)? I personally don't think it should be a goal of this draft. There's a can = of worms in that goal, imho. This draft is short and to the point, address= ing one specific issue and solution. My hope is to get it fast-tracked if = people agree with it, or I'll change it to a BCP recommendation as an indiv= idual draft if people don't care. -hadriel From victor.pascual.avila@gmail.com Sat Mar 7 13:14:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76053A6A2A for ; Sat, 7 Mar 2009 13:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gG87bEAZ+Lb for ; Sat, 7 Mar 2009 13:14:57 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 83B083A68A4 for ; Sat, 7 Mar 2009 13:14:56 -0800 (PST) Received: by ewy25 with SMTP id 25so476060ewy.37 for ; Sat, 07 Mar 2009 13:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9i80R5JUSyrpBv8Iafx0efVEFjuziBwLQx73GaVSUho=; b=M6IRolSRjdZQLnHzN/rhodMaW76F0yIBWujRpKKL6Ydb4/x4c36ep30jWIk85oY2KE gaA3wgkw1+tniCNTxUYUoWqMSFoBuTZdfUyUE1UrzWZ5GtdK+cffPnmAwl6Woz5ky0Fj HLIv7hn8uM5oBuXdd6BQfel7XZ/aI0Vn8Qtg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=R68cwbg1MppSxEur23ZyJqo/he3nSqZVPZJguNUHL91jeoQx495LU7E089VH797yp9 EGClij/jZpiSk7i6zK6gS0HOcO0I0jsso847AQX5Vdwn+PauqEgvWnkIbi4B/OWrZEu3 qJKhlSrxX2KFXTTMtvk4EEtu4k3zZL0lupUHE= MIME-Version: 1.0 Received: by 10.210.125.7 with SMTP id x7mr1049608ebc.89.1236460527911; Sat, 07 Mar 2009 13:15:27 -0800 (PST) In-Reply-To: References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <20090307195045.GC4364@x61s.janakj.ryngle.net> Date: Sat, 7 Mar 2009 22:15:27 +0100 Message-ID: <618e24240903071315r56fd9794s6273d87fcfa87508@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 21:14:57 -0000 On Sat, Mar 7, 2009 at 9:45 PM, Hadriel Kaplan wro= te: > > >> -----Original Message----- >> From: Jan Janak [mailto:jan@ryngle.com] >> Sent: Saturday, March 07, 2009 2:51 PM >> >> I am not sure I understand how accepting/not-accepting INVITEs from >> non-registered contacts makes it different, could you elaborate? > > Assume Bob is bad, Alice is the victim. > The setup for the attack is such that Bob sends an INVITE to/through Alic= e's domain, pretending to be Alice. =C2=A0Alice's domain challenges the INV= ITE, which Bob passes on to Alice, and using her challenge-response Bob cha= llenge-responds to Alice's domain. =C2=A0Right? > > I am arguing that in common practice (in my particular market space, anyw= ay), Alice's domain wouldn't accept Bob's spoofed INVITE to begin with. =C2= =A0Because it requires Bob's UA to actually be Registered as Alice in order= to send in an INVITE pretending to be Alice. As an example: what would proxy.com check upon receipt of Bob's spoofed INVITE over UDP (forging packet source ip and port)? Thanks! --=20 Victor Pascual =C3=81vila From theo@crazygreek.co.uk Sat Mar 7 13:25:39 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2487B3A6AA6 for ; Sat, 7 Mar 2009 13:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.73 X-Spam-Level: X-Spam-Status: No, score=-5.73 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zplY5nCbMTZh for ; Sat, 7 Mar 2009 13:25:38 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id 1FBDE3A6818 for ; Sat, 7 Mar 2009 13:25:38 -0800 (PST) Received: from source ([72.14.220.157]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSbLmcjwH0FVu+UiGx9R+MYTRGNom4fUm@postini.com; Sat, 07 Mar 2009 13:26:10 PST Received: by fg-out-1718.google.com with SMTP id l26so600794fgb.29 for ; Sat, 07 Mar 2009 13:26:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.53.11 with SMTP id b11mr2872135fga.70.1236461169498; Sat, 07 Mar 2009 13:26:09 -0800 (PST) In-Reply-To: References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <20090307195045.GC4364@x61s.janakj.ryngle.net> Date: Sat, 7 Mar 2009 21:26:09 +0000 Message-ID: <167dfb9b0903071326u7a44d55fub7ebdb426460ce61@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sip@ietf.org" , Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 21:25:39 -0000 On Sat, Mar 7, 2009 at 8:45 PM, Hadriel Kaplan wro= te: > Not in my experience. =A0They place *many* restrictions on incoming calls= . >From what i see (at least in the UK), it seems to depend on if the provider is selling "PSTN termination" or "SIP services". The former tend to place many restrictions (make calls only if registered and from the IP that registered, only allow a single binding in AOR, etc), and the later tend not to (although may provide customers with the ability to). In the UK, I'm seeing a slow shift from the former to the later, although no idea about the rest of the world. hmm, the above paragraph could almost have been talking about AOL/compuserv vs a "real" ISP 15 years ago :-) ~ Theo From victor.pascual.avila@gmail.com Sat Mar 7 13:26:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050AE3A6B5C for ; Sat, 7 Mar 2009 13:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyQ7eMeKivDj for ; Sat, 7 Mar 2009 13:26:29 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id F22843A6818 for ; Sat, 7 Mar 2009 13:26:28 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so128012nfh.39 for ; Sat, 07 Mar 2009 13:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4apmNBUkz45eR7CxgAxsncNnc9Qn4Cw4VuiunQR0SDU=; b=MA71jivztdvq/HjqANKWKtEUj+YscuEf01YU/guFz9P4SYd+YbfLxhlmXUzyofGocI 3sR0LAdZWn8kGUhya2ULGoeRQXOtttfron9sD/3jhs33lR3o3CBG1VlNeWJvalmaI6i5 PVX+u30QXOw2H1kbv3ScCXOYm3u+FGEUJie48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YJZ3PDpJhxAFqQ+GX4fdF+49n53uv4s+bewKSSq/m/CMY784OYstx48aLnhCoxjH/V QC9foBMflPxdueUxx12upKX5tNlDgJZq/APGyOc4EzaT7ZQwQKFM+3Txa9Zq6jZUWof5 2Aa3bcqfhnYNV+PSgXAY8fKmXsYDhNYH8y6j8= MIME-Version: 1.0 Received: by 10.210.126.18 with SMTP id y18mr2182336ebc.69.1236461220291; Sat, 07 Mar 2009 13:27:00 -0800 (PST) In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D0019C04BD@GBNTHT12009MSX.gb002.siemens.net> <618e24240903071244n32821877qe9782854e12cb08a@mail.gmail.com> Date: Sat, 7 Mar 2009 22:27:00 +0100 Message-ID: <618e24240903071327o6eb3ef62ucfb04f86198daa6d@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 21:26:30 -0000 On Sat, Mar 7, 2009 at 10:08 PM, Hadriel Kaplan wr= ote: > > >> -----Original Message----- >> From: Victor Pascual =C3=81vila [mailto:victor.pascual.avila@gmail.com] >> Sent: Saturday, March 07, 2009 3:45 PM >> >> IMO the UAS shall be able to know whether or not the call-id is >> end-to-end (e.g. INVITE-Initiated Dialog Event Package: a B2BUA can't >> fix the call-id if the return-routed subscribe request gets routed >> along a different path). > > Are you suggesting that be added to this draft's goals, or just that we s= hould tackle that problem (separately)? I was just wondering if a magic cookie could help the UAS to identify end-to-end identifiers. --=20 Victor Pascual =C3=81vila From HKaplan@acmepacket.com Sat Mar 7 14:02:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66BD3A689A for ; Sat, 7 Mar 2009 14:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+AanilZNTRU for ; Sat, 7 Mar 2009 14:02:05 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BAF643A672F for ; Sat, 7 Mar 2009 14:02:05 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 17:02:35 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 17:02:36 -0500 From: Hadriel Kaplan To: =?iso-8859-1?Q?Victor_Pascual_=C1vila?= Date: Sat, 7 Mar 2009 17:02:32 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmfaeIybqBF+niVTyOL0istvYQ0/gAAVEUA Message-ID: References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <20090307195045.GC4364@x61s.janakj.ryngle.net> <618e24240903071315r56fd9794s6273d87fcfa87508@mail.gmail.com> In-Reply-To: <618e24240903071315r56fd9794s6273d87fcfa87508@mail.gmail.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 Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 22:02:06 -0000 > -----Original Message----- > From: Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com] > Sent: Saturday, March 07, 2009 4:15 PM > > As an example: what would proxy.com check upon receipt of Bob's > spoofed INVITE over UDP (forging packet source ip and port)? Well that is a trade secret, and specific to the proxy/SBC vendor being use= d, and probably its configuration. :) But anyway if Bob could guess Alice's source UDP IP and port (which by the = way is not always trivial to do), then it changes the form and scope of the= attack. The interesting characteristics of a relay-attack, baiting-attack= , etc., are that they do not require IP-layer spoofing. Typically, though, spoofing enough to get through would be less useful for = Bob to do unless he's actually a true MitM, because the SIP responses for t= he call will go to Alice, so Bob won't be able to pass along the challenge = and won't be able to establish a call. And even if Alice's UA is broken en= ough to answer a challenge for a request it didn't send, Bob would not get = the SIP responses to setup the call fully, nor send or receive media for it= . Bob could try to mount a resource-exhaustion attack on the provider, but= that too is throttled (and besides Bob won't be able to get Alice to chall= enge-response fast enough for each INVITE). Bob could try to perform an an= noyance attack by making phones ring, if he figures out how to avoid gettin= g Alice blocked automatically, but there are even countermeasures for that = available. Bob could try an attack for the purpose of getting Alice blocke= d from getting service for a period of time, but if Bob knows Alice's UDP s= ource info he can do that directly on Alice anyway, and the best the provid= er can do is stop it from affecting others. -hadriel From HKaplan@acmepacket.com Sat Mar 7 14:06:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D3D3A685D for ; Sat, 7 Mar 2009 14:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NFOgGtJ3Mok for ; Sat, 7 Mar 2009 14:06:05 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F1EB33A672F for ; Sat, 7 Mar 2009 14:06:04 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 17:06:36 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 17:06:34 -0500 From: Hadriel Kaplan To: =?iso-8859-1?Q?Victor_Pascual_=C1vila?= Date: Sat, 7 Mar 2009 17:06:27 -0500 Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: Acmfa4ENs3UPdCZbS2KGaIknVahbgQABPqsQ Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D0019C04BD@GBNTHT12009MSX.gb002.siemens.net> <618e24240903071244n32821877qe9782854e12cb08a@mail.gmail.com> <618e24240903071327o6eb3ef62ucfb04f86198daa6d@mail.gmail.com> In-Reply-To: <618e24240903071327o6eb3ef62ucfb04f86198daa6d@mail.gmail.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 Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 22:06:05 -0000 > -----Original Message----- > From: Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com] > Sent: Saturday, March 07, 2009 4:27 PM > > I was just wondering if a magic cookie could help the UAS to identify > end-to-end identifiers. Ahh, I see. Nope, it won't, I don't think. If a B2BUA changes the Call-ID= for reasons other than the security aspects, it would/should still create = a secure-call-id format - simply so that other B2BUA's along the path don't= feel compelled to as well and exacerbate the problem. I should make that = clear in the draft. -hadriel From HKaplan@acmepacket.com Sat Mar 7 14:39:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9E53A6A58 for ; Sat, 7 Mar 2009 14:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW6+b+HfJdcM for ; Sat, 7 Mar 2009 14:39:30 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A4C0E3A6923 for ; Sat, 7 Mar 2009 14:39:30 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 17:40:01 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 17:40:01 -0500 From: Hadriel Kaplan To: Theo Zourzouvillys Date: Sat, 7 Mar 2009 17:39:59 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: Acmfa1y7mzEa2TTeSzyWMntAalBFBAABboDw Message-ID: References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <20090307195045.GC4364@x61s.janakj.ryngle.net> <167dfb9b0903071326u7a44d55fub7ebdb426460ce61@mail.gmail.com> In-Reply-To: <167dfb9b0903071326u7a44d55fub7ebdb426460ce61@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" , Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 22:39:31 -0000 > -----Original Message----- > From: Theo Zourzouvillys [mailto:theo@crazygreek.co.uk] > Sent: Saturday, March 07, 2009 4:26 PM > > hmm, the above paragraph could almost have been talking about > AOL/compuserv vs a "real" ISP 15 years ago :-) Indeed. :) And email has been getting less spam and phishing and viruses ever since. = And email has an even stronger architecture for security than SIP in some w= ays, ironically. And less impact on the user-experience when it fails. In= many ways SIP's user-experience model is closer to IM than email, but with= some worse security properties. (and it's debatable if one would call IM = "open", or end-to-end) But even in that context of closed vs. open, you find web hosts having to e= mploy strong and stronger means of user authentication, such as captcha's, = and connection-layer security, such as TLS. If the open SIP providers don'= t employ some counter-measures for spoofing, user authentication, and servi= ce control, then they will when the issues crop up. (if they have enough us= ers to make attacking them interesting, which is the big "if") But anyway, that's why I want a SIP Identity mechanism that actually works,= fwiw. -hadriel From lists@ohlmeier.org Sat Mar 7 14:40:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9403A6A58 for ; Sat, 7 Mar 2009 14:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiPsKlx7d-gF for ; Sat, 7 Mar 2009 14:40:30 -0800 (PST) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 87F893A6923 for ; Sat, 7 Mar 2009 14:40:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id AACCA7F82; Sat, 7 Mar 2009 23:40:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iza5vAJwEE-j; Sat, 7 Mar 2009 23:40:57 +0100 (CET) Received: from Nils-MacBook-2.local (unknown [78.52.229.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bespin.rfc3261.net (Postfix) with ESMTPSA id 408CC7F55; Sat, 7 Mar 2009 23:40:57 +0100 (CET) Message-ID: <49B2F7F2.6030804@ohlmeier.org> Date: Sat, 07 Mar 2009 23:40:50 +0100 From: Nils Ohlmeier User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Hadriel Kaplan References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 22:40:31 -0000 Am 07.03.2009 20:18 Uhr, schrieb Hadriel Kaplan: >> So a requirement to make the attack possible is that the user agent >> responds >> to challenges generated for in-dialog requests. > > Right, and that the attacked domain accepts INVITEs from its AoR's with non-registered Contacts; or accepts INVITEs from its static AoR's to come in from unknown locations. That's pretty rare in my world, but ymmv. Luckily it seems we are not living in the same world :-) I call it a feature that I can make authenticated calls without being registered. [...] >>> - I never unterstood why a proxy should pass through the authentication >>> request from a foreign domain. >> Because this is how it is specified in section 22.3 of RFC3261. > > And it would have to continue to do so. There are actual use-cases for this. Could you please share one of these use-cases with me. > I think there's even a reasonable use-case for challenging in-dialog requests: connected-identity, for example. > > But you don't even need to challenge in-dialog requests for this form of attack: if the victim calls you, then you can challenge the initial INVITE. Sorry, but how is this going to work in world without a SBC which knows my credentials? Remember my proxy can not answer the challenge (CSeq mis-match). And the caller hopefully does not know my credentials, otherwise the whole attack would be pointless. Cheers Nils From theo@crazygreek.co.uk Sat Mar 7 15:22:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD313A6929 for ; Sat, 7 Mar 2009 15:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.744 X-Spam-Level: X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oof2rTxk07i8 for ; Sat, 7 Mar 2009 15:22:54 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with SMTP id 9A7003A67D6 for ; Sat, 7 Mar 2009 15:22:53 -0800 (PST) Received: from source ([72.14.220.154]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSbMB7dttJkpEkPl4Eg/zLm7U1/CKVHXp@postini.com; Sat, 07 Mar 2009 15:23:26 PST Received: by fg-out-1718.google.com with SMTP id 16so642291fgg.25 for ; Sat, 07 Mar 2009 15:23:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.86.31.18 with SMTP id e18mr2932524fge.72.1236468205084; Sat, 07 Mar 2009 15:23:25 -0800 (PST) In-Reply-To: References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <20090307195045.GC4364@x61s.janakj.ryngle.net> <167dfb9b0903071326u7a44d55fub7ebdb426460ce61@mail.gmail.com> Date: Sat, 7 Mar 2009 23:23:25 +0000 Message-ID: <167dfb9b0903071523x5eacc1a6w19efc32313b3b0be@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sip@ietf.org" , Dan Wing Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 23:22:54 -0000 On Sat, Mar 7, 2009 at 10:39 PM, Hadriel Kaplan wr= ote: > And email has been getting less spam and phishing and viruses ever since. SIP also has one major advantage than email does: we've not *yet* got the same penetration that SMTP did when it started really suffering. Although I do see exactly the same apathy to the problem in voice service providers and network operators now that I did in ISPs 10 years ago: "not a problem yet, can't afford to spend time on that". >=A0If the open SIP providers don't employ some counter-measures for spoofi= ng, user authentication, and service control, then they will when the issue= s crop up. It's difficult to do *that* much: a lot of the counter-measures need support from the endpoint vendors for various features. A look at the quality (or even existence) of mutual TLS and related things in almost all UAs speaks loads on their interest in such matters! > But anyway, that's why I want a SIP Identity mechanism that actually work= s, fwiw. i'll give 10 pounds (of the Great British variety) and a bottle of sheppy's finest Somerset cider to whoever comes up with such a thing. ~ Theo From dean.willis@softarmor.com Sat Mar 7 15:30:01 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49AB3A6AA8 for ; Sat, 7 Mar 2009 15:30:01 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4LBPcTueivd for ; Sat, 7 Mar 2009 15:30:01 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1DF073A6874 for ; Sat, 7 Mar 2009 15:30:01 -0800 (PST) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n27NURKQ021962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Mar 2009 17:30:29 -0600 Message-Id: From: Dean Willis To: Bob Penfield In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 17:30:22 -0600 References: <9B2A061A1137254BBE4F4B2CD843646A0FD7115231@mbx02.citservers.local> X-Mailer: Apple Mail (2.930.3) Cc: SIP IETF , Brett Tate Subject: Re: [Sip] draft-ietf-sip-info-events-03: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 23:30:02 -0000 Bob said: I'm inclined to say that since the INFO is not suppose to change > dialog state, a 489 response to an INFO should not destroy the INVITE > dialog usage. With SUBSCRIBE/NOTIFY its a failure of the dialog > establishing/target-refresh request which is essential to the dialog > usage. But INFO is not essential to the INVITE dialog usage, so > applying the last sentence above makes sense to me. Doesn't a 489 in any in-dialog Non-Invite-Transaction destroy the dialog usage? It seems like we break the state machine if we make INFO a special case. -- Dean From mdolly@att.com Sat Mar 7 15:39:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65DA3A6929 for ; Sat, 7 Mar 2009 15:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3qJYmoWn6er for ; Sat, 7 Mar 2009 15:39:18 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id C563E3A67A7 for ; Sat, 7 Mar 2009 15:39:17 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1236469188!3042321!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 30101 invoked from network); 7 Mar 2009 23:39:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 7 Mar 2009 23:39:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n27NdmkZ012681 for ; Sat, 7 Mar 2009 18:39:48 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n27Ndhj9012653 for ; Sat, 7 Mar 2009 18:39:43 -0500 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: Sat, 7 Mar 2009 18:39:42 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA01239075@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-info-events-03: comments and questions Thread-index: AcmffQRtzdidY039SDaQOmy+byrC8QAAPkjL From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: sip@ietf.org, brett@broadsoft.com Subject: Re: [Sip] draft-ietf-sip-info-events-03: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 23:39:18 -0000 U0lQIGhhcyBhIHN0YXRlIG1hY2hpbmU/Pz8gWW91IGNvdWxkIGZvb2wgbWUuLi4uDQoNCldoZXJl IGNhbiBJIGZpbmQgaXQ/IERvIG5vdCBzYXkgMzI2MQ0KDQpNYXJ0aW4NCg0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogc2lwLWJvdW5jZXNAaWV0Zi5vcmcgPHNpcC1ib3VuY2Vz QGlldGYub3JnPg0KVG86IEJvYiBQZW5maWVsZCA8QlBlbmZpZWxkQGFjbWVwYWNrZXQuY29tPg0K Q2M6IFNJUCBJRVRGIDxzaXBAaWV0Zi5vcmc+OyBCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQu Y29tPg0KU2VudDogU2F0IE1hciAwNyAxODozMDoyMiAyMDA5DQpTdWJqZWN0OiBSZTogW1NpcF0g ZHJhZnQtaWV0Zi1zaXAtaW5mby1ldmVudHMtMDM6IGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMNCg0K Qm9iIHNhaWQ6DQpJJ20gaW5jbGluZWQgdG8gc2F5IHRoYXQgc2luY2UgdGhlIElORk8gaXMgbm90 IHN1cHBvc2UgdG8gY2hhbmdlDQo+IGRpYWxvZyBzdGF0ZSwgYSA0ODkgcmVzcG9uc2UgdG8gYW4g SU5GTyBzaG91bGQgbm90IGRlc3Ryb3kgdGhlIElOVklURQ0KPiBkaWFsb2cgdXNhZ2UuIFdpdGgg U1VCU0NSSUJFL05PVElGWSBpdHMgYSBmYWlsdXJlIG9mIHRoZSBkaWFsb2cNCj4gZXN0YWJsaXNo aW5nL3RhcmdldC1yZWZyZXNoIHJlcXVlc3Qgd2hpY2ggaXMgZXNzZW50aWFsIHRvIHRoZSBkaWFs b2cNCj4gdXNhZ2UuIEJ1dCBJTkZPIGlzIG5vdCBlc3NlbnRpYWwgdG8gdGhlIElOVklURSBkaWFs b2cgdXNhZ2UsIHNvDQo+IGFwcGx5aW5nIHRoZSBsYXN0IHNlbnRlbmNlIGFib3ZlIG1ha2VzIHNl bnNlIHRvIG1lLg0KDQpEb2Vzbid0IGEgNDg5IGluIGFueSBpbi1kaWFsb2cgTm9uLUludml0ZS1U cmFuc2FjdGlvbiBkZXN0cm95IHRoZSAgDQpkaWFsb2cgdXNhZ2U/IEl0IHNlZW1zIGxpa2Ugd2Ug YnJlYWsgdGhlIHN0YXRlIG1hY2hpbmUgaWYgd2UgbWFrZSBJTkZPICANCmEgc3BlY2lhbCBjYXNl Lg0KDQotLQ0KRGVhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXANClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3Jl IFNJUCBQcm90b2NvbA0KVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBx dWVzdGlvbnMgb24gY3VycmVudCBzaXANClVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2 ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCg== From HKaplan@acmepacket.com Sat Mar 7 16:30:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE523A68BD for ; Sat, 7 Mar 2009 16:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb00ka5w-AMM for ; Sat, 7 Mar 2009 16:30:04 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 833113A6A88 for ; Sat, 7 Mar 2009 16:30:04 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 19:30:35 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 19:30:33 -0500 From: Hadriel Kaplan To: Nils Ohlmeier Date: Sat, 7 Mar 2009 19:30:30 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmfdcpVzceegU5LQJi8tV3rXHaJDQAACpUA Message-ID: References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> In-Reply-To: <49B2F7F2.6030804@ohlmeier.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 00:30:10 -0000 > -----Original Message----- > From: Nils Ohlmeier [mailto:lists@ohlmeier.org] > Sent: Saturday, March 07, 2009 5:41 PM > > Am 07.03.2009 20:18 Uhr, schrieb Hadriel Kaplan: > >> So a requirement to make the attack possible is that the user agent > >> responds > >> to challenges generated for in-dialog requests. > > > > Right, and that the attacked domain accepts INVITEs from its AoR's with > non-registered Contacts; or accepts INVITEs from its static AoR's to come > in from unknown locations. That's pretty rare in my world, but ymmv. > > Luckily it seems we are not living in the same world :-) > I call it a feature that I can make authenticated calls without being > registered. Why, is sending a REGISTER hard?? It looks like a simple enough message to= generate. How about OPTIONS? (has anyone ever noticed that OPTIONS is an anagram for POTIONS, or "O, NOT= SIP" or "ON TO SIP" or "TON-O-SIP" or "TIS NO-OP" or "I NO POTS"? weird) But anyway, sure - I'm not saying the attack isn't interesting or worth fig= uring out a solution/prevention for. I think it *is*. I was only challeng= ing a claim that Service Providers on the Internet are currently exposed to= it. Not all of them are. > >>> - I never unterstood why a proxy should pass through the > authentication > >>> request from a foreign domain. > >> Because this is how it is specified in section 22.3 of RFC3261. > > > > And it would have to continue to do so. There are actual use-cases for > this. > > Could you please share one of these use-cases with me. Well, the 3GPP roaming case, for one. A pictorial version: http://www.tech-invite.com/Ti-ims-regflow-1.html > > I think there's even a reasonable use-case for challenging in-dialog > requests: connected-identity, for example. > > > > But you don't even need to challenge in-dialog requests for this form o= f > attack: if the victim calls you, then you can challenge the initial > INVITE. > > Sorry, but how is this going to work in world without a SBC which knows > my credentials? SBC's don't usually know your credentials, even now. They don't need to. But anyway, I'm not sure what you mean by the question. How is what going = to work? Stopping INVITE-based authentication relay-attacks? You don't ne= ed an SBC-type box to stop that. Just disconnect the cable. :) Or, use the counter-measures in the draft. Or change the protocol, or at l= east the authentication mechanism. -hadriel From HKaplan@acmepacket.com Sat Mar 7 20:24:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C073A6AE1 for ; Sat, 7 Mar 2009 20:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qssnond83jV2 for ; Sat, 7 Mar 2009 20:24:56 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CCC623A698E for ; Sat, 7 Mar 2009 20:24:55 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 23:25:26 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 23:25:24 -0500 From: Hadriel Kaplan To: Hadriel Kaplan , Nils Ohlmeier Date: Sat, 7 Mar 2009 23:25:20 -0500 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmfdcpVzceegU5LQJi8tV3rXHaJDQAACpUAAAvL5FA= Message-ID: References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 04:24:57 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Saturday, March 07, 2009 7:31 PM > > But anyway, I'm not sure what you mean by the question. How is what goin= g > to work? Stopping INVITE-based authentication relay-attacks? You don't > need an SBC-type box to stop that. Just disconnect the cable. :) > Or, use the counter-measures in the draft. Or change the protocol, or at > least the authentication mechanism. BTW, you don't need to be an SBC to have such policies. There is nothing i= n RFC 3261 which prohibits a pure Proxy from restricting who it accepts INV= ITEs from, and when. There are even some clever tricks one can do to make = it a stateless mechanism. -hadriel From HKaplan@acmepacket.com Sun Mar 8 12:43:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719CD3A6802 for ; Sun, 8 Mar 2009 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8bVv5G7ViRC for ; Sun, 8 Mar 2009 12:43:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 78C6D3A6860 for ; Sun, 8 Mar 2009 12:43:49 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 8 Mar 2009 15:44:21 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 8 Mar 2009 15:44:21 -0400 From: Hadriel Kaplan To: "sip@ietf.org" Date: Sun, 8 Mar 2009 15:44:02 -0400 Thread-Topic: I-D Action:draft-kaplan-sip-session-id-02.txt Thread-Index: AcmgJHCEzbaNHlb9Tq6vwrvEsCDm3gAAVqHg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_E6C2E8958BA59A4FB960963D475F7AC314C4DE6376mail_" MIME-Version: 1.0 Subject: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:43:50 -0000 --_002_E6C2E8958BA59A4FB960963D475F7AC314C4DE6376mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, A new version of the session-id draft has been uploaded, removing the match= ing properties from the requirements and solution, in the hopes of progress= ing it faster. The purpose of it is now solely for troubleshooting across SIP nodes. -hadriel > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of Internet-Drafts@ietf.org > Sent: Sunday, March 08, 2009 3:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-kaplan-sip-session-id-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Session Identifier for the Session Initiation > Protocol (SIP) > Author(s) : H. Kaplan > Filename : draft-kaplan-sip-session-id-02.txt > Pages : 11 > Date : 2009-03-08 > > There are several reasons for having a globally unique session > identifier for the same SIP session, which can be maintained across > B2BUA's and other SIP middle-boxes. This draft proposes a new SIP > header to carry such a value: Session-ID. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-sip-session-id-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --_002_E6C2E8958BA59A4FB960963D475F7AC314C4DE6376mail_ Content-Type: text/plain; name="draft-kaplan-sip-session-id-02.url.txt" Content-Description: draft-kaplan-sip-session-id-02.url.txt Content-Disposition: attachment; filename="draft-kaplan-sip-session-id-02.url.txt"; size=95; creation-date="Sun, 08 Mar 2009 15:31:12 GMT"; modification-date="Sun, 08 Mar 2009 15:31:12 GMT" Content-Transfer-Encoding: base64 VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg== --_002_E6C2E8958BA59A4FB960963D475F7AC314C4DE6376mail_-- From HKaplan@acmepacket.com Sun Mar 8 12:51:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F923A6C3F for ; Sun, 8 Mar 2009 12:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXaoBfROX7wC for ; Sun, 8 Mar 2009 12:51:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EF60E3A6ACE for ; Sun, 8 Mar 2009 12:51:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 8 Mar 2009 15:52:31 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 8 Mar 2009 15:52:26 -0400 From: Hadriel Kaplan To: "sip@ietf.org" Date: Sun, 8 Mar 2009 15:52:23 -0400 Thread-Topic: I-D Action:draft-kaplan-sip-asserter-identity-01.txt Thread-Index: AcmgHAvp4O4wrLI1Qnyv3RMS6sFcgwACk1lw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_E6C2E8958BA59A4FB960963D475F7AC314C4DE6378mail_" MIME-Version: 1.0 Subject: [Sip] FW: I-D Action:draft-kaplan-sip-asserter-identity-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 19:52:00 -0000 --_002_E6C2E8958BA59A4FB960963D475F7AC314C4DE6378mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, An updated version of SIP Asserter Identity has been uploaded, though with = virtually no changes other than to avoid expiration. But since the topic of SIP Identity is coming up (again) at the upcoming me= eting, and this draft is related, I thought I'd post this again. There was not much feedback to the previous rev, so I'm guessing folks eith= er don't like it, or don't care, or just haven't had the time to read it. As always, comments are appreciated - including just saying "don't care". -hadriel > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of Internet-Drafts@ietf.org > Sent: Sunday, March 08, 2009 2:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-kaplan-sip-asserter-identity-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Private Extensions to the Session Initiation > Protocol (SIP) for Asserter Identification within Trusted Networks > Author(s) : H. Kaplan > Filename : draft-kaplan-sip-asserter-identity-01.txt > Pages : 17 > Date : 2009-03-08 > > This document describes private extensions to the Session > Initiation Protocol (SIP) that enable a network of trusted SIP > servers to identify the asserter of private user identity defined > in RFC 3325. The use of these extensions is only applicable > inside a set of administrative domains with previously agreed-upon > policies for generation, transport and usage of such information. > This document does NOT offer a general identity model suitable for > use between different trust domains, or use in the Internet at > large. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-sip-asserter-identity- > 01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --_002_E6C2E8958BA59A4FB960963D475F7AC314C4DE6378mail_ Content-Type: text/plain; name="draft-kaplan-sip-asserter-identity-01.url.txt" Content-Description: draft-kaplan-sip-asserter-identity-01.url.txt Content-Disposition: attachment; filename="draft-kaplan-sip-asserter-identity-01.url.txt"; size=102; creation-date="Sun, 08 Mar 2009 14:31:07 GMT"; modification-date="Sun, 08 Mar 2009 14:31:07 GMT" Content-Transfer-Encoding: base64 VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg== --_002_E6C2E8958BA59A4FB960963D475F7AC314C4DE6378mail_-- From brett@broadsoft.com Sun Mar 8 14:31:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF333A68F9 for ; Sun, 8 Mar 2009 14:31:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUS0Mx93oCUG for ; Sun, 8 Mar 2009 14:31:02 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 438A63A6882 for ; Sun, 8 Mar 2009 14:31:02 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 8 Mar 2009 14:31:35 -0700 From: Brett Tate To: Eric Burger , SIP IETF Date: Sun, 8 Mar 2009 14:31:32 -0700 Thread-Topic: [Sip] draft-ietf-sip-info-events-03: comments and questions Thread-Index: AcmfM5Uo1wTw/ecKSuaOP9+xAcaIpgA7cvNg Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10B4A04C5B@mbx02.citservers.local> References: <9B2A061A1137254BBE4F4B2CD843646A0FD7115231@mbx02.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] draft-ietf-sip-info-events-03: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 21:31:03 -0000 Thanks for the response; reply inline. > > Section 3.1 paragraph 1: Concerning "MUST advertise" and > > "provisional 1xx", please clarify that the "MUST advertise"=20 > > is not applicable to the 100 response. Does the=20 > > "MUST advertise" and "provisional 1xx" apply to all (first=20 > > and subsequent within dialog) INVITE non 101-199=20 > > (intentionally indicated 199)? Concerning ACK for initial=20 > > INVITE's 2xx, does the "MUST advertise" always apply? >=20 > I would offer "MUST advertise" is appropriate. What is the=20 > rationale to not require it? We are expecting "early INFO,"=20 > so no reason to screw up UACs by having random appearances=20 > and disappearances of Recv-Info headers. A 100 response does not create a dialog; thus including it during setup has= no meaning or purpose. A proxy can send 100 responses within dialog; howe= ver the lack of Recv-Info appears to disable draft support per the followin= g draft snippet. Thus I prefer the text cover 101-299 Reponses instead of = 100-299 responses. Section 3.1: "if the UA neglects to include the Recv-Info header, the other= UA in the dial will assume the first UA no longer supports INFO as specifi= ed by this document." Nit: "dial" should be "dialog". > > Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1=20 > > indicates "session parameters" and sentence 2 indicates=20 > > "dialog parameters" concerning Info Package negotiation,=20 > > I'm not sure when the negotiation/renegotiation occurs. =20 > > Does it follow SDP offer/answer rules or something else;=20 > > if something else, what? I have the same question=20 > > concerning "dialog refresh" text discussed later within=20 > > the same section since incorrect interpretations might=20 > > trigger deactivation. >=20 > Should be dialog parameters everywhere. Would that clear=20 > up the confusion? Partially; when are dialog parameters renegotiated? My main concern is wit= h impacts of "neglects to include the Recv-Info" as reflected within above = section 3.1 snippet; thus the reason I'm trying to understand. To avoid disabling, Recv-Info must be within re-INVITE, UPDATE, ACK-for-2xx= , and 101-299 responses for these requests. Is Recv-Info mandatory within = PRACK and PRACK 2xx to avoid disabling? Is it mandatory within REFER and R= EFER 2xx to avoid disabling (REFER isn't listed within section 5.2)? > > Section 4.3: When sending a 489, it indicates "MUST=20 > > terminate the INVITE dialog". The "MUST terminate"=20 > > seems severe even if all the negotiation race conditions=20 > > are adequately addressed. The mentioned "protocol failure"=20 > > reason seems contrary to the "strictly send and lenient=20 > > receive" mantra. > Let us look at this from a practical perspective. If you are=20 > a bad implementor and send a 489 you didn't mean to, who=20 > knows what else you will get wrong. Conversely, if you > are a bad implementor and forget to tear down a 489-ed INFO,=20 > bad things probably will not happen. Consider ACK from caller glaring with INFO from called. If the ACK adjuste= d Recv-Info to no longer support foo and INFO contained foo, why MUST the c= aller terminate the dialog upon sending 489 instead of realizing that it wa= s just a glare? I actually think a good implementer would ignore the MUST = and choose to be non compliant to avoid customer complaints; however I'd ra= ther the draft be changed instead. Because updated Recv-Info can be within so many requests and responses with= in a dialog, there can be glare and ordering issues. Adding to the issue (= change and change back), is that the Recv-Info is required to be within so = many requests and responses to avoid disabling. From gao.yang2@zte.com.cn Sun Mar 8 19:49:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B047B3A6965; Sun, 8 Mar 2009 19:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.818 X-Spam-Level: X-Spam-Status: No, score=-92.818 tagged_above=-999 required=5 tests=[AWL=1.972, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00N1vYnOlztD; Sun, 8 Mar 2009 19:49:29 -0700 (PDT) Received: from mail.zte.com.cn (unknown [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 3AB133A692E; Sun, 8 Mar 2009 19:49:27 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.1590844366; Mon, 9 Mar 2009 11:12:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n292nMBn051578; Mon, 9 Mar 2009 10:49:22 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) From: gao.yang2@zte.com.cn To: SIP , SIPPING MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Mon, 9 Mar 2009 10:49:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-09 10:49:18, Serialize complete at 2009-03-09 10:49:18 Content-Type: multipart/alternative; boundary="=_alternative 000F7EA448257574_=" X-MAIL: mse1.zte.com.cn n292nMBn051578 Subject: [Sip] "UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 02:49:30 -0000 This is a multipart message in MIME format. --=_alternative 000F7EA448257574_= Content-Type: text/plain; charset="US-ASCII" There are two thought about "UPDATE during Re-INVITE". Which one is better or suits for current RFCs There are two thought about "UPDATE during Re-INVITE". 1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction RFC3312(Precondition) is a case. As there is such case, we can making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction. 2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction of Re-INVITE There is really need nested-modification, such as precondition and more in the future. But the cascade of nested transaction should be defined in application-level, not signal-level. So, it is better to make Re-INVITE and UPDATE separatly expect for definition such as precondition. And this obeys current definition of RFC3311. In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), the change of states is committed and effort at once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction can be violation of RFC3311. So, we shold not treat all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction. While UPDATE/200OK just refresh "precondition state table" in RFC3312("precondition state table" is modified at once, so this obeys RFC3312), having no impat on the commitment of modification triggered by Re-INVITE, these UPDATE/200OK can be treated as sub-transaction of Re-INVITE. Other UPDATE/200OK can not be treated as sub-transaction of Re-INVITE. Comments/feeling are welcome! -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000F7EA448257574_= Content-Type: text/html; charset="US-ASCII"
There are two thought about "UPDATE during Re-INVITE". Which one is better or suits for current RFCs

There are two thought about "UPDATE during Re-INVITE".

1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction
RFC3312(Precondition) is a case. As there is such case, we can making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.

2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction of Re-INVITE
There is really need nested-modification, such as precondition and more in the future.  But the cascade of nested transaction should be defined in application-level, not signal-level. So, it is better to make Re-INVITE and UPDATE separatly expect for definition such as precondition.  And this obeys current definition of RFC3311.

In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), the change of states is committed and effort at once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction can be violation of RFC3311. So, we shold not treat all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.

While UPDATE/200OK just refresh "precondition state table" in RFC3312("precondition state table" is modified at once, so this obeys RFC3312), having no impat on the commitment of modification triggered by Re-INVITE, these UPDATE/200OK can be treated as sub-transaction of Re-INVITE.
Other UPDATE/200OK can not be treated as sub-transaction of Re-INVITE.

Comments/feeling are welcome! 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000F7EA448257574_=-- From rco@iptel.org Mon Mar 9 04:41:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9453A6C78 for ; Mon, 9 Mar 2009 04:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNLoXlVjx4o3 for ; Mon, 9 Mar 2009 04:41:02 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 794AE3A67EA for ; Mon, 9 Mar 2009 04:41:02 -0700 (PDT) Received: by mail.iptel.org (Postfix, from userid 103) id 2C6EF1811CE1; Mon, 9 Mar 2009 12:41:35 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 5339D1811CD8; Mon, 9 Mar 2009 12:41:34 +0100 (CET) Message-ID: <49B5006D.8050702@iptel.org> Date: Mon, 09 Mar 2009 12:41:33 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hadriel Kaplan References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nils Ohlmeier , "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 11:41:03 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Hadriel Kaplan >> Sent: Saturday, March 07, 2009 7:31 PM >> >> But anyway, I'm not sure what you mean by the question. How is what going >> to work? Stopping INVITE-based authentication relay-attacks? You don't >> need an SBC-type box to stop that. Just disconnect the cable. :) >> Or, use the counter-measures in the draft. Or change the protocol, or at >> least the authentication mechanism. >> > > BTW, you don't need to be an SBC to have such policies. There is nothing in RFC 3261 which prohibits a pure Proxy from restricting who it accepts INVITEs from, and when. There are even some clever tricks one can do to make it a stateless mechanism. > > That's a good point. Requiring the user to be registered and only accepting requests from the registered contacts provide a fair-enough level of security concerning the attack debated. But I am still hoping that we could find a solution not requiring this kind of measures, which I would call "user-restricting". -Raphael. From eric.wangxr@gmail.com Mon Mar 9 05:05:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1073A685C; Mon, 9 Mar 2009 05:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.649 X-Spam-Level: ** X-Spam-Status: No, score=2.649 tagged_above=-999 required=5 tests=[AWL=-2.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHDVMpmWNyjh; Mon, 9 Mar 2009 05:05:30 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id 84B2E3A682E; Mon, 9 Mar 2009 05:05:29 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id 11so1133585tim.25 for ; Mon, 09 Mar 2009 05:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=qgZFyI1uqJnLXMfJINGiAieS+Bm2bUqNvTwutQKKI38=; b=feu7NUy26fdwcrTdxLh1Ua4QONnC/59pkYo/N9drXxbBLIAUK3O/XvZ7kzCOneCW44 MyTbkKu/K6LdnMbekNeh4tdU7usae+N+lgqtDPlU5HtVr37ADhlOnWDM+yZ+zM9euv8O WxSDTWMkTk1zf3XDYnSdv6ARp/WC3qfCLemqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=byCv/T+equ42CSnQIXm/zm6xWhLtset6V442EvDJVQaQeUROuUjdNr8Gx9mJjx0twO eN4wL0YhBSVyCmpO1hJebs7R8lgeFd4sVtef/r4EeNgMHA57zu5R2+k7cC/JtUSYyrmH wnRMYchCPQq5c9bvt7nBCWyKvrVYNxziTf8tY= Received: by 10.110.86.3 with SMTP id j3mr9019002tib.48.1236600355702; Mon, 09 Mar 2009 05:05:55 -0700 (PDT) Received: from EricXr ([222.94.145.234]) by mx.google.com with ESMTPS id y5sm237993tia.17.2009.03.09.05.05.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Mar 2009 05:05:54 -0700 (PDT) From: "Eric.wang" To: , "'SIP'" , "'SIPPING'" References: In-Reply-To: Date: Mon, 9 Mar 2009 20:05:51 +0800 Message-ID: <49b50622.054c6e0a.4998.ffffa440@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0270_01C9A0F2.73ED9690" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmgYce7sOUFYhoYTZGzYPsCJT+SYAAS3J6A Content-Language: zh-cn Subject: [Sip] =?gb2312?b?tPC4tDogICJVUERBVEUgZHVyaW5nIFJlLUlOVklURSIgZGlz?= =?gb2312?b?Y3Vzc2lvbg==?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 12:05:31 -0000 һ MIME ʽĶಿʼ ------=_NextPart_000_0270_01C9A0F2.73ED9690 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, =20 I support view 2,not all update can be considered as sub-transaction of re-INVITE. According to current RFCs, it=A1=AFs NOT proper to consider all UPDATEs = as re-INVITE=A1=AFs sub-transaction=20 Eg: UPDATE nested in re-INVITE for target refresh can=A1=AFt be considered = as sub-transaction. =20 =B7=A2=BC=FE=C8=CB: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = =B4=FA=B1=ED gao-.yang2@zte.com.cn =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA3=D4=C29=C8=D5 10:49 =CA=D5=BC=FE=C8=CB: SIP; SIPPING =D6=F7=CC=E2: [Sip] "UPDATE during Re-INVITE" discussion =20 There are two thought about "UPDATE during Re-INVITE". Which one is = better or suits for current RFCs=20 There are two thought about "UPDATE during Re-INVITE".=20 1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction=20 RFC3312(Precondition) is a case. As there is such case, we can making = all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.=20 2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction = of Re-INVITE=20 There is really need nested-modification, such as precondition and more = in the future. But the cascade of nested transaction should be defined in application-level, not signal-level. So, it is better to make Re-INVITE = and UPDATE separatly expect for definition such as precondition. And this = obeys current definition of RFC3311.=20 In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), = the change of states is committed and effort at once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction can be violation of = RFC3311. So, we shold not treat all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.=20 While UPDATE/200OK just refresh "precondition state table" in RFC3312("precondition state table" is modified at once, so this obeys RFC3312), having no impat on the commitment of modification triggered by Re-INVITE, these UPDATE/200OK can be treated as sub-transaction of Re-INVITE.=20 Other UPDATE/200OK can not be treated as sub-transaction of Re-INVITE.=20 Comments/feeling are welcome!=20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =20 __________ Information from ESET NOD32 Antivirus, version of virus = signature database 3918 (20090309) __________ =20 The message was checked by ESET NOD32 Antivirus. =20 http://www.eset.com ------=_NextPart_000_0270_01C9A0F2.73ED9690 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 

I support view 2,not all update can be considered as = sub-transaction of re-INVITE.

According to current RFCs, it=A1=AFs NOT proper to = consider all UPDATEs as re-INVITE=A1=AFs sub-transaction

Eg:

UPDATE nested in re-INVITE  for target refresh = can=A1=AFt be considered as sub-transaction.

 

=B7=A2=BC=FE=C8=CB: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] =B4=FA=B1=ED = gao-.yang2@zte.com.cn=
=B7=A2=CB=CD=CA=B1=BC= =E4: = 2009=C4=EA3=D4=C29=C8=D5 10:49
=CA=D5=BC=FE=C8=CB: SIP; SIPPING
=D6=F7=CC=E2: = [Sip] "UPDATE during Re-INVITE" discussion

 


There are two thought about "UPDATE during Re-INVITE". Which one is = better or suits for current RFCs

There are two thought about "UPDATE during = Re-INVITE".

1. All UPDATEs during Re-INVITE are Re-INVITE's = sub-transaction
RFC3312(Preco= ndition) is a case. As there is such case, we can making all UPDATEs during = Re-INVITE as Re-INVITE's sub-transaction.

2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction of = Re-INVITE
There is really need nested-modification, such as precondition and more in the future.  But the cascade of nested transaction should be defined in application-level, not signal-level. So, it is better to make = Re-INVITE and UPDATE separatly expect for definition such as precondition. =  And this obeys current definition of RFC3311. =

In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), = the change of states is committed and effort at once. And making all UPDATEs = during Re-INVITE as Re-INVITE's sub-transaction can be violation of RFC3311. = So, we shold not treat all UPDATEs during Re-INVITE as Re-INVITE's = sub-transaction.

While UPDATE/200OK just refresh "precondition state table" in RFC3312("precondition state table" is modified at once, so = this obeys RFC3312), having no impat on the commitment of modification triggered by Re-INVITE, these UPDATE/200OK can be treated as sub-transaction of = Re-INVITE.
Other UPDATE/200OK can not be treated as sub-transaction of = Re-INVITE.

Comments/feel= ing are welcome! 

 
--------------------------------------------------------
ZTE Information Security Notice: The&nbs=
p;information contained in this mail is sol=
ely property of the sender's organization. =
This mail communication is confidential. Recipie=
nts named above are obligated to maintain&n=
bsp;secrecy and are not permitted to disclo=
se the contents of this communication to&nb=
sp;others.
This email and any files transmitte=
d with it are confidential and intended&nbs=
p;solely for the use of the individual =
;or entity to whom they are addressed. =
;If you have received this email in er=
ror please notify the originator of the&nbs=
p;message. Any views expressed in this mess=
age are those of the individual sender.
This message has been scanned for&n=
bsp;viruses and Spam by ZTE Anti-Spam syste=
m.

 

__________ Information from ESET NOD32 Antivirus, = version of virus signature database 3918 (20090309) = __________

 

The message was checked by ESET NOD32 = Antivirus.

 

http://www.eset.com

------=_NextPart_000_0270_01C9A0F2.73ED9690-- From lists@ohlmeier.org Mon Mar 9 07:16:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83DC3A6AFB for ; Mon, 9 Mar 2009 07:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2pD9tb-7yjs for ; Mon, 9 Mar 2009 07:16:00 -0700 (PDT) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 02FE13A6961 for ; Mon, 9 Mar 2009 07:15:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 97EB77F97; Mon, 9 Mar 2009 15:16:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRdPkh+Lxhov; Mon, 9 Mar 2009 15:16:31 +0100 (CET) Received: from www.ohlmeier.com (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 43DF87F55; Mon, 9 Mar 2009 15:16:31 +0100 (CET) Received: from 192.100.130.229 (SquirrelMail authenticated user lando) by www.ohlmeier.com with HTTP; Mon, 9 Mar 2009 15:16:31 +0100 (CET) Message-ID: In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA01239075@gaalpa1msgusr7e.ugd.att.com> References: <14C85D6CCBE92743AF33663BF5D24EBA01239075@gaalpa1msgusr7e.ugd.att.com> Date: Mon, 9 Mar 2009 15:16:31 +0100 (CET) From: "Nils Ohlmeier" To: "DOLLY, MARTIN C, ATTLABS" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: bpenfield@acmepacket.com, sip@ietf.org, brett@broadsoft.com, dean.willis@softarmor.com Subject: Re: [Sip] draft-ietf-sip-info-events-03: comments and questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:16:00 -0000 > SIP has a state machine??? You could fool me.... > > Where can I find it? Do not say 3261 Search in your favorite SIP stack. Some have it, others not... :-) Some even have a state per transaction and dialog. But don't get fooled by the marketing/sales department ;-) SCNR Nils From root@core3.amsl.com Mon Mar 9 07:45:02 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2CA3A28C187; Mon, 9 Mar 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309144502.2CA3A28C187@core3.amsl.com> Date: Mon, 9 Mar 2009 07:45:02 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-connect-reuse-13.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : V. Gurbani, et al. Filename : draft-ietf-sip-connect-reuse-13.txt Pages : 18 Date : 2009-03-09 This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forward and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TLS. For this reason, we only consider connection reuse for TLS over TCP and TLS over SCTP. This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09074001.I-D@ietf.org> --NextPart-- From vkg@alcatel-lucent.com Mon Mar 9 07:53:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887CC3A6966 for ; Mon, 9 Mar 2009 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJyMygIvz6pz for ; Mon, 9 Mar 2009 07:53:24 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 85C133A6909 for ; Mon, 9 Mar 2009 07:53:24 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n29Erpqj025545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Mar 2009 09:53:52 -0500 (CDT) Received: from shoonya.ih.lucent.com (pcp399716pcs.mh.lucent.com [135.222.225.47]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n29Erouo015531 for ; Mon, 9 Mar 2009 09:53:51 -0500 (CDT) Message-ID: <49B51F99.8040305@alcatel-lucent.com> Date: Mon, 09 Mar 2009 08:54:33 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: sip@ietf.org 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 Subject: [Sip] connect-reuse-13 released X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:53:25 -0000 Folks: connect-reuse-13 has been released to address AD comments and move the work forward in IESG. By far the most pervasive change was to restrict connection reuse to TLS connections, as we discussed on the list last week. We will explore a separate draft for TCP connection reuse after IETF 74. The draft is now available in the archives at: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-13.txt On behalf of the author team, I am hoping that version 13 will prove to be a charm ;-) Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://ect.bell-labs.com/who/vkg From lists@ohlmeier.org Mon Mar 9 08:04:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C483A69BA for ; Mon, 9 Mar 2009 08:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7AaEWfM1dln for ; Mon, 9 Mar 2009 08:04:11 -0700 (PDT) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 3D2EC3A6C3D for ; Mon, 9 Mar 2009 08:04:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id DC1697F97; Mon, 9 Mar 2009 16:04:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLrxVzePOLJ5; Mon, 9 Mar 2009 16:04:41 +0100 (CET) Received: from www.ohlmeier.com (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id A3C577F55; Mon, 9 Mar 2009 16:04:41 +0100 (CET) Received: from 192.100.130.229 (SquirrelMail authenticated user lando) by www.ohlmeier.com with HTTP; Mon, 9 Mar 2009 16:04:41 +0100 (CET) Message-ID: <3dc358653901c68d17436668827161f7.squirrel@www.ohlmeier.com> In-Reply-To: References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> Date: Mon, 9 Mar 2009 16:04:41 +0100 (CET) From: "Nils Ohlmeier" To: "Hadriel Kaplan" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:04:18 -0000 >> >>> - I never unterstood why a proxy should pass through the >> authentication >> >>> request from a foreign domain. >> >> Because this is how it is specified in section 22.3 of RFC3261. >> > >> > And it would have to continue to do so. There are actual use-cases >> for >> this. >> >> Could you please share one of these use-cases with me. > > Well, the 3GPP roaming case, for one. > A pictorial version: http://www.tech-invite.com/Ti-ims-regflow-1.html Well you are right, I was just thinking about the "typical" proxy/registrar combination. But there are outbound or travesering proxyies which don't do authentication at all. To stay at your 3GPP romain case: I don't think this attack would be possible if the S-CSCF does not pass through "unknown" auth requests. Right? The P-CSCF has to forward REGISTERs to non-local S-CSCF which then will authenticate the registration with "unknown"/non-local realms. But as soon as the UA is registered the P-CSCF should only accept terminating INVITE requests for that UA from the S-CSCF where the user is registered to. And again the S-CSCF of the user/UA has in my opinion no need to forward "foreign" authentication requests, or?! BTW as you pointed out already earlier debating this attack for IMS is only hypothetical, because IMS allows calls only from registered UAs. And from a more general perspective: I believe that such a transitive proxy which does not do authentication by himself should only accept auth requests from the serving/registrar proxy (or however you call the element which does the authentication part). Furthermore this transitive proxy should not allow dialogs over "just transitive proxys" (which have now clue about authentication) only (because that would allow the attacker again to send a challenge). >> > I think there's even a reasonable use-case for challenging in-dialog >> requests: connected-identity, for example. >> > >> > But you don't even need to challenge in-dialog requests for this form >> of >> attack: if the victim calls you, then you can challenge the initial >> INVITE. >> >> Sorry, but how is this going to work in world without a SBC which knows >> my credentials? > > SBC's don't usually know your credentials, even now. They don't need to. > > But anyway, I'm not sure what you mean by the question. How is what going > to work? Stopping INVITE-based authentication relay-attacks? You don't > need an SBC-type box to stop that. Just disconnect the cable. :) > Or, use the counter-measures in the draft. Or change the protocol, or at > least the authentication mechanism. My fault. I mis-read your original point. Cheers Nils From root@core3.amsl.com Mon Mar 9 09:15:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6D2B13A69DE; Mon, 9 Mar 2009 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309161501.6D2B13A69DE@core3.amsl.com> Date: Mon, 9 Mar 2009 09:15:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-07.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Framework for Establishing an SRTP Security Context using DTLS Author(s) : J. Fischl, et al. Filename : draft-ietf-sip-dtls-srtp-framework-07.txt Pages : 38 Date : 2009-03-09 This document specifies how to use the Session Initiation Protocol (SIP) to establish an Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-dtls-srtp-framework-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09090802.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 9 10:45:02 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 72FE13A695B; Mon, 9 Mar 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309174502.72FE13A695B@core3.amsl.com> Date: Mon, 9 Mar 2009 10:45:02 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-13.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-13.txt Pages : 46 Date : 2009-3-9 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where SIP servers make routing decisions based on the location of the user agent clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-3-9103602.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 9 12:00:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A7A7E3A6A91; Mon, 9 Mar 2009 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309190001.A7A7E3A6A91@core3.amsl.com> Date: Mon, 9 Mar 2009 12:00:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-saml-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP SAML Profile and Binding Author(s) : H. Tschofenig, et al. Filename : draft-ietf-sip-saml-06.txt Pages : 52 Date : 2009-03-09 This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-saml-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09115847.I-D@ietf.org> --NextPart-- From HKaplan@acmepacket.com Mon Mar 9 13:29:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265D23A6A0D for ; Mon, 9 Mar 2009 13:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSFc74PcSniR for ; Mon, 9 Mar 2009 13:29:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4CA633A69BA for ; Mon, 9 Mar 2009 13:29:30 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 9 Mar 2009 16:30:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 9 Mar 2009 16:30:03 -0400 From: Hadriel Kaplan To: Raphael Coeffic Date: Mon, 9 Mar 2009 16:30:01 -0400 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmgrAdWZnDRwuuzRh+l4fkwrKJgxQASKi+g Message-ID: References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> <49B5006D.8050702@iptel.org> In-Reply-To: <49B5006D.8050702@iptel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nils Ohlmeier , "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:29:34 -0000 > -----Original Message----- > From: Raphael Coeffic [mailto:rco@iptel.org] > Sent: Monday, March 09, 2009 7:42 AM > > That's a good point. Requiring the user to be registered and only > accepting requests from the registered contacts provide a fair-enough > level of security concerning the attack debated. But I am still hoping > that we could find a solution not requiring this kind of measures, which > I would call "user-restricting". How is it "user-restricting" to require a UA to generate a REGISTER request= ? Most humans don't generate the REGISTER request by hand - typically soft= ware does it for them. :) I mean at that point you can also just say "digest authentication is user-r= estricting". -hadriel From gonzalo.camarillo@ericsson.com Mon Mar 9 14:30:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1CB428C21F for ; Mon, 9 Mar 2009 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.677 X-Spam-Level: X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[AWL=1.572, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYsH1laE+RUr for ; Mon, 9 Mar 2009 14:30:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BB2CE28C12E for ; Mon, 9 Mar 2009 14:30:05 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 02393212D3; Mon, 9 Mar 2009 22:30:39 +0100 (CET) X-AuditID: c1b4fb3c-ad009bb000001b43-c0-49b58a7edb45 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C8A68206C0; Mon, 9 Mar 2009 22:30:38 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 22:30:38 +0100 Received: from [131.160.126.131] ([131.160.126.131]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 22:30:38 +0100 Message-ID: <49B58A7D.2070500@ericsson.com> Date: Mon, 09 Mar 2009 23:30:37 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Burger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2009 21:30:38.0523 (UTC) FILETIME=[4A4960B0:01C9A0FE] X-Brightmail-Tracker: AAAAAA== Cc: SIP List Subject: Re: [Sip] Comments on draft-ietf-sip-body-handling-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:30:08 -0000 Hi Eric, thanks for your comments. We had already agreed to request the publication of 05. We were just waiting for the chairs to do or get someone to do the PROTO write up for the draft (the PROTO write up has already been done at this point). In any case, I will revise the draft so that the revision we use for the publication request (06) will include your comments. My answers inline: > Good work and almost done! > > General > ======= > Many of the rules for multipart/mumble say things like "all parts must > be foo." This construction is not strictly correct. For example, in > multipart/alternative, I could have a multipart/mixed. Saying something > like "all parts in a multipart/alternative must be marked foo" means > that ALL parts, including walking down the multipart/mixed contained > therein, must be marked foo. What we really want to say is "all > top-level parts in a multipart/alternative must be marked foo." That > means, for example, if one of the parts is a multipart/mixed, the > multipart/mixed needs to have the foo marking, but things within the > multipart/mixed, I presume, will follow the appropriate rules for > multipart/mixed and the body's context. Good point. I have fixed it. > Section 3.2 > =========== > Please make clear that binary *SIP* message body parts MUST be binary, > as the text currently says. However, it is quite possible, and should be > legal, to encode application parts transported in SIP, such as INFO or > NOTIFY bodies. For example, one might forward a base64 e-mail or a > uuencoded file. Since that would be an application-level message, there > is no reason to burden the application with decoding the body part to > get it to binary, just for the other side to re-encode it. I have added the following: "The only case where a UA MAY use a different encoding is when transferring application data between applications that only handle a different encoding (e.g., base64)." > Section 6.2 > =========== > What confused me is section 6.2 starts with what looks like a normative > statement, but it really is a forward reference. To me, there is no > reference to which 'same' we are referring to. The text then seems to > jump to what looks like a special case for 'session' and > 'early-session'. I would suggest the following: > > > 6.2. UA Behavior to Generate 'multipart/alternative' Message Bodies > > Section 8.2 mandates all top-level body parts within a > 'multipart/alternative' have the same disposition type as the enclosing > 'multipart/alternative'. > > The 'session' and 'early-session' [RFC3959] disposition types require > that all body parts of a 'multipart/alternative' body have different > content types. Consequently, for the 'session' and 'early-session' > disposition types, each top-level body type within the > 'multipart/alternative' body MUST be different. Otherwise, the rules > for the specific disposition type apply. > NOTE: One could envision situations where a UA presents multiple > alternatives with the same body type, where the receiving UA picks the > best or richest alternative it can use. I have split the paragraphs as you suggest. I agree it makes the text clearer. However, I have stick to using the active voice for normative text, which is the trend nowadays (e.g., the UA MUST set the parameters to different values instead of the values of the parameters MUST be different). > Section 6.3 > =========== > Ah, but there ARE handling rules for multipart/alternative. I would > replace this section with: > > When a UA receives a message with a 'multipart/alternative' body > part, if the body part has a 'required' handling, then the UA MUST pick > the best alternative body part to use. If the UA is unable to use any > of the body parts, the UA MUST reject the request with a 415 error > response. This could occur if the UA did not understand any of the > top-level body parts within the 'multipart/alternative'. > > The handling marking for top-level body parts in a > 'multipart/alternative' has no meaning. Therefore, the UA MUST ignore > any 'handling' tags in the top-level body parts of the > 'multipart/alternative' body part. Once the UA picks one of the > top-level body parts to use, then the UA MUST use the appropriate > processing rules for the 'handling' tags within the selected top-level > body part. Rules about the handling parameter are given in Section 8.3. Below, you suggest to remove Section 8.3 and keep this one instead. The thing is that we had discussions on the structure of the document and this is the structure we agreed to have, including having sections like 6,3 for completeness. At this point, I do not want to reopen that agreement. > Section 8.2 > =========== > For multipart/alternative, a top-level body type with > 'handling=required' makes no sense. By definition, using > multipart/alternative means we expect the UA to not be able to handle > one or more of the body parts - we just do not know which one. I would > remove the note and incorporate the gist into the text: > > If the sending UA requires the handling of a 'multipart/alternative' > body as a whole, the UA MUST set the 'handling' parameter of the > 'multipart/alternative' body to 'required'. Otherwise, the UA MUST set > the 'handling' parameter to 'optional'. The sending UA MUST set all the > top-level body parts within the 'multipart/alternative' to > 'handling=optional'. > the draft already said this. I have added the clarification about "top-level" body parts. > Section 8.2 > =========== > For multipart/related, I disagree that if any part is required, the > /related is required. the text talks about the "root body part", not about the multipart/related body. The text in the draft already says what you propose below. > The last sentence is a non-sequitur. Either I > mandate doing something with the 'multipart/related' body or I do not. > I could see, for example, saying that processing the multipart/related > is optional, but if you do process it, one or more of the sub-parts is > required. In this case, the multipart/related is optional, yet one of > the sub-parts is required. > > How about: > > If the sending UA requires the handling of a 'multipart/related' body > as a whole, the UA MUST set the 'handling' parameter of the > 'multipart/related' body to 'required'. Otherwise, the UA MUST set the > handling to 'optional'. The UA sets the 'handling' parameters of the > body parts within the 'multipart/related' body independently from the > 'handling' parameter o the 'multipart/related' body. If the sending UA > requires the handling of a particular body, the UA MUST set the > 'handling' parameter of that body part 'required'. Otherwise, the UA > MUST set the parameter to 'optional'. > > > > Section 8.2 > =========== > General: I really do not like the construction "If the UA requires the > handling of foo the UA MUST mark it with 'handling=required'." The > reason I do not like this is this is precisely what RFC 3459 says to > do. All this draft does is repeat what is in that draft. Saying "You > MUST do what you MUST do" seems redundant and error prone. the feedback we got is that people found this section useful to clarify what to do in each case. > > Section 8.3 > =========== > This section is redundant with section 6.3. Remove section 8.3, as > section 6.3 talks about processing. See my comments above about this issue. > Section 8.4 > =========== > OK, I'll bite: what if I do not feel like returning a 415? Either > enumerate the situation where I MUST return a 415 or enumerate the > situations where I would return something other than 415. When specifying response codes, we typically use SHOULD because the request may have some other problem the UAS needs to report using a different error response. Specifying all those cases would be something like "go and read RFC 3261" :o)... I think using SHOULD in this context is clear enough. > Section 9.2 > =========== > Nit in last line of Note: s/constrain/constraint/ > Fixed. > > Section 9.4 > =========== > Since RFC 3459 updated 3204, would not the normative current reference > be to 3459? both references are listed as normative because the draft also references the parts of RFC 3204 that deal with signalling transport. > Section 11 > ========== > I would offer we point out the potential for DoS attacks from complex > MIME bodies. UA's need to be aware of potential stack depth overflow, > line length overflow, pointers to missing content, incorrect > content-lengths, correct content-lengths that span what a parser that > does not look at content-lengths might consider to be content boundaries > with other body parts snuck in. If you provide me with a reference to a discussion of this attack, I will be glad to add it to this section. In any case, I will add it to the next revision of the draft, because I intend to submit 06 in a while. Thanks for your comments, Gonzalo From root@core3.amsl.com Mon Mar 9 14:45:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E045B3A6CB7; Mon, 9 Mar 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309214501.E045B3A6CB7@core3.amsl.com> Date: Mon, 9 Mar 2009 14:45:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-body-handling-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Message Body Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-sip-body-handling-06.txt Pages : 19 Date : 2009-03-09 This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-body-handling-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09143745.I-D@ietf.org> --NextPart-- From gao.yang2@zte.com.cn Tue Mar 10 00:16:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8AA23A67B4; Tue, 10 Mar 2009 00:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.015 X-Spam-Level: X-Spam-Status: No, score=-90.015 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUhh-+JPmeWA; Tue, 10 Mar 2009 00:16:46 -0700 (PDT) Received: from mail.zte.com.cn (mail.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 777513A6C9D; Tue, 10 Mar 2009 00:16:44 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.3578538329; Tue, 10 Mar 2009 15:39:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2A6rxCO026560; Tue, 10 Mar 2009 14:54:00 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <49b50622.054c6e0a.4998.ffffa440@mx.google.com> From: gao.yang2@zte.com.cn To: "Eric.wang" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Tue, 10 Mar 2009 14:53:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-10 14:53:52, Serialize complete at 2009-03-10 14:53:52 Content-Type: multipart/alternative; boundary="=_alternative 0025E1C248257575_=" X-MAIL: mse1.zte.com.cn n2A6rxCO026560 Cc: 'SIP' , 'SIPPING' Subject: [Sip] =?gb2312?b?tPC4tDogICJVUERBVEUgZHVyaW5nIFJlLUlOVklURSIgZGlz?= =?gb2312?b?Y3Vzc2lvbg==?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 07:16:47 -0000 This is a multipart message in MIME format. --=_alternative 0025E1C248257575_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzLiBJZiB3ZSBhY2NlcHQgdmlldyAxLCB0aGVyZSB3b3VsZCBiZSBzb21lIGJhY2t3YXJkIGNv bXBhdGlibGUgcHJvYmxlbS4gDQpBbmQgdGhpcyBpcyBhIGNoYW5nZSB0byBSRkMzMzExLg0KDQpJ IGFtIHdhaXRpbmcgZm9yIG1vcmUgY29tbWVudHMgZnJvbSBwZW9wbGUgd2FudCB0byBrZWVwIFJG QzMzMTEgZnJvbSANCnJlLXdyaXRlLg0KDQpHYW8NCg0KDQoiRXJpYy53YW5nIiA8ZXJpYy53YW5n eHJAZ21haWwuY29tPiDQtNPaIDIwMDktMDMtMDkgMjA6MDU6NTE6DQoNCj4gSGksDQo+IA0KPiBJ IHN1cHBvcnQgdmlldyAyLG5vdCBhbGwgdXBkYXRlIGNhbiBiZSBjb25zaWRlcmVkIGFzIHN1Yi10 cmFuc2FjdGlvbg0KPiBvZiByZS1JTlZJVEUuDQo+IEFjY29yZGluZyB0byBjdXJyZW50IFJGQ3Ms IGl0oa9zIE5PVCBwcm9wZXIgdG8gY29uc2lkZXIgYWxsIFVQREFURXMgDQo+IGFzIHJlLUlOVklU RaGvcyBzdWItdHJhbnNhY3Rpb24gDQo+IEVnOg0KPiBVUERBVEUgbmVzdGVkIGluIHJlLUlOVklU RSAgZm9yIHRhcmdldCByZWZyZXNoIGNhbqGvdCBiZSBjb25zaWRlcmVkIA0KPiBhcyBzdWItdHJh bnNhY3Rpb24uDQoNCg0KIA0KPiBUaGVyZSBhcmUgdHdvIHRob3VnaHQgYWJvdXQgIlVQREFURSBk dXJpbmcgUmUtSU5WSVRFIi4gV2hpY2ggb25lIGlzIA0KPiBiZXR0ZXIgb3Igc3VpdHMgZm9yIGN1 cnJlbnQgUkZDcyANCj4gDQo+IFRoZXJlIGFyZSB0d28gdGhvdWdodCBhYm91dCAiVVBEQVRFIGR1 cmluZyBSZS1JTlZJVEUiLiANCj4gDQo+IDEuIEFsbCBVUERBVEVzIGR1cmluZyBSZS1JTlZJVEUg YXJlIFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbiANCj4gUkZDMzMxMihQcmVjb25kaXRpb24p IGlzIGEgY2FzZS4gQXMgdGhlcmUgaXMgc3VjaCBjYXNlLCB3ZSBjYW4gDQo+IG1ha2luZyBhbGwg VVBEQVRFcyBkdXJpbmcgUmUtSU5WSVRFIGFzIFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbi4g DQo+IA0KPiAyLiBOb3QgYWxsIFVQREFURShkdXJpbmcgUmUtSU5WSVRFKSBjYW4gYmUgY29uc2lk ZXJlZCBhcyBzdWItDQo+IHRyYW5zYWN0aW9uIG9mIFJlLUlOVklURSANCj4gVGhlcmUgaXMgcmVh bGx5IG5lZWQgbmVzdGVkLW1vZGlmaWNhdGlvbiwgc3VjaCBhcyBwcmVjb25kaXRpb24gYW5kIA0K PiBtb3JlIGluIHRoZSBmdXR1cmUuICBCdXQgdGhlIGNhc2NhZGUgb2YgbmVzdGVkIHRyYW5zYWN0 aW9uIHNob3VsZCBiZQ0KPiBkZWZpbmVkIGluIGFwcGxpY2F0aW9uLWxldmVsLCBub3Qgc2lnbmFs LWxldmVsLiBTbywgaXQgaXMgYmV0dGVyIHRvIA0KPiBtYWtlIFJlLUlOVklURSBhbmQgVVBEQVRF IHNlcGFyYXRseSBleHBlY3QgZm9yIGRlZmluaXRpb24gc3VjaCBhcyANCj4gcHJlY29uZGl0aW9u LiAgQW5kIHRoaXMgb2JleXMgY3VycmVudCBkZWZpbml0aW9uIG9mIFJGQzMzMTEuIA0KPiANCj4g SW4gUkZDMzMxMSwgd2hlbiB0aGUgVVBEQVRFIGlzIGFjY2VwdGVkIGJ5IHRoZSBvdGhlciANCj4g c2lkZShVUERBVEUvMjAwT0spLCB0aGUgY2hhbmdlIG9mIHN0YXRlcyBpcyBjb21taXR0ZWQgYW5k IGVmZm9ydCBhdCANCj4gb25jZS4gQW5kIG1ha2luZyBhbGwgVVBEQVRFcyBkdXJpbmcgUmUtSU5W SVRFIGFzIFJlLUlOVklURSdzIHN1Yi0NCj4gdHJhbnNhY3Rpb24gY2FuIGJlIHZpb2xhdGlvbiBv ZiBSRkMzMzExLiBTbywgd2Ugc2hvbGQgbm90IHRyZWF0IGFsbCANCj4gVVBEQVRFcyBkdXJpbmcg UmUtSU5WSVRFIGFzIFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbi4gDQo+IA0KPiBXaGlsZSBV UERBVEUvMjAwT0sganVzdCByZWZyZXNoICJwcmVjb25kaXRpb24gc3RhdGUgdGFibGUiIGluIA0K PiBSRkMzMzEyKCJwcmVjb25kaXRpb24gc3RhdGUgdGFibGUiIGlzIG1vZGlmaWVkIGF0IG9uY2Us IHNvIHRoaXMgDQo+IG9iZXlzIFJGQzMzMTIpLCBoYXZpbmcgbm8gaW1wYXQgb24gdGhlIGNvbW1p dG1lbnQgb2YgbW9kaWZpY2F0aW9uIA0KPiB0cmlnZ2VyZWQgYnkgUmUtSU5WSVRFLCB0aGVzZSBV UERBVEUvMjAwT0sgY2FuIGJlIHRyZWF0ZWQgYXMgc3ViLQ0KPiB0cmFuc2FjdGlvbiBvZiBSZS1J TlZJVEUuIA0KPiBPdGhlciBVUERBVEUvMjAwT0sgY2FuIG5vdCBiZSB0cmVhdGVkIGFzIHN1Yi10 cmFuc2FjdGlvbiBvZiBSZS1JTlZJVEUuIA0KPiANCj4gQ29tbWVudHMvZmVlbGluZyBhcmUgd2Vs Y29tZSEgDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVu dGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNl Y3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0 aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRy YW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFk ZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ug bm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhp cyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFu dGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0025E1C248257575_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy4gSWYgd2UgYWNj ZXB0IHZpZXcgMSwgdGhlcmUgd291bGQNCmJlIHNvbWUgYmFja3dhcmQgY29tcGF0aWJsZSBwcm9i bGVtLiBBbmQgdGhpcyBpcyBhIGNoYW5nZSB0byBSRkMzMzExLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhbSB3YWl0aW5nIGZvciBtb3JlIGNvbW1l bnRzIGZyb20NCnBlb3BsZSB3YW50IHRvIGtlZXAgUkZDMzMxMSBmcm9tIHJlLXdyaXRlLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+JnF1b3Q7RXJpYy53YW5nJnF1b3Q7ICZs dDtlcmljLndhbmd4ckBnbWFpbC5jb20mZ3Q7DQrQtNPaIDIwMDktMDMtMDkgMjA6MDU6NTE6PGJy Pg0KPGJyPg0KJmd0OyBIaSw8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsg Jm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IEkgc3VwcG9ydCB2 aWV3IDIsbm90IGFsbCB1cGRhdGUgY2FuIGJlIGNvbnNpZGVyZWQNCmFzIHN1Yi10cmFuc2FjdGlv bjxicj4NCiZndDsgb2YgcmUtSU5WSVRFLjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+Jmd0OyBBY2NvcmRpbmcgdG8gY3VycmVudCBSRkNzLCBpdKGvcyBOT1QgcHJvcGVyDQp0byBj b25zaWRlciBhbGwgVVBEQVRFcyA8YnI+DQomZ3Q7IGFzIHJlLUlOVklURaGvcyBzdWItdHJhbnNh Y3Rpb24gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IEVnOjwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBVUERBVEUgbmVzdGVkIGluIHJlLUlOVklU RSAmbmJzcDtmb3IgdGFyZ2V0IHJlZnJlc2gNCmNhbqGvdCBiZSBjb25zaWRlcmVkIDxicj4NCiZn dDsgYXMgc3ViLXRyYW5zYWN0aW9uLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+Jm5ic3A7PGJyPg0KJmd0OyBUaGVyZSBhcmUgdHdvIHRob3VnaHQgYWJvdXQg JnF1b3Q7VVBEQVRFIGR1cmluZyBSZS1JTlZJVEUmcXVvdDsuIFdoaWNoDQpvbmUgaXMgPGJyPg0K Jmd0OyBiZXR0ZXIgb3Igc3VpdHMgZm9yIGN1cnJlbnQgUkZDcyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgVGhlcmUgYXJlIHR3byB0aG91Z2h0IGFib3V0ICZxdW90O1VQREFURSBkdXJpbmcgUmUtSU5W SVRFJnF1b3Q7LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgMS4gQWxsIFVQREFURXMgZHVyaW5nIFJl LUlOVklURSBhcmUgUmUtSU5WSVRFJ3Mgc3ViLXRyYW5zYWN0aW9uIDxicj4NCiZndDsgUkZDMzMx MihQcmVjb25kaXRpb24pIGlzIGEgY2FzZS4gQXMgdGhlcmUgaXMgc3VjaCBjYXNlLCB3ZSBjYW4g PGJyPg0KJmd0OyBtYWtpbmcgYWxsIFVQREFURXMgZHVyaW5nIFJlLUlOVklURSBhcyBSZS1JTlZJ VEUncyBzdWItdHJhbnNhY3Rpb24uDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgMi4gTm90IGFsbCBV UERBVEUoZHVyaW5nIFJlLUlOVklURSkgY2FuIGJlIGNvbnNpZGVyZWQgYXMgc3ViLTxicj4NCiZn dDsgdHJhbnNhY3Rpb24gb2YgUmUtSU5WSVRFIDxicj4NCiZndDsgVGhlcmUgaXMgcmVhbGx5IG5l ZWQgbmVzdGVkLW1vZGlmaWNhdGlvbiwgc3VjaCBhcyBwcmVjb25kaXRpb24gYW5kDQo8YnI+DQom Z3Q7IG1vcmUgaW4gdGhlIGZ1dHVyZS4gJm5ic3A7QnV0IHRoZSBjYXNjYWRlIG9mIG5lc3RlZCB0 cmFuc2FjdGlvbiBzaG91bGQNCmJlPGJyPg0KJmd0OyBkZWZpbmVkIGluIGFwcGxpY2F0aW9uLWxl dmVsLCBub3Qgc2lnbmFsLWxldmVsLiBTbywgaXQgaXMgYmV0dGVyIHRvDQo8YnI+DQomZ3Q7IG1h a2UgUmUtSU5WSVRFIGFuZCBVUERBVEUgc2VwYXJhdGx5IGV4cGVjdCBmb3IgZGVmaW5pdGlvbiBz dWNoIGFzDQo8YnI+DQomZ3Q7IHByZWNvbmRpdGlvbi4gJm5ic3A7QW5kIHRoaXMgb2JleXMgY3Vy cmVudCBkZWZpbml0aW9uIG9mIFJGQzMzMTEuDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSW4gUkZD MzMxMSwgd2hlbiB0aGUgVVBEQVRFIGlzIGFjY2VwdGVkIGJ5IHRoZSBvdGhlciA8YnI+DQomZ3Q7 IHNpZGUoVVBEQVRFLzIwME9LKSwgdGhlIGNoYW5nZSBvZiBzdGF0ZXMgaXMgY29tbWl0dGVkIGFu ZCBlZmZvcnQgYXQNCjxicj4NCiZndDsgb25jZS4gQW5kIG1ha2luZyBhbGwgVVBEQVRFcyBkdXJp bmcgUmUtSU5WSVRFIGFzIFJlLUlOVklURSdzIHN1Yi08YnI+DQomZ3Q7IHRyYW5zYWN0aW9uIGNh biBiZSB2aW9sYXRpb24gb2YgUkZDMzMxMS4gU28sIHdlIHNob2xkIG5vdCB0cmVhdCBhbGwNCjxi cj4NCiZndDsgVVBEQVRFcyBkdXJpbmcgUmUtSU5WSVRFIGFzIFJlLUlOVklURSdzIHN1Yi10cmFu c2FjdGlvbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoaWxlIFVQREFURS8yMDBPSyBqdXN0IHJl ZnJlc2ggJnF1b3Q7cHJlY29uZGl0aW9uIHN0YXRlIHRhYmxlJnF1b3Q7DQppbiA8YnI+DQomZ3Q7 IFJGQzMzMTIoJnF1b3Q7cHJlY29uZGl0aW9uIHN0YXRlIHRhYmxlJnF1b3Q7IGlzIG1vZGlmaWVk IGF0IG9uY2UsDQpzbyB0aGlzIDxicj4NCiZndDsgb2JleXMgUkZDMzMxMiksIGhhdmluZyBubyBp bXBhdCBvbiB0aGUgY29tbWl0bWVudCBvZiBtb2RpZmljYXRpb24NCjxicj4NCiZndDsgdHJpZ2dl cmVkIGJ5IFJlLUlOVklURSwgdGhlc2UgVVBEQVRFLzIwME9LIGNhbiBiZSB0cmVhdGVkIGFzIHN1 Yi08YnI+DQomZ3Q7IHRyYW5zYWN0aW9uIG9mIFJlLUlOVklURS4gPGJyPg0KJmd0OyBPdGhlciBV UERBVEUvMjAwT0sgY2FuIG5vdCBiZSB0cmVhdGVkIGFzIHN1Yi10cmFuc2FjdGlvbiBvZiBSZS1J TlZJVEUuDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ29tbWVudHMvZmVlbGluZyBhcmUgd2VsY29t ZSEgPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZu YnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7 Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5 Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5p emF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5i c3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5i c3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3km bmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rp c2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQm bmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5i c3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xl bHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJz cDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVj ZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNl Jm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5i c3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5i c3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFz Jm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5i c3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9w cmU+ --=_alternative 0025E1C248257575_=-- From christer.holmberg@ericsson.com Tue Mar 10 00:21:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E733A6A60; Tue, 10 Mar 2009 00:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=-3.774, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrmu0QBw7mXc; Tue, 10 Mar 2009 00:21:41 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AA0E53A6CBF; Tue, 10 Mar 2009 00:21:40 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DA54E21483; Tue, 10 Mar 2009 08:22:13 +0100 (CET) X-AuditID: c1b4fb3e-ab899bb0000023da-df-49b615259007 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A8EF420402; Tue, 10 Mar 2009 08:22:13 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 08:22:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A150.EE5CD0F8" Date: Tue, 10 Mar 2009 08:22:12 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?GB2312?B?W1NpcHBpbmddILTwuLQ6IFtTaXBdICJVUERBVEUgZHVyaW5nIFJlLUlOVkk=?= =?GB2312?B?VEUiIGRpc2N1c3Npb24=?= Thread-Index: AcmhUElTGpNvbzK4R/Wrmsjv5fPrxQAAGLaQ References: <49b50622.054c6e0a.4998.ffffa440@mx.google.com> From: "Christer Holmberg" To: , "Eric.wang" X-OriginalArrivalTime: 10 Mar 2009 07:22:13.0040 (UTC) FILETIME=[EEAADB00:01C9A150] X-Brightmail-Tracker: AAAAAA== Cc: SIP , SIPPING Subject: Re: [Sip] =?gb2312?b?W1NpcHBpbmddILTwuLQ6ICAiVVBEQVRFIGR1cmluZyBSZS1J?= =?gb2312?b?TlZJVEUiIGRpc2N1c3Npb24=?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 07:21:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A150.EE5CD0F8 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable I support view 1. =20 Regards, =20 Christer ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On = Behalf Of gao.yang2@zte.com.cn Sent: 10. maaliskuuta 2009 8:54 To: Eric.wang Cc: 'SIP'; 'SIPPING' Subject: [Sipping] =B4=F0=B8=B4: [Sip] "UPDATE during Re-INVITE" = discussion =09 =09 Yes. If we accept view 1, there would be some backward compatible = problem. And this is a change to RFC3311.=20 =09 I am waiting for more comments from people want to keep RFC3311 from = re-write.=20 =09 Gao=20 =09 =09 "Eric.wang" =D0=B4=D3=DA 2009-03-09 20:05:51: =09 > Hi,=20 > =20 > I support view 2,not all update can be considered as sub-transaction > of re-INVITE.=20 > According to current RFCs, it=A1=AFs NOT proper to consider all = UPDATEs=20 > as re-INVITE=A1=AFs sub-transaction=20 > Eg:=20 > UPDATE nested in re-INVITE for target refresh can=A1=AFt be = considered=20 > as sub-transaction.=20 =09 =09 =20 > There are two thought about "UPDATE during Re-INVITE". Which one is=20 > better or suits for current RFCs=20 >=20 > There are two thought about "UPDATE during Re-INVITE".=20 >=20 > 1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction=20 > RFC3312(Precondition) is a case. As there is such case, we can=20 > making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.=20 >=20 > 2. Not all UPDATE(during Re-INVITE) can be considered as sub- > transaction of Re-INVITE=20 > There is really need nested-modification, such as precondition and=20 > more in the future. But the cascade of nested transaction should be > defined in application-level, not signal-level. So, it is better to=20 > make Re-INVITE and UPDATE separatly expect for definition such as=20 > precondition. And this obeys current definition of RFC3311.=20 >=20 > In RFC3311, when the UPDATE is accepted by the other=20 > side(UPDATE/200OK), the change of states is committed and effort at=20 > once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub- > transaction can be violation of RFC3311. So, we shold not treat all=20 > UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.=20 >=20 > While UPDATE/200OK just refresh "precondition state table" in=20 > RFC3312("precondition state table" is modified at once, so this=20 > obeys RFC3312), having no impat on the commitment of modification=20 > triggered by Re-INVITE, these UPDATE/200OK can be treated as sub- > transaction of Re-INVITE.=20 > Other UPDATE/200OK can not be treated as sub-transaction of = Re-INVITE.=20 >=20 > Comments/feeling are welcome!=20 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9A150.EE5CD0F8 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
I support view 1.
 
Regards,
 
Christer

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of=20 gao.yang2@zte.com.cn
Sent: 10. maaliskuuta 2009=20 8:54
To: Eric.wang
Cc: 'SIP'; = 'SIPPING'
Subject:=20 [Sipping] =B4=F0=B8=B4: [Sip] "UPDATE during Re-INVITE" = discussion



Yes. If we accept = view 1,=20 there would be some backward compatible problem. And this is a change = to=20 RFC3311.

I am waiting = for more=20 comments from people want to keep RFC3311 from re-write. =

Gao


"Eric.wang"=20 <eric.wangxr@gmail.com> =D0=B4=D3=DA 2009-03-09 = 20:05:51:

>=20 Hi,
>   =
> I support view 2,not all update can be considered as = sub-transaction
> of re-INVITE.
>=20 According to current RFCs, it=A1=AFs NOT proper to consider all = UPDATEs
> as=20 re-INVITE=A1=AFs sub-transaction
>=20 Eg:
> UPDATE nested in re-INVITE =  for=20 target refresh can=A1=AFt be considered
> as = sub-transaction.=20


 
> There are two thought = about=20 "UPDATE during Re-INVITE". Which one is
> better or suits for = current=20 RFCs
>
> There are two thought about "UPDATE during = Re-INVITE".=20
>
> 1. All UPDATEs during Re-INVITE are Re-INVITE's=20 sub-transaction
> RFC3312(Precondition) is a case. As there is = such=20 case, we can
> making all UPDATEs during Re-INVITE as = Re-INVITE's=20 sub-transaction.
>
> 2. Not all UPDATE(during Re-INVITE) = can be=20 considered as sub-
> transaction of Re-INVITE
> There is = really=20 need nested-modification, such as precondition and
> more in = the=20 future.  But the cascade of nested transaction should be
> = defined=20 in application-level, not signal-level. So, it is better to
> = make=20 Re-INVITE and UPDATE separatly expect for definition such as
>=20 precondition.  And this obeys current definition of RFC3311. =
>=20
> In RFC3311, when the UPDATE is accepted by the other
> = side(UPDATE/200OK), the change of states is committed and effort at =
>=20 once. And making all UPDATEs during Re-INVITE as Re-INVITE's = sub-
>=20 transaction can be violation of RFC3311. So, we shold not treat all =
>=20 UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.
> =
>=20 While UPDATE/200OK just refresh "precondition state table" in
> = RFC3312("precondition state table" is modified at once, so this =
> obeys=20 RFC3312), having no impat on the commitment of modification
> = triggered=20 by Re-INVITE, these UPDATE/200OK can be treated as sub-
> = transaction of=20 Re-INVITE.
> Other UPDATE/200OK can not be treated as = sub-transaction=20 of Re-INVITE.
>
> Comments/feeling are welcome!=20 = 

------------------------------------------------=
--------
ZTE Information Security Notice: The information=
 contained in this mail is solely prop=
erty of the sender's organization. This mai=
l communication is confidential. Recipients name=
d above are obligated to maintain secrecy&n=
bsp;and are not permitted to disclose the&n=
bsp;contents of this communication to others.
This email and any files transmitted with&n=
bsp;it are confidential and intended solely =
;for the use of the individual or enti=
ty to whom they are addressed. If you&=
nbsp;have received this email in error plea=
se notify the originator of the message.&nb=
sp;Any views expressed in this message are&=
nbsp;those of the individual sender.
This message has been scanned for viruses&n=
bsp;and Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01C9A150.EE5CD0F8-- From gao.yang2@zte.com.cn Tue Mar 10 00:52:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980033A698E; Tue, 10 Mar 2009 00:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.131 X-Spam-Level: X-Spam-Status: No, score=-92.131 tagged_above=-999 required=5 tests=[AWL=1.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_66=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEUP8bsJjiCq; Tue, 10 Mar 2009 00:52:29 -0700 (PDT) Received: from mail.zte.com.cn (mail2.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 89D053A6946; Tue, 10 Mar 2009 00:52:25 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.5188501892; Tue, 10 Mar 2009 16:15:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2A7aFjX063633; Tue, 10 Mar 2009 15:36:15 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: From: gao.yang2@zte.com.cn To: "Christer Holmberg" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Tue, 10 Mar 2009 15:35:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-10 15:36:07, Serialize complete at 2009-03-10 15:36:07 Content-Type: multipart/alternative; boundary="=_alternative 0029BF1348257575_=" X-MAIL: mse1.zte.com.cn n2A7aFjX063633 Cc: SIP , SIPPING Subject: [Sip] "UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 07:52:30 -0000 This is a multipart message in MIME format. --=_alternative 0029BF1348257575_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 T0suIFRoYW5rcyBmb3IgeW91ciBzdGFuZHBvaW50Lg0KDQpCdXQgYWNjZXB0aW5nIHRoaXMgbWVh bnM6DQoxLiBSZXdyaXRlIG9mIGN1cnJlbnQgc29mdHdhcmUgdG8gYmUgYXMgdGhlIGJlaGF2aW9y IGRlZmluZWQgYnkgDQoiZHJhZnQtY2FtYXJpbGxvLXNpcHBpbmctcmVpbnZpdGUtMDAiLg0KMi4g TWFraW5nIGFsbCBVUERBVEUvMjAwT0sgImR1cmluZyIgUmUtSU5WSVRFIGFzIFJlLUlOVklURSdz IHBhcnQuDQoNCkdhbw0KDQoNCg0KDQoiQ2hyaXN0ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+IA0KMjAwOS0wMy0xMCAxNToyMg0KDQrK1bz+yMsNCjxnYW8ueWFu ZzJAenRlLmNvbS5jbj4sICJFcmljLndhbmciIDxlcmljLndhbmd4ckBnbWFpbC5jb20+DQqzrcvN DQoiU0lQIiA8c2lwQGlldGYub3JnPiwgIlNJUFBJTkciIDxzaXBwaW5nQGlldGYub3JnPg0K1vfM 4g0KUkU6IFtTaXBwaW5nXSC08Li0OiBbU2lwXSAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUiIGRp c2N1c3Npb24NCg0KDQoNCg0KDQoNCkkgc3VwcG9ydCB2aWV3IDEuDQogDQpSZWdhcmRzLA0KIA0K Q2hyaXN0ZXINCg0KRnJvbTogc2lwcGluZy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwcGlu Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQpPZiBnYW8ueWFuZzJAenRlLmNvbS5jbg0K U2VudDogMTAuIG1hYWxpc2t1dXRhIDIwMDkgODo1NA0KVG86IEVyaWMud2FuZw0KQ2M6ICdTSVAn OyAnU0lQUElORycNClN1YmplY3Q6IFtTaXBwaW5nXSC08Li0OiBbU2lwXSAiVVBEQVRFIGR1cmlu ZyBSZS1JTlZJVEUiIGRpc2N1c3Npb24NCg0KDQoNClllcy4gSWYgd2UgYWNjZXB0IHZpZXcgMSwg dGhlcmUgd291bGQgYmUgc29tZSBiYWNrd2FyZCBjb21wYXRpYmxlIHByb2JsZW0uIA0KQW5kIHRo aXMgaXMgYSBjaGFuZ2UgdG8gUkZDMzMxMS4gDQoNCkkgYW0gd2FpdGluZyBmb3IgbW9yZSBjb21t ZW50cyBmcm9tIHBlb3BsZSB3YW50IHRvIGtlZXAgUkZDMzMxMSBmcm9tIA0KcmUtd3JpdGUuIA0K DQpHYW8gDQoNCg0KIkVyaWMud2FuZyIgPGVyaWMud2FuZ3hyQGdtYWlsLmNvbT4g0LTT2iAyMDA5 LTAzLTA5IDIwOjA1OjUxOg0KDQo+IEhpLCANCj4gICANCj4gSSBzdXBwb3J0IHZpZXcgMixub3Qg YWxsIHVwZGF0ZSBjYW4gYmUgY29uc2lkZXJlZCBhcyBzdWItdHJhbnNhY3Rpb24NCj4gb2YgcmUt SU5WSVRFLiANCj4gQWNjb3JkaW5nIHRvIGN1cnJlbnQgUkZDcywgaXShr3MgTk9UIHByb3BlciB0 byBjb25zaWRlciBhbGwgVVBEQVRFcyANCj4gYXMgcmUtSU5WSVRFoa9zIHN1Yi10cmFuc2FjdGlv biANCj4gRWc6IA0KPiBVUERBVEUgbmVzdGVkIGluIHJlLUlOVklURSAgZm9yIHRhcmdldCByZWZy ZXNoIGNhbqGvdCBiZSBjb25zaWRlcmVkIA0KPiBhcyBzdWItdHJhbnNhY3Rpb24uIA0KDQoNCiAN Cj4gVGhlcmUgYXJlIHR3byB0aG91Z2h0IGFib3V0ICJVUERBVEUgZHVyaW5nIFJlLUlOVklURSIu IFdoaWNoIG9uZSBpcyANCj4gYmV0dGVyIG9yIHN1aXRzIGZvciBjdXJyZW50IFJGQ3MgDQo+IA0K PiBUaGVyZSBhcmUgdHdvIHRob3VnaHQgYWJvdXQgIlVQREFURSBkdXJpbmcgUmUtSU5WSVRFIi4g DQo+IA0KPiAxLiBBbGwgVVBEQVRFcyBkdXJpbmcgUmUtSU5WSVRFIGFyZSBSZS1JTlZJVEUncyBz dWItdHJhbnNhY3Rpb24gDQo+IFJGQzMzMTIoUHJlY29uZGl0aW9uKSBpcyBhIGNhc2UuIEFzIHRo ZXJlIGlzIHN1Y2ggY2FzZSwgd2UgY2FuIA0KPiBtYWtpbmcgYWxsIFVQREFURXMgZHVyaW5nIFJl LUlOVklURSBhcyBSZS1JTlZJVEUncyBzdWItdHJhbnNhY3Rpb24uIA0KPiANCj4gMi4gTm90IGFs bCBVUERBVEUoZHVyaW5nIFJlLUlOVklURSkgY2FuIGJlIGNvbnNpZGVyZWQgYXMgc3ViLQ0KPiB0 cmFuc2FjdGlvbiBvZiBSZS1JTlZJVEUgDQo+IFRoZXJlIGlzIHJlYWxseSBuZWVkIG5lc3RlZC1t b2RpZmljYXRpb24sIHN1Y2ggYXMgcHJlY29uZGl0aW9uIGFuZCANCj4gbW9yZSBpbiB0aGUgZnV0 dXJlLiAgQnV0IHRoZSBjYXNjYWRlIG9mIG5lc3RlZCB0cmFuc2FjdGlvbiBzaG91bGQgYmUNCj4g ZGVmaW5lZCBpbiBhcHBsaWNhdGlvbi1sZXZlbCwgbm90IHNpZ25hbC1sZXZlbC4gU28sIGl0IGlz IGJldHRlciB0byANCj4gbWFrZSBSZS1JTlZJVEUgYW5kIFVQREFURSBzZXBhcmF0bHkgZXhwZWN0 IGZvciBkZWZpbml0aW9uIHN1Y2ggYXMgDQo+IHByZWNvbmRpdGlvbi4gIEFuZCB0aGlzIG9iZXlz IGN1cnJlbnQgZGVmaW5pdGlvbiBvZiBSRkMzMzExLiANCj4gDQo+IEluIFJGQzMzMTEsIHdoZW4g dGhlIFVQREFURSBpcyBhY2NlcHRlZCBieSB0aGUgb3RoZXIgDQo+IHNpZGUoVVBEQVRFLzIwME9L KSwgdGhlIGNoYW5nZSBvZiBzdGF0ZXMgaXMgY29tbWl0dGVkIGFuZCBlZmZvcnQgYXQgDQo+IG9u Y2UuIEFuZCBtYWtpbmcgYWxsIFVQREFURXMgZHVyaW5nIFJlLUlOVklURSBhcyBSZS1JTlZJVEUn cyBzdWItDQo+IHRyYW5zYWN0aW9uIGNhbiBiZSB2aW9sYXRpb24gb2YgUkZDMzMxMS4gU28sIHdl IHNob2xkIG5vdCB0cmVhdCBhbGwgDQo+IFVQREFURXMgZHVyaW5nIFJlLUlOVklURSBhcyBSZS1J TlZJVEUncyBzdWItdHJhbnNhY3Rpb24uIA0KPiANCj4gV2hpbGUgVVBEQVRFLzIwME9LIGp1c3Qg cmVmcmVzaCAicHJlY29uZGl0aW9uIHN0YXRlIHRhYmxlIiBpbiANCj4gUkZDMzMxMigicHJlY29u ZGl0aW9uIHN0YXRlIHRhYmxlIiBpcyBtb2RpZmllZCBhdCBvbmNlLCBzbyB0aGlzIA0KPiBvYmV5 cyBSRkMzMzEyKSwgaGF2aW5nIG5vIGltcGF0IG9uIHRoZSBjb21taXRtZW50IG9mIG1vZGlmaWNh dGlvbiANCj4gdHJpZ2dlcmVkIGJ5IFJlLUlOVklURSwgdGhlc2UgVVBEQVRFLzIwME9LIGNhbiBi ZSB0cmVhdGVkIGFzIHN1Yi0NCj4gdHJhbnNhY3Rpb24gb2YgUmUtSU5WSVRFLiANCj4gT3RoZXIg VVBEQVRFLzIwME9LIGNhbiBub3QgYmUgdHJlYXRlZCBhcyBzdWItdHJhbnNhY3Rpb24gb2YgUmUt SU5WSVRFLiANCj4gDQo+IENvbW1lbnRzL2ZlZWxpbmcgYXJlIHdlbGNvbWUhIA0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gDQpvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gDQpzeXN0ZW0uDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkg b2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMg Y29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFp bnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkg ZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhl eSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBl eHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5k ZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBi eSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0029BF1348257575_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9LLiBUaGFua3MgZm9yIHlvdXIg c3RhbmRwb2ludC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkJ1dCBhY2NlcHRpbmcgdGhpcyBtZWFuczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjEuIFJld3JpdGUgb2YgY3VycmVudCBzb2Z0d2FyZSB0byBiZQ0KYXMg dGhlIGJlaGF2aW9yIGRlZmluZWQgYnkgJnF1b3Q7ZHJhZnQtY2FtYXJpbGxvLXNpcHBpbmctcmVp bnZpdGUtMDAmcXVvdDsuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4yLiBNYWtpbmcgYWxsIFVQREFURS8yMDBPSyAmcXVvdDtkdXJpbmcmcXVvdDsNClJlLUlOVklU RSBhcyBSZS1JTlZJVEUncyBwYXJ0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0NocmlzdGVyIEhvbG1iZXJnJnF1b3Q7DQombHQ7 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDMtMTAgMTU6MjI8L2ZvbnQ+DQo8dGQgd2lk dGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2dhby55YW5nMkB6 dGUuY29tLmNuJmd0OywgJnF1b3Q7RXJpYy53YW5nJnF1b3Q7DQombHQ7ZXJpYy53YW5neHJAZ21h aWwuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7U0lQJnF1b3Q7ICZsdDtzaXBAaWV0 Zi5vcmcmZ3Q7LA0KJnF1b3Q7U0lQUElORyZxdW90OyAmbHQ7c2lwcGluZ0BpZXRmLm9yZyZndDs8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbU2lwcGluZ10gtPC4tDogW1NpcF0gJnF1b3Q7VVBEQVRF DQpkdXJpbmcgUmUtSU5WSVRFJnF1b3Q7IGRpc2N1c3Npb248L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+ SSBzdXBwb3J0IHZpZXcgMS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlh bCI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+Q2hy aXN0ZXI8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8aHI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ PGI+RnJvbTo8L2I+IHNpcHBpbmctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcHBpbmctYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Z2FvLnlhbmcyQHp0ZS5jb20uY248 Yj48YnI+DQpTZW50OjwvYj4gMTAuIG1hYWxpc2t1dXRhIDIwMDkgODo1NDxiPjxicj4NClRvOjwv Yj4gRXJpYy53YW5nPGI+PGJyPg0KQ2M6PC9iPiAnU0lQJzsgJ1NJUFBJTkcnPGI+PGJyPg0KU3Vi amVjdDo8L2I+IFtTaXBwaW5nXSC08Li0OiBbU2lwXSAmcXVvdDtVUERBVEUgZHVyaW5nIFJlLUlO VklURSZxdW90Ow0KZGlzY3Vzc2lvbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClllcy4gSWYgd2Ug YWNjZXB0IHZpZXcgMSwgdGhlcmUgd291bGQgYmUgc29tZSBiYWNrd2FyZCBjb21wYXRpYmxlIHBy b2JsZW0uDQpBbmQgdGhpcyBpcyBhIGNoYW5nZSB0byBSRkMzMzExLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCkkgYW0gd2FpdGluZyBmb3IgbW9yZSBjb21tZW50cyBmcm9tIHBlb3Bs ZSB3YW50IHRvIGtlZXAgUkZDMzMxMSBmcm9tIHJlLXdyaXRlLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCkdhbzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxi cj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiZxdW90O0VyaWMud2FuZyZx dW90OyAmbHQ7ZXJpYy53YW5neHJAZ21haWwuY29tJmd0OyDQtNPaIDIwMDktMDMtMDkgMjA6MDU6 NTE6PGJyPg0KPGJyPg0KJmd0OyBIaSw8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiZndDsgJm5ic3A7PC90dD48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y Pjx0dD48YnI+DQomZ3Q7IEkgc3VwcG9ydCB2aWV3IDIsbm90IGFsbCB1cGRhdGUgY2FuIGJlIGNv bnNpZGVyZWQgYXMgc3ViLXRyYW5zYWN0aW9uPGJyPg0KJmd0OyBvZiByZS1JTlZJVEUuPC90dD48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y Pjx0dD48YnI+DQomZ3Q7IEFjY29yZGluZyB0byBjdXJyZW50IFJGQ3MsIGl0oa9zIE5PVCBwcm9w ZXIgdG8gY29uc2lkZXIgYWxsIFVQREFURXMNCjxicj4NCiZndDsgYXMgcmUtSU5WSVRFoa9zIHN1 Yi10cmFuc2FjdGlvbiA8YnI+DQomZ3Q7IEVnOjwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9Mj48dHQ+PGJyPg0KJmd0OyBVUERBVEUg bmVzdGVkIGluIHJlLUlOVklURSAmbmJzcDtmb3IgdGFyZ2V0IHJlZnJlc2ggY2Fuoa90IGJlIGNv bnNpZGVyZWQNCjxicj4NCiZndDsgYXMgc3ViLXRyYW5zYWN0aW9uLjwvdHQ+PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9 Mj48dHQ+PGJyPg0KIDxicj4NCiZndDsgVGhlcmUgYXJlIHR3byB0aG91Z2h0IGFib3V0ICZxdW90 O1VQREFURSBkdXJpbmcgUmUtSU5WSVRFJnF1b3Q7LiBXaGljaA0Kb25lIGlzIDxicj4NCiZndDsg YmV0dGVyIG9yIHN1aXRzIGZvciBjdXJyZW50IFJGQ3MgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRo ZXJlIGFyZSB0d28gdGhvdWdodCBhYm91dCAmcXVvdDtVUERBVEUgZHVyaW5nIFJlLUlOVklURSZx dW90Oy4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEuIEFsbCBVUERBVEVzIGR1cmluZyBSZS1JTlZJ VEUgYXJlIFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbiA8YnI+DQomZ3Q7IFJGQzMzMTIoUHJl Y29uZGl0aW9uKSBpcyBhIGNhc2UuIEFzIHRoZXJlIGlzIHN1Y2ggY2FzZSwgd2UgY2FuIDxicj4N CiZndDsgbWFraW5nIGFsbCBVUERBVEVzIGR1cmluZyBSZS1JTlZJVEUgYXMgUmUtSU5WSVRFJ3Mg c3ViLXRyYW5zYWN0aW9uLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIuIE5vdCBhbGwgVVBEQVRF KGR1cmluZyBSZS1JTlZJVEUpIGNhbiBiZSBjb25zaWRlcmVkIGFzIHN1Yi08YnI+DQomZ3Q7IHRy YW5zYWN0aW9uIG9mIFJlLUlOVklURSA8YnI+DQomZ3Q7IFRoZXJlIGlzIHJlYWxseSBuZWVkIG5l c3RlZC1tb2RpZmljYXRpb24sIHN1Y2ggYXMgcHJlY29uZGl0aW9uIGFuZA0KPGJyPg0KJmd0OyBt b3JlIGluIHRoZSBmdXR1cmUuICZuYnNwO0J1dCB0aGUgY2FzY2FkZSBvZiBuZXN0ZWQgdHJhbnNh Y3Rpb24gc2hvdWxkDQpiZTxicj4NCiZndDsgZGVmaW5lZCBpbiBhcHBsaWNhdGlvbi1sZXZlbCwg bm90IHNpZ25hbC1sZXZlbC4gU28sIGl0IGlzIGJldHRlciB0bw0KPGJyPg0KJmd0OyBtYWtlIFJl LUlOVklURSBhbmQgVVBEQVRFIHNlcGFyYXRseSBleHBlY3QgZm9yIGRlZmluaXRpb24gc3VjaCBh cw0KPGJyPg0KJmd0OyBwcmVjb25kaXRpb24uICZuYnNwO0FuZCB0aGlzIG9iZXlzIGN1cnJlbnQg ZGVmaW5pdGlvbiBvZiBSRkMzMzExLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIFJGQzMzMTEs IHdoZW4gdGhlIFVQREFURSBpcyBhY2NlcHRlZCBieSB0aGUgb3RoZXIgPGJyPg0KJmd0OyBzaWRl KFVQREFURS8yMDBPSyksIHRoZSBjaGFuZ2Ugb2Ygc3RhdGVzIGlzIGNvbW1pdHRlZCBhbmQgZWZm b3J0IGF0DQo8YnI+DQomZ3Q7IG9uY2UuIEFuZCBtYWtpbmcgYWxsIFVQREFURXMgZHVyaW5nIFJl LUlOVklURSBhcyBSZS1JTlZJVEUncyBzdWItPGJyPg0KJmd0OyB0cmFuc2FjdGlvbiBjYW4gYmUg dmlvbGF0aW9uIG9mIFJGQzMzMTEuIFNvLCB3ZSBzaG9sZCBub3QgdHJlYXQgYWxsDQo8YnI+DQom Z3Q7IFVQREFURXMgZHVyaW5nIFJlLUlOVklURSBhcyBSZS1JTlZJVEUncyBzdWItdHJhbnNhY3Rp b24uIDxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGlsZSBVUERBVEUvMjAwT0sganVzdCByZWZyZXNo ICZxdW90O3ByZWNvbmRpdGlvbiBzdGF0ZSB0YWJsZSZxdW90Ow0KaW4gPGJyPg0KJmd0OyBSRkMz MzEyKCZxdW90O3ByZWNvbmRpdGlvbiBzdGF0ZSB0YWJsZSZxdW90OyBpcyBtb2RpZmllZCBhdCBv bmNlLA0Kc28gdGhpcyA8YnI+DQomZ3Q7IG9iZXlzIFJGQzMzMTIpLCBoYXZpbmcgbm8gaW1wYXQg b24gdGhlIGNvbW1pdG1lbnQgb2YgbW9kaWZpY2F0aW9uDQo8YnI+DQomZ3Q7IHRyaWdnZXJlZCBi eSBSZS1JTlZJVEUsIHRoZXNlIFVQREFURS8yMDBPSyBjYW4gYmUgdHJlYXRlZCBhcyBzdWItPGJy Pg0KJmd0OyB0cmFuc2FjdGlvbiBvZiBSZS1JTlZJVEUuIDxicj4NCiZndDsgT3RoZXIgVVBEQVRF LzIwME9LIGNhbiBub3QgYmUgdHJlYXRlZCBhcyBzdWItdHJhbnNhY3Rpb24gb2YgUmUtSU5WSVRF Lg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENvbW1lbnRzL2ZlZWxpbmcgYXJlIHdlbGNvbWUhIDwv dHQ+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zPjx0dD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsDQppcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24N CmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUg Y29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQNCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YNCnRoZSBtZXNzYWdl LiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGlu ZGl2aWR1YWwNCnNlbmRlci48YnI+DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48YnI+DQo8L3R0PjwvZm9u dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkm bmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0 eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7 VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRp YWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtv YmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNw O2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0 aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJz cDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNw O2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtj b25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZu YnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29y Jm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2Fk ZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3Ro aXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkm bmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZu YnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5i c3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7 YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0029BF1348257575_=-- From christer.holmberg@ericsson.com Tue Mar 10 01:01:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A740E3A6991; Tue, 10 Mar 2009 01:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_66=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX3O9uD7y1yr; Tue, 10 Mar 2009 01:01:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A04793A69A8; Tue, 10 Mar 2009 01:01:10 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EC482203FD; Tue, 10 Mar 2009 09:01:43 +0100 (CET) X-AuditID: c1b4fb3e-aa897bb0000023da-6c-49b61e66a2e2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C572221699; Tue, 10 Mar 2009 09:01:42 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 09:01:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A156.72610B24" Date: Tue, 10 Mar 2009 09:01:41 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] "UPDATE during Re-INVITE" discussion Thread-Index: AcmhVTsxk5ZI+5dmRxO72HVA7jSHTwAAFXSw References: From: "Christer Holmberg" To: X-OriginalArrivalTime: 10 Mar 2009 08:01:42.0580 (UTC) FILETIME=[7305F740:01C9A156] X-Brightmail-Tracker: AAAAAA== Cc: SIP , SIPPING Subject: Re: [Sip] "UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 08:01:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A156.72610B24 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable The reason why we have this whole discussion is because the current = specifications are unclear. If everything was clear, and everybody had = the same understanding, we wouldn't need to clarify anything. =20 So, whatever solution we choose, I am sure that someone will have to = "rewrite their software". =20 ....IF that software exists in the first place, that is.=20 =20 I am not aware of any deployments which would support re-INVITEs with = nested UPDATEs/PRACKs. Maybe there are such deployments, but I doubt = they would all behave in the way as you describe. =20 Regarding your second bullet, I don't even think that one should send = "nested" UPDATEs, if they don't have anything to do with the re-INVITE. = I think that is bad application design. Non-related changes should be = done outside the re-INVITE transaction. =20 Regards, =20 Christer ________________________________ From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: 10. maaliskuuta 2009 9:36 To: Christer Holmberg Cc: Eric.wang; SIP; SIPPING Subject: [Sip] "UPDATE during Re-INVITE" discussion =09 =09 OK. Thanks for your standpoint.=20 =09 But accepting this means:=20 1. Rewrite of current software to be as the behavior defined by = "draft-camarillo-sipping-reinvite-00".=20 2. Making all UPDATE/200OK "during" Re-INVITE as Re-INVITE's part.=20 =09 Gao=20 =09 =09 =09 =09 "Christer Holmberg" =20 2009-03-10 15:22=20 =CA=D5=BC=FE=C8=CB , "Eric.wang" =20 =B3=AD=CB=CD "SIP" , "SIPPING" =20 =D6=F7=CC=E2 RE: [Sipping] =B4=F0=B8=B4: [Sip] "UPDATE during Re-INVITE" discussion =09 I support view 1.=20 =20 Regards,=20 =20 Christer=20 =09 =09 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On = Behalf Of gao.yang2@zte.com.cn Sent: 10. maaliskuuta 2009 8:54 To: Eric.wang Cc: 'SIP'; 'SIPPING' Subject: [Sipping] =B4=F0=B8=B4: [Sip] "UPDATE during Re-INVITE" = discussion =09 =09 =09 Yes. If we accept view 1, there would be some backward compatible = problem. And this is a change to RFC3311.=20 =09 I am waiting for more comments from people want to keep RFC3311 from = re-write.=20 =09 Gao=20 =09 =09 "Eric.wang" =D0=B4=D3=DA 2009-03-09 20:05:51: =09 > Hi,=20 > =20 > I support view 2,not all update can be considered as sub-transaction > of re-INVITE.=20 > According to current RFCs, it=A1=AFs NOT proper to consider all = UPDATEs=20 > as re-INVITE=A1=AFs sub-transaction=20 > Eg:=20 > UPDATE nested in re-INVITE for target refresh can=A1=AFt be = considered=20 > as sub-transaction.=20 =09 =09 =09 > There are two thought about "UPDATE during Re-INVITE". Which one is=20 > better or suits for current RFCs=20 >=20 > There are two thought about "UPDATE during Re-INVITE".=20 >=20 > 1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction=20 > RFC3312(Precondition) is a case. As there is such case, we can=20 > making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.=20 >=20 > 2. Not all UPDATE(during Re-INVITE) can be considered as sub- > transaction of Re-INVITE=20 > There is really need nested-modification, such as precondition and=20 > more in the future. But the cascade of nested transaction should be > defined in application-level, not signal-level. So, it is better to=20 > make Re-INVITE and UPDATE separatly expect for definition such as=20 > precondition. And this obeys current definition of RFC3311.=20 >=20 > In RFC3311, when the UPDATE is accepted by the other=20 > side(UPDATE/200OK), the change of states is committed and effort at=20 > once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub- > transaction can be violation of RFC3311. So, we shold not treat all=20 > UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.=20 >=20 > While UPDATE/200OK just refresh "precondition state table" in=20 > RFC3312("precondition state table" is modified at once, so this=20 > obeys RFC3312), having no impat on the commitment of modification=20 > triggered by Re-INVITE, these UPDATE/200OK can be treated as sub- > transaction of Re-INVITE.=20 > Other UPDATE/200OK can not be treated as sub-transaction of = Re-INVITE.=20 >=20 > Comments/feeling are welcome!=20 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9A156.72610B24 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
The reason why we have this = whole discussion is=20 because the current specifications are unclear. If everything was clear, = and=20 everybody had the same understanding, we wouldn't need to clarify=20 anything.
 
So, whatever solution we choose, I am sure that = someone=20 will have to "rewrite their software".
 
....IF that software exists in the first place, = that is.=20
 
I am not aware of any deployments which would = support=20 re-INVITEs with nested UPDATEs/PRACKs. Maybe there are such deployments, = but I=20 doubt they would all behave in the way as you = describe.
 
Regarding your second bullet, I don't even = think that one=20 should send "nested" UPDATEs, if they don't have anything to do = with the=20 re-INVITE. I think that is bad application design. Non-related changes = should be=20 done outside the re-INVITE transaction.
 
Regards,
 
Christer

From: gao.yang2@zte.com.cn=20 [mailto:gao.yang2@zte.com.cn]
Sent: 10. maaliskuuta 2009=20 9:36
To: Christer Holmberg
Cc: Eric.wang; SIP;=20 SIPPING
Subject: [Sip] "UPDATE during Re-INVITE"=20 discussion


OK. Thanks for your=20 standpoint.

But = accepting this=20 means:
1. Rewrite of = current software=20 to be as the behavior defined by = "draft-camarillo-sipping-reinvite-00".=20
2. Making all UPDATE/200OK = "during" Re-INVITE=20 as Re-INVITE's part.

Gao=20



"Christer = Holmberg"=20 <christer.holmberg@ericsson.com>

2009-03-10 15:22

=CA=D5=BC=FE=C8=CB
<gao.yang2@zte.com.cn>,=20 "Eric.wang" <eric.wangxr@gmail.com>=20
=B3=AD=CB=CD
"SIP" = <sip@ietf.org>,=20 "SIPPING" <sipping@ietf.org>=20
=D6=F7=CC=E2
RE: [Sipping] = =B4=F0=B8=B4: [Sip] "UPDATE=20 during Re-INVITE" = discussion

=




I support view 1.
 
Regards,=20
 
Christer

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of=20 gao.yang2@zte.com.cn
Sent: 10. maaliskuuta 2009=20 8:54
To: Eric.wang
Cc: 'SIP'; = 'SIPPING'
Subject:=20 [Sipping] =B4=F0=B8=B4: [Sip] "UPDATE during Re-INVITE" = discussion



Yes. If we = accept view 1,=20 there would be some backward compatible problem. And this is a change = to=20 RFC3311.

I am waiting for more comments from people want to keep = RFC3311=20 from re-write. =

Gao=20


"Eric.wang" = <eric.wangxr@gmail.com>=20 =D0=B4=D3=DA 2009-03-09 20:05:51:

> Hi,
>  
> I = support view 2,not=20 all update can be considered as sub-transaction
> of=20 re-INVITE.
> According to current RFCs, it=A1=AFs NOT proper = to consider all=20 UPDATEs
> as re-INVITE=A1=AFs sub-transaction
> = Eg:
> UPDATE = nested in=20 re-INVITE  for target refresh can=A1=AFt be considered
> = as=20 sub-transaction. =



> There are two thought about "UPDATE during = Re-INVITE".=20 Which one is
> better or suits for current RFCs
> =
> There=20 are two thought about "UPDATE during Re-INVITE".
>
> 1. = All=20 UPDATEs during Re-INVITE are Re-INVITE's sub-transaction
>=20 RFC3312(Precondition) is a case. As there is such case, we can =
> making=20 all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.
> =
>=20 2. Not all UPDATE(during Re-INVITE) can be considered as sub-
>=20 transaction of Re-INVITE
> There is really need = nested-modification,=20 such as precondition and
> more in the future.  But the = cascade of=20 nested transaction should be
> defined in application-level, not = signal-level. So, it is better to
> make Re-INVITE and UPDATE = separatly=20 expect for definition such as
> precondition.  And this = obeys=20 current definition of RFC3311.
>
> In RFC3311, when the = UPDATE=20 is accepted by the other
> side(UPDATE/200OK), the change of = states is=20 committed and effort at
> once. And making all UPDATEs during = Re-INVITE=20 as Re-INVITE's sub-
> transaction can be violation of RFC3311. = So, we=20 shold not treat all
> UPDATEs during Re-INVITE as Re-INVITE's=20 sub-transaction.
>
> While UPDATE/200OK just refresh=20 "precondition state table" in
> RFC3312("precondition state = table" is=20 modified at once, so this
> obeys RFC3312), having no impat on = the=20 commitment of modification
> triggered by Re-INVITE, these = UPDATE/200OK=20 can be treated as sub-
> transaction of Re-INVITE.
> = Other=20 UPDATE/200OK can not be treated as sub-transaction of Re-INVITE. =
>=20
> Comments/feeling are welcome!

--------------------------------------------------------
= ZTE=20 Information Security Notice: The information contained in this mail is = solely=20 property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy = and are=20 not permitted to disclose the contents of this communication to=20 others.
This email and any files transmitted with it are = confidential and=20 intended solely for the use of the individual or entity to whom they = are=20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are = those of=20 the individual sender.
This message has been scanned for viruses = and Spam=20 by ZTE Anti-Spam = system.


-------------------------------------=
-------------------
ZTE Information Security Notice: The information=
 contained in this mail is solely prop=
erty of the sender's organization. This mai=
l communication is confidential. Recipients name=
d above are obligated to maintain secrecy&n=
bsp;and are not permitted to disclose the&n=
bsp;contents of this communication to others.
This email and any files transmitted with&n=
bsp;it are confidential and intended solely =
;for the use of the individual or enti=
ty to whom they are addressed. If you&=
nbsp;have received this email in error plea=
se notify the originator of the message.&nb=
sp;Any views expressed in this message are&=
nbsp;those of the individual sender.
This message has been scanned for viruses&n=
bsp;and Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01C9A156.72610B24-- From gao.yang2@zte.com.cn Tue Mar 10 01:31:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4249D3A6A22; Tue, 10 Mar 2009 01:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.943 X-Spam-Level: X-Spam-Status: No, score=-88.943 tagged_above=-999 required=5 tests=[AWL=-1.942, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 705TeXC-xmQd; Tue, 10 Mar 2009 01:31:49 -0700 (PDT) Received: from mail.zte.com.cn (unknown [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 52C763A6AFD; Tue, 10 Mar 2009 01:31:43 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.5188501892; Tue, 10 Mar 2009 16:54:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2A8SGJ2018154; Tue, 10 Mar 2009 16:28:16 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: From: gao.yang2@zte.com.cn To: "Christer Holmberg" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Tue, 10 Mar 2009 16:28:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-10 16:28:06, Serialize complete at 2009-03-10 16:28:06 Content-Type: multipart/alternative; boundary="=_alternative 002E82EC48257575_=" X-MAIL: mse1.zte.com.cn n2A8SGJ2018154 Cc: SIP , SIPPING Subject: [Sip] =?gb2312?b?tPC4tDogUkU6ICAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUi?= =?gb2312?b?IGRpc2N1c3Npb24=?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 08:31:51 -0000 This is a multipart message in MIME format. --=_alternative 002E82EC48257575_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQoNCiJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4gDQoyMDA5LTAzLTEwIDE2OjAxDQoNCsrVvP7Iyw0KPGdhby55YW5nMkB6dGUuY29t LmNuPg0Ks63LzQ0KIkVyaWMud2FuZyIgPGVyaWMud2FuZ3hyQGdtYWlsLmNvbT4sICJTSVAiIDxz aXBAaWV0Zi5vcmc+LCAiU0lQUElORyIgDQo8c2lwcGluZ0BpZXRmLm9yZz4NCtb3zOINClJFOiBb U2lwXSAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUiIGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNClRo ZSByZWFzb24gd2h5IHdlIGhhdmUgdGhpcyB3aG9sZSBkaXNjdXNzaW9uIGlzIGJlY2F1c2UgdGhl IGN1cnJlbnQgDQpzcGVjaWZpY2F0aW9ucyBhcmUgdW5jbGVhci4gSWYgZXZlcnl0aGluZyB3YXMg Y2xlYXIsIGFuZCBldmVyeWJvZHkgaGFkIHRoZSANCnNhbWUgdW5kZXJzdGFuZGluZywgd2Ugd291 bGRuJ3QgbmVlZCB0byBjbGFyaWZ5IGFueXRoaW5nLg0KW0dhb10gSSB0aGluayBldmVyeXRoaW5n IGlzIGNsZWFyLiBCdXQgcGVvcGxlIGhhdmUgZGlmZmVyZW50IHZpZXcgdG93YXJkcyANClVQREFU RS4gU28gd2UgbmVlZCBjbGFyaWZpY2F0aW9uIHRoYW4gcmUtZGVmaW5pdGlvbiBoZXJlLg0KIA0K U28sIHdoYXRldmVyIHNvbHV0aW9uIHdlIGNob29zZSwgSSBhbSBzdXJlIHRoYXQgc29tZW9uZSB3 aWxsIGhhdmUgdG8gDQoicmV3cml0ZSB0aGVpciBzb2Z0d2FyZSIuDQpbR2FvXSBZZXMuIEJ1dCB3 ZSBzaG91bGQgZ3VhcmQgdGhlIHJpZ2h0IHVuZGVyc3RhbmRpbmcuIEFuZCBjb21wZWwgcGVvcGxl IA0Kd2l0aCBtaXN1bmRlcnN0YW5kaW5nIHRvICJyZXdyaXRlIHRoZWlyIHNvZnR3YXJlIi4gSSB0 aGluayBtYWtlIGV2ZXJ5IA0KVVBEQVRFLzIwME9LIGR1cmluZyBSZS1JTlZJVEUgYXMgcGFydCBv ZiBSZS1JTlZJVEUgaXMgYSAiYmlnIiBjaGFuZ2UgZm9yIA0Kc29tZSBzb2Z0d2FyZS4NCkkgc3Vw cG9ydCB0byB0YWtlIFVQREFURS8yMDBPSyBqdXN0IHJlZnJlc2hpbmcgInByZWNvbmRpdGlvbiBz dGF0ZSB0YWJsZSIgDQphcyBwYXJ0IG9mIFJlLUlOVklURS4gQW5kIEkgdGhpbmsgbW9zdCBvZiBj dXJyZW50IHNvZnR3YXJlIGlzIGRvaW5nIHNvLg0KIA0KLi4uLklGIHRoYXQgc29mdHdhcmUgZXhp c3RzIGluIHRoZSBmaXJzdCBwbGFjZSwgdGhhdCBpcy4gDQogDQpJIGFtIG5vdCBhd2FyZSBvZiBh bnkgZGVwbG95bWVudHMgd2hpY2ggd291bGQgc3VwcG9ydCByZS1JTlZJVEVzIHdpdGggDQpuZXN0 ZWQgVVBEQVRFcy9QUkFDS3MuIE1heWJlIHRoZXJlIGFyZSBzdWNoIGRlcGxveW1lbnRzLCBidXQg SSBkb3VidCB0aGV5IA0Kd291bGQgYWxsIGJlaGF2ZSBpbiB0aGUgd2F5IGFzIHlvdSBkZXNjcmli ZS4NCltHYW9dIEkganVzdCB0YWxrZWQgYWJvdXQgaWYgd2Ugd2FudCB0byBvYmV5IFJGQzMzMTEs IGl0IGlzIG5vdCByaWdodCB0byANCnRha2UgYWxsIFVQREFURS8yMDBPSyhkdXJpbmcgUmUtSU5W SVRFKSBhcyBwYXJ0IG9mIFJlLUlOVklURS4NCiANClJlZ2FyZGluZyB5b3VyIHNlY29uZCBidWxs ZXQsIEkgZG9uJ3QgZXZlbiB0aGluayB0aGF0IG9uZSBzaG91bGQgc2VuZCANCiJuZXN0ZWQiIFVQ REFURXMsIGlmIHRoZXkgZG9uJ3QgaGF2ZSBhbnl0aGluZyB0byBkbyB3aXRoIHRoZSByZS1JTlZJ VEUuIEkgDQp0aGluayB0aGF0IGlzIGJhZCBhcHBsaWNhdGlvbiBkZXNpZ24uIE5vbi1yZWxhdGVk IGNoYW5nZXMgc2hvdWxkIGJlIGRvbmUgDQpvdXRzaWRlIHRoZSByZS1JTlZJVEUgdHJhbnNhY3Rp b24uDQpbR2FvXSBJdCBpcyBub3QgYnVsbGV0LCBqdXN0IGZyaWVuZGx5IGRpc2N1c3Npb24uDQpB bmQgSSB0aGluayB0aGUgcmVsYXRpb25zaGlwIG9mIFJlLUlOVklURSBhbmQgVVBEQVRFcyBzaG91 bGQgYmUgZGVmaW5lZCBieSANCmFwcGxpY2F0aW9uIGxldmVsIGRlZmluaXRpb24sIHN1Y2ggYXMg cHJlY29uZGl0aW9uLiBXZSBzaG91bGQgbm90IGp1c3QgDQptYWtpbmcgcmVsYXRpb25zaGlwICBi eSAiZHVyaW5nIi4NCiANCg0KR2FvDQoNCkZyb206IGdhby55YW5nMkB6dGUuY29tLmNuIFttYWls dG86Z2FvLnlhbmcyQHp0ZS5jb20uY25dIA0KU2VudDogMTAuIG1hYWxpc2t1dXRhIDIwMDkgOToz Ng0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogRXJpYy53YW5nOyBTSVA7IFNJUFBJTkcNClN1 YmplY3Q6IFtTaXBdICJVUERBVEUgZHVyaW5nIFJlLUlOVklURSIgZGlzY3Vzc2lvbg0KDQoNCk9L LiBUaGFua3MgZm9yIHlvdXIgc3RhbmRwb2ludC4gDQoNCkJ1dCBhY2NlcHRpbmcgdGhpcyBtZWFu czogDQoxLiBSZXdyaXRlIG9mIGN1cnJlbnQgc29mdHdhcmUgdG8gYmUgYXMgdGhlIGJlaGF2aW9y IGRlZmluZWQgYnkgDQoiZHJhZnQtY2FtYXJpbGxvLXNpcHBpbmctcmVpbnZpdGUtMDAiLiANCjIu IE1ha2luZyBhbGwgVVBEQVRFLzIwME9LICJkdXJpbmciIFJlLUlOVklURSBhcyBSZS1JTlZJVEUn cyBwYXJ0LiANCg0KR2FvIA0KDQoNCg0KIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPiANCjIwMDktMDMtMTAgMTU6MjIgDQoNCg0KytW8/sjLDQo8Z2Fv LnlhbmcyQHp0ZS5jb20uY24+LCAiRXJpYy53YW5nIiA8ZXJpYy53YW5neHJAZ21haWwuY29tPiAN CrOty80NCiJTSVAiIDxzaXBAaWV0Zi5vcmc+LCAiU0lQUElORyIgPHNpcHBpbmdAaWV0Zi5vcmc+ IA0K1vfM4g0KUkU6IFtTaXBwaW5nXSC08Li0OiBbU2lwXSAiVVBEQVRFIGR1cmluZyBSZS1JTlZJ VEUiIGRpc2N1c3Npb24NCg0KDQoNCg0KDQoNCg0KDQpJIHN1cHBvcnQgdmlldyAxLiANCiAgDQpS ZWdhcmRzLCANCiAgDQpDaHJpc3RlciANCg0KRnJvbTogc2lwcGluZy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86c2lwcGluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQpPZiBnYW8ueWFu ZzJAenRlLmNvbS5jbg0KU2VudDogMTAuIG1hYWxpc2t1dXRhIDIwMDkgODo1NA0KVG86IEVyaWMu d2FuZw0KQ2M6ICdTSVAnOyAnU0lQUElORycNClN1YmplY3Q6IFtTaXBwaW5nXSC08Li0OiBbU2lw XSAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUiIGRpc2N1c3Npb24NCg0KDQoNClllcy4gSWYgd2Ug YWNjZXB0IHZpZXcgMSwgdGhlcmUgd291bGQgYmUgc29tZSBiYWNrd2FyZCBjb21wYXRpYmxlIHBy b2JsZW0uIA0KQW5kIHRoaXMgaXMgYSBjaGFuZ2UgdG8gUkZDMzMxMS4gDQoNCkkgYW0gd2FpdGlu ZyBmb3IgbW9yZSBjb21tZW50cyBmcm9tIHBlb3BsZSB3YW50IHRvIGtlZXAgUkZDMzMxMSBmcm9t IA0KcmUtd3JpdGUuIA0KDQpHYW8gDQoNCg0KIkVyaWMud2FuZyIgPGVyaWMud2FuZ3hyQGdtYWls LmNvbT4g0LTT2iAyMDA5LTAzLTA5IDIwOjA1OjUxOg0KDQo+IEhpLCANCj4gICANCj4gSSBzdXBw b3J0IHZpZXcgMixub3QgYWxsIHVwZGF0ZSBjYW4gYmUgY29uc2lkZXJlZCBhcyBzdWItdHJhbnNh Y3Rpb24NCj4gb2YgcmUtSU5WSVRFLiANCj4gQWNjb3JkaW5nIHRvIGN1cnJlbnQgUkZDcywgaXSh r3MgTk9UIHByb3BlciB0byBjb25zaWRlciBhbGwgVVBEQVRFcyANCj4gYXMgcmUtSU5WSVRFoa9z IHN1Yi10cmFuc2FjdGlvbiANCj4gRWc6IA0KPiBVUERBVEUgbmVzdGVkIGluIHJlLUlOVklURSAg Zm9yIHRhcmdldCByZWZyZXNoIGNhbqGvdCBiZSBjb25zaWRlcmVkIA0KPiBhcyBzdWItdHJhbnNh Y3Rpb24uIA0KDQoNCg0KPiBUaGVyZSBhcmUgdHdvIHRob3VnaHQgYWJvdXQgIlVQREFURSBkdXJp bmcgUmUtSU5WSVRFIi4gV2hpY2ggb25lIGlzIA0KPiBiZXR0ZXIgb3Igc3VpdHMgZm9yIGN1cnJl bnQgUkZDcyANCj4gDQo+IFRoZXJlIGFyZSB0d28gdGhvdWdodCBhYm91dCAiVVBEQVRFIGR1cmlu ZyBSZS1JTlZJVEUiLiANCj4gDQo+IDEuIEFsbCBVUERBVEVzIGR1cmluZyBSZS1JTlZJVEUgYXJl IFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbiANCj4gUkZDMzMxMihQcmVjb25kaXRpb24pIGlz IGEgY2FzZS4gQXMgdGhlcmUgaXMgc3VjaCBjYXNlLCB3ZSBjYW4gDQo+IG1ha2luZyBhbGwgVVBE QVRFcyBkdXJpbmcgUmUtSU5WSVRFIGFzIFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbi4gDQo+ IA0KPiAyLiBOb3QgYWxsIFVQREFURShkdXJpbmcgUmUtSU5WSVRFKSBjYW4gYmUgY29uc2lkZXJl ZCBhcyBzdWItDQo+IHRyYW5zYWN0aW9uIG9mIFJlLUlOVklURSANCj4gVGhlcmUgaXMgcmVhbGx5 IG5lZWQgbmVzdGVkLW1vZGlmaWNhdGlvbiwgc3VjaCBhcyBwcmVjb25kaXRpb24gYW5kIA0KPiBt b3JlIGluIHRoZSBmdXR1cmUuICBCdXQgdGhlIGNhc2NhZGUgb2YgbmVzdGVkIHRyYW5zYWN0aW9u IHNob3VsZCBiZQ0KPiBkZWZpbmVkIGluIGFwcGxpY2F0aW9uLWxldmVsLCBub3Qgc2lnbmFsLWxl dmVsLiBTbywgaXQgaXMgYmV0dGVyIHRvIA0KPiBtYWtlIFJlLUlOVklURSBhbmQgVVBEQVRFIHNl cGFyYXRseSBleHBlY3QgZm9yIGRlZmluaXRpb24gc3VjaCBhcyANCj4gcHJlY29uZGl0aW9uLiAg QW5kIHRoaXMgb2JleXMgY3VycmVudCBkZWZpbml0aW9uIG9mIFJGQzMzMTEuIA0KPiANCj4gSW4g UkZDMzMxMSwgd2hlbiB0aGUgVVBEQVRFIGlzIGFjY2VwdGVkIGJ5IHRoZSBvdGhlciANCj4gc2lk ZShVUERBVEUvMjAwT0spLCB0aGUgY2hhbmdlIG9mIHN0YXRlcyBpcyBjb21taXR0ZWQgYW5kIGVm Zm9ydCBhdCANCj4gb25jZS4gQW5kIG1ha2luZyBhbGwgVVBEQVRFcyBkdXJpbmcgUmUtSU5WSVRF IGFzIFJlLUlOVklURSdzIHN1Yi0NCj4gdHJhbnNhY3Rpb24gY2FuIGJlIHZpb2xhdGlvbiBvZiBS RkMzMzExLiBTbywgd2Ugc2hvbGQgbm90IHRyZWF0IGFsbCANCj4gVVBEQVRFcyBkdXJpbmcgUmUt SU5WSVRFIGFzIFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbi4gDQo+IA0KPiBXaGlsZSBVUERB VEUvMjAwT0sganVzdCByZWZyZXNoICJwcmVjb25kaXRpb24gc3RhdGUgdGFibGUiIGluIA0KPiBS RkMzMzEyKCJwcmVjb25kaXRpb24gc3RhdGUgdGFibGUiIGlzIG1vZGlmaWVkIGF0IG9uY2UsIHNv IHRoaXMgDQo+IG9iZXlzIFJGQzMzMTIpLCBoYXZpbmcgbm8gaW1wYXQgb24gdGhlIGNvbW1pdG1l bnQgb2YgbW9kaWZpY2F0aW9uIA0KPiB0cmlnZ2VyZWQgYnkgUmUtSU5WSVRFLCB0aGVzZSBVUERB VEUvMjAwT0sgY2FuIGJlIHRyZWF0ZWQgYXMgc3ViLQ0KPiB0cmFuc2FjdGlvbiBvZiBSZS1JTlZJ VEUuIA0KPiBPdGhlciBVUERBVEUvMjAwT0sgY2FuIG5vdCBiZSB0cmVhdGVkIGFzIHN1Yi10cmFu c2FjdGlvbiBvZiBSZS1JTlZJVEUuIA0KPiANCj4gQ29tbWVudHMvZmVlbGluZyBhcmUgd2VsY29t ZSEgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlh bC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3Jl Y3kgYW5kIA0KYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRo aXMgY29tbXVuaWNhdGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJl IGFkZHJlc3NlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2Vu ZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQpzb2xl bHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11 bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9i bGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQpU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIA0K dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 002E82EC48257575_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtDaHJpc3Rl ciBIb2xtYmVyZyZxdW90Ow0KJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8 L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTAzLTEw IDE2OjAxPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPiZsdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O0VyaWMud2FuZyZxdW90OyAmbHQ7ZXJpYy53YW5neHJAZ21haWwuY29tJmd0OywNCiZxdW90 O1NJUCZxdW90OyAmbHQ7c2lwQGlldGYub3JnJmd0OywgJnF1b3Q7U0lQUElORyZxdW90OyAmbHQ7 c2lwcGluZ0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbU2lwXSAmcXVvdDtV UERBVEUgZHVyaW5nIFJlLUlOVklURSZxdW90Ow0KZGlzY3Vzc2lvbjwvZm9udD48L3RhYmxlPg0K PGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48 L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+VGhlIHJl YXNvbiB3aHkgd2UgaGF2ZSB0aGlzIHdob2xlIGRpc2N1c3Npb24NCmlzIGJlY2F1c2UgdGhlIGN1 cnJlbnQgc3BlY2lmaWNhdGlvbnMgYXJlIHVuY2xlYXIuIElmIGV2ZXJ5dGhpbmcgd2FzIGNsZWFy LA0KYW5kIGV2ZXJ5Ym9keSBoYWQgdGhlIHNhbWUgdW5kZXJzdGFuZGluZywgd2Ugd291bGRuJ3Qg bmVlZCB0byBjbGFyaWZ5IGFueXRoaW5nLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJBcmlhbCI+W0dhb10gSSB0aGluayBldmVyeXRoaW5nIGlzIGNsZWFyLg0KQnV0 IHBlb3BsZSBoYXZlIGRpZmZlcmVudCB2aWV3IHRvd2FyZHMgVVBEQVRFLiBTbyB3ZSBuZWVkIGNs YXJpZmljYXRpb24NCnRoYW4gcmUtZGVmaW5pdGlvbiBoZXJlLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+U28sIHdoYXRldmVyIHNvbHV0aW9uIHdlIGNob29zZSwgSSBhbSBzdXJlDQp0 aGF0IHNvbWVvbmUgd2lsbCBoYXZlIHRvICZxdW90O3Jld3JpdGUgdGhlaXIgc29mdHdhcmUmcXVv dDsuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5bR2Fv XSBZZXMuIEJ1dCB3ZSBzaG91bGQgZ3VhcmQNCnRoZSByaWdodCB1bmRlcnN0YW5kaW5nLiBBbmQg Y29tcGVsIHBlb3BsZSB3aXRoIG1pc3VuZGVyc3RhbmRpbmcgdG8gJnF1b3Q7cmV3cml0ZQ0KdGhl aXIgc29mdHdhcmUmcXVvdDsuIEkgdGhpbmsgbWFrZSBldmVyeSBVUERBVEUvMjAwT0sgZHVyaW5n IFJlLUlOVklURQ0KYXMgcGFydCBvZiBSZS1JTlZJVEUgaXMgYSAmcXVvdDtiaWcmcXVvdDsgY2hh bmdlIGZvciBzb21lIHNvZnR3YXJlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJBcmlhbCI+SSBzdXBwb3J0IHRvIHRha2UgVVBEQVRFLzIwME9LDQpqdXN0IHJlZnJl c2hpbmcgJnF1b3Q7cHJlY29uZGl0aW9uIHN0YXRlIHRhYmxlJnF1b3Q7IGFzIHBhcnQgb2YgUmUt SU5WSVRFLg0KQW5kIEkgdGhpbmsgbW9zdCBvZiBjdXJyZW50IHNvZnR3YXJlIGlzIGRvaW5nIHNv LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Li4uLklGIHRoYXQgc29mdHdhcmUgZXhp c3RzIGluIHRoZSBmaXJzdA0KcGxhY2UsIHRoYXQgaXMuIDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+SSBhbSBub3QgYXdhcmUgb2YgYW55IGRlcGxveW1lbnRzIHdoaWNoIHdvdWxkDQpz dXBwb3J0IHJlLUlOVklURXMgd2l0aCBuZXN0ZWQgVVBEQVRFcy9QUkFDS3MuIE1heWJlIHRoZXJl IGFyZSBzdWNoIGRlcGxveW1lbnRzLA0KYnV0IEkgZG91YnQgdGhleSB3b3VsZCBhbGwgYmVoYXZl IGluIHRoZSB3YXkgYXMgeW91IGRlc2NyaWJlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJBcmlhbCI+W0dhb10gSSBqdXN0IHRhbGtlZCBhYm91dCBpZiB3ZQ0Kd2Fu dCB0byBvYmV5IFJGQzMzMTEsIGl0IGlzIG5vdCByaWdodCB0byB0YWtlIGFsbCBVUERBVEUvMjAw T0soZHVyaW5nIFJlLUlOVklURSkNCmFzIHBhcnQgb2YgUmUtSU5WSVRFLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+UmVnYXJkaW5nIHlvdXIgc2Vjb25kIGJ1bGxldCwgSSBkb24ndCBl dmVuDQp0aGluayB0aGF0IG9uZSBzaG91bGQgc2VuZCAmcXVvdDtuZXN0ZWQmcXVvdDsgVVBEQVRF cywgaWYgdGhleSBkb24ndCBoYXZlDQphbnl0aGluZyB0byBkbyB3aXRoIHRoZSByZS1JTlZJVEUu IEkgdGhpbmsgdGhhdCBpcyBiYWQgYXBwbGljYXRpb24gZGVzaWduLg0KTm9uLXJlbGF0ZWQgY2hh bmdlcyBzaG91bGQgYmUgZG9uZSBvdXRzaWRlIHRoZSByZS1JTlZJVEUgdHJhbnNhY3Rpb24uPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5bR2FvXSBJdCBp cyBub3QgYnVsbGV0LCBqdXN0IGZyaWVuZGx5DQpkaXNjdXNzaW9uLjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+QW5kIEkgdGhpbmsgdGhlIHJlbGF0aW9u c2hpcCBvZg0KUmUtSU5WSVRFIGFuZCBVUERBVEVzIHNob3VsZCBiZSBkZWZpbmVkIGJ5IGFwcGxp Y2F0aW9uIGxldmVsIGRlZmluaXRpb24sDQpzdWNoIGFzIHByZWNvbmRpdGlvbi4gV2Ugc2hvdWxk IG5vdCBqdXN0IG1ha2luZyByZWxhdGlvbnNoaXAgJm5ic3A7YnkgJnF1b3Q7ZHVyaW5nJnF1b3Q7 LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8aHI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IGdh by55YW5nMkB6dGUuY29tLmNuIFttYWlsdG86Z2FvLnlhbmcyQHp0ZS5jb20uY25dDQo8Yj48YnI+ DQpTZW50OjwvYj4gMTAuIG1hYWxpc2t1dXRhIDIwMDkgOTozNjxiPjxicj4NClRvOjwvYj4gQ2hy aXN0ZXIgSG9sbWJlcmc8Yj48YnI+DQpDYzo8L2I+IEVyaWMud2FuZzsgU0lQOyBTSVBQSU5HPGI+ PGJyPg0KU3ViamVjdDo8L2I+IFtTaXBdICZxdW90O1VQREFURSBkdXJpbmcgUmUtSU5WSVRFJnF1 b3Q7IGRpc2N1c3Npb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KT0suIFRo YW5rcyBmb3IgeW91ciBzdGFuZHBvaW50LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K QnV0IGFjY2VwdGluZyB0aGlzIG1lYW5zOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KMS4gUmV3 cml0ZSBvZiBjdXJyZW50IHNvZnR3YXJlIHRvIGJlIGFzIHRoZSBiZWhhdmlvciBkZWZpbmVkIGJ5 ICZxdW90O2RyYWZ0LWNhbWFyaWxsby1zaXBwaW5nLXJlaW52aXRlLTAwJnF1b3Q7LjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCjIuIE1ha2luZyBhbGwgVVBEQVRFLzIwME9LICZxdW90O2R1cmlu ZyZxdW90OyBSZS1JTlZJVEUgYXMgUmUtSU5WSVRFJ3MNCnBhcnQuPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpHYW88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkIHdpZHRoPTQ3JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1 b3Q7Q2hyaXN0ZXIgSG9sbWJlcmcmcXVvdDsNCiZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAwOS0wMy0xMCAxNToyMjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+DQo8dGQgd2lkdGg9NTIlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD04JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MSU+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZndDssDQom cXVvdDtFcmljLndhbmcmcXVvdDsgJmx0O2VyaWMud2FuZ3hyQGdtYWlsLmNvbSZndDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv dDtTSVAmcXVvdDsgJmx0O3NpcEBpZXRmLm9yZyZndDssDQomcXVvdDtTSVBQSU5HJnF1b3Q7ICZs dDtzaXBwaW5nQGlldGYub3JnJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbU2lwcGluZ10gtPC4tDogW1NpcF0gJnF1b3Q7 VVBEQVRFDQpkdXJpbmcgUmUtSU5WSVRFJnF1b3Q7IGRpc2N1c3Npb248L2ZvbnQ+PC90YWJsZT4N Cjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KSSBzdXBwb3J0IHZpZXcgMS48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQogJm5ic3A7PC9mb250Pjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+DQpSZWdhcmRzLDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCkNocmlzdGVyPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPGhyPjxmb250IHNpemU9 MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBzaXBwaW5nLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpzaXBwaW5nLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmdhby55 YW5nMkB6dGUuY29tLmNuPGI+PGJyPg0KU2VudDo8L2I+IDEwLiBtYWFsaXNrdXV0YSAyMDA5IDg6 NTQ8Yj48YnI+DQpUbzo8L2I+IEVyaWMud2FuZzxiPjxicj4NCkNjOjwvYj4gJ1NJUCc7ICdTSVBQ SU5HJzxiPjxicj4NClN1YmplY3Q6PC9iPiBbU2lwcGluZ10gtPC4tDogW1NpcF0gJnF1b3Q7VVBE QVRFIGR1cmluZyBSZS1JTlZJVEUmcXVvdDsNCmRpc2N1c3Npb248L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KWWVzLiBJZiB3ZSBhY2NlcHQgdmlldyAxLCB0aGVyZSB3 b3VsZCBiZSBzb21lIGJhY2t3YXJkIGNvbXBhdGlibGUgcHJvYmxlbS4NCkFuZCB0aGlzIGlzIGEg Y2hhbmdlIHRvIFJGQzMzMTEuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KSSBhbSB3 YWl0aW5nIGZvciBtb3JlIGNvbW1lbnRzIGZyb20gcGVvcGxlIHdhbnQgdG8ga2VlcCBSRkMzMzEx IGZyb20gcmUtd3JpdGUuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KR2FvPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9 Mj48dHQ+PGJyPg0KPGJyPg0KJnF1b3Q7RXJpYy53YW5nJnF1b3Q7ICZsdDtlcmljLndhbmd4ckBn bWFpbC5jb20mZ3Q7INC009ogMjAwOS0wMy0wOSAyMDowNTo1MTo8YnI+DQo8YnI+DQomZ3Q7IEhp LDwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250 IHNpemU9Mj48dHQ+PGJyPg0KJmd0OyAmbmJzcDs8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiZndDsgSSBzdXBw b3J0IHZpZXcgMixub3QgYWxsIHVwZGF0ZSBjYW4gYmUgY29uc2lkZXJlZCBhcyBzdWItdHJhbnNh Y3Rpb248YnI+DQomZ3Q7IG9mIHJlLUlOVklURS48L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiZndDsgQWNjb3Jk aW5nIHRvIGN1cnJlbnQgUkZDcywgaXShr3MgTk9UIHByb3BlciB0byBjb25zaWRlciBhbGwgVVBE QVRFcw0KPGJyPg0KJmd0OyBhcyByZS1JTlZJVEWhr3Mgc3ViLXRyYW5zYWN0aW9uIDxicj4NCiZn dDsgRWc6PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQomZ3Q7IFVQREFURSBuZXN0ZWQgaW4gcmUtSU5WSVRFICZu YnNwO2ZvciB0YXJnZXQgcmVmcmVzaCBjYW6hr3QgYmUgY29uc2lkZXJlZA0KPGJyPg0KJmd0OyBh cyBzdWItdHJhbnNhY3Rpb24uPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7 IFRoZXJlIGFyZSB0d28gdGhvdWdodCBhYm91dCAmcXVvdDtVUERBVEUgZHVyaW5nIFJlLUlOVklU RSZxdW90Oy4gV2hpY2gNCm9uZSBpcyA8YnI+DQomZ3Q7IGJldHRlciBvciBzdWl0cyBmb3IgY3Vy cmVudCBSRkNzIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGVyZSBhcmUgdHdvIHRob3VnaHQgYWJv dXQgJnF1b3Q7VVBEQVRFIGR1cmluZyBSZS1JTlZJVEUmcXVvdDsuIDxicj4NCiZndDsgPGJyPg0K Jmd0OyAxLiBBbGwgVVBEQVRFcyBkdXJpbmcgUmUtSU5WSVRFIGFyZSBSZS1JTlZJVEUncyBzdWIt dHJhbnNhY3Rpb24gPGJyPg0KJmd0OyBSRkMzMzEyKFByZWNvbmRpdGlvbikgaXMgYSBjYXNlLiBB cyB0aGVyZSBpcyBzdWNoIGNhc2UsIHdlIGNhbiA8YnI+DQomZ3Q7IG1ha2luZyBhbGwgVVBEQVRF cyBkdXJpbmcgUmUtSU5WSVRFIGFzIFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbi4NCjxicj4N CiZndDsgPGJyPg0KJmd0OyAyLiBOb3QgYWxsIFVQREFURShkdXJpbmcgUmUtSU5WSVRFKSBjYW4g YmUgY29uc2lkZXJlZCBhcyBzdWItPGJyPg0KJmd0OyB0cmFuc2FjdGlvbiBvZiBSZS1JTlZJVEUg PGJyPg0KJmd0OyBUaGVyZSBpcyByZWFsbHkgbmVlZCBuZXN0ZWQtbW9kaWZpY2F0aW9uLCBzdWNo IGFzIHByZWNvbmRpdGlvbiBhbmQNCjxicj4NCiZndDsgbW9yZSBpbiB0aGUgZnV0dXJlLiAmbmJz cDtCdXQgdGhlIGNhc2NhZGUgb2YgbmVzdGVkIHRyYW5zYWN0aW9uIHNob3VsZA0KYmU8YnI+DQom Z3Q7IGRlZmluZWQgaW4gYXBwbGljYXRpb24tbGV2ZWwsIG5vdCBzaWduYWwtbGV2ZWwuIFNvLCBp dCBpcyBiZXR0ZXIgdG8NCjxicj4NCiZndDsgbWFrZSBSZS1JTlZJVEUgYW5kIFVQREFURSBzZXBh cmF0bHkgZXhwZWN0IGZvciBkZWZpbml0aW9uIHN1Y2ggYXMNCjxicj4NCiZndDsgcHJlY29uZGl0 aW9uLiAmbmJzcDtBbmQgdGhpcyBvYmV5cyBjdXJyZW50IGRlZmluaXRpb24gb2YgUkZDMzMxMS4N Cjxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiBSRkMzMzExLCB3aGVuIHRoZSBVUERBVEUgaXMgYWNj ZXB0ZWQgYnkgdGhlIG90aGVyIDxicj4NCiZndDsgc2lkZShVUERBVEUvMjAwT0spLCB0aGUgY2hh bmdlIG9mIHN0YXRlcyBpcyBjb21taXR0ZWQgYW5kIGVmZm9ydCBhdA0KPGJyPg0KJmd0OyBvbmNl LiBBbmQgbWFraW5nIGFsbCBVUERBVEVzIGR1cmluZyBSZS1JTlZJVEUgYXMgUmUtSU5WSVRFJ3Mg c3ViLTxicj4NCiZndDsgdHJhbnNhY3Rpb24gY2FuIGJlIHZpb2xhdGlvbiBvZiBSRkMzMzExLiBT bywgd2Ugc2hvbGQgbm90IHRyZWF0IGFsbA0KPGJyPg0KJmd0OyBVUERBVEVzIGR1cmluZyBSZS1J TlZJVEUgYXMgUmUtSU5WSVRFJ3Mgc3ViLXRyYW5zYWN0aW9uLiA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgV2hpbGUgVVBEQVRFLzIwME9LIGp1c3QgcmVmcmVzaCAmcXVvdDtwcmVjb25kaXRpb24gc3Rh dGUgdGFibGUmcXVvdDsNCmluIDxicj4NCiZndDsgUkZDMzMxMigmcXVvdDtwcmVjb25kaXRpb24g c3RhdGUgdGFibGUmcXVvdDsgaXMgbW9kaWZpZWQgYXQgb25jZSwNCnNvIHRoaXMgPGJyPg0KJmd0 OyBvYmV5cyBSRkMzMzEyKSwgaGF2aW5nIG5vIGltcGF0IG9uIHRoZSBjb21taXRtZW50IG9mIG1v ZGlmaWNhdGlvbg0KPGJyPg0KJmd0OyB0cmlnZ2VyZWQgYnkgUmUtSU5WSVRFLCB0aGVzZSBVUERB VEUvMjAwT0sgY2FuIGJlIHRyZWF0ZWQgYXMgc3ViLTxicj4NCiZndDsgdHJhbnNhY3Rpb24gb2Yg UmUtSU5WSVRFLiA8YnI+DQomZ3Q7IE90aGVyIFVQREFURS8yMDBPSyBjYW4gbm90IGJlIHRyZWF0 ZWQgYXMgc3ViLXRyYW5zYWN0aW9uIG9mIFJlLUlOVklURS4NCjxicj4NCiZndDsgPGJyPg0KJmd0 OyBDb21tZW50cy9mZWVsaW5nIGFyZSB3ZWxjb21lISA8L3R0PjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9Mz48dHQ+PGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh bml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkDQpzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVz c2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90 aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0K VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRF IEFudGktU3BhbSBzeXN0ZW0uPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PHR0Pi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwNCmlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9u LiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3Qg cGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24g dG8NCm90aGVycy48YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7 SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZv cm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtp cyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIn cyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRp b24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQm bmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4m bmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5i c3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0 aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2Vt YWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dp dGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVu ZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20m bmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7 aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJv ciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNz ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVz c2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNl cyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNw O3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002E82EC48257575_=-- From christer.holmberg@ericsson.com Tue Mar 10 01:44:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7BE13A6CE0; Tue, 10 Mar 2009 01:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.898 X-Spam-Level: X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_66=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASb4vk0rcD1B; Tue, 10 Mar 2009 01:44:31 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7A5403A6CCB; Tue, 10 Mar 2009 01:44:30 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4A3542041D; Tue, 10 Mar 2009 09:45:04 +0100 (CET) X-AuditID: c1b4fb3e-ab899bb0000023da-f2-49b628904256 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0CE8F2058B; Tue, 10 Mar 2009 09:45:04 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 09:45:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A15C.80A59A4E" Date: Tue, 10 Mar 2009 09:45:02 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Sip] "UPDATE during Re-INVITE" discussion Thread-Index: AcmhWrv4glKJydrsQvmPsn1fhFNTywAAaB2A References: From: "Christer Holmberg" To: X-OriginalArrivalTime: 10 Mar 2009 08:45:03.0790 (UTC) FILETIME=[81771CE0:01C9A15C] X-Brightmail-Tracker: AAAAAA== Cc: SIP , SIPPING Subject: Re: [Sip] "UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 08:44:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A15C.80A59A4E Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable With bullet I didn't mean that you were trying to shoot me, or = something. "Bullet" in this context refers to the second statement you = gave :) ________________________________ From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: 10. maaliskuuta 2009 10:28 To: Christer Holmberg Cc: Eric.wang; SIP; SIPPING Subject: =B4=F0=B8=B4: RE: [Sip] "UPDATE during Re-INVITE" discussion =09 =09 Hi,=20 =09 =09 =09 =09 "Christer Holmberg" =20 2009-03-10 16:01=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD "Eric.wang" , "SIP" , "SIPPING" = =20 =D6=F7=CC=E2 RE: [Sip] "UPDATE during Re-INVITE" discussion =09 The reason why we have this whole discussion is because the current = specifications are unclear. If everything was clear, and everybody had = the same understanding, we wouldn't need to clarify anything.=20 [Gao] I think everything is clear. But people have different view = towards UPDATE. So we need clarification than re-definition here.=20 =20 So, whatever solution we choose, I am sure that someone will have to = "rewrite their software".=20 [Gao] Yes. But we should guard the right understanding. And compel = people with misunderstanding to "rewrite their software". I think make = every UPDATE/200OK during Re-INVITE as part of Re-INVITE is a "big" = change for some software.=20 I support to take UPDATE/200OK just refreshing "precondition state = table" as part of Re-INVITE. And I think most of current software is = doing so.=20 =20 ....IF that software exists in the first place, that is.=20 =20 I am not aware of any deployments which would support re-INVITEs with = nested UPDATEs/PRACKs. Maybe there are such deployments, but I doubt = they would all behave in the way as you describe.=20 [Gao] I just talked about if we want to obey RFC3311, it is not right = to take all UPDATE/200OK(during Re-INVITE) as part of Re-INVITE.=20 =20 Regarding your second bullet, I don't even think that one should send = "nested" UPDATEs, if they don't have anything to do with the re-INVITE. = I think that is bad application design. Non-related changes should be = done outside the re-INVITE transaction.=20 [Gao] It is not bullet, just friendly discussion.=20 And I think the relationship of Re-INVITE and UPDATEs should be defined = by application level definition, such as precondition. We should not = just making relationship by "during".=20 =20 =09 Gao=20 =09 =09 ________________________________ From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: 10. maaliskuuta 2009 9:36 To: Christer Holmberg Cc: Eric.wang; SIP; SIPPING Subject: [Sip] "UPDATE during Re-INVITE" discussion =09 =09 OK. Thanks for your standpoint.=20 =09 But accepting this means:=20 1. Rewrite of current software to be as the behavior defined by = "draft-camarillo-sipping-reinvite-00".=20 2. Making all UPDATE/200OK "during" Re-INVITE as Re-INVITE's part.=20 =09 Gao=20 =09 =09 =09 "Christer Holmberg" =20 2009-03-10 15:22=20 =CA=D5=BC=FE=C8=CB , "Eric.wang" =20 =B3=AD=CB=CD "SIP" , "SIPPING" =20 =D6=F7=CC=E2 RE: [Sipping] =B4=F0=B8=B4: [Sip] "UPDATE during Re-INVITE" discussion =09 =09 =09 =09 I support view 1.=20 =20 Regards,=20 =20 Christer=20 =09 =09 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On = Behalf Of gao.yang2@zte.com.cn Sent: 10. maaliskuuta 2009 8:54 To: Eric.wang Cc: 'SIP'; 'SIPPING' Subject: [Sipping] =B4=F0=B8=B4: [Sip] "UPDATE during Re-INVITE" = discussion =09 =09 =09 Yes. If we accept view 1, there would be some backward compatible = problem. And this is a change to RFC3311.=20 =09 I am waiting for more comments from people want to keep RFC3311 from = re-write.=20 =09 Gao=20 =09 =09 "Eric.wang" =D0=B4=D3=DA 2009-03-09 20:05:51: =09 > Hi,=20 > =20 > I support view 2,not all update can be considered as sub-transaction > of re-INVITE.=20 > According to current RFCs, it=A1=AFs NOT proper to consider all = UPDATEs=20 > as re-INVITE=A1=AFs sub-transaction=20 > Eg:=20 > UPDATE nested in re-INVITE for target refresh can=A1=AFt be = considered=20 > as sub-transaction.=20 =09 =09 =09 > There are two thought about "UPDATE during Re-INVITE". Which one is=20 > better or suits for current RFCs=20 >=20 > There are two thought about "UPDATE during Re-INVITE".=20 >=20 > 1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction=20 > RFC3312(Precondition) is a case. As there is such case, we can=20 > making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.=20 >=20 > 2. Not all UPDATE(during Re-INVITE) can be considered as sub- > transaction of Re-INVITE=20 > There is really need nested-modification, such as precondition and=20 > more in the future. But the cascade of nested transaction should be > defined in application-level, not signal-level. So, it is better to=20 > make Re-INVITE and UPDATE separatly expect for definition such as=20 > precondition. And this obeys current definition of RFC3311.=20 >=20 > In RFC3311, when the UPDATE is accepted by the other=20 > side(UPDATE/200OK), the change of states is committed and effort at=20 > once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub- > transaction can be violation of RFC3311. So, we shold not treat all=20 > UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.=20 >=20 > While UPDATE/200OK just refresh "precondition state table" in=20 > RFC3312("precondition state table" is modified at once, so this=20 > obeys RFC3312), having no impat on the commitment of modification=20 > triggered by Re-INVITE, these UPDATE/200OK can be treated as sub- > transaction of Re-INVITE.=20 > Other UPDATE/200OK can not be treated as sub-transaction of = Re-INVITE.=20 >=20 > Comments/feeling are welcome!=20 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9A15C.80A59A4E Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
With bullet I didn't mean that you were = trying to=20 shoot me, or something. "Bullet" in this context refers to the second = statement=20 you gave :)

From: gao.yang2@zte.com.cn=20 [mailto:gao.yang2@zte.com.cn]
Sent: 10. maaliskuuta 2009=20 10:28
To: Christer Holmberg
Cc: Eric.wang; SIP;=20 SIPPING
Subject: =B4=F0=B8=B4: RE: [Sip] "UPDATE during = Re-INVITE"=20 discussion


Hi, =



"Christer = Holmberg"=20 <christer.holmberg@ericsson.com>

2009-03-10 16:01

=CA=D5=BC=FE=C8=CB
<gao.yang2@zte.com.cn>=20
=B3=AD=CB=CD
"Eric.wang"=20 <eric.wangxr@gmail.com>, "SIP" <sip@ietf.org>, = "SIPPING" <sipping@ietf.org>=20
=D6=F7=CC=E2
RE: [Sip] "UPDATE = during=20 Re-INVITE" discussion

=




The reason why we have this whole discussion is because the = current=20 specifications are unclear. If everything was clear, and everybody had = the=20 same understanding, we wouldn't need to clarify anything. =
[Gao] I think everything is clear. = But people=20 have different view towards UPDATE. So we need clarification than=20 re-definition here.
 =20
So, whatever solution we choose, I am = sure that=20 someone will have to "rewrite their software".
[Gao] Yes. But we should guard the right = understanding. And=20 compel people with misunderstanding to "rewrite their software". I = think make=20 every UPDATE/200OK during Re-INVITE as part of Re-INVITE is a "big" = change for=20 some software.
I = support to take=20 UPDATE/200OK just refreshing "precondition state table" as part of = Re-INVITE.=20 And I think most of current software is doing so.
 
....IF that=20 software exists in the first place, that is.
 
I am not aware = of any=20 deployments which would support re-INVITEs with nested UPDATEs/PRACKs. = Maybe=20 there are such deployments, but I doubt they would all behave in the = way as=20 you describe.
[Gao] I just=20 talked about if we want to obey RFC3311, it is not right to take all=20 UPDATE/200OK(during Re-INVITE) as part of Re-INVITE.
 
Regarding=20 your second bullet, I don't even think that one should send "nested" = UPDATEs,=20 if they don't have anything to do with the re-INVITE. I think that is = bad=20 application design. Non-related changes should be done outside the = re-INVITE=20 transaction.
[Gao] = It is not=20 bullet, just friendly discussion.
And I think the relationship of Re-INVITE and UPDATEs should = be defined=20 by application level definition, such as precondition. We should not = just=20 making relationship  by "during".
 

Gao

From: gao.yang2@zte.com.cn=20 [mailto:gao.yang2@zte.com.cn]
Sent: 10. maaliskuuta 2009=20 9:36
To: Christer Holmberg
Cc: Eric.wang; SIP;=20 SIPPING
Subject: [Sip] "UPDATE during Re-INVITE"=20 discussion


OK. Thanks for your = standpoint.

But=20 accepting this means: =
1. Rewrite of current software to be as = the=20 behavior defined by "draft-camarillo-sipping-reinvite-00".
2. Making all=20 UPDATE/200OK "during" Re-INVITE as Re-INVITE's part.

Gao =


"Christer = Holmberg"=20 <christer.holmberg@ericsson.com>

2009-03-10 15:22


=CA=D5=BC=FE=C8=CB
<gao.yang2@zte.com.cn>, "Eric.wang"=20 <eric.wangxr@gmail.com>=20
=B3=AD=CB=CD
"SIP" = <sip@ietf.org>,=20 "SIPPING" <sipping@ietf.org>
=D6=F7=CC=E2
RE: [Sipping] = =B4=F0=B8=B4: [Sip] "UPDATE=20 during Re-INVITE" = discussion







I=20 support view 1. =
 
Regards,=20
 
Christer

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of=20 gao.yang2@zte.com.cn
Sent: 10. maaliskuuta 2009=20 8:54
To: Eric.wang
Cc: 'SIP'; = 'SIPPING'
Subject:=20 [Sipping] =B4=F0=B8=B4: [Sip] "UPDATE during Re-INVITE" = discussion



Yes. If we accept view 1, there would be some = backward=20 compatible problem. And this is a change to RFC3311.

I am=20 waiting for more comments from people want to keep RFC3311 from=20 re-write.

Gao =


"Eric.wang" <eric.wangxr@gmail.com> = =D0=B4=D3=DA 2009-03-09=20 20:05:51:

> Hi, =
>  
> I support view 2,not all = update can=20 be considered as sub-transaction
> of = re-INVITE.
> = According to current=20 RFCs, it=A1=AFs NOT proper to consider all UPDATEs
> as = re-INVITE=A1=AFs=20 sub-transaction
> Eg:=20
> UPDATE nested in re-INVITE =  for target=20 refresh can=A1=AFt be considered
> as = sub-transaction.



> There are=20 two thought about "UPDATE during Re-INVITE". Which one is
> = better or=20 suits for current RFCs
>
> There are two thought about = "UPDATE=20 during Re-INVITE".
>
> 1. All UPDATEs during Re-INVITE = are=20 Re-INVITE's sub-transaction
> RFC3312(Precondition) is a case. = As there=20 is such case, we can
> making all UPDATEs during Re-INVITE as=20 Re-INVITE's sub-transaction.
>
> 2. Not all = UPDATE(during=20 Re-INVITE) can be considered as sub-
> transaction of Re-INVITE =
>=20 There is really need nested-modification, such as precondition and =
>=20 more in the future.  But the cascade of nested transaction should = be
> defined in application-level, not signal-level. So, it is = better to=20
> make Re-INVITE and UPDATE separatly expect for definition = such as=20
> precondition.  And this obeys current definition of = RFC3311.=20
>
> In RFC3311, when the UPDATE is accepted by the other =
> side(UPDATE/200OK), the change of states is committed and = effort at=20
> once. And making all UPDATEs during Re-INVITE as Re-INVITE's=20 sub-
> transaction can be violation of RFC3311. So, we shold not = treat=20 all
> UPDATEs during Re-INVITE as Re-INVITE's sub-transaction. =
>=20
> While UPDATE/200OK just refresh "precondition state table" in =
> RFC3312("precondition state table" is modified at once, so = this=20
> obeys RFC3312), having no impat on the commitment of = modification=20
> triggered by Re-INVITE, these UPDATE/200OK can be treated as=20 sub-
> transaction of Re-INVITE.
> Other UPDATE/200OK can = not be=20 treated as sub-transaction of Re-INVITE.
>
> = Comments/feeling=20 are welcome!

--------------------------------------------------------=
ZTE=20 Information Security Notice: The information contained in this mail is = solely=20 property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy = and are=20 not permitted to disclose the contents of this communication to=20 others.
This email and any files transmitted with it are = confidential and=20 intended solely for the use of the individual or entity to whom they = are=20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are = those of=20 the individual sender.
This message has been scanned for viruses = and Spam=20 by ZTE Anti-Spam system.


--------------------------------------------------------
= ZTE=20 Information Security Notice: The information contained in this mail is = solely=20 property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy = and are=20 not permitted to disclose the contents of this communication to=20 others.
This email and any files transmitted with it are = confidential and=20 intended solely for the use of the individual or entity to whom they = are=20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are = those of=20 the individual sender.
This message has been scanned for viruses = and Spam=20 by ZTE Anti-Spam = system.


-------------------------------------=
-------------------
ZTE Information Security Notice: The information=
 contained in this mail is solely prop=
erty of the sender's organization. This mai=
l communication is confidential. Recipients name=
d above are obligated to maintain secrecy&n=
bsp;and are not permitted to disclose the&n=
bsp;contents of this communication to others.
This email and any files transmitted with&n=
bsp;it are confidential and intended solely =
;for the use of the individual or enti=
ty to whom they are addressed. If you&=
nbsp;have received this email in error plea=
se notify the originator of the message.&nb=
sp;Any views expressed in this message are&=
nbsp;those of the individual sender.
This message has been scanned for viruses&n=
bsp;and Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01C9A15C.80A59A4E-- From john.elwell@siemens.com Tue Mar 10 02:28:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FFB3A69C3 for ; Tue, 10 Mar 2009 02:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwilBvC42IZV for ; Tue, 10 Mar 2009 02:28:11 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 08B823A68C0 for ; Tue, 10 Mar 2009 02:27:54 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGA0048SABFFI@siemenscomms.co.uk> for sip@ietf.org; Tue, 10 Mar 2009 09:28:27 +0000 (GMT) Date: Tue, 10 Mar 2009 09:28:35 +0000 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019F7234@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-asserter-identity-01.txt Thread-Index: AcmgHAvp4O4wrLI1Qnyv3RMS6sFcgwACk1lwAE61iiA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-asserter-identity-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 09:28:12 -0000 Hadriel, An interesting draft, perhaps useful in two ways: first in the way you intend (as asserter ID in closed domains or federations of closed domains), but secondly some aspects might be relevant for inclusion in an eventual solution to the SIP-Identity problem, notably the means of selecting particular body parts and SDP attributes to sign. On that particular issue, I am not sure whether the asserter is in a position to decide on a request-by-request basis which body parts and SDP attributes to sign, since it cannot know what downstream entities are likely to need to do to those fields, so we may need some guidance (e.g., a default list of things to sign). John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: 08 March 2009 19:52 > To: sip@ietf.org > Subject: [Sip] FW: I-D=20 > Action:draft-kaplan-sip-asserter-identity-01.txt >=20 >=20 > Howdy, > An updated version of SIP Asserter Identity has been=20 > uploaded, though with virtually no changes other than to=20 > avoid expiration. > But since the topic of SIP Identity is coming up (again) at=20 > the upcoming meeting, and this draft is related, I thought=20 > I'd post this again. >=20 > There was not much feedback to the previous rev, so I'm=20 > guessing folks either don't like it, or don't care, or just=20 > haven't had the time to read it. >=20 > As always, comments are appreciated - including just saying=20 > "don't care". >=20 > -hadriel >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of Internet-Drafts@ietf.org > > Sent: Sunday, March 08, 2009 2:30 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-kaplan-sip-asserter-identity-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Private Extensions to the Session=20 > Initiation > > Protocol (SIP) for Asserter Identification within Trusted Networks > > Author(s) : H. Kaplan > > Filename : draft-kaplan-sip-asserter-identity-01.txt > > Pages : 17 > > Date : 2009-03-08 > > > > This document describes private extensions to the Session > > Initiation Protocol (SIP) that enable a network of trusted SIP > > servers to identify the asserter of private user identity defined > > in RFC 3325. The use of these extensions is only applicable > > inside a set of administrative domains with previously agreed-upon > > policies for generation, transport and usage of such information. > > This document does NOT offer a general identity model suitable for > > use between different trust domains, or use in the Internet at > > large. > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-kaplan-sip-asserter- > identity- > > 01.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. >=20 From rco@iptel.org Tue Mar 10 03:05:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509BB3A67F5 for ; Tue, 10 Mar 2009 03:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPv0wXOeRrW1 for ; Tue, 10 Mar 2009 03:05:52 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 341763A672F for ; Tue, 10 Mar 2009 03:05:52 -0700 (PDT) Received: by mail.iptel.org (Postfix, from userid 103) id E0AA41810C4A; Tue, 10 Mar 2009 11:06:25 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 0638B1811242; Tue, 10 Mar 2009 11:06:24 +0100 (CET) Message-ID: <49B63B9F.9000101@iptel.org> Date: Tue, 10 Mar 2009 11:06:23 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hadriel Kaplan References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> <49B5006D.8050702@iptel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nils Ohlmeier , "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 10:05:53 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Raphael Coeffic [mailto:rco@iptel.org] >> Sent: Monday, March 09, 2009 7:42 AM >> >> That's a good point. Requiring the user to be registered and only >> accepting requests from the registered contacts provide a fair-enough >> level of security concerning the attack debated. But I am still hoping >> that we could find a solution not requiring this kind of measures, which >> I would call "user-restricting". >> > > How is it "user-restricting" to require a UA to generate a REGISTER request? Most humans don't generate the REGISTER request by hand - typically software does it for them. :) > Forcing registrations is the path that IMS went for, I believe. But if you want to take advantage of this, you may have to deploy a little more IMS than you'd like to. This reminds me of some email providers that require you to connect through POP3 prior to send any message through SMTP, instead of deploying any secure authentication mechnism. Maybe just an example: let's say you have a home SIP server, doing the usual least cost routing. Your least cost router might have something like 50 different routes. Do you want this box, or maybe your phones to have 50 running registrations, just for the purpose of having cheap calls? Well, personaly, I would prefer to just install my certificate on this box, and use TLS. But as very very few of those PSTN providers do support TLS, I cannot. By the way, there are already commercial products supporting this scenario. Regards, Raphael. From wwwrun@core3.amsl.com Tue Mar 10 07:47:48 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6F48C3A6B26; Tue, 10 Mar 2009 07:47:48 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090310144748.6F48C3A6B26@core3.amsl.com> Date: Tue, 10 Mar 2009 07:47:48 -0700 (PDT) Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'Framework for Establishing an SRTP Security Context using DTLS' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:47:48 -0000 The IESG has approved the following document: - 'Framework for Establishing an SRTP Security Context using DTLS ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-07.txt Technical Summary This document is part of a suite of documents that specify a mechanism for keying the Secure Real-time Transport Protocol (SRTP) using Datagram Transport Layer Security (DTLS). Together, these protocols provide for in-band establishment of secure multimedia sessions without dependencies on external authentication infrastructures. This document specifies the SIP framework for DTLS-SRTP. A companion document, draft-ietf-avt-dtls-srtp, specifies the SRTP portion. Working Group Summary This document is a product of the Session Initiation Protocol (SIP) Working Group. It was developed in response to coordinated meetings held with several working groups, and in consideration of several competing specifications. Document Quality There are at least two known implementations of earlier versions of this draft, one Open Source and one commercial. Several implementors have expressed interest in implementation and deployment of the final version. Personnel The Proto Shepherd for this document is Dean Willis, and the responsible Area Director is Cullen Jennings. From brett@broadsoft.com Tue Mar 10 08:04:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B493A69C0; Tue, 10 Mar 2009 08:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q6+bZ-ATb4e; Tue, 10 Mar 2009 08:04:20 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 00A0E3A68A6; Tue, 10 Mar 2009 08:04:20 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 10 Mar 2009 08:04:54 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" , SIP , SIPPING Date: Tue, 10 Mar 2009 08:04:54 -0700 Thread-Topic: [Sip] "UPDATE during Re-INVITE" discussion Thread-Index: AcmgYcN2W+UPNgzaQ52MC51GyY3OGwBIB98A Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10B4A04F41@mbx02.citservers.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9B2A061A1137254BBE4F4B2CD843646A10B4A04F41mbx02citserve_" MIME-Version: 1.0 Subject: Re: [Sip] "UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 15:04:24 -0000 --_000_9B2A061A1137254BBE4F4B2CD843646A10B4A04F41mbx02citserve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think number 2 more accurately represents RFC 3261, RFC 3262, and RFC 331= 1. From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of gao.y= ang2@zte.com.cn Sent: Sunday, March 08, 2009 10:49 PM To: SIP; SIPPING Subject: [Sip] "UPDATE during Re-INVITE" discussion There are two thought about "UPDATE during Re-INVITE". Which one is better = or suits for current RFCs There are two thought about "UPDATE during Re-INVITE". 1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction RFC3312(Precondition) is a case. As there is such case, we can making all U= PDATEs during Re-INVITE as Re-INVITE's sub-transaction. 2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction of= Re-INVITE There is really need nested-modification, such as precondition and more in = the future. But the cascade of nested transaction should be defined in app= lication-level, not signal-level. So, it is better to make Re-INVITE and UP= DATE separatly expect for definition such as precondition. And this obeys = current definition of RFC3311. In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), th= e change of states is committed and effort at once. And making all UPDATEs = during Re-INVITE as Re-INVITE's sub-transaction can be violation of RFC3311= . So, we shold not treat all UPDATEs during Re-INVITE as Re-INVITE's sub-tr= ansaction. While UPDATE/200OK just refresh "precondition state table" in RFC3312("prec= ondition state table" is modified at once, so this obeys RFC3312), having n= o impat on the commitment of modification triggered by Re-INVITE, these UPD= ATE/200OK can be treated as sub-transaction of Re-INVITE. Other UPDATE/200OK can not be treated as sub-transaction of Re-INVITE. Comments/feeling are welcome! -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_9B2A061A1137254BBE4F4B2CD843646A10B4A04F41mbx02citserve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think number 2 more accurately represents RFC 3261, RFC 32= 62, and RFC 3311.

 

 

From: sip-bounces@i= etf.org [mailto:sip-bounces@ietf.org] On Behalf Of gao.yang2@zte.com.cn
Sent: Sunday, March 08, 2009 10:49 PM
To: SIP; SIPPING
Subject: [Sip] "UPDATE during Re-INVITE" discussion

 


There are= two thought about "UPDATE during Re-INVITE". Which one is better or s= uits for current RFCs

There = are two thought about "UPDATE during Re-INVITE".

1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction
RFC3312(P= recondition) is a case. As there is such case, we can making all UPDATEs during Re-INVIT= E as Re-INVITE's sub-transaction.

2. Not= all UPDATE(during Re-INVITE) can be considered as sub-transaction of Re-INVITE<= /span>
There is = really need nested-modification, such as precondition and more in the future.  But the cascade of nested transaction should be defined in application-level, not signal-level. So, it is better to make Re-INVITE = and UPDATE separatly expect for definition such as precondition.  A= nd this obeys current definition of RFC3311.

In RFC331= 1, when the UPDATE is accepted by the other side(UPDATE/200OK), the change of states is committed and effort at once. And making all UPDATEs during Re-IN= VITE as Re-INVITE's sub-transaction can be violation of RFC3311. So, we shold no= t treat all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction. <= br>
While UPDATE/200OK just refresh "precondition state table" in RFC3312("precondition state table" is modified at once, so this o= beys RFC3312), having no impat on the commitment of modification triggered by Re-INVITE, these UPDATE/200OK can be treated as sub-transaction of Re-INVIT= E.
Other UPDATE/200OK can not be treated as sub-transaction of Re-INVITE.
Commen= ts/feeling are welcome! 

 
------------------------------------------=
--------------
ZTE Information Security =
;Notice: The information contained in this ma=
il is solely property of the sender's or=
ganization. This mail communication is confidentia=
l. Recipients named above are obligated to&nb=
sp;maintain secrecy and are not permitted to&=
nbsp;disclose the contents of this communication&n=
bsp;to others.
This email and any&=
nbsp;files transmitted with it are confidential&nb=
sp;and intended solely for the use of th=
e individual or entity to whom they are&=
nbsp;addressed. If you have received this ema=
il in error please notify the originator =
;of the message. Any views expressed in =
this message are those of the individual =
;sender.
This message has been sca=
nned for viruses and Spam by ZTE Anti-Sp=
am system.
--_000_9B2A061A1137254BBE4F4B2CD843646A10B4A04F41mbx02citserve_-- From brett@broadsoft.com Tue Mar 10 08:04:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77BB3A65A5; Tue, 10 Mar 2009 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DL6F0KNBPkf; Tue, 10 Mar 2009 08:04:20 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 22B083A69C3; Tue, 10 Mar 2009 08:04:20 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 10 Mar 2009 08:04:54 -0700 From: Brett Tate To: Christer Holmberg , SIPPING , SIP Date: Tue, 10 Mar 2009 08:04:53 -0700 Thread-Topic: [Sip] "UPDATE during Re-INVITE" discussion Thread-Index: AcmhVTsxk5ZI+5dmRxO72HVA7jSHTwAAFXSwAAohS8A= Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10B4A04F40@mbx02.citservers.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] "UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 15:04:26 -0000 > The reason why we have this whole=A0discussion is because the=20 > current specifications are unclear. As mentioned before, I think the following RFC 3261 quote is clear although= some disagree. RFC 3261 section 14.1: "If a UA receives a non-2xx final response to a re-I= NVITE, the session parameters MUST remain unchanged, as if no re-INVITE had= been issued." > Regarding your second bullet, I don't even think that one=20 > should send "nested"=A0UPDATEs, if they don't have anything to=20 > do with the re-INVITE. I think that is bad application design.=20 > Non-related changes should be done outside the re-INVITE transaction. =A0 Sending UPDATE per RFC 4028 to refresh or audit the dialog is one of the ti= mes UPDATE may be tried while a re-INVITE is occurring. From christer.holmberg@ericsson.com Tue Mar 10 08:15:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B69A3A6AB1; Tue, 10 Mar 2009 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfMkAfMeG2ih; Tue, 10 Mar 2009 08:15:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 44B513A6A9F; Tue, 10 Mar 2009 08:15:27 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F1B0321080; Tue, 10 Mar 2009 16:16:00 +0100 (CET) X-AuditID: c1b4fb3e-ab899bb0000023da-bd-49b6843052aa Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D20C62044A; Tue, 10 Mar 2009 16:16:00 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 16:16:00 +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: Tue, 10 Mar 2009 16:15:59 +0100 Message-ID: In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A10B4A04F40@mbx02.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] "UPDATE during Re-INVITE" discussion Thread-Index: AcmhVTsxk5ZI+5dmRxO72HVA7jSHTwAAFXSwAAohS8AABSlcoA== References: <9B2A061A1137254BBE4F4B2CD843646A10B4A04F40@mbx02.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "SIPPING" , "SIP" X-OriginalArrivalTime: 10 Mar 2009 15:16:00.0540 (UTC) FILETIME=[1EC71DC0:01C9A193] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] "UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 15:15:28 -0000 Hi,=20 >>Regarding your second bullet, I don't even think that one should send=20 >>"nested"=A0UPDATEs, if they don't have anything to do with the=20 >>re-INVITE. I think that is bad application design. >>Non-related changes should be done outside the re-INVITE transaction. > =A0 >Sending UPDATE per RFC 4028 to refresh or audit the dialog is=20 >one of the times UPDATE may be tried while a re-INVITE is occurring. True, but normally those UPDATEs are not going to modify session = parameters. So, yes, it may happen, but I think we should recommend against doing = so. Regards, Christer From scott.lawrence@nortel.com Tue Mar 10 11:02:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C593A6A56 for ; Tue, 10 Mar 2009 11:02:09 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyazohF-xOVa for ; Tue, 10 Mar 2009 11:02:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 16B4B3A6A49 for ; Tue, 10 Mar 2009 11:02:03 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2AI2aR20351; Tue, 10 Mar 2009 18:02:36 GMT Received: from [127.0.0.1] ([47.16.91.121]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 14:02:35 -0400 From: "Scott Lawrence" To: Hadriel Kaplan In-Reply-To: References: <49AE593F.6080807@iptel.org> <167dfb9b0903050631r383fdb28x75c964a48e31ea3b@mail.gmail.com> <20090307190922.GB4364@x61s.janakj.ryngle.net> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 10 Mar 2009 14:02:34 -0400 Message-Id: <1236708154.16972.122.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2009 18:02:35.0415 (UTC) FILETIME=[64300270:01C9A1AA] Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:02:09 -0000 On Sat, 2009-03-07 at 14:51 -0500, Hadriel Kaplan wrote: > Another question is whether an attacker can create special nonce's for > one or more challenges it sends, that will help it figure out the > password. For example can they help a rainbow-table type of password > cracking, and how much the cnonce can prevent that. If the cnonce is well chosen and the nc value incremented, I think that gets pretty hard, but I'm not by any means an expert on cracking one-way hash functions. From brett@broadsoft.com Tue Mar 10 11:08:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F643A6B04; Tue, 10 Mar 2009 11:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93E4bQpknXwG; Tue, 10 Mar 2009 11:08:11 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 2299E28C115; Tue, 10 Mar 2009 11:07:57 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 10 Mar 2009 11:08:32 -0700 From: Brett Tate To: Christer Holmberg , SIPPING , SIP Date: Tue, 10 Mar 2009 11:08:35 -0700 Thread-Topic: [Sip] "UPDATE during Re-INVITE" discussion Thread-Index: AcmhVTsxk5ZI+5dmRxO72HVA7jSHTwAAFXSwAAohS8AABSlcoAAEcBwg Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10B4A04FBD@mbx02.citservers.local> References: <9B2A061A1137254BBE4F4B2CD843646A10B4A04F40@mbx02.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] "UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:08:12 -0000 >>> Regarding your second bullet, I don't even think that one=20 >>> should send "nested"=A0UPDATEs, if they don't have anything=20 >>> to do with the re-INVITE. I think that is bad application=20 >>> design. Non-related changes should be done outside the=20 >>> re-INVITE transaction. >> >> Sending UPDATE per RFC 4028 to refresh or audit the dialog >> is one of the times UPDATE may be tried while a re-INVITE is >> occurring. >=20 > True, but normally those UPDATEs are not going to modify session > parameters. > > So, yes, it may happen, but I think we should recommend=20 > against doing so. There are two key phrases within rfc3261 which might be adding to the confu= sion: "session parameters" and "state changes". RFC 3261 section 12.2.2 an= d 14.1 basically indicate to rollback as though the re-INVITE was not sent.= There have been numerous proposal concerning what should and shouldn't ro= llback; it is occasional hard to distinguish if people mean 1) SDP 2) non S= DP state data (like Contact, Session-Expires, ...), or 3) both. =20 I agree that UPDATE likely wouldn't include SDP when only attempting to ref= resh or audit the session; however it can. I think 12.2.2 is sufficiently clear concerning what should occur upon re-I= NVITE failure; however I think it was unfortunate that section 14.1 indicat= ed "session parameters" instead of "state changes". RFC 3261 section 12.2.2: "Requests sent within a dialog, as any other reque= sts, are atomic. If a particular request is accepted by the UAS, all the s= tate changes associated with it are performed. If the request is rejected,= none of the state changes are performed." Concerning UPDATE in relation to section 12.2.2, I consider it an atomic tr= ansaction. And for it is worth, I consider PRACK to not be an atomic trans= action. From HKaplan@acmepacket.com Tue Mar 10 14:35:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CCF3A68CB for ; Tue, 10 Mar 2009 14:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZhyEOoJRdSA for ; Tue, 10 Mar 2009 14:35:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 518FC3A685F for ; Tue, 10 Mar 2009 14:35:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 10 Mar 2009 17:36:26 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 10 Mar 2009 17:36:25 -0400 From: Hadriel Kaplan To: Raphael Coeffic Date: Tue, 10 Mar 2009 17:36:24 -0400 Thread-Topic: [Sip] draft-state-sip-relay-attack-00 Thread-Index: AcmhZ+BVWZZUHaF4RraGNLbmaKCiiAAIfqnA Message-ID: References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> <49B5006D.8050702@iptel.org> <49B63B9F.9000101@iptel.org> In-Reply-To: <49B63B9F.9000101@iptel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nils Ohlmeier , "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 21:35:52 -0000 > -----Original Message----- > From: Raphael Coeffic [mailto:rco@iptel.org] > Sent: Tuesday, March 10, 2009 6:06 AM >=20 > Hadriel Kaplan wrote: >=20 > Forcing registrations is the path that IMS went for, I believe. But if > you want to take advantage of this, you may have to deploy a little more > IMS than you'd like to.=20 The concept and practice of "forcing" UA's, which have AoR's belonging to a= domain, to REGISTER their contact binding for those AoR's in order to make= calls, has been around a lot longer than IMS has. Invoking the "that soun= ds like IMS" defense is a cheap guilt-by-association argument, and not rele= vant. One might as well argue that using INVITE's or RTP "is the path that= IMS went for". You keep making it sound like sending a SIP request which does not create a= dialog is somehow a difficult mechanism to implement, or "forces" people t= o do something they don't want to. What is it forcing? You're looking for a means of authenticating a UA without being subject to = a relay attack. Using a different SIP Method name, which can only be initi= ated by the client with the credentials, and one that UA's cannot be baited= to provide by random third parties, is one solution to the problem. If yo= u don't like the string "REGISTER", then how about "OPTIONS"? > This reminds me of some email providers that > require you to connect through POP3 prior to send any message through > SMTP, instead of deploying any secure authentication mechnism. No, this is more like a Website which offers email services requiring you t= o login using your credentials before letting you send. It's not analogous= to making you use POP3 because a REGISTER does not use a different protoco= l, and can be tied to the same connection-layer "flow" as the INVITE et al. You may not like it, but any form of authentication by definition is more r= estrictive than no form of authentication. =20 > Maybe just an example: let's say you have a home SIP server, doing the > usual least cost routing. Your least cost router might have something > like 50 different routes. Do you want this box, or maybe your phones to > have 50 running registrations, just for the purpose of having cheap > calls? Well, personaly, I would prefer to just install my certificate on > this box, and use TLS. But as very very few of those PSTN providers do > support TLS, I cannot. By the way, there are already commercial products > supporting this scenario. So you have a mechanism that people don't seem to want to implement - and m= eanwhile you have another mechanism, which is widely implemented. And the = problem is...? -hadriel From gao.yang2@zte.com.cn Tue Mar 10 17:22:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE173A6A3A; Tue, 10 Mar 2009 17:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.303 X-Spam-Level: X-Spam-Status: No, score=-90.303 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG-hNpUqaVt2; Tue, 10 Mar 2009 17:22:27 -0700 (PDT) Received: from mail.zte.com.cn (mail.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 2EE143A6867; Tue, 10 Mar 2009 17:22:26 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.7100726527; Wed, 11 Mar 2009 08:46:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2B0N3QO028603; Wed, 11 Mar 2009 08:23:03 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: From: gao.yang2@zte.com.cn To: "Christer Holmberg" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Wed, 11 Mar 2009 08:22:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-11 08:23:01, Serialize complete at 2009-03-11 08:23:01 Content-Type: multipart/alternative; boundary="=_alternative 00021A3D48257576_=" X-MAIL: mse1.zte.com.cn n2B0N3QO028603 Cc: SIP , sipping-bounces@ietf.org, SIPPING , Brett Tate Subject: [Sip] =?gb2312?b?tPC4tDogUmU6IFtTaXBwaW5nXSAgIlVQREFURSBkdXJpbmcg?= =?gb2312?b?UmUtSU5WSVRFIiBkaXNjdXNzaW9u?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 00:22:28 -0000 This is a multipart message in MIME format. --=_alternative 00021A3D48257576_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UHJlY29uZGl0aW9uIGRvIG1vZGlmeSBzZXNzaW9uIHBhcmFtZXRlcnMuIFByZWNvbmRpdGlvbiBz dGF0ZSBpcyBwYXJ0IG9mIA0Kc2Vzc2lvbiBwYXJhbWV0ZXJzLg0KDQpUaGUgcG9pbnQgaXMgdGhh dCBpZiBTRFAgb25seSByZWZyZXNoICJwcmVjb25kdGlvbiBzdGF0ZSB0YWJsZSIsIGl0IGhhcyBu byANCmltcGFjdCBvbiB0aGUgY29tbWl0bWVudCBvZiBzZXNzaW9uIG1vZGlmaWNhdGlvbi4NCg0K DQoNCg0KIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PiANCreivP7IyzogIHNpcHBpbmctYm91bmNlc0BpZXRmLm9yZw0KMjAwOS0wMy0xMCAyMzoxNQ0K DQrK1bz+yMsNCiJCcmV0dCBUYXRlIiA8YnJldHRAYnJvYWRzb2Z0LmNvbT4sICJTSVBQSU5HIiA8 c2lwcGluZ0BpZXRmLm9yZz4sICJTSVAiIA0KPHNpcEBpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0K UmU6IFtTaXBwaW5nXSBbU2lwXSAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUiIGRpc2N1c3Npb24N Cg0KDQoNCg0KDQoNCg0KSGksIA0KDQo+PlJlZ2FyZGluZyB5b3VyIHNlY29uZCBidWxsZXQsIEkg ZG9uJ3QgZXZlbiB0aGluayB0aGF0IG9uZSBzaG91bGQgc2VuZCANCj4+Im5lc3RlZCIgVVBEQVRF cywgaWYgdGhleSBkb24ndCBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggdGhlIA0KPj5yZS1JTlZJ VEUuIEkgdGhpbmsgdGhhdCBpcyBiYWQgYXBwbGljYXRpb24gZGVzaWduLg0KPj5Ob24tcmVsYXRl ZCBjaGFuZ2VzIHNob3VsZCBiZSBkb25lIG91dHNpZGUgdGhlIHJlLUlOVklURSB0cmFuc2FjdGlv bi4NCj4gIA0KPlNlbmRpbmcgVVBEQVRFIHBlciBSRkMgNDAyOCB0byByZWZyZXNoIG9yIGF1ZGl0 IHRoZSBkaWFsb2cgaXMgDQo+b25lIG9mIHRoZSB0aW1lcyBVUERBVEUgbWF5IGJlIHRyaWVkIHdo aWxlIGEgcmUtSU5WSVRFIGlzIG9jY3VycmluZy4NCg0KVHJ1ZSwgYnV0IG5vcm1hbGx5IHRob3Nl IFVQREFURXMgYXJlIG5vdCBnb2luZyB0byBtb2RpZnkgc2Vzc2lvbiANCnBhcmFtZXRlcnMuDQoN ClNvLCB5ZXMsIGl0IG1heSBoYXBwZW4sIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCByZWNvbW1lbmQg YWdhaW5zdCBkb2luZyBzby4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNpcHBpbmcgbWFpbGluZyBsaXN0 ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHBpbmcNClRoaXMgbGlz dCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBhcHBsaWNhdGlvbiBvZiBTSVANClVzZSBz aXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQg c2lwDQpVc2Ugc2lwQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9mIGNvcmUgU0lQDQoN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg== --=_alternative 00021A3D48257576_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlByZWNvbmRpdGlvbiBkbyBtb2Rp ZnkgPC9mb250Pjxmb250IHNpemU9Mj48dHQ+c2Vzc2lvbg0KcGFyYW1ldGVyczwvdHQ+PC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4uIFByZWNvbmRpdGlvbiBzdGF0ZQ0KaXMg cGFydCBvZiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5zZXNzaW9uIHBhcmFtZXRlcnM8L3R0Pjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHBvaW50IGlzIHRoYXQgaWYgU0RQIG9u bHkgcmVmcmVzaA0KJnF1b3Q7cHJlY29uZHRpb24gc3RhdGUgdGFibGUmcXVvdDssIGl0IGhhcyBu byBpbXBhY3Qgb24gdGhlIGNvbW1pdG1lbnQNCm9mIHNlc3Npb24gbW9kaWZpY2F0aW9uLjwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4m cXVvdDtDaHJpc3RlciBIb2xtYmVyZyZxdW90Ow0KJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+t6K8/sjLOiAmbmJzcDtzaXBwaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wMy0xMCAyMzoxNTwvZm9udD4NCjx0ZCB3 aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtCcmV0dCBU YXRlJnF1b3Q7ICZsdDticmV0dEBicm9hZHNvZnQuY29tJmd0OywNCiZxdW90O1NJUFBJTkcmcXVv dDsgJmx0O3NpcHBpbmdAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtTSVAmcXVvdDsgJmx0O3NpcEBpZXRm Lm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbU2lwcGluZ10gW1NpcF0gJnF1b3Q7VVBEQVRFIGR1cmluZw0KUmUtSU5W SVRFJnF1b3Q7IGRpc2N1c3Npb248L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCkhpLCA8YnI+DQo8YnI+DQomZ3Q7Jmd0O1JlZ2Fy ZGluZyB5b3VyIHNlY29uZCBidWxsZXQsIEkgZG9uJ3QgZXZlbiB0aGluayB0aGF0IG9uZSBzaG91 bGQNCnNlbmQgPGJyPg0KJmd0OyZndDsmcXVvdDtuZXN0ZWQmcXVvdDsmbmJzcDtVUERBVEVzLCBp ZiB0aGV5IGRvbid0IGhhdmUgYW55dGhpbmcgdG8NCmRvIHdpdGggdGhlIDxicj4NCiZndDsmZ3Q7 cmUtSU5WSVRFLiBJIHRoaW5rIHRoYXQgaXMgYmFkIGFwcGxpY2F0aW9uIGRlc2lnbi48YnI+DQom Z3Q7Jmd0O05vbi1yZWxhdGVkIGNoYW5nZXMgc2hvdWxkIGJlIGRvbmUgb3V0c2lkZSB0aGUgcmUt SU5WSVRFIHRyYW5zYWN0aW9uLjxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0O1NlbmRpbmcgVVBE QVRFIHBlciBSRkMgNDAyOCB0byByZWZyZXNoIG9yIGF1ZGl0IHRoZSBkaWFsb2cgaXMgPGJyPg0K Jmd0O29uZSBvZiB0aGUgdGltZXMgVVBEQVRFIG1heSBiZSB0cmllZCB3aGlsZSBhIHJlLUlOVklU RSBpcyBvY2N1cnJpbmcuPGJyPg0KPGJyPg0KVHJ1ZSwgYnV0IG5vcm1hbGx5IHRob3NlIFVQREFU RXMgYXJlIG5vdCBnb2luZyB0byBtb2RpZnkgc2Vzc2lvbiBwYXJhbWV0ZXJzLjxicj4NCjxicj4N ClNvLCB5ZXMsIGl0IG1heSBoYXBwZW4sIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCByZWNvbW1lbmQg YWdhaW5zdCBkb2luZyBzby48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVy PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpTaXBwaW5nIG1haWxpbmcgbGlzdCAmbmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcHBpbmc8YnI+DQpUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9w bWVudCBvZiB0aGUgYXBwbGljYXRpb24gb2YgU0lQPGJyPg0KVXNlIHNpcC1pbXBsZW1lbnRvcnNA Y3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXA8YnI+DQpVc2Ugc2lw QGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9mIGNvcmUgU0lQPGJyPg0KPC90dD48L2Zv bnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5 Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVy dHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNw O1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50 aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7 b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJz cDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7 dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJz cDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7 Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3Im bmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtv ciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDth ZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0 aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5 Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4m bmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZu YnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNw O2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00021A3D48257576_=-- From gao.yang2@zte.com.cn Tue Mar 10 17:30:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE113A6A51; Tue, 10 Mar 2009 17:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.999 X-Spam-Level: X-Spam-Status: No, score=-89.999 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlLydchr-IV0; Tue, 10 Mar 2009 17:30:41 -0700 (PDT) Received: from mail.zte.com.cn (mail2.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 1B99C3A6A29; Tue, 10 Mar 2009 17:30:39 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.3475471162; Wed, 11 Mar 2009 08:42:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2B0J55b027962; Wed, 11 Mar 2009 08:19:05 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A10B4A04F41@mbx02.citservers.local> From: gao.yang2@zte.com.cn To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Wed, 11 Mar 2009 08:18:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-11 08:19:04, Serialize complete at 2009-03-11 08:19:04 Content-Type: multipart/alternative; boundary="=_alternative 0001BD4F48257576_=" X-MAIL: mse1.zte.com.cn n2B0J55b027962 Cc: SIP , SIPPING Subject: [Sip] =?gb2312?b?tPC4tDogUkU6ICAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUi?= =?gb2312?b?IGRpc2N1c3Npb24=?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 00:30:42 -0000 This is a multipart message in MIME format. --=_alternative 0001BD4F48257576_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHN0YW5kcG9pbnQuDQoNCkFuZCBtb3JlIGNvbW1tZW50L2ZlZWxpbmcg ZnJvbSBtb3JlIHBlb3BsZSBhcmUgd2VsY29tZS4NCg0KDQoNCg0KQnJldHQgVGF0ZSA8YnJldHRA YnJvYWRzb2Z0LmNvbT4gDQoyMDA5LTAzLTEwIDIzOjA0DQoNCsrVvP7Iyw0KImdhby55YW5nMkB6 dGUuY29tLmNuIiA8Z2FvLnlhbmcyQHp0ZS5jb20uY24+LCBTSVAgPHNpcEBpZXRmLm9yZz4sIFNJ UFBJTkcgDQo8c2lwcGluZ0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KUkU6IFtTaXBdICJVUERB VEUgZHVyaW5nIFJlLUlOVklURSIgZGlzY3Vzc2lvbg0KDQoNCg0KDQoNCg0KSSB0aGluayBudW1i ZXIgMiBtb3JlIGFjY3VyYXRlbHkgcmVwcmVzZW50cyBSRkMgMzI2MSwgUkZDIDMyNjIsIGFuZCBS RkMgDQozMzExLg0KIA0KIA0KRnJvbTogc2lwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXAt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KZ2FvLnlhbmcyQHp0ZS5jb20uY24NClNl bnQ6IFN1bmRheSwgTWFyY2ggMDgsIDIwMDkgMTA6NDkgUE0NClRvOiBTSVA7IFNJUFBJTkcNClN1 YmplY3Q6IFtTaXBdICJVUERBVEUgZHVyaW5nIFJlLUlOVklURSIgZGlzY3Vzc2lvbg0KIA0KDQpU aGVyZSBhcmUgdHdvIHRob3VnaHQgYWJvdXQgIlVQREFURSBkdXJpbmcgUmUtSU5WSVRFIi4gV2hp Y2ggb25lIGlzIGJldHRlciANCm9yIHN1aXRzIGZvciBjdXJyZW50IFJGQ3MgDQoNClRoZXJlIGFy ZSB0d28gdGhvdWdodCBhYm91dCAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUiLiANCg0KMS4gQWxs IFVQREFURXMgZHVyaW5nIFJlLUlOVklURSBhcmUgUmUtSU5WSVRFJ3Mgc3ViLXRyYW5zYWN0aW9u IA0KUkZDMzMxMihQcmVjb25kaXRpb24pIGlzIGEgY2FzZS4gQXMgdGhlcmUgaXMgc3VjaCBjYXNl LCB3ZSBjYW4gbWFraW5nIGFsbCANClVQREFURXMgZHVyaW5nIFJlLUlOVklURSBhcyBSZS1JTlZJ VEUncyBzdWItdHJhbnNhY3Rpb24uIA0KDQoyLiBOb3QgYWxsIFVQREFURShkdXJpbmcgUmUtSU5W SVRFKSBjYW4gYmUgY29uc2lkZXJlZCBhcyBzdWItdHJhbnNhY3Rpb24gDQpvZiBSZS1JTlZJVEUg DQpUaGVyZSBpcyByZWFsbHkgbmVlZCBuZXN0ZWQtbW9kaWZpY2F0aW9uLCBzdWNoIGFzIHByZWNv bmRpdGlvbiBhbmQgbW9yZSBpbiANCnRoZSBmdXR1cmUuICBCdXQgdGhlIGNhc2NhZGUgb2YgbmVz dGVkIHRyYW5zYWN0aW9uIHNob3VsZCBiZSBkZWZpbmVkIGluIA0KYXBwbGljYXRpb24tbGV2ZWws IG5vdCBzaWduYWwtbGV2ZWwuIFNvLCBpdCBpcyBiZXR0ZXIgdG8gbWFrZSBSZS1JTlZJVEUgDQph bmQgVVBEQVRFIHNlcGFyYXRseSBleHBlY3QgZm9yIGRlZmluaXRpb24gc3VjaCBhcyBwcmVjb25k aXRpb24uICBBbmQgdGhpcyANCm9iZXlzIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiBSRkMzMzExLiAN Cg0KSW4gUkZDMzMxMSwgd2hlbiB0aGUgVVBEQVRFIGlzIGFjY2VwdGVkIGJ5IHRoZSBvdGhlciBz aWRlKFVQREFURS8yMDBPSyksIA0KdGhlIGNoYW5nZSBvZiBzdGF0ZXMgaXMgY29tbWl0dGVkIGFu ZCBlZmZvcnQgYXQgb25jZS4gQW5kIG1ha2luZyBhbGwgDQpVUERBVEVzIGR1cmluZyBSZS1JTlZJ VEUgYXMgUmUtSU5WSVRFJ3Mgc3ViLXRyYW5zYWN0aW9uIGNhbiBiZSB2aW9sYXRpb24gDQpvZiBS RkMzMzExLiBTbywgd2Ugc2hvbGQgbm90IHRyZWF0IGFsbCBVUERBVEVzIGR1cmluZyBSZS1JTlZJ VEUgYXMgDQpSZS1JTlZJVEUncyBzdWItdHJhbnNhY3Rpb24uIA0KDQpXaGlsZSBVUERBVEUvMjAw T0sganVzdCByZWZyZXNoICJwcmVjb25kaXRpb24gc3RhdGUgdGFibGUiIGluIA0KUkZDMzMxMigi cHJlY29uZGl0aW9uIHN0YXRlIHRhYmxlIiBpcyBtb2RpZmllZCBhdCBvbmNlLCBzbyB0aGlzIG9i ZXlzIA0KUkZDMzMxMiksIGhhdmluZyBubyBpbXBhdCBvbiB0aGUgY29tbWl0bWVudCBvZiBtb2Rp ZmljYXRpb24gdHJpZ2dlcmVkIGJ5IA0KUmUtSU5WSVRFLCB0aGVzZSBVUERBVEUvMjAwT0sgY2Fu IGJlIHRyZWF0ZWQgYXMgc3ViLXRyYW5zYWN0aW9uIG9mIA0KUmUtSU5WSVRFLiANCk90aGVyIFVQ REFURS8yMDBPSyBjYW4gbm90IGJlIHRyZWF0ZWQgYXMgc3ViLXRyYW5zYWN0aW9uIG9mIFJlLUlO VklURS4gDQoNCkNvbW1lbnRzL2ZlZWxpbmcgYXJlIHdlbGNvbWUhIA0KIA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgDQphcmUgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRv IA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQg YXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiANCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVz c2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0K c3lzdGVtLg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUg c2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRl bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz ZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBh ZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRo aXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBB bnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0001BD4F48257576_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBzdGFu ZHBvaW50LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ QW5kIG1vcmUgY29tbW1lbnQvZmVlbGluZyBmcm9tIG1vcmUNCnBlb3BsZSBhcmUgd2VsY29tZS48 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+QnJldHQgVGF0ZSAmbHQ7YnJldHRAYnJvYWRzb2Z0LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wMy0xMCAyMzowNDwvZm9udD4N Cjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtn YW8ueWFuZzJAenRlLmNvbS5jbiZxdW90OyAmbHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7LA0K U0lQICZsdDtzaXBAaWV0Zi5vcmcmZ3Q7LCBTSVBQSU5HICZsdDtzaXBwaW5nQGlldGYub3JnJmd0 OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UkU6IFtTaXBdICZxdW90O1VQREFURSBkdXJpbmcgUmUtSU5WSVRFJnF1b3Q7DQpkaXNjdXNz aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N Cjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ291cmllciBOZXciPkkgdGhpbmsgbnVtYmVyIDIgbW9yZQ0K YWNjdXJhdGVseSByZXByZXNlbnRzIFJGQyAzMjYxLCBSRkMgMzI2MiwgYW5kIFJGQyAzMzExLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDb3VyaWVyIE5ldyI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+ RnJvbTo8L2I+IHNpcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmdhby55YW5nMkB6dGUuY29tLmNuPGI+PGJyPg0KU2Vu dDo8L2I+IFN1bmRheSwgTWFyY2ggMDgsIDIwMDkgMTA6NDkgUE08Yj48YnI+DQpUbzo8L2I+IFNJ UDsgU0lQUElORzxiPjxicj4NClN1YmplY3Q6PC9iPiBbU2lwXSAmcXVvdDtVUERBVEUgZHVyaW5n IFJlLUlOVklURSZxdW90OyBkaXNjdXNzaW9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxicj4NClRoZXJlIGFyZSB0d28gdGhvdWdodCBhYm91dCAmcXVvdDtVUERBVEUgZHVy aW5nIFJlLUlOVklURSZxdW90Oy4gV2hpY2gNCm9uZSBpcyBiZXR0ZXIgb3Igc3VpdHMgZm9yIGN1 cnJlbnQgUkZDczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPjxicj4NClRoZXJlIGFyZSB0 d28gdGhvdWdodCBhYm91dCAmcXVvdDtVUERBVEUgZHVyaW5nIFJlLUlOVklURSZxdW90Oy48L2I+ PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+PGJyPg0KMS4gQWxsIFVQREFURXMgZHVyaW5n IFJlLUlOVklURSBhcmUgUmUtSU5WSVRFJ3Mgc3ViLXRyYW5zYWN0aW9uPC9iPjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPjxicj4NClJGQzMzMTIoUHJlY29uZGl0aW9uKSBpcyBhIGNhc2UuIEFzIHRoZXJl IGlzIHN1Y2ggY2FzZSwgd2UgY2FuIG1ha2luZyBhbGwNClVQREFURXMgZHVyaW5nIFJlLUlOVklU RSBhcyBSZS1JTlZJVEUncyBzdWItdHJhbnNhY3Rpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGI+PGJyPg0KMi4gTm90IGFsbCBVUERBVEUoZHVyaW5nIFJlLUlOVklURSkgY2FuIGJlIGNv bnNpZGVyZWQgYXMgc3ViLXRyYW5zYWN0aW9uDQpvZiBSZS1JTlZJVEU8L2I+PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpUaGVyZSBpcyByZWFsbHkgbmVlZCBuZXN0ZWQtbW9kaWZpY2F0aW9uLCBz dWNoIGFzIHByZWNvbmRpdGlvbiBhbmQgbW9yZQ0KaW4gdGhlIGZ1dHVyZS4gJm5ic3A7QnV0IHRo ZSBjYXNjYWRlIG9mIG5lc3RlZCB0cmFuc2FjdGlvbiBzaG91bGQgYmUgZGVmaW5lZA0KaW4gYXBw bGljYXRpb24tbGV2ZWwsIG5vdCBzaWduYWwtbGV2ZWwuIDxiPlNvLCBpdCBpcyBiZXR0ZXIgdG8g bWFrZSBSZS1JTlZJVEUNCmFuZCBVUERBVEUgc2VwYXJhdGx5IGV4cGVjdCBmb3IgZGVmaW5pdGlv biBzdWNoIGFzIHByZWNvbmRpdGlvbi48L2I+ICZuYnNwOzxiPkFuZA0KdGhpcyBvYmV5cyBjdXJy ZW50IGRlZmluaXRpb24gb2YgUkZDMzMxMS48L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KSW4gUkZDMzMxMSwgd2hlbiB0aGUgVVBEQVRFIGlzIGFjY2VwdGVkIGJ5IHRoZSBvdGhl ciBzaWRlKFVQREFURS8yMDBPSyksDQp0aGUgY2hhbmdlIG9mIHN0YXRlcyBpcyBjb21taXR0ZWQg YW5kIGVmZm9ydCBhdCBvbmNlLiBBbmQgbWFraW5nIGFsbCBVUERBVEVzDQpkdXJpbmcgUmUtSU5W SVRFIGFzIFJlLUlOVklURSdzIHN1Yi10cmFuc2FjdGlvbiBjYW4gYmUgdmlvbGF0aW9uIG9mIFJG QzMzMTEuDQpTbywgd2Ugc2hvbGQgbm90IHRyZWF0IGFsbCBVUERBVEVzIGR1cmluZyBSZS1JTlZJ VEUgYXMgUmUtSU5WSVRFJ3Mgc3ViLXRyYW5zYWN0aW9uLjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCldoaWxlIFVQREFURS8yMDBPSyBqdXN0IHJlZnJlc2ggJnF1b3Q7cHJlY29uZGl0 aW9uIHN0YXRlIHRhYmxlJnF1b3Q7IGluDQpSRkMzMzEyKCZxdW90O3ByZWNvbmRpdGlvbiBzdGF0 ZSB0YWJsZSZxdW90OyBpcyBtb2RpZmllZCBhdCBvbmNlLCBzbyB0aGlzDQpvYmV5cyBSRkMzMzEy KSwgaGF2aW5nIG5vIGltcGF0IG9uIHRoZSBjb21taXRtZW50IG9mIG1vZGlmaWNhdGlvbiB0cmln Z2VyZWQNCmJ5IFJlLUlOVklURSwgdGhlc2UgVVBEQVRFLzIwME9LIGNhbiBiZSB0cmVhdGVkIGFz IHN1Yi10cmFuc2FjdGlvbiBvZiBSZS1JTlZJVEUuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K T3RoZXIgVVBEQVRFLzIwME9LIGNhbiBub3QgYmUgdHJlYXRlZCBhcyBzdWItdHJhbnNhY3Rpb24g b2YgUmUtSU5WSVRFLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N Cjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPjxicj4NCkNvbW1lbnRz L2ZlZWxpbmcgYXJlIHdlbGNvbWUhPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+WlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlz IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLg0KVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQNCnRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzDQpjb21tdW5pY2F0aW9uIHRvIG90aGVycy48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQNCndpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsDQpvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4NCmVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFu eSB2aWV3cyBleHByZXNzZWQNCmluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PlRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzDQphbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIHN5c3RlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 0001BD4F48257576_=-- From gao.yang2@zte.com.cn Tue Mar 10 17:33:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EEEA3A68AE; Tue, 10 Mar 2009 17:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.516 X-Spam-Level: X-Spam-Status: No, score=-89.516 tagged_above=-999 required=5 tests=[AWL=-1.315, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnUFwdqSKHAM; Tue, 10 Mar 2009 17:33:45 -0700 (PDT) Received: from mail.zte.com.cn (unknown [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id A79AE3A67C1; Tue, 10 Mar 2009 17:33:43 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.6843256625; Wed, 11 Mar 2009 08:57:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2B0YC6N031900; Wed, 11 Mar 2009 08:34:12 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A10B4A04FBD@mbx02.citservers.local> From: gao.yang2@zte.com.cn To: Brett Tate MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Wed, 11 Mar 2009 08:34:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-11 08:34:10, Serialize complete at 2009-03-11 08:34:10 Content-Type: multipart/alternative; boundary="=_alternative 00031F9E48257576_=" X-MAIL: mse1.zte.com.cn n2B0YC6N031900 Cc: SIP , SIPPING , sip-bounces@ietf.org, Christer Holmberg Subject: [Sip] =?gb2312?b?tPC4tDogUmU6ICAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUi?= =?gb2312?b?IGRpc2N1c3Npb24=?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 00:33:46 -0000 This is a multipart message in MIME format. --=_alternative 00031F9E48257576_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWxzbyBjb25zaWRlciBVUERBVEUvMjAwT0sgYXMgYXRvbWljIHRyYW5zYWN0aW9u LiBBbmQgSSB0aGluayBVUERBVEUncyANCmF0b21pY2l0eSBoYXMgbm8gY29uZmxpY3Qgd2l0aCBS ZS1JTlZJVEUncyBhdG9taWNpdHkgaW4gY3VycmVudCBSRkNzLiANCg0KQXMgd2Uga25vdywgYXRv bWljaXR5J3Mgc2VtYW50aWNzIGlzICJhbGwgb3Igbm90aGluZyIuICBBbmQgaWYgbmV3IA0KbW9k aWZpY2F0aW9uIGlzIGFjY2VwdHRlZCwgdGhlIG9sZGVyIHBlbmRpbmcgb25lIHdvdWxkIGJlIGRp c2NhcmRlZCh0aGF0IA0KaXMgdGhlIHNlbWFudGljcyBvZiAibm90aGluZyIpLiBUaGVuLCBVUERB VEUncyBhdG9taWNpdHkgaGFzIG5vIGNvbmZsaWN0IA0Kd2l0aCBSZS1JTlZJVEUncyBhdG9taWNp dHkuDQoNCk9uZSBzcGVjaWFsIHRoaW5nIGlzIHByZWNvbmRpdGlvbjoNCkZpcnN0LCB3ZSBzaG91 bGQgbWFrZSBzdXJlIHRoZSBlZmZlY3Qgb2YgdGhlIGxhdGVyIE9mZmVyL0Fuc3dlciBwYWlycw0K ICAgd2hpY2ggYXJlIHVzZWQgYXMgInJlZnJlc2hpbmcgdGhlIHByZWNvbmR0aW9uIHN0YXRlIHRh YmxlIiBkdXJpbmcNCiAgIHN1c3BlbmRpbmcgc3RhdGUgb2Ygc2Vzc2lvbi4gIEJ5IFJGQzMzMTIs IHRoZXNlIE9mZmVyL0Fuc3dlciBwYWlycw0KICAganVzdCByZWZyZXNoIHRoZSBwcmVjb25kdGlv biBzdGF0ZSB0YWJsZSwgYnV0IGl0IGhhcyBubyBpbXBhY3Qgb24gdGhlDQogICBjb21taXRtZW50 IG9mIHRoZSBtb2RpZmljYXRpb24uDQoNCiAgIFRoZW4sIGFzIHRoZSBVQXMgaGFzIGFkanVzdGVk IHRoZSBzZXNzaW9uIHBhcmFtZXRlcnMocmVmcmVzaCB0aGUNCiAgIHByZWNvbmR0aW9uIHN0YXRl IHRhYmxlKSBhY2NvcmRpbmdseSwgaXQgb2JleXMgUkZDMzMxMS4NCg0KICAgQW5kIGFzIGN1cnJl bnQgcGVuZGluZyBzZXNzaW9uIG1vZGlmaWNhdGlvbiBpcyBzdGlsbCB0aGUgb25lDQogICB0cmln Z2VyZWQgYnkgUmUtSU5WSVRFLCBhbmQgaXQgaXMgb25seSBkaXNjYXJkZWQgZm9yIHRoZSBmYWls dXJlIG9mIFJlLQ0KICAgSU5WSVRFLCBub3QgYnkgInJlZnJlc2hpbmcgdGhlIHByZWNvbmR0aW9u IHN0YXRlIHRhYmxlIi4gIFRoaXMgb2JleXMgDQpSRkMzMjYxLg0KDQpHYW8NCg0KDQoNCg0KQnJl dHQgVGF0ZSA8YnJldHRAYnJvYWRzb2Z0LmNvbT4gDQq3orz+yMs6ICBzaXAtYm91bmNlc0BpZXRm Lm9yZw0KMjAwOS0wMy0xMSAwMjowOA0KDQrK1bz+yMsNCkNocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+LCBTSVBQSU5HIA0KPHNpcHBpbmdAaWV0Zi5vcmc+ LCBTSVAgPHNpcEBpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KUmU6IFtTaXBdICJVUERBVEUgZHVy aW5nIFJlLUlOVklURSIgZGlzY3Vzc2lvbg0KDQoNCg0KDQoNCg0KPj4+IFJlZ2FyZGluZyB5b3Vy IHNlY29uZCBidWxsZXQsIEkgZG9uJ3QgZXZlbiB0aGluayB0aGF0IG9uZSANCj4+PiBzaG91bGQg c2VuZCAibmVzdGVkIiBVUERBVEVzLCBpZiB0aGV5IGRvbid0IGhhdmUgYW55dGhpbmcgDQo+Pj4g dG8gZG8gd2l0aCB0aGUgcmUtSU5WSVRFLiBJIHRoaW5rIHRoYXQgaXMgYmFkIGFwcGxpY2F0aW9u IA0KPj4+IGRlc2lnbi4gIE5vbi1yZWxhdGVkIGNoYW5nZXMgc2hvdWxkIGJlIGRvbmUgb3V0c2lk ZSB0aGUgDQo+Pj4gcmUtSU5WSVRFIHRyYW5zYWN0aW9uLg0KPj4NCj4+IFNlbmRpbmcgVVBEQVRF IHBlciBSRkMgNDAyOCB0byByZWZyZXNoIG9yIGF1ZGl0IHRoZSBkaWFsb2cNCj4+IGlzIG9uZSBv ZiB0aGUgdGltZXMgVVBEQVRFIG1heSBiZSB0cmllZCB3aGlsZSBhIHJlLUlOVklURSBpcw0KPj4g b2NjdXJyaW5nLg0KPiANCj4gVHJ1ZSwgYnV0IG5vcm1hbGx5IHRob3NlIFVQREFURXMgYXJlIG5v dCBnb2luZyB0byBtb2RpZnkgc2Vzc2lvbg0KPiBwYXJhbWV0ZXJzLg0KPg0KPiBTbywgeWVzLCBp dCBtYXkgaGFwcGVuLCBidXQgSSB0aGluayB3ZSBzaG91bGQgcmVjb21tZW5kIA0KPiBhZ2FpbnN0 IGRvaW5nIHNvLg0KDQpUaGVyZSBhcmUgdHdvIGtleSBwaHJhc2VzIHdpdGhpbiByZmMzMjYxIHdo aWNoIG1pZ2h0IGJlIGFkZGluZyB0byB0aGUgDQpjb25mdXNpb246ICJzZXNzaW9uIHBhcmFtZXRl cnMiIGFuZCAic3RhdGUgY2hhbmdlcyIuICBSRkMgMzI2MSBzZWN0aW9uIA0KMTIuMi4yIGFuZCAx NC4xIGJhc2ljYWxseSBpbmRpY2F0ZSB0byByb2xsYmFjayBhcyB0aG91Z2ggdGhlIHJlLUlOVklU RSB3YXMgDQpub3Qgc2VudC4gIFRoZXJlIGhhdmUgYmVlbiBudW1lcm91cyBwcm9wb3NhbCBjb25j ZXJuaW5nIHdoYXQgc2hvdWxkIGFuZCANCnNob3VsZG4ndCByb2xsYmFjazsgaXQgaXMgb2NjYXNp b25hbCBoYXJkIHRvIGRpc3Rpbmd1aXNoIGlmIHBlb3BsZSBtZWFuIDEpIA0KU0RQIDIpIG5vbiBT RFAgc3RhdGUgZGF0YSAobGlrZSBDb250YWN0LCBTZXNzaW9uLUV4cGlyZXMsIC4uLiksIG9yIDMp IA0KYm90aC4gDQoNCkkgYWdyZWUgdGhhdCBVUERBVEUgbGlrZWx5IHdvdWxkbid0IGluY2x1ZGUg U0RQIHdoZW4gb25seSBhdHRlbXB0aW5nIHRvIA0KcmVmcmVzaCBvciBhdWRpdCB0aGUgc2Vzc2lv bjsgaG93ZXZlciBpdCBjYW4uDQoNCkkgdGhpbmsgMTIuMi4yIGlzIHN1ZmZpY2llbnRseSBjbGVh ciBjb25jZXJuaW5nIHdoYXQgc2hvdWxkIG9jY3VyIHVwb24gDQpyZS1JTlZJVEUgZmFpbHVyZTsg aG93ZXZlciBJIHRoaW5rIGl0IHdhcyB1bmZvcnR1bmF0ZSB0aGF0IHNlY3Rpb24gMTQuMSANCmlu ZGljYXRlZCAic2Vzc2lvbiBwYXJhbWV0ZXJzIiBpbnN0ZWFkIG9mICJzdGF0ZSBjaGFuZ2VzIi4N Cg0KUkZDIDMyNjEgc2VjdGlvbiAxMi4yLjI6ICJSZXF1ZXN0cyBzZW50IHdpdGhpbiBhIGRpYWxv ZywgYXMgYW55IG90aGVyIA0KcmVxdWVzdHMsIGFyZSBhdG9taWMuICBJZiBhIHBhcnRpY3VsYXIg cmVxdWVzdCBpcyBhY2NlcHRlZCBieSB0aGUgVUFTLCBhbGwgDQp0aGUgc3RhdGUgY2hhbmdlcyBh c3NvY2lhdGVkIHdpdGggaXQgYXJlIHBlcmZvcm1lZC4gIElmIHRoZSByZXF1ZXN0IGlzIA0KcmVq ZWN0ZWQsIG5vbmUgb2YgdGhlIHN0YXRlIGNoYW5nZXMgYXJlIHBlcmZvcm1lZC4iDQoNCkNvbmNl cm5pbmcgVVBEQVRFIGluIHJlbGF0aW9uIHRvIHNlY3Rpb24gMTIuMi4yLCBJIGNvbnNpZGVyIGl0 IGFuIGF0b21pYyANCnRyYW5zYWN0aW9uLiAgQW5kIGZvciBpdCBpcyB3b3J0aCwgSSBjb25zaWRl ciBQUkFDSyB0byBub3QgYmUgYW4gYXRvbWljIA0KdHJhbnNhY3Rpb24uDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaXAgbWFpbGluZyBsaXN0ICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcA0KVGhpcyBsaXN0IGlzIGZv ciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQpVc2Ugc2lwLWltcGxl bWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KVXNl IHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9u IG9mIHNpcA0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRo ZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZp ZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWlu IHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBv ZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVz IHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJl IGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVh c2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVz c2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0K VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRF IEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00031F9E48257576_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTI+PHR0PkkgYWxzbyBjb25zaWRlciBVUERBVEUvMjAwT0sgYXMgYXRvbWlj IHRyYW5zYWN0aW9uLg0KQW5kIEkgdGhpbmsgPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlVQREFURSdzIGF0b21pY2l0eQ0KaGFzIG5vIGNvbmZsaWN0IHdpdGggUmUt SU5WSVRFJ3MgYXRvbWljaXR5IGluIGN1cnJlbnQgUkZDcy4gPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BcyB3ZSBrbm93LCBhdG9taWNpdHkncyBzZW1h bnRpY3MgaXMNCiZxdW90O2FsbCBvciBub3RoaW5nJnF1b3Q7LiAmbmJzcDtBbmQgPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPmlmDQpuZXcgbW9kaWZpY2F0 aW9uIGlzIGFjY2VwdHRlZCwgdGhlIG9sZGVyIHBlbmRpbmcgb25lIHdvdWxkIGJlIGRpc2NhcmRl ZDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KHRoYXQNCmlzIHRoZSBzZW1h bnRpY3Mgb2YgJnF1b3Q7bm90aGluZyZxdW90OykuIFRoZW4sIFVQREFURSdzIGF0b21pY2l0eSBo YXMNCm5vIGNvbmZsaWN0IHdpdGggUmUtSU5WSVRFJ3MgYXRvbWljaXR5LjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+T25lIHNwZWNpYWwgdGhpbmcgaXMg cHJlY29uZGl0aW9uOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Rmlyc3QsIHdlIHNob3VsZCBtYWtlIHN1cmUgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPnRoZQ0KZWZmZWN0IG9mIHRoZSBsYXRlciBPZmZlci9BbnN3ZXIg cGFpcnM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwO3doaWNoIGFyZSB1c2VkDQphcyAmcXVvdDtyZWZyZXNoaW5nIHRoZSBw cmVjb25kdGlvbiBzdGF0ZSB0YWJsZSZxdW90OyBkdXJpbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3N1c3BlbmRpbmcg c3RhdGUNCm9mIHNlc3Npb248L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi4g Jm5ic3A7QnkgUkZDMzMxMiwgdGhlc2UNCk9mZmVyL0Fuc3dlciBwYWlyczwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2p1c3QgcmVmcmVzaCB0 aGUgcHJlY29uZHRpb24NCnN0YXRlIHRhYmxlLCBidXQgaXQgaGFzIG5vIGltcGFjdCBvbiB0aGU8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtj b21taXRtZW50IG9mIHRoZSBtb2RpZmljYXRpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7VGhlbiwgPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPmFzDQp0aGUgVUFzIGhhcyBhZGp1c3Rl ZCB0aGUgc2Vzc2lvbiBwYXJhbWV0ZXJzKHJlZnJlc2ggdGhlPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtwcmVjb25kdGlv bg0Kc3RhdGUgdGFibGUpIGFjY29yZGluZ2x5LCBpdCBvYmV5cyBSRkMzMzExPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QW5kIGFzIGN1cnJlbnQgcGVuZGluZw0K c2Vzc2lvbiBtb2RpZmljYXRpb24gaXMgc3RpbGwgdGhlIG9uZTwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3RyaWdnZXJlZCBieSBSZS1JTlZJ VEUsDQphbmQgaXQgaXMgb25seSBkaXNjYXJkZWQgZm9yIHRoZSBmYWlsdXJlIG9mIFJlLTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0lOVklU RSwgbm90IGJ5IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij4mcXVvdDtyZWZyZXNoaW5nDQp0aGUgcHJlY29uZHRpb24gc3RhdGUgdGFibGUmcXVvdDs8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi4NCiZuYnNwO1RoaXMgb2JleXMgUkZD MzI2MS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdh bzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj5CcmV0dCBUYXRlICZsdDticmV0dEBicm9hZHNvZnQuY29tJmd0OzwvYj4NCjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXAtYm91 bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDA5LTAzLTExIDAyOjA4PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPkNocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20mZ3Q7LA0KU0lQUElORyAmbHQ7c2lwcGluZ0BpZXRmLm9yZyZndDssIFNJUCAm bHQ7c2lwQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rp dj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtTaXBdICZxdW90O1VQREFURSBkdXJpbmcgUmUtSU5W SVRFJnF1b3Q7DQpkaXNjdXNzaW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7Jmd0OyZndDsgUmVnYXJkaW5nIHlvdXIgc2Vjb25k IGJ1bGxldCwgSSBkb24ndA0KZXZlbiB0aGluayB0aGF0IG9uZSA8YnI+DQomZ3Q7Jmd0OyZndDsg c2hvdWxkIHNlbmQgJnF1b3Q7bmVzdGVkJnF1b3Q7Jm5ic3A7VVBEQVRFcywgaWYgdGhleSBkb24n dA0KaGF2ZSBhbnl0aGluZyA8YnI+DQomZ3Q7Jmd0OyZndDsgdG8gZG8gd2l0aCB0aGUgcmUtSU5W SVRFLiBJIHRoaW5rIHRoYXQgaXMgYmFkIGFwcGxpY2F0aW9uDQo8YnI+DQomZ3Q7Jmd0OyZndDsg ZGVzaWduLiAmbmJzcDtOb24tcmVsYXRlZCBjaGFuZ2VzIHNob3VsZCBiZSBkb25lIG91dHNpZGUg dGhlDQo8YnI+DQomZ3Q7Jmd0OyZndDsgcmUtSU5WSVRFIHRyYW5zYWN0aW9uLjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgU2VuZGluZyBVUERBVEUgcGVyIFJGQyA0MDI4IHRvIHJlZnJlc2gg b3IgYXVkaXQgdGhlIGRpYWxvZzxicj4NCiZndDsmZ3Q7IGlzIG9uZSBvZiB0aGUgdGltZXMgVVBE QVRFIG1heSBiZSB0cmllZCB3aGlsZSBhIHJlLUlOVklURSBpczxicj4NCiZndDsmZ3Q7IG9jY3Vy cmluZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgVHJ1ZSwgYnV0IG5vcm1hbGx5IHRob3NlIFVQREFU RXMgYXJlIG5vdCBnb2luZyB0byBtb2RpZnkgc2Vzc2lvbjxicj4NCiZndDsgcGFyYW1ldGVycy48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBTbywgeWVzLCBpdCBtYXkgaGFwcGVuLCBidXQgSSB0aGluayB3 ZSBzaG91bGQgcmVjb21tZW5kIDxicj4NCiZndDsgYWdhaW5zdCBkb2luZyBzby48YnI+DQo8YnI+ DQpUaGVyZSBhcmUgdHdvIGtleSBwaHJhc2VzIHdpdGhpbiByZmMzMjYxIHdoaWNoIG1pZ2h0IGJl IGFkZGluZyB0byB0aGUgY29uZnVzaW9uOg0KJnF1b3Q7c2Vzc2lvbiBwYXJhbWV0ZXJzJnF1b3Q7 IGFuZCAmcXVvdDtzdGF0ZSBjaGFuZ2VzJnF1b3Q7LiAmbmJzcDtSRkMNCjMyNjEgc2VjdGlvbiAx Mi4yLjIgYW5kIDE0LjEgYmFzaWNhbGx5IGluZGljYXRlIHRvIHJvbGxiYWNrIGFzIHRob3VnaCB0 aGUNCnJlLUlOVklURSB3YXMgbm90IHNlbnQuICZuYnNwO1RoZXJlIGhhdmUgYmVlbiBudW1lcm91 cyBwcm9wb3NhbCBjb25jZXJuaW5nDQp3aGF0IHNob3VsZCBhbmQgc2hvdWxkbid0IHJvbGxiYWNr OyBpdCBpcyBvY2Nhc2lvbmFsIGhhcmQgdG8gZGlzdGluZ3Vpc2gNCmlmIHBlb3BsZSBtZWFuIDEp IFNEUCAyKSBub24gU0RQIHN0YXRlIGRhdGEgKGxpa2UgQ29udGFjdCwgU2Vzc2lvbi1FeHBpcmVz LA0KLi4uKSwgb3IgMykgYm90aC4gJm5ic3A7PGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IFVQREFU RSBsaWtlbHkgd291bGRuJ3QgaW5jbHVkZSBTRFAgd2hlbiBvbmx5IGF0dGVtcHRpbmcgdG8NCnJl ZnJlc2ggb3IgYXVkaXQgdGhlIHNlc3Npb247IGhvd2V2ZXIgaXQgY2FuLjxicj4NCjxicj4NCkkg dGhpbmsgMTIuMi4yIGlzIHN1ZmZpY2llbnRseSBjbGVhciBjb25jZXJuaW5nIHdoYXQgc2hvdWxk IG9jY3VyIHVwb24NCnJlLUlOVklURSBmYWlsdXJlOyBob3dldmVyIEkgdGhpbmsgaXQgd2FzIHVu Zm9ydHVuYXRlIHRoYXQgc2VjdGlvbiAxNC4xDQppbmRpY2F0ZWQgJnF1b3Q7c2Vzc2lvbiBwYXJh bWV0ZXJzJnF1b3Q7IGluc3RlYWQgb2YgJnF1b3Q7c3RhdGUgY2hhbmdlcyZxdW90Oy48YnI+DQo8 YnI+DQpSRkMgMzI2MSBzZWN0aW9uIDEyLjIuMjogJnF1b3Q7UmVxdWVzdHMgc2VudCB3aXRoaW4g YSBkaWFsb2csIGFzIGFueSBvdGhlcg0KcmVxdWVzdHMsIGFyZSBhdG9taWMuICZuYnNwO0lmIGEg cGFydGljdWxhciByZXF1ZXN0IGlzIGFjY2VwdGVkIGJ5IHRoZQ0KVUFTLCBhbGwgdGhlIHN0YXRl IGNoYW5nZXMgYXNzb2NpYXRlZCB3aXRoIGl0IGFyZSBwZXJmb3JtZWQuICZuYnNwO0lmIHRoZQ0K cmVxdWVzdCBpcyByZWplY3RlZCwgbm9uZSBvZiB0aGUgc3RhdGUgY2hhbmdlcyBhcmUgcGVyZm9y bWVkLiZxdW90Ozxicj4NCjxicj4NCkNvbmNlcm5pbmcgVVBEQVRFIGluIHJlbGF0aW9uIHRvIHNl Y3Rpb24gMTIuMi4yLCBJIGNvbnNpZGVyIGl0IGFuIGF0b21pYw0KdHJhbnNhY3Rpb24uICZuYnNw O0FuZCBmb3IgaXQgaXMgd29ydGgsIEkgY29uc2lkZXIgUFJBQ0sgdG8gbm90IGJlIGFuIGF0b21p Yw0KdHJhbnNhY3Rpb24uPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpTaXAgbWFpbGluZyBsaXN0ICZuYnNwO2h0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwPGJyPg0KVGhpcyBsaXN0IGlzIGZvciBORVcg ZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sPGJyPg0KVXNlIHNpcC1pbXBsZW1l bnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXA8YnI+DQpV c2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRp b24gb2Ygc2lwPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 00031F9E48257576_=-- From dean.willis@softarmor.com Tue Mar 10 21:18:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41CA23A68D5 for ; Tue, 10 Mar 2009 21:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2OE6g4wu80M for ; Tue, 10 Mar 2009 21:18:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 62B1B3A6838 for ; Tue, 10 Mar 2009 21:18:27 -0700 (PDT) Received: from [192.168.2.104] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2B4IY2I027540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Mar 2009 23:18:42 -0500 Message-Id: <31F87DA3-7AD0-44E7-BED2-D890ABBE894A@softarmor.com> From: Dean Willis To: SIP IETF Content-Type: multipart/alternative; boundary=Apple-Mail-1-739871689 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 23:18:29 -0500 X-Mailer: Apple Mail (2.930.3) Cc: Cullen Jennings , Keith Drage , Mary Barnes , Gonzalo Camarillo Subject: [Sip] Agenda posted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 04:18:29 -0000 --Apple-Mail-1-739871689 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit A SIP agenda for IETF 74 has been posted at: http://www.ietf.org/proceedings/09mar/agenda/sip.html The WIKI version remains active at: http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_74 Note that we're trying out the SIPCORE/DISPATCH split. The Tuesday session will run as SIPCORE and start with an intro, but no discussion of, the new model. The Wednesday session will run as DISPATCH. This may be something of a gong show. Ongoing SIP and SIPPING work that is not clearly in the draft charters of SIPCORE or DISPATCH will be handled in the Friday morning SIPPING session. We will also discuss the new work model and RFC3274bis in the Friday session. Here's an mhtml version of the agenda for you folks (like cullen) who really want it in email. Note that it includes on the reading list a bunch of drafts that we haven't allocated time to; the inclusion is so you folks can see where those drafts might go in the new model. Draft Agenda for SIP at IETF 74 -- SIPCORE Session Victim Topic Drafts Time Jon Peterson SIP Change Process Intro (Discussion on Friday) draft-peterson-rai-rfc3427bis-01 20 Christer Holmberg Early Dialog termination draft-ietf-sip-199-06 20 Robert Sparks 3261 Interop Statement draft-sparks-sip-3261-interop- statement-00 15 Robert Sparks 3261 Normative References draft-sparks-sip-3261-norm-ref- status-00 15 Robert Sparks Fix INVITE transaction draft-sparks-sip-invfix-03 15 Mary Barnes RFC 4244bis draft-barnes-sip-rfc4244bis-00 20 Placeholder No Agenda Time draft-ietf-sip-ipv6-abnf-fix-03 draft-rosenberg-sip-target-uri-delivery-00 0 Draft Agenda for SIP at IETF 74 -- DISPATCH Victim Topic Drafts Time Theo Zourzouvillys Via Cookies draft-zourzouvillys-sip-via-cookie-02 15 Christer Holmberg Keepalive Without Outbound draft-holmberg-sip- keep-03 15 Hadriel Kaplan Secure Call ID draft-kaplan-sip-secure-call-id-00 15 Hadriel Kaplan Session ID draft-kaplan-sip-session-id-01 15 Alan Johnston Batch NOTIFYs draft-johnston-sipping-batch-notify-00 10 Alan Johnston User to User for ISDN draft-johnston-sipping-cc-uui-07 10 Salvatore Loreto Context-ID Requirements draft-loreto-sipping-context- id-requirements 10 Salvatore Loreto Changes to Referred-By draft-loreto- sipping-3892bis-01 10 Hadriel Kaplan Updates to the Updates to Asserted Identity in SIP draft-kaplan-sipping-pai-responses-00 10 Raphael Coeffic Radu State Digest Relay Attack draft-state-sip-relay-attack-00 10 Placeholder Agenda Time Not Requested draft-avasarala-sipping-reason- header-dynamic-icb-00 draft-boucadair-sipping-ipv6-atypes-00 draft-gurbani-sipping-clf-00 draft-niccolini-sipping-siphandover-05 draft-rosenberg-sip-app-media-tag-02 draft-kuthan-sip-derive-00 draft-polk-geopriv-sip-lo-retrans-rec-concerns-00 draft-roach-sip-http-subscribe-01 draft-rosenberg-sip-tote-02 draft-york-sip-visual-identifier-trusted-identity-01 0 Draft Agenda for SIP at IETF 74 -- SIP/SIPPING Continuing Work Victim Topic Drafts Time Gonzalo Camarillo Re-INVITE Handling in SIP & Media State under Preconditions in SIP draft-camarillo-sipping-reinvite-00 draft-camarillo-sipping-precons-00 15 Christer Holmberg Re-Invite Fallback (based on ML discussion) draft- ietf-sipping-sip-offeranswer-10 15 Eric Burger Info Events draft-ietf-sip-info-events-03 15 Hadriel Kaplan Identity draft-elwell-sip-e2e-identity-important-03 30 Dale Worley Profile Datasets draft-ietf-sipping-profile-datasets-02 15 Volker Hilt SIP Overload Control draft-ietf-sipping-overload-design-02 15 Salvatore Loreto Event Throttling draft-niemi-sipping-event- throttle-08 15 Jon Peterson SIP Change Process Intro (Discussion on Friday) draft- peterson-rai-rfc3427bis-01 30 Placeholder No Agenda Time draft-ietf-sip-outbound-16 draft-ietf-sip-connect-reuse-12 draft-ietf-sipping-sip-offeranswer-10 draft-ietf-sip-certs-07 draft-ietf-sip-dtls-srtp-framework-06 draft-ietf-sip-session-policy-framework-05 draft-ietf-sip-xcapevent-04 draft-ietf-sip-location-conveyance-12 draft-ietf-sip-body-handling-05 draft-ietf-sip-domain-certs-02 draft-ietf-sip-eku-03 draft-ietf-sip-record-route-fix-05 draft-ietf-sip-saml-05 draft-ietf-sip-ua-privacy-05 draft-rosenberg-sip-info-litmus-02 draft-ietf-sip-ua-privacy-06 0 --Apple-Mail-1-739871689 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

A SIP = agenda for IETF 74 has been posted at:


Th= e WIKI version remains active at:

Note that we're trying out the SIPCORE/DISPATCH = split.

The Tuesday session will run as SIPCORE = and start with an intro, but no discussion of, the new = model. 

The Wednesday session will run as = DISPATCH.  This may be something of a gong = show.

Ongoing SIP and SIPPING work that is not = clearly in the draft charters of SIPCORE or DISPATCH will be handled in = the Friday morning SIPPING session. We will also discuss the new work = model and RFC3274bis in the Friday = session.

Here's an mhtml version of the agenda = for you folks (like cullen) who really want it in email. Note that it = includes on the reading list a bunch of drafts that we haven't allocated = time to; the inclusion is so you folks can see where those drafts might = go in the new = model.



RFC 4244bis<= th>Time
Draft Agenda for SIP at = IETF 74 -- = DISPATCH
VictimTopicDrafts
Theo ZourzouvillysVia = Cookies
Draft Agenda for SIP at IETF 74 -- = SIP/SIPPING Continuing = Work
VictimTopicDraftsT= ime
Gonzalo CamarilloRe-INVITE Handling in SIP = & Media State under Preconditions in SIPdraft-ietf-sip-certs-07
draft-ietf-sip-eku-03
draft-ietf-sip-saml-05
'. The Content- Length in the same message is also invalid. Please replace line 230, which is currently: Content-Length: 617 with: Content-Length: 619 Please replace line 250, which is currently: From shida@ntt-at.com Tue Mar 10 23:12:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825EB3A68B2 for ; Tue, 10 Mar 2009 23:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kliTVoiMhCbs for ; Tue, 10 Mar 2009 23:12:54 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.56.195.29]) by core3.amsl.com (Postfix) with SMTP id C8EE63A6767 for ; Tue, 10 Mar 2009 23:12:53 -0700 (PDT) Received: (qmail 6059 invoked from network); 11 Mar 2009 06:32:02 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway05.websitewelcome.com with SMTP; 11 Mar 2009 06:32:02 -0000 Received: from flh1ahc140.tky.mesh.ad.jp ([125.192.94.140]:55808 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LhHh1-00019n-3Q; Wed, 11 Mar 2009 01:13:27 -0500 Message-Id: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> From: Shida Schubert To: "sip@ietf.org List" Content-Type: multipart/alternative; boundary=Apple-Mail-3-746768133 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 15:13:25 +0900 X-Mailer: Apple Mail (2.930.3) 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 Cc: Mary Barnes Subject: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 06:12:55 -0000 --Apple-Mail-3-746768133 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit We have submitted the updated target-uri draft based on the comments submitted to the list and comments received at IETF73. I have taken over as editor as Jonathan didn't have the cycles to update the draft, with Francois, Christer and Hans Erick as additional co-authors and great deal of help from Mary. The following summarizes the changes made to the target-uri document 1. Added use-case for toll-free number back 2. Added definition of "retarget" operation. 3. Removed a reference to URN 4. Added a text discussing the difference to P-Called-Party-Id 5. Changed parameter name from "target" to "istarget" Note, that the target-uri document still contains the normative text for the History-Info header. In addition, Mary (with Francois as co-author) has submitted a rfc4244bis, with the following changes: 1. Incorporated the normative aspects of the target-uri document into the existing normative text in RFC 4244 - the functionality is virtually identical (as is some of the text) as the HI based solution described in the target-uri document. It's important that the solution be integrated into RFC 4244 as it MUST work and be based on the normative aspects of RFC 4244. 2. Added the use cases from target-uri the the summary in the overview of rfc4244bis. 3. Added an additional requirement to capture the "target-uri" information. 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. 5. Added a more simplified example. We had some very long offline exchanges as to the best way forward and remaining work for both documents. Some of the issues identified are: ::Issues:: 1. Should we remove the normative text from target-uri and progress 4244bis along with the target-uri document to meet the chartered SIP WG milestone? 2. Name of the parameter. At the last meeting, parameter "target" was said inappropriate because voicemail-uri spec already defines a parameter called "target" which also can be found in hi-entry, thus potentially causing confusion. Currently the target-uri draft uses "istarget" and 4244bis uses "retarget" but we could never come to a consensus on what name is appropriate. Other suggestions have included the following: "target-identity" (someone didn't like that "identity" is also a SIP header) "reg-uri" (can be paired with "mapped-uri" for item 3 below) "aor" "jibberish" etc. One reason this is so difficult relates to the problem statement in target-uri in that RFC 3261 doesn't differentiate the mechanism by which the new (target) Request-URI is selected. Another issue is that some of the terminology in RFC 3261 is overloaded - e.g., "forwarding" refers both to a Proxy which does not have responsibility for the domain of the request-URI in the incoming request, thus the proxy just "forwards" the request to the next hop AND "forwarding" is used to describe the process whereby the outgoing request is built and "forwarded" to the next hop at which point the proxy does not know how the new request-uri was selected. RFC 4244 has attempted to clarify the terms and attempts to use "forward" in the context of the former situation and "retarget" for the case whereby a proxy is responsible for the domain and thus can use a number of mechanism to select the new target for the request - e.g., a REGISTRAR, configured data, etc. 3. Related to the last point in item 2 above, it has been proposed that we differentiate the hi-entries even more by defining separate parameters for registered and configured/mapped contacts. Currently when the R-URI is translated to a URI which is either derived from location service lookup(registered by UA) or from mapping table, there is no differentiation as to how the URI was derived once it is added to the list of potential targets. The general consensus of the authors of the two documents was that it may be useful for some services to have the hi-entries tagged with the more specific information. And, of course, this gets us into another naming contest. In the end, the naming is not so important as long as the term isn't too overloaded and it is defined precisely in the document(s). We would appreciate WG feedback on these issues and any other comments on the two documents prior to IETF-74. Regards, Shida and Mary. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 10, 2009 2:30:01 AM JST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Delivery of Request-URI Targets to User Agents > Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. > Schubert > Filename : draft-rosenberg-sip-target-uri-delivery-01.txt > Pages : 16 > Date : 2009-3-9 > > When a Session Initiation Protocol (SIP) proxy receives a request > targeted at a URI identifying a user or resource it is responsible > for, the proxy translates the URI to a registered or configured > contact URI of an agent representing that user or resource. In the > process, the original URI is removed from the request. Numerous use > cases have arisen which require this information to be delivered to > the user agent. This document describes these use cases and defines > an extension to the History-Info header field which allows it to be > used to support those cases. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-delivery-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. Content-Type: text/plain
Content-ID: <2009-3-9102756.I- D@ietf.org>

> _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-3-746768133 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

We have = submitted the updated target-uri draft based on the = comments 
submitted to the list and comments received at = IETF73. 

I have taken over as editor as = Jonathan didn't have the cycles to 
update the draft, = with Francois, Christer and Hans Erick as = additional 
co-authors and great deal of help from Mary. =  
 
The following summarizes the changes = made to the target-uri document
1. Added use-case for = toll-free number back
2. Added definition of "retarget" = operation. 
3. Removed a reference to URN
4. = Added a text discussing the difference to P-Called-Party-Id
5. = Changed parameter name from "target" to = "istarget"
 
Note, that the target-uri document = still contains the normative text for the
History-Info = header.
 
In addition, Mary (with Francois as = co-author) has submitted a
rfc4244bis, with the following = changes:
1. Incorporated the normative aspects of the = target-uri document
into the existing normative text in RFC = 4244 - the functionality is 
virtually identical (as is = some of the text) as the HI based solution 
described in = the target-uri document.  It's important that the = solution
be integrated into RFC 4244 as it MUST work and be = based on the normative
aspects of RFC 4244.
2. =  Added the use cases from target-uri the the summary
in = the overview of rfc4244bis.
3. Added an additional requirement = to capture the "target-uri" information.
4. Fixed an error in = the RFC 4244 ABNF and added "retarget" parameter.
5. Added a = more simplified example.
 
 
We = had some very long offline exchanges as to the best way forward = and
remaining work for both = documents.
 
Some of the issues identified = are:

::Issues::
   1. = Should we remove the normative text from target-uri and = progress
       4244bis along with the = target-uri document to meet the chartered
     =  SIP WG = milestone? 
 
 
   = 2. Name of the parameter. 
      At = the last meeting, parameter "target" was said = inappropriate 
      because = voicemail-uri spec already defines a parameter = called 
      "target" which also can = be found in hi-entry, thus potentially 
   =    causing confusion.
   =   
      Currently the = target-uri draft uses "istarget" and 4244bis uses
   =    "retarget"  but we could never come = to 
      a consensus on what name is = appropriate.  Other suggestions have
     =  included the following:
     =  "target-identity" (someone didn't like that "identity" is also a = SIP header)
      "reg-uri"  (can be = paired with "mapped-uri" for item 3 below)
     =  "aor"
     =  "jibberish" 
     =  etc.
 
      One = reason this is so difficult relates to the problem statement in = target-uri in that
      RFC 3261 doesn't = differentiate the mechanism by which the new
   =    (target) Request-URI is selected.  Another issue is = that some of the terminology in
      RFC = 3261 is overloaded - e.g., "forwarding" refers both to a = Proxy
      which does not have = responsibility for the domain of the request-URI
   =    in the incoming request, thus the proxy just "forwards" the = request to
      the next hop AND = "forwarding" is used to describe the process = whereby
      the outgoing request is = built and "forwarded" to the next hop at which
   =    point the proxy does not know how the new request-uri was = selected.
      RFC 4244 has attempted to = clarify the terms and attempts to use = "forward" 
      in the context of = the former situation and "retarget" for the case = whereby
      a proxy is responsible for = the domain and thus can use a number of 
   =    mechanism to select the new target for the request - e.g., = a REGISTRAR, 
      configured data, = etc.  

 3.  Related to the last = point in item 2 above, it has been proposed that
   =    we differentiate the hi-entries even more by defining = separate parameters
     for registered and = configured/mapped contacts. 
     = Currently when the R-URI is translated to a URI which is either = derived 
     from location service = lookup(registered by UA) or from mapping 
   =   table, there is no differentiation as to how the URI was derived = once it is
     added to the list of potential = targets.
     
   =   The general consensus of the authors of the two documents was = that it may 
     be useful for some = services to have the hi-entries tagged with the
   =   more specific = information. 
 
     And, = of course, this gets us into another naming contest. In the end, the = naming
     is not so important as long as the = term isn't too overloaded and it is defined
   =   precisely in the document(s).
 
We would = appreciate WG feedback on these issues and any other comments = on
the two documents prior to = IETF-74.
 
Regards,
Shida and = Mary.



Begin forwarded = message:
Date: March 10, 2009 2:30:01 AM JST
To: i-d-announce@ietf.org
Subject: I-D = ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt 

A New = Internet-Draft is available from the on-line = Internet-Drafts 
directories.


= Title = = : Delivery of Request-URI Targets to User Agents
= Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. = Schubert
= Filename = Pages = = : 16

When a Session Initiation = Protocol (SIP) proxy receives a request
  targeted at a URI = identifying a user or resource it is responsible
  for, the = proxy translates the URI to a registered or = configured
  contact URI of an agent representing that user = or resource.  In the
  process, the original URI is = removed from the request.  Numerous use
  cases have = arisen which require this information to be delivered = to
  the user agent.  This document describes these = use cases and defines
  an extension to the History-Info = header field which allows it to be
  used to support those = cases.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-= target-uri-delivery-01.txt

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

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
Content-Type: = text/plain<BR>Content-ID: &lt;2009-3-9102756.I-D@ietf.org&gt;<BR><BR>
= --Apple-Mail-3-746768133-- From dean.willis@softarmor.com Tue Mar 10 23:37:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA813A698F for ; Tue, 10 Mar 2009 23:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrQlbJhrKlUM for ; Tue, 10 Mar 2009 23:37:02 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3502B3A6767 for ; Tue, 10 Mar 2009 23:37:02 -0700 (PDT) Received: from [192.168.2.104] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2B6bZ0w028197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Mar 2009 01:37:37 -0500 Message-Id: <4CE1C789-127F-4495-A1C6-65EB3E2E9E54@softarmor.com> From: Dean Willis To: Shida Schubert In-Reply-To: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 01:37:30 -0500 References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> X-Mailer: Apple Mail (2.930.3) Cc: "sip@ietf.org List" , Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 06:37:03 -0000 On Mar 11, 2009, at 1:13 AM, Shida Schubert wrote: > > One reason this is so difficult relates to the problem > statement in target-uri in that > RFC 3261 doesn't differentiate the mechanism by which the new > (target) Request-URI is selected. Another issue is that some > of the terminology in > RFC 3261 is overloaded - e.g., "forwarding" refers both to a > Proxy > which does not have responsibility for the domain of the > request-URI > in the incoming request, thus the proxy just "forwards" the > request to > the next hop AND "forwarding" is used to describe the process > whereby > the outgoing request is built and "forwarded" to the next hop > at which > point the proxy does not know how the new request-uri was > selected. > RFC 4244 has attempted to clarify the terms and attempts to > use "forward" > in the context of the former situation and "retarget" for the > case whereby > a proxy is responsible for the domain and thus can use a > number of > mechanism to select the new target for the request - e.g., a > REGISTRAR, > configured data, etc. > Thanks, Shida. I personally would not be averse to an Essential Correction that corrects the terminology in RFC 3261, but I suspect that will make many heads spin around elsewhere in the WG. -- Dean From dwillis@peerance.com Tue Mar 10 23:49:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7377D3A6A1F for ; Tue, 10 Mar 2009 23:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTqVWhp+86m9 for ; Tue, 10 Mar 2009 23:49:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id DB4A93A6784 for ; Tue, 10 Mar 2009 23:49:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so2398724rvb.49 for ; Tue, 10 Mar 2009 23:49:39 -0700 (PDT) MIME-Version: 1.0 Sender: dwillis@peerance.com Received: by 10.140.161.11 with SMTP id j11mr4213496rve.114.1236754179469; Tue, 10 Mar 2009 23:49:39 -0700 (PDT) Date: Wed, 11 Mar 2009 01:49:39 -0500 X-Google-Sender-Auth: 51974e9bb4174dba Message-ID: <2210d2240903102349t585713aew476e307950b8868a@mail.gmail.com> From: Dean Willis To: sip@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2176c8ab2e70464d245f5 Subject: [Sip] Test, please ignore X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 06:51:54 -0000 --000e0cd2176c8ab2e70464d245f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've been having difficulties impersonating myself with my backup gmail account. Maybe this will work, maybe not. -- Dean --000e0cd2176c8ab2e70464d245f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I've been having difficulties impersonating myself with my backup gmail account. Maybe this will work, maybe not.

--
Dean
--000e0cd2176c8ab2e70464d245f5-- From HKaplan@acmepacket.com Tue Mar 10 23:54:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688333A6A6E for ; Tue, 10 Mar 2009 23:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45TzBL5CTppt for ; Tue, 10 Mar 2009 23:54:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F2D9F28C0F3 for ; Tue, 10 Mar 2009 23:54:53 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 02:55:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 11 Mar 2009 02:55:28 -0400 From: Hadriel Kaplan To: Shida Schubert , "sip@ietf.org List" Date: Wed, 11 Mar 2009 02:55:28 -0400 Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AAAnCqA Message-ID: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> In-Reply-To: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 06:54:55 -0000 At the risk of opening up a topic we have already agreed on, but in the spi= rit of open communication... [how's that for an opener!?] Are we absolutely sure we want to put this target-URI in the History-Info h= eader? I am not asking this because I think it's hard. I am asking because I am n= ot sure it will be used. Several of us from this same WG are involved in t= he SIP-Forum's SIP-Connect profile, and when faced with either using this n= ew History-Info mechanism for a target-uri delivery issue, vs. not, we chos= e not to. And we were mostly the same people who liked the idea of putting= it in History-Info in the IETF! (myself included) But I am concerned that= when given a reasonable opportunity to use a mechanism we ourselves promot= e when wearing a different hat, we chose not to use it in practice. It doe= sn't bode well. :( -hadriel p.s. sorry Mary for raising this, but there isn't much email traffic anyway= . :) ________________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Shida= Schubert Sent: Wednesday, March 11, 2009 2:13 AM To: sip@ietf.org List We have submitted the updated target-uri draft based on the comments=A0 submitted to the list and comments received at IETF73.=A0 I have taken over as editor as Jonathan didn't have the cycles to=A0 update the draft, with Francois, Christer and Hans Erick as additional=A0 co-authors and great deal of help from Mary. =A0 =A0 The following summarizes the changes made to the target-uri document 1. Added use-case for toll-free number back 2. Added definition of "retarget" operation.=A0 3. Removed a reference to URN 4. Added a text discussing the difference to P-Called-Party-Id 5. Changed parameter name from "target" to "istarget" =A0 Note, that the target-uri document still contains the normative text for th= e History-Info header. =A0 In addition, Mary (with Francois as co-author) has submitted a rfc4244bis, with the following changes: 1. Incorporated the normative aspects of the target-uri document into the existing normative text in RFC 4244 - the functionality is=A0 virtually identical (as is some of the text) as the HI based solution=A0 described in the target-uri document. =A0It's important that the solution be integrated into RFC 4244 as it MUST work and be based on the normative aspects of RFC 4244. 2. =A0Added the use cases from target-uri the the summary in the overview of rfc4244bis. 3. Added an additional requirement to capture the "target-uri" information. 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. 5. Added a more simplified example. =A0 =A0 We had some very long offline exchanges as to the best way forward and remaining work for both documents. =A0 Some of the issues identified are: ::Issues:: =A0=A0 1. Should we remove the normative text from target-uri and progress =A0=A0 =A0 =A0 4244bis along with the target-uri document to meet the chart= ered =A0=A0 =A0 =A0SIP WG milestone?=A0 =A0 =A0 =A0=A0 2. Name of the parameter.=A0 =A0=A0 =A0 =A0At the last meeting, parameter "target" was said inappropriat= e=A0 =A0=A0 =A0 =A0because voicemail-uri spec already defines a parameter called= =A0 =A0=A0 =A0 =A0"target" which also can be found in hi-entry, thus potentiall= y=A0 =A0=A0 =A0 =A0causing confusion. =A0=A0 =A0=A0 =A0=A0 =A0 =A0Currently the target-uri draft uses "istarget" and 4244bis us= es =A0=A0 =A0 =A0"retarget" =A0but we could never come to=A0 =A0=A0 =A0 =A0a consensus on what name is appropriate. =A0Other suggestions= have =A0=A0 =A0 =A0included the following: =A0=A0 =A0 =A0"target-identity" (someone didn't like that "identity" is als= o a SIP header) =A0=A0 =A0 =A0"reg-uri" =A0(can be paired with "mapped-uri" for item 3 belo= w) =A0=A0 =A0 =A0"aor" =A0=A0 =A0 =A0"jibberish"=A0 =A0=A0 =A0 =A0etc. =A0 =A0=A0 =A0 =A0One reason this is so difficult relates to the problem statem= ent in target-uri in that =A0=A0 =A0 =A0RFC 3261 doesn't differentiate the mechanism by which the new =A0=A0 =A0 =A0(target) Request-URI is selected. =A0Another issue is that so= me of the terminology in =A0=A0 =A0 =A0RFC 3261 is overloaded - e.g., "forwarding" refers both to a = Proxy =A0=A0 =A0 =A0which does not have responsibility for the domain of the requ= est-URI =A0=A0 =A0 =A0in the incoming request, thus the proxy just "forwards" the r= equest to =A0=A0 =A0 =A0the next hop AND "forwarding" is used to describe the process= whereby =A0=A0 =A0 =A0the outgoing request is built and "forwarded" to the next hop= at which =A0=A0 =A0 =A0point the proxy does not know how the new request-uri was sel= ected. =A0=A0 =A0 =A0RFC 4244 has attempted to clarify the terms and attempts to u= se "forward"=A0 =A0=A0 =A0 =A0in the context of the former situation and "retarget" for the= case whereby =A0=A0 =A0 =A0a proxy is responsible for the domain and thus can use a numb= er of=A0 =A0=A0 =A0 =A0mechanism to select the new target for the request - e.g., a = REGISTRAR,=A0 =A0=A0 =A0 =A0configured data, etc. =A0 =A03. =A0Related to the last point in item 2 above, it has been proposed th= at =A0=A0 =A0 =A0we differentiate the hi-entries even more by defining separat= e parameters =A0=A0 =A0 for registered and configured/mapped contacts.=A0 =A0=A0 =A0 Currently when the R-URI is translated to a URI which is either = derived=A0 =A0=A0 =A0 from location service lookup(registered by UA) or from mapping= =A0 =A0=A0 =A0 table, there is no differentiation as to how the URI was derived= once it is =A0=A0 =A0 added to the list of potential targets. =A0=A0 =A0=A0 =A0=A0 =A0 The general consensus of the authors of the two documents was th= at it may=A0 =A0=A0 =A0 be useful for some services to have the hi-entries tagged with t= he =A0=A0 =A0 more specific information.=A0 =A0 =A0=A0 =A0 And, of course, this gets us into another naming contest. In the= end, the naming =A0=A0 =A0 is not so important as long as the term isn't too overloaded and= it is defined =A0=A0 =A0 precisely in the document(s). =A0 We would appreciate WG feedback on these issues and any other comments on the two documents prior to IETF-74. =A0 Regards, Shida and Mary. Begin forwarded message: From:=A0Internet-Drafts@ietf.org Date:=A0March 10, 2009 2:30:01 AM JST To:=A0i-d-announce@ietf.org Subject:=A0I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=A0 Reply-To:=A0internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=A0 directories. Title : Delivery of Request-URI Targets to User Agents Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schuber= t Filename : draft-rosenberg-sip-target-uri-delivery-01.txt Pages : 16 Date : 2009-3-9 =09 When a Session Initiation Protocol (SIP) proxy receives a request =A0=A0targeted at a URI identifying a user or resource it is responsible =A0=A0for, the proxy translates the URI to a registered or configured =A0=A0contact URI of an agent representing that user or resource. =A0In the =A0=A0process, the original URI is removed from the request. =A0Numerous us= e =A0=A0cases have arisen which require this information to be delivered to =A0=A0the user agent. =A0This document describes these use cases and define= s =A0=A0an extension to the History-Info header field which allows it to be =A0=A0used to support those cases. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-delivery= -01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain
Content-ID: <2009-3-9102756.I-D@ietf.org>=

_______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories:=A0http://www.ietf.org/shadow.html or=A0ftp://ftp.ietf.org/ietf/1shadow-sites.txt From HKaplan@acmepacket.com Tue Mar 10 23:58:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7127E3A68BF for ; Tue, 10 Mar 2009 23:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82ljMah5Phxj for ; Tue, 10 Mar 2009 23:58:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9D9E63A67DA for ; Tue, 10 Mar 2009 23:58:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 02:59:26 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 11 Mar 2009 02:59:26 -0400 From: Hadriel Kaplan To: Shida Schubert , "sip@ietf.org List" Date: Wed, 11 Mar 2009 02:59:24 -0400 Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AABeIUA Message-ID: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> In-Reply-To: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 06:58:54 -0000 =A03. =A0Related to the last point in item 2 above, it has been proposed th= at =A0=A0 =A0 =A0we differentiate the hi-entries even more by defining separat= e parameters =A0=A0 =A0 for registered and configured/mapped contacts.=A0 I vote no on 3, fwiw. Keep it Simple. -hadriel From ietf.hanserik@gmail.com Wed Mar 11 01:35:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918B53A6AAE for ; Wed, 11 Mar 2009 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=2.026, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl2NEOiZyOtH for ; Wed, 11 Mar 2009 01:35:51 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 1A2363A69EC for ; Wed, 11 Mar 2009 01:35:50 -0700 (PDT) Received: by ewy25 with SMTP id 25so1565960ewy.37 for ; Wed, 11 Mar 2009 01:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ex7I3FqjL62OXXRLaLn/gyia+3L6YH8UAZQpdeq48cA=; b=UIZKXDFC/qQKsPiD2MZt1RPkQdtUHXqmhmNHCWUUbqBlt3Oc72AmJvqSJ9OG9PLmnb h6MZYYSoKisSCe5tED1ph/IlAsPZqBypotuF3skZe6T5kyxQlh+VDzMF1CkRWQklw4Pj Lr/id+LHaoOSQtcFNE/cN7FLnAPvgGi4LbdtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rxY+aMw6R+g9k2DMu5/ULPvcnEP7bO/SSdbp5KVgZleIaxOAQxC3BVuOctpBcRtx6K +1OPW/oKxE4nMyNcoF8RQavMRxU/d9QAbcoVGFVy7kDJ7kDfyW83Rv3BHi/dgv9RYkFS 5jQFCflc+BaIeHYMCpkE1vhyIFZOaoX6K/bI8= MIME-Version: 1.0 Received: by 10.210.112.4 with SMTP id k4mr4204773ebc.81.1236760586492; Wed, 11 Mar 2009 01:36:26 -0700 (PDT) In-Reply-To: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> Date: Wed, 11 Mar 2009 09:36:26 +0100 Message-ID: <9ae56b1e0903110136t2d127012p68a113d650451463@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174c16486e1b7b0464d3c3f1 Cc: "sip@ietf.org List" , Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 08:35:53 -0000 --0015174c16486e1b7b0464d3c3f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think that is a good question, because it is real world use that we would like to serve. But at the same time when we want to progress this requirement, it would be good to know what is an acceptable means to transport the target-URI towards the UAS? Would you reconsider using a distinct header for this? /Hans Erik van Elburg On Wed, Mar 11, 2009 at 7:55 AM, Hadriel Kaplan wrote: > > At the risk of opening up a topic we have already agreed on, but in the > spirit of open communication... [how's that for an opener!?] > > Are we absolutely sure we want to put this target-URI in the History-Info > header? > > I am not asking this because I think it's hard. I am asking because I am > not sure it will be used. Several of us from this same WG are involved in > the SIP-Forum's SIP-Connect profile, and when faced with either using this > new History-Info mechanism for a target-uri delivery issue, vs. not, we > chose not to. And we were mostly the same people who liked the idea of > putting it in History-Info in the IETF! (myself included) But I am > concerned that when given a reasonable opportunity to use a mechanism we > ourselves promote when wearing a different hat, we chose not to use it in > practice. It doesn't bode well. :( > > -hadriel > p.s. sorry Mary for raising this, but there isn't much email traffic > anyway. :) > > ________________________________________ > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Shida Schubert > Sent: Wednesday, March 11, 2009 2:13 AM > To: sip@ietf.org List > > We have submitted the updated target-uri draft based on the comments > submitted to the list and comments received at IETF73. > > I have taken over as editor as Jonathan didn't have the cycles to > update the draft, with Francois, Christer and Hans Erick as additional > co-authors and great deal of help from Mary. > > The following summarizes the changes made to the target-uri document > 1. Added use-case for toll-free number back > 2. Added definition of "retarget" operation. > 3. Removed a reference to URN > 4. Added a text discussing the difference to P-Called-Party-Id > 5. Changed parameter name from "target" to "istarget" > > Note, that the target-uri document still contains the normative text for > the > History-Info header. > > In addition, Mary (with Francois as co-author) has submitted a > rfc4244bis, with the following changes: > 1. Incorporated the normative aspects of the target-uri document > into the existing normative text in RFC 4244 - the functionality is > virtually identical (as is some of the text) as the HI based solution > described in the target-uri document. It's important that the solution > be integrated into RFC 4244 as it MUST work and be based on the normative > aspects of RFC 4244. > 2. Added the use cases from target-uri the the summary > in the overview of rfc4244bis. > 3. Added an additional requirement to capture the "target-uri" information. > 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. > 5. Added a more simplified example. > > > We had some very long offline exchanges as to the best way forward and > remaining work for both documents. > > Some of the issues identified are: > > ::Issues:: > 1. Should we remove the normative text from target-uri and progress > 4244bis along with the target-uri document to meet the chartered > SIP WG milestone? > > > 2. Name of the parameter. > At the last meeting, parameter "target" was said inappropriate > because voicemail-uri spec already defines a parameter called > "target" which also can be found in hi-entry, thus potentially > causing confusion. > > Currently the target-uri draft uses "istarget" and 4244bis uses > "retarget" but we could never come to > a consensus on what name is appropriate. Other suggestions have > included the following: > "target-identity" (someone didn't like that "identity" is also a SIP > header) > "reg-uri" (can be paired with "mapped-uri" for item 3 below) > "aor" > "jibberish" > etc. > > One reason this is so difficult relates to the problem statement in > target-uri in that > RFC 3261 doesn't differentiate the mechanism by which the new > (target) Request-URI is selected. Another issue is that some of the > terminology in > RFC 3261 is overloaded - e.g., "forwarding" refers both to a Proxy > which does not have responsibility for the domain of the request-URI > in the incoming request, thus the proxy just "forwards" the request > to > the next hop AND "forwarding" is used to describe the process whereby > the outgoing request is built and "forwarded" to the next hop at > which > point the proxy does not know how the new request-uri was selected. > RFC 4244 has attempted to clarify the terms and attempts to use > "forward" > in the context of the former situation and "retarget" for the case > whereby > a proxy is responsible for the domain and thus can use a number of > mechanism to select the new target for the request - e.g., a > REGISTRAR, > configured data, etc. > > 3. Related to the last point in item 2 above, it has been proposed that > we differentiate the hi-entries even more by defining separate > parameters > for registered and configured/mapped contacts. > Currently when the R-URI is translated to a URI which is either > derived > from location service lookup(registered by UA) or from mapping > table, there is no differentiation as to how the URI was derived once > it is > added to the list of potential targets. > > The general consensus of the authors of the two documents was that it > may > be useful for some services to have the hi-entries tagged with the > more specific information. > > And, of course, this gets us into another naming contest. In the end, > the naming > is not so important as long as the term isn't too overloaded and it is > defined > precisely in the document(s). > > We would appreciate WG feedback on these issues and any other comments on > the two documents prior to IETF-74. > > Regards, > Shida and Mary. > > > > Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 10, 2009 2:30:01 AM JST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Delivery of Request-URI Targets to User Agents > Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. > Audet, S. Schubert > Filename : draft-rosenberg-sip-target-uri-delivery-01.txt > Pages : 16 > Date : 2009-3-9 > > When a Session Initiation Protocol (SIP) proxy receives a request > targeted at a URI identifying a user or resource it is responsible > for, the proxy translates the URI to a registered or configured > contact URI of an agent representing that user or resource. In the > process, the original URI is removed from the request. Numerous use > cases have arisen which require this information to be delivered to > the user agent. This document describes these use cases and defines > an extension to the History-Info header field which allows it to be > used to support those cases. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-delivery-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain
Content-ID: <2009-3-9102756.I-D@ietf.org > >

> _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draftdirectories: > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --0015174c16486e1b7b0464d3c3f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that is a good question, because it is real world use that we would= like to serve. But at the same time when we want to progress this requirem= ent, it would be good to know what is an acceptable means to transport the = target-URI towards the UAS?

Would you reconsider using a distinct header for this?

/Hans Erik van Elburg


On Wed, Mar 11, 2009 at 7:55 AM, Hadriel= Kaplan <HKa= plan@acmepacket.com> wrote:

At the risk of opening up a topic we have already agreed on, but in the spi= rit of open communication... [how's that for an opener!?]

Are we absolutely sure we want to put this target-URI in the History-Info h= eader?

I am not asking this because I think it's hard. =A0I am asking because = I am not sure it will be used. =A0Several of us from this same WG are invol= ved in the SIP-Forum's SIP-Connect profile, and when faced with either = using this new History-Info mechanism for a target-uri delivery issue, vs. = not, we chose not to. =A0And we were mostly the same people who liked the i= dea of putting it in History-Info in the IETF! (myself included) =A0But I a= m concerned that when given a reasonable opportunity to use a mechanism we = ourselves promote when wearing a different hat, we chose not to use it in p= ractice. =A0It doesn't bode well. :(

-hadriel
p.s. sorry Mary for raising this, but there isn't much email traffic an= yway. :)

________________________________________
From: sip-bounces@ietf.org [mai= lto:sip-bounces@ietf.org] On Be= half Of Shida Schubert
Sent: Wednesday, March 11, 2009 2:13 AM
To: sip@ietf.org List

We have submitted the updated target-uri draft based on the comments=A0
submitted to the list and comments received at IETF73.=A0

I have taken over as editor as Jonathan didn't have the cycles to=A0 update the draft, with Francois, Christer and Hans Erick as additional=A0 co-authors and great deal of help from Mary. =A0
=A0
The following summarizes the changes made to the target-uri document
1. Added use-case for toll-free number back
2. Added definition of "retarget" operation.=A0
3. Removed a reference to URN
4. Added a text discussing the difference to P-Called-Party-Id
5. Changed parameter name from "target" to "istarget" =A0
Note, that the target-uri document still contains the normative text for th= e
History-Info header.
=A0
In addition, Mary (with Francois as co-author) has submitted a
rfc4244bis, with the following changes:
1. Incorporated the normative aspects of the target-uri document
into the existing normative text in RFC 4244 - the functionality is=A0
virtually identical (as is some of the text) as the HI based solution=A0 described in the target-uri document. =A0It's important that the soluti= on
be integrated into RFC 4244 as it MUST work and be based on the normative aspects of RFC 4244.
2. =A0Added the use cases from target-uri the the summary
in the overview of rfc4244bis.
3. Added an additional requirement to capture the "target-uri" in= formation.
4. Fixed an error in the RFC 4244 ABNF and added "retarget" param= eter.
5. Added a more simplified example.
=A0
=A0
We had some very long offline exchanges as to the best way forward and
remaining work for both documents.
=A0
Some of the issues identified are:

::Issues::
=A0=A0 1. Should we remove the normative text from target-uri and progress<= br> =A0=A0 =A0 =A0 4244bis along with the target-uri document to meet the chart= ered
=A0=A0 =A0 =A0SIP WG milestone?=A0
=A0
=A0
=A0=A0 2. Name of the parameter.=A0
=A0=A0 =A0 =A0At the last meeting, parameter "target" was said in= appropriate=A0
=A0=A0 =A0 =A0because voicemail-uri spec already defines a parameter called= =A0
=A0=A0 =A0 =A0"target" which also can be found in hi-entry, thus = potentially=A0
=A0=A0 =A0 =A0causing confusion.
=A0=A0 =A0=A0
=A0=A0 =A0 =A0Currently the target-uri draft uses "istarget" and = 4244bis uses
=A0=A0 =A0 =A0"retarget" =A0but we could never come to=A0
=A0=A0 =A0 =A0a consensus on what name is appropriate. =A0Other suggestions= have
=A0=A0 =A0 =A0included the following:
=A0=A0 =A0 =A0"target-identity" (someone didn't like that &qu= ot;identity" is also a SIP header)
=A0=A0 =A0 =A0"reg-uri" =A0(can be paired with "mapped-uri&q= uot; for item 3 below)
=A0=A0 =A0 =A0"aor"
=A0=A0 =A0 =A0"jibberish"=A0
=A0=A0 =A0 =A0etc.
=A0
=A0=A0 =A0 =A0One reason this is so difficult relates to the problem statem= ent in target-uri in that
=A0=A0 =A0 =A0RFC 3261 doesn't differentiate the mechanism by which the= new
=A0=A0 =A0 =A0(target) Request-URI is selected. =A0Another issue is that so= me of the terminology in
=A0=A0 =A0 =A0RFC 3261 is overloaded - e.g., "forwarding" refers = both to a Proxy
=A0=A0 =A0 =A0which does not have responsibility for the domain of the requ= est-URI
=A0=A0 =A0 =A0in the incoming request, thus the proxy just "forwards&q= uot; the request to
=A0=A0 =A0 =A0the next hop AND "forwarding" is used to describe t= he process whereby
=A0=A0 =A0 =A0the outgoing request is built and "forwarded" to th= e next hop at which
=A0=A0 =A0 =A0point the proxy does not know how the new request-uri was sel= ected.
=A0=A0 =A0 =A0RFC 4244 has attempted to clarify the terms and attempts to u= se "forward"=A0
=A0=A0 =A0 =A0in the context of the former situation and "retarget&quo= t; for the case whereby
=A0=A0 =A0 =A0a proxy is responsible for the domain and thus can use a numb= er of=A0
=A0=A0 =A0 =A0mechanism to select the new target for the request - e.g., a = REGISTRAR,=A0
=A0=A0 =A0 =A0configured data, etc. =A0

=A03. =A0Related to the last point in item 2 above, it has been proposed th= at
=A0=A0 =A0 =A0we differentiate the hi-entries even more by defining separat= e parameters
=A0=A0 =A0 for registered and configured/mapped contacts.=A0
=A0=A0 =A0 Currently when the R-URI is translated to a URI which is either = derived=A0
=A0=A0 =A0 from location service lookup(registered by UA) or from mapping= =A0
=A0=A0 =A0 table, there is no differentiation as to how the URI was derived= once it is
=A0=A0 =A0 added to the list of potential targets.
=A0=A0 =A0=A0
=A0=A0 =A0 The general consensus of the authors of the two documents was th= at it may=A0
=A0=A0 =A0 be useful for some services to have the hi-entries tagged with t= he
=A0=A0 =A0 more specific information.=A0
=A0
=A0=A0 =A0 And, of course, this gets us into another naming contest. In the= end, the naming
=A0=A0 =A0 is not so important as long as the term isn't too overloaded= and it is defined
=A0=A0 =A0 precisely in the document(s).
=A0
We would appreciate WG feedback on these issues and any other comments on the two documents prior to IETF-74.
=A0
Regards,
Shida and Mary.



Begin forwarded message:
From:=A0Internet-Drafts@ietf.or= g
Date:=A0March 10, 2009 2:30:01 AM JST
To:=A0i-d-announce@ietf.org Subject:=A0I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=A0
Reply-To:=A0internet-drafts@iet= f.org

A New Internet-Draft is available from the on-line Internet-Drafts=A0
directories.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Delivery of Request-URI Targets= to User Agents
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Rosenberg, H. van Elburg, C. Hol= mberg, F. Audet, S. Schubert
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-rosenberg-sip-target-uri-de= livery-01.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-3-9

When a Session Initiation Protocol (SIP) proxy receives a request
=A0=A0targeted at a URI identifying a user or resource it is responsible =A0=A0for, the proxy translates the URI to a registered or configured
=A0=A0contact URI of an agent representing that user or resource. =A0In the=
=A0=A0process, the original URI is removed from the request. =A0Numerous us= e
=A0=A0cases have arisen which require this information to be delivered to =A0=A0the user agent. =A0This document describes these use cases and define= s
=A0=A0an extension to the History-Info header field which allows it to be =A0=A0used to support those cases.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/d= raft-rosenberg-sip-target-uri-delivery-01.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain<BR>Content-ID: &lt;2009-3-9102756.I-D@ietf.org&gt;<B= R><BR>
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories:=A0http://www.ietf.org/shadow.html
or=A0ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_____________________________= __________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs= .columbia.edu for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip

--0015174c16486e1b7b0464d3c3f1-- From rco@iptel.org Wed Mar 11 01:52:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771E63A67A1 for ; Wed, 11 Mar 2009 01:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q89qGaarZf0t for ; Wed, 11 Mar 2009 01:52:26 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 0DB6F3A6AAE for ; Wed, 11 Mar 2009 01:52:26 -0700 (PDT) Received: by mail.iptel.org (Postfix, from userid 103) id 593241810C69; Wed, 11 Mar 2009 09:53:01 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 28E2C1810C67; Wed, 11 Mar 2009 09:53:00 +0100 (CET) Message-ID: <49B77BEB.4000501@iptel.org> Date: Wed, 11 Mar 2009 09:52:59 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hadriel Kaplan References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> <49B5006D.8050702@iptel.org> <49B63B9F.9000101@iptel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nils Ohlmeier , "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 08:52:27 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Raphael Coeffic [mailto:rco@iptel.org] >> Sent: Tuesday, March 10, 2009 6:06 AM >> >> Hadriel Kaplan wrote: >> >> Forcing registrations is the path that IMS went for, I believe. But if >> you want to take advantage of this, you may have to deploy a little more >> IMS than you'd like to. >> > > The concept and practice of "forcing" UA's, which have AoR's belonging to a domain, to REGISTER their contact binding for those AoR's in order to make calls, has been around a lot longer than IMS has. Invoking the "that sounds like IMS" defense is a cheap guilt-by-association argument, and not relevant. One might as well argue that using INVITE's or RTP "is the path that IMS went for". > > You keep making it sound like sending a SIP request which does not create a dialog is somehow a difficult mechanism to implement, or "forces" people to do something they don't want to. What is it forcing? > > Well, it is not required as per RFC 3261 ;-) > You're looking for a means of authenticating a UA without being subject to a relay attack. Using a different SIP Method name, which can only be initiated by the client with the credentials, and one that UA's cannot be baited to provide by random third parties, is one solution to the problem. If you don't like the string "REGISTER", then how about "OPTIONS"? > > No, I think you missunderstood me. I still think that requiring a registration and checking the source IP and port against the registered contact is a fair measure to take. However, it introduces more traffic in some scenarios, where it is not necessarily needed. REGISTERs could become the "background load" in the servers. This also puts a lot of state into some proxies that does not need it, etc... My concern is just that it seems like there is no better solution. >> Maybe just an example: let's say you have a home SIP server, doing the >> usual least cost routing. Your least cost router might have something >> like 50 different routes. Do you want this box, or maybe your phones to >> have 50 running registrations, just for the purpose of having cheap >> calls? Well, personaly, I would prefer to just install my certificate on >> this box, and use TLS. But as very very few of those PSTN providers do >> support TLS, I cannot. By the way, there are already commercial products >> supporting this scenario. >> > > So you have a mechanism that people don't seem to want to implement - and meanwhile you have another mechanism, which is widely implemented. And the problem is...? > > See previous answer. Cheers Raphael. From ietf.hanserik@gmail.com Wed Mar 11 01:58:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF5A3A67D6 for ; Wed, 11 Mar 2009 01:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn5x1pR1Q-15 for ; Wed, 11 Mar 2009 01:58:14 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id 3BB343A67A1 for ; Wed, 11 Mar 2009 01:58:13 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so422844nfh.39 for ; Wed, 11 Mar 2009 01:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xCc7uZ+juxD5RETAnxYXbhPQ7Zm8Jv10n1Gg3Upct5c=; b=JxjvXd5le7RqRLTGPi4ngsMYKi98u6dk/6gml9cS6FEE/7+ywcmJI6G4BwTToReiGL 0XIZ24YEjOPaqCzSTxVIHpB0Tmbm5sEU5ItRgH2SJp/tXk8itxK0L/CrB3YhmEF4ERr0 bKB6dZKZcf4rjadNyi9cAUwGaaIY0Mp9ofl8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sx/xh+wA5NHLZaBicEMH8K4rZFBI5WoBFqd119AqKoJTUdzpfAEnwEN9KfYDHEO5OU 611Q/V59Mnff9ebvmuEVWDpvJ08wo5qcR8gN+0CS0QYfoVqLXlCDvlb2tyerhtks2Vdy cZq68fTP22YKl4s/YzDpzmH46FNlJAWVUEDm4= MIME-Version: 1.0 Received: by 10.210.136.10 with SMTP id j10mr1211442ebd.24.1236761928533; Wed, 11 Mar 2009 01:58:48 -0700 (PDT) In-Reply-To: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> Date: Wed, 11 Mar 2009 09:58:48 +0100 Message-ID: <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> From: Hans Erik van Elburg To: Shida Schubert Content-Type: multipart/alternative; boundary=0015174bdeaa6c08510464d4130f Cc: "sip@ietf.org List" , Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 08:58:15 -0000 --0015174bdeaa6c08510464d4130f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One of the problems that made the discussion quite tedious is the complete inversed meaning of the terms "retarget" and "reroute" between 4244bis and target-uri factions have. Conclusion was that the terminology need to be properly defined and some attempt was made to start such activity. On 3. I have strong concerns when we start tagging the URI as to how they come about "retarget"/"mapped conficuration" etc. It is better to embellish them with a tag that just represents there meaning for example "istarget" or "hop". For the following reasons: 1. It is much more intuitive for the user of this information, its meaning can basically be guessed. 2. Such meaning also probably survives application in other problem spaces that we had not foreseen when introducing the concept. The solution that is described now in the target-URI delivery draft is not yet complete, it does not solve the freephone use case for example and in its current form it will deliver exactly the same target-URI as that which would be delivered by the P-Called-Party-ID header. Contrary to what the draft says. So some work is needed still. /Hans Erik van Elburg On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert wrote: > > We have submitted the updated target-uri draft based on the comments > submitted to the list and comments received at IETF73. > > I have taken over as editor as Jonathan didn't have the cycles to > update the draft, with Francois, Christer and Hans Erick as additional > co-authors and great deal of help from Mary. > > The following summarizes the changes made to the target-uri document > 1. Added use-case for toll-free number back > 2. Added definition of "retarget" operation. > 3. Removed a reference to URN > 4. Added a text discussing the difference to P-Called-Party-Id > 5. Changed parameter name from "target" to "istarget" > > Note, that the target-uri document still contains the normative text for > the > History-Info header. > > In addition, Mary (with Francois as co-author) has submitted a > rfc4244bis, with the following changes: > 1. Incorporated the normative aspects of the target-uri document > into the existing normative text in RFC 4244 - the functionality is > virtually identical (as is some of the text) as the HI based solution > described in the target-uri document. It's important that the solution > be integrated into RFC 4244 as it MUST work and be based on the normative > aspects of RFC 4244. > 2. Added the use cases from target-uri the the summary > in the overview of rfc4244bis. > 3. Added an additional requirement to capture the "target-uri" information. > 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. > 5. Added a more simplified example. > > > We had some very long offline exchanges as to the best way forward and > remaining work for both documents. > > Some of the issues identified are: > > ::Issues:: > 1. Should we remove the normative text from target-uri and progress > 4244bis along with the target-uri document to meet the chartered > SIP WG milestone? > > > 2. Name of the parameter. > At the last meeting, parameter "target" was said inappropriate > because voicemail-uri spec already defines a parameter called > "target" which also can be found in hi-entry, thus potentially > causing confusion. > > Currently the target-uri draft uses "istarget" and 4244bis uses > "retarget" but we could never come to > a consensus on what name is appropriate. Other suggestions have > included the following: > "target-identity" (someone didn't like that "identity" is also a SIP > header) > "reg-uri" (can be paired with "mapped-uri" for item 3 below) > "aor" > "jibberish" > etc. > > One reason this is so difficult relates to the problem statement in > target-uri in that > RFC 3261 doesn't differentiate the mechanism by which the new > (target) Request-URI is selected. Another issue is that some of the > terminology in > RFC 3261 is overloaded - e.g., "forwarding" refers both to a Proxy > which does not have responsibility for the domain of the request-URI > in the incoming request, thus the proxy just "forwards" the request > to > the next hop AND "forwarding" is used to describe the process whereby > the outgoing request is built and "forwarded" to the next hop at > which > point the proxy does not know how the new request-uri was selected. > RFC 4244 has attempted to clarify the terms and attempts to use > "forward" > in the context of the former situation and "retarget" for the case > whereby > a proxy is responsible for the domain and thus can use a number of > mechanism to select the new target for the request - e.g., a > REGISTRAR, > configured data, etc. > > 3. Related to the last point in item 2 above, it has been proposed that > we differentiate the hi-entries even more by defining separate > parameters > for registered and configured/mapped contacts. > Currently when the R-URI is translated to a URI which is either > derived > from location service lookup(registered by UA) or from mapping > table, there is no differentiation as to how the URI was derived once > it is > added to the list of potential targets. > > The general consensus of the authors of the two documents was that it > may > be useful for some services to have the hi-entries tagged with the > more specific information. > > And, of course, this gets us into another naming contest. In the end, > the naming > is not so important as long as the term isn't too overloaded and it is > defined > precisely in the document(s). > > We would appreciate WG feedback on these issues and any other comments on > the two documents prior to IETF-74. > > Regards, > Shida and Mary. > > > > Begin forwarded message: > > *From: *Internet-Drafts@ietf.org > *Date: *March 10, 2009 2:30:01 AM JST > *To: *i-d-announce@ietf.org > *Subject: **I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * > *Reply-To: *internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Delivery of Request-URI Targets to User Agents > Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. > Schubert > Filename : draft-rosenberg-sip-target-uri-delivery-01.txt > Pages : 16 > Date : 2009-3-9 > > When a Session Initiation Protocol (SIP) proxy receives a request > targeted at a URI identifying a user or resource it is responsible > for, the proxy translates the URI to a registered or configured > contact URI of an agent representing that user or resource. In the > process, the original URI is removed from the request. Numerous use > cases have arisen which require this information to be delivered to > the user agent. This document describes these use cases and defines > an extension to the History-Info header field which allows it to be > used to support those cases. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-delivery-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > Content-Type: text/plain
Content-ID: <2009-3-9102756.I-D@ietf.org > >

> > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --0015174bdeaa6c08510464d4130f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One of the problems that made the discussion quite tedious is the complete = inversed meaning of the terms "retarget" and "reroute" = between 4244bis and target-uri factions have.

Conclusion was that th= e terminology need to be properly defined and some attempt was made to star= t such activity.

On 3. I have strong concerns when we start tagging the URI as to how th= ey come about "retarget"/"mapped conficuration" etc. It= is better to embellish them with a tag that just represents there meaning = for example "istarget" or "hop". For the following reas= ons:
1. It is much more intuitive for the user of this information, its meaning = can basically be guessed.
2. Such meaning also probably survives applica= tion in other problem spaces that we had not foreseen when introducing the = concept.

The solution that is=A0 described now in the target-URI delivery draft = is not yet complete, it does not solve the freephone use case for example a= nd in its current form it will deliver exactly the same target-URI as that = which would be delivered by the=A0 P-Called-Party-ID header. Contrary to wh= at the draft says. So some work is needed still.

/Hans Erik van Elburg


On Wed, Mar 11, 2009 at 7:13 AM, Shida S= chubert <shida@ntt= -at.com> wrote:

We have submitted the updated target-ur= i draft based on the comments=A0
submitted to the list and commen= ts received at IETF73.=A0

I have taken over as edi= tor as Jonathan didn't have the cycles to=A0
update the draft, with Francois, Christer and Hans Erick as additional= =A0
co-authors and great deal of help from Mary. =A0
= =A0
The following summarizes the changes made to the target-uri d= ocument
1. Added use-case for toll-free number back
2. Added definit= ion of "retarget" operation.=A0
3. Removed a reference = to URN
4. Added a text discussing the difference to P-Called-Part= y-Id
5. Changed parameter name from "target" to "istarget&qu= ot;
=A0
Note, that the target-uri document still contai= ns the normative text for the
History-Info header.
=A0<= /div>
In addition, Mary (with Francois as co-author) has submitted a
rfc4244bis, with the following changes:
1. Incorporated the no= rmative aspects of the target-uri document
into the existing norm= ative text in RFC 4244 - the functionality is=A0
virtually identical (as is some of the text) as the HI based solution= =A0
described in the target-uri document. =A0It's important t= hat the solution
be integrated into RFC 4244 as it MUST work and = be based on the normative
aspects of RFC 4244.
2. =A0Added the use cases from target-u= ri the the summary
in the overview of rfc4244bis.
3. Ad= ded an additional requirement to capture the "target-uri" informa= tion.
4. Fixed an error in the RFC 4244 ABNF and added "retarget" = parameter.
5. Added a more simplified example.
=A0
=A0
We had some very long offline exchanges as to the best = way forward and
remaining work for both documents.
=A0
Some of the= issues identified are:

::Issues::
=A0= =A0 1. Should we remove the normative text from target-uri and progress
=A0=A0 =A0 =A0 4244bis along with the target-uri document to meet the chart= ered
=A0=A0 =A0 =A0SIP WG milestone?=A0
=A0
= =A0
=A0=A0 2. Name of the parameter.=A0
=A0=A0 =A0 =A0A= t the last meeting, parameter "target" was said inappropriate=A0<= /div>
=A0=A0 =A0 =A0because voicemail-uri spec already defines a parameter c= alled=A0
=A0=A0 =A0 =A0"target" which also can be found= in hi-entry, thus potentially=A0
=A0=A0 =A0 =A0causing confusion= .
=A0=A0 =A0=A0
=A0=A0 =A0 =A0Currently the target-uri draft uses "istarget" and = 4244bis uses
=A0=A0 =A0 =A0"retarget" =A0but we could n= ever come to=A0
=A0=A0 =A0 =A0a consensus on what name is appropr= iate. =A0Other suggestions have
=A0=A0 =A0 =A0included the following:
=A0=A0 =A0 =A0"ta= rget-identity" (someone didn't like that "identity" is a= lso a SIP header)
=A0=A0 =A0 =A0"reg-uri" =A0(can be pa= ired with "mapped-uri" for item 3 below)
=A0=A0 =A0 =A0"aor"
=A0=A0 =A0 =A0"jibberish&= quot;=A0
=A0=A0 =A0 =A0etc.
=A0
=A0=A0 =A0 = =A0One reason this is so difficult relates to the problem statement in targ= et-uri in that
=A0=A0 =A0 =A0RFC 3261 doesn't differentiate t= he mechanism by which the new
=A0=A0 =A0 =A0(target) Request-URI is selected. =A0Another issue is th= at some of the terminology in
=A0=A0 =A0 =A0RFC 3261 is overloade= d - e.g., "forwarding" refers both to a Proxy
=A0=A0 = =A0 =A0which does not have responsibility for the domain of the request-URI=
=A0=A0 =A0 =A0in the incoming request, thus the proxy just "forwa= rds" the request to
=A0=A0 =A0 =A0the next hop AND "for= warding" is used to describe the process whereby
=A0=A0 =A0 = =A0the outgoing request is built and "forwarded" to the next hop = at which
=A0=A0 =A0 =A0point the proxy does not know how the new request-uri wa= s selected.
=A0=A0 =A0 =A0RFC 4244 has attempted to clarify the t= erms and attempts to use "forward"=A0
=A0=A0 =A0 =A0in = the context of the former situation and "retarget" for the case w= hereby
=A0=A0 =A0 =A0a proxy is responsible for the domain and thus can use a= number of=A0
=A0=A0 =A0 =A0mechanism to select the new target fo= r the request - e.g., a REGISTRAR,=A0
=A0=A0 =A0 =A0configured da= ta, etc. =A0

=A03. =A0Related to the last point in item 2 above, it has been = proposed that
=A0=A0 =A0 =A0we differentiate the hi-entries even = more by defining separate parameters
=A0=A0 =A0 for registered an= d configured/mapped contacts.=A0
=A0=A0 =A0 Currently when the R-URI is translated to a URI which is ei= ther derived=A0
=A0=A0 =A0 from location service lookup(registere= d by UA) or from mapping=A0
=A0=A0 =A0 table, there is no differe= ntiation as to how the URI was derived once it is
=A0=A0 =A0 added to the list of potential targets.
=A0=A0 = =A0=A0
=A0=A0 =A0 The general consensus of the authors of the two= documents was that it may=A0
=A0=A0 =A0 be useful for some servi= ces to have the hi-entries tagged with the
=A0=A0 =A0 more specific information.=A0
=A0
=A0= =A0 =A0 And, of course, this gets us into another naming contest. In the en= d, the naming
=A0=A0 =A0 is not so important as long as the term = isn't too overloaded and it is defined
=A0=A0 =A0 precisely in the document(s).
=A0
We wo= uld appreciate WG feedback on these issues and any other comments on
<= div>the two documents prior to IETF-74.
=A0
Regards,
Shida and Mary.



= Begin forwarded message:
Date:=A0March 10, 2009 2:30:01 AM JST
A New In= ternet-Draft is available from the on-line Internet-Drafts=A0
directorie= s.


Title : Del= ivery of Request-URI Targets to User Agents
Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. = Schubert
Filename : draft-rosenberg-sip-target-uri-delivery-01= .txt
Pages : 16
Date : 2009-3-9

When a Session Initiation Pro= tocol (SIP) proxy receives a request
=A0=A0targeted at a URI identifying= a user or resource it is responsible
=A0=A0for, the proxy translates th= e URI to a registered or configured
=A0=A0contact URI of an agent representing that user or resource. =A0In the=
=A0=A0process, the original URI is removed from the request. =A0Numerou= s use
=A0=A0cases have arisen which require this information to be deliv= ered to
=A0=A0the user agent. =A0This document describes these use cases= and defines
=A0=A0an extension to the History-Info header field which allows it to be=A0=A0used to support those cases.

A URL for this Internet-Draft i= s:
http://www.ietf.org/internet-dr= afts/draft-rosenberg-sip-target-uri-delivery-01.txt

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

Below is the data which will enable a MIME compli= ant mail reader
implementation to automatically retrieve the ASCII version of the
Intern= et-Draft.
Content-Type: text/plain<BR&= gt;Content-ID: &lt;2009-3-9102756.I-D@ietf.org&gt;<BR><BR>
_______________________________________= ________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.iet= f.org/mailman/listinfo/i-d-announce
Internet-Draft directories:=A0http://www.ietf.org/shadow.html
or=A0ftp://ftp.ietf.or= g/ietf/1shadow-sites.txt

__________________________________= _____________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs= .columbia.edu for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip

--0015174bdeaa6c08510464d4130f-- From ian.elz@ericsson.com Wed Mar 11 02:52:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAFE53A6B52 for ; Wed, 11 Mar 2009 02:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m07PH66HkC8 for ; Wed, 11 Mar 2009 02:52:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 32DA53A67FF for ; Wed, 11 Mar 2009 02:52:41 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3330221445; Wed, 11 Mar 2009 10:52:22 +0100 (CET) X-AuditID: c1b4fb3c-ab806bb000001b43-a0-49b789d6a41c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 134B621345; Wed, 11 Mar 2009 10:52:22 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 10:52:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 10:53:59 +0100 Message-ID: In-Reply-To: <20090304151501.4951728C331@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-barnes-sip-rfc4244bis-00.txt thread-index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkw References: <20090304151501.4951728C331@core3.amsl.com> From: "Ian Elz" To: "Mary Barnes" , "Francois Audet" X-OriginalArrivalTime: 11 Mar 2009 09:52:21.0299 (UTC) FILETIME=[126BD830:01C9A22F] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 09:52:43 -0000 Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 04 March 2009 15:15 To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From john.elwell@siemens.com Wed Mar 11 04:33:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487253A6B9D for ; Wed, 11 Mar 2009 04:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n9UYSaH7Cfo for ; Wed, 11 Mar 2009 04:33:34 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id EF31D3A694A for ; Wed, 11 Mar 2009 04:33:33 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGC0050VAQ2B1@siemenscomms.co.uk> for sip@ietf.org; Wed, 11 Mar 2009 11:33:22 +0000 (GMT) Date: Wed, 11 Mar 2009 11:32:23 +0000 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , Shida Schubert , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019F797F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AAAnCqAAAoWh+A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> Cc: Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 11:33:40 -0000 Just to expand on what Hadriel says, the SIP Forum is addressing the = case where a request is delivered by a SIP Service Provider to a = SIP-PBX, the SIP-PBX having registered with the SIP-SP. The SIP-PBX = needs to be in possession of the target, in order to route onwards = correctly within the enterprise. If only the SIP-PBX's contact URI is = available in the Request-URI, the SIP-PBX would have to look elsewhere = for the target. In accordance with recent SIP WG agreements, this would = be the History-Info header field, but that requires the present = extension. Advantages of putting the target in the Request-URI for this particular = situation: - This is where the SIP-PBX would normally expect to find the target = when a request is received from elsewhere (e.g., another SIP-PBX within = the enterprise), so it is reasonable also to expect it there when = received from a SIP SP. - SIPConnect 1.1 will not require History-Info for any other purpose, so = it would make it a mandatory specification for SIPConnect 1.1 just in = order to solve this particular problem, thereby raising the bar for SPs = and SIP-PBXs wanting to comply with the spec. - We would need to define procedures for what to do if History-Info is = absent from a received request or if there is no entry marked as = 'istarget'. - SIPConnect 1.1 is due for completion in the next few weeks, and cannot = wait the usual IETF cycle time for History-Info update to hit the RFC = Editor's queue. - If History-Info is used anyway (for its original purpose), the history = revealed when a request comes from a SIP-SP via a SIP-PBX to another = proxy and finally to a UAS would be unnecessarily complicated and = therefore confusing, because the target would be replaced by a contact = and would then appear again at the next hop. John =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: 11 March 2009 06:55 > To: Shida Schubert; sip@ietf.org List > Cc: Mary Barnes > Subject: Re: [Sip] Fwd: I-D=20 > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >=20 >=20 > At the risk of opening up a topic we have already agreed on,=20 > but in the spirit of open communication... [how's that for an=20 > opener!?] >=20 > Are we absolutely sure we want to put this target-URI in the=20 > History-Info header? >=20 > I am not asking this because I think it's hard. I am asking=20 > because I am not sure it will be used. Several of us from=20 > this same WG are involved in the SIP-Forum's SIP-Connect=20 > profile, and when faced with either using this new=20 > History-Info mechanism for a target-uri delivery issue, vs.=20 > not, we chose not to. And we were mostly the same people who=20 > liked the idea of putting it in History-Info in the IETF!=20 > (myself included) But I am concerned that when given a=20 > reasonable opportunity to use a mechanism we ourselves=20 > promote when wearing a different hat, we chose not to use it=20 > in practice. It doesn't bode well. :( >=20 > -hadriel > p.s. sorry Mary for raising this, but there isn't much email=20 > traffic anyway. :) >=20 > ________________________________________ > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Shida Schubert > Sent: Wednesday, March 11, 2009 2:13 AM > To: sip@ietf.org List >=20 > We have submitted the updated target-uri draft based on the = comments=A0 > submitted to the list and comments received at IETF73.=A0 >=20 > I have taken over as editor as Jonathan didn't have the cycles to=A0 > update the draft, with Francois, Christer and Hans Erick as=20 > additional=A0 > co-authors and great deal of help from Mary. =A0 > =A0 > The following summarizes the changes made to the target-uri document > 1. Added use-case for toll-free number back > 2. Added definition of "retarget" operation.=A0 > 3. Removed a reference to URN > 4. Added a text discussing the difference to P-Called-Party-Id > 5. Changed parameter name from "target" to "istarget" > =A0 > Note, that the target-uri document still contains the=20 > normative text for the > History-Info header. > =A0 > In addition, Mary (with Francois as co-author) has submitted a > rfc4244bis, with the following changes: > 1. Incorporated the normative aspects of the target-uri document > into the existing normative text in RFC 4244 - the functionality is=A0 > virtually identical (as is some of the text) as the HI based = solution=A0 > described in the target-uri document. =A0It's important that=20 > the solution > be integrated into RFC 4244 as it MUST work and be based on=20 > the normative > aspects of RFC 4244. > 2. =A0Added the use cases from target-uri the the summary > in the overview of rfc4244bis. > 3. Added an additional requirement to capture the=20 > "target-uri" information. > 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. > 5. Added a more simplified example. > =A0 > =A0 > We had some very long offline exchanges as to the best way forward and > remaining work for both documents. > =A0 > Some of the issues identified are: >=20 > ::Issues:: > =A0=A0 1. Should we remove the normative text from target-uri and = progress > =A0=A0 =A0 =A0 4244bis along with the target-uri document to meet the=20 > chartered > =A0=A0 =A0 =A0SIP WG milestone?=A0 > =A0 > =A0 > =A0=A0 2. Name of the parameter.=A0 > =A0=A0 =A0 =A0At the last meeting, parameter "target" was said = inappropriate=A0 > =A0=A0 =A0 =A0because voicemail-uri spec already defines a parameter = called=A0 > =A0=A0 =A0 =A0"target" which also can be found in hi-entry, thus = potentially=A0 > =A0=A0 =A0 =A0causing confusion. > =A0=A0 =A0=A0 > =A0=A0 =A0 =A0Currently the target-uri draft uses "istarget" and = 4244bis uses > =A0=A0 =A0 =A0"retarget" =A0but we could never come to=A0 > =A0=A0 =A0 =A0a consensus on what name is appropriate. =A0Other = suggestions have > =A0=A0 =A0 =A0included the following: > =A0=A0 =A0 =A0"target-identity" (someone didn't like that "identity"=20 > is also a SIP header) > =A0=A0 =A0 =A0"reg-uri" =A0(can be paired with "mapped-uri" for item 3 = below) > =A0=A0 =A0 =A0"aor" > =A0=A0 =A0 =A0"jibberish"=A0 > =A0=A0 =A0 =A0etc. > =A0 > =A0=A0 =A0 =A0One reason this is so difficult relates to the problem=20 > statement in target-uri in that > =A0=A0 =A0 =A0RFC 3261 doesn't differentiate the mechanism by which = the new > =A0=A0 =A0 =A0(target) Request-URI is selected. =A0Another issue is=20 > that some of the terminology in > =A0=A0 =A0 =A0RFC 3261 is overloaded - e.g., "forwarding" refers both=20 > to a Proxy > =A0=A0 =A0 =A0which does not have responsibility for the domain of=20 > the request-URI > =A0=A0 =A0 =A0in the incoming request, thus the proxy just "forwards"=20 > the request to > =A0=A0 =A0 =A0the next hop AND "forwarding" is used to describe the=20 > process whereby > =A0=A0 =A0 =A0the outgoing request is built and "forwarded" to the=20 > next hop at which > =A0=A0 =A0 =A0point the proxy does not know how the new request-uri=20 > was selected. > =A0=A0 =A0 =A0RFC 4244 has attempted to clarify the terms and=20 > attempts to use "forward"=A0 > =A0=A0 =A0 =A0in the context of the former situation and "retarget"=20 > for the case whereby > =A0=A0 =A0 =A0a proxy is responsible for the domain and thus can use=20 > a number of=A0 > =A0=A0 =A0 =A0mechanism to select the new target for the request -=20 > e.g., a REGISTRAR,=A0 > =A0=A0 =A0 =A0configured data, etc. =A0 >=20 > =A03. =A0Related to the last point in item 2 above, it has been=20 > proposed that > =A0=A0 =A0 =A0we differentiate the hi-entries even more by defining=20 > separate parameters > =A0=A0 =A0 for registered and configured/mapped contacts.=A0 > =A0=A0 =A0 Currently when the R-URI is translated to a URI which is=20 > either derived=A0 > =A0=A0 =A0 from location service lookup(registered by UA) or from = mapping=A0 > =A0=A0 =A0 table, there is no differentiation as to how the URI was=20 > derived once it is > =A0=A0 =A0 added to the list of potential targets. > =A0=A0 =A0=A0 > =A0=A0 =A0 The general consensus of the authors of the two=20 > documents was that it may=A0 > =A0=A0 =A0 be useful for some services to have the hi-entries=20 > tagged with the > =A0=A0 =A0 more specific information.=A0 > =A0 > =A0=A0 =A0 And, of course, this gets us into another naming=20 > contest. In the end, the naming > =A0=A0 =A0 is not so important as long as the term isn't too=20 > overloaded and it is defined > =A0=A0 =A0 precisely in the document(s). > =A0 > We would appreciate WG feedback on these issues and any other=20 > comments on > the two documents prior to IETF-74. > =A0 > Regards, > Shida and Mary. >=20 >=20 >=20 > Begin forwarded message: > From:=A0Internet-Drafts@ietf.org > Date:=A0March 10, 2009 2:30:01 AM JST > To:=A0i-d-announce@ietf.org > Subject:=A0I-D = ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=A0 > Reply-To:=A0internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=A0 > directories. >=20 >=20 > Title : Delivery of Request-URI Targets to User Agents > Author(s) : J. Rosenberg, H. van Elburg, C.=20 > Holmberg, F. Audet, S. Schubert > Filename : draft-rosenberg-sip-target-uri-delivery-01.txt > Pages : 16 > Date : 2009-3-9 > =09 > When a Session Initiation Protocol (SIP) proxy receives a request > =A0=A0targeted at a URI identifying a user or resource it is = responsible > =A0=A0for, the proxy translates the URI to a registered or configured > =A0=A0contact URI of an agent representing that user or resource. = =A0In the > =A0=A0process, the original URI is removed from the request. = =A0Numerous use > =A0=A0cases have arisen which require this information to be delivered = to > =A0=A0the user agent. =A0This document describes these use cases and = defines > =A0=A0an extension to the History-Info header field which allows it to = be > =A0=A0used to support those cases. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target -uri-delivery-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain
Content-ID:=20 > <2009-3-9102756.I-D@ietf.org>

> _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories:=A0http://www.ietf.org/shadow.html > or=A0ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From john.elwell@siemens.com Wed Mar 11 04:34:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3343A694A for ; Wed, 11 Mar 2009 04:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_00=-2.599, MANGLED_DELIVY=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFjppN95xIJL for ; Wed, 11 Mar 2009 04:34:42 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 541033A6B2B for ; Wed, 11 Mar 2009 04:34:42 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGC004AWALEPV@siemenscomms.co.uk> for sip@ietf.org; Wed, 11 Mar 2009 11:34:40 +0000 (GMT) Date: Wed, 11 Mar 2009 11:34:14 +0000 From: "Elwell, John" In-reply-to: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> To: Shida Schubert , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019F798B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEI6Xoyz/7Vi2SBii6m4TJgBe2AALJOXA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> Cc: Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 11:34:44 -0000 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Shida Schubert Sent: 11 March 2009 06:13 To: sip@ietf.org List Cc: Mary Barnes Subject: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 We have submitted the updated target-uri draft based on the comments=20 submitted to the list and comments received at IETF73.=20 I have taken over as editor as Jonathan didn't have the cycles to=20 update the draft, with Francois, Christer and Hans Erick as additional=20 co-authors and great deal of help from Mary. =20 =20 The following summarizes the changes made to the target-uri document 1. Added use-case for toll-free number back 2. Added definition of "retarget" operation.=20 3. Removed a reference to URN 4. Added a text discussing the difference to P-Called-Party-Id 5. Changed parameter name from "target" to "istarget" =20 Note, that the target-uri document still contains the normative text for the History-Info header. [JRE] I don't like this. I would prefer to have all the normative stuff in one place, if RFC 4244 is being revised anyway. John =20 In addition, Mary (with Francois as co-author) has submitted a rfc4244bis, with the following changes: 1. Incorporated the normative aspects of the target-uri document into the existing normative text in RFC 4244 - the functionality is=20 virtually identical (as is some of the text) as the HI based solution=20 described in the target-uri document. It's important that the solution be integrated into RFC 4244 as it MUST work and be based on the normative aspects of RFC 4244. 2. Added the use cases from target-uri the the summary in the overview of rfc4244bis. 3. Added an additional requirement to capture the "target-uri" information. 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. 5. Added a more simplified example. =20 =20 We had some very long offline exchanges as to the best way forward and remaining work for both documents. =20 Some of the issues identified are: ::Issues:: 1. Should we remove the normative text from target-uri and progress 4244bis along with the target-uri document to meet the chartered SIP WG milestone?=20 =20 =20 2. Name of the parameter.=20 At the last meeting, parameter "target" was said inappropriate=20 because voicemail-uri spec already defines a parameter called=20 "target" which also can be found in hi-entry, thus potentially=20 causing confusion. =20 Currently the target-uri draft uses "istarget" and 4244bis uses "retarget" but we could never come to=20 a consensus on what name is appropriate. Other suggestions have included the following: "target-identity" (someone didn't like that "identity" is also a SIP header) "reg-uri" (can be paired with "mapped-uri" for item 3 below) "aor" "jibberish"=20 etc. =20 One reason this is so difficult relates to the problem statement in target-uri in that RFC 3261 doesn't differentiate the mechanism by which the new (target) Request-URI is selected. Another issue is that some of the terminology in RFC 3261 is overloaded - e.g., "forwarding" refers both to a Proxy which does not have responsibility for the domain of the request-URI in the incoming request, thus the proxy just "forwards" the request to the next hop AND "forwarding" is used to describe the process whereby the outgoing request is built and "forwarded" to the next hop at which point the proxy does not know how the new request-uri was selected. RFC 4244 has attempted to clarify the terms and attempts to use "forward"=20 in the context of the former situation and "retarget" for the case whereby a proxy is responsible for the domain and thus can use a number of=20 mechanism to select the new target for the request - e.g., a REGISTRAR,=20 configured data, etc. =20 3. Related to the last point in item 2 above, it has been proposed that we differentiate the hi-entries even more by defining separate parameters for registered and configured/mapped contacts.=20 Currently when the R-URI is translated to a URI which is either derived=20 from location service lookup(registered by UA) or from mapping=20 table, there is no differentiation as to how the URI was derived once it is added to the list of potential targets. =20 The general consensus of the authors of the two documents was that it may=20 be useful for some services to have the hi-entries tagged with the more specific information.=20 =20 And, of course, this gets us into another naming contest. In the end, the naming is not so important as long as the term isn't too overloaded and it is defined precisely in the document(s). =20 We would appreciate WG feedback on these issues and any other comments on the two documents prior to IETF-74. =20 Regards, Shida and Mary. Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 10, 2009 2:30:01 AM JST To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =09 =09 Title : Delivery of Request-URI Targets to User Agents Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert Filename : draft-rosenberg-sip-target-uri-delivery-01.txt Pages : 16 Date : 2009-3-9 =09 When a Session Initiation Protocol (SIP) proxy receives a request targeted at a URI identifying a user or resource it is responsible for, the proxy translates the URI to a registered or configured contact URI of an agent representing that user or resource. In the process, the original URI is removed from the request. Numerous use cases have arisen which require this information to be delivered to the user agent. This document describes these use cases and defines an extension to the History-Info header field which allows it to be used to support those cases. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-deliv ery-01.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 Content-Type: text/plain
Content-ID: <2009-3-9102756.I-D@ietf.org>

=20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From christer.holmberg@ericsson.com Wed Mar 11 05:26:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A9E3A694A for ; Wed, 11 Mar 2009 05:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9HylqaMi3K4 for ; Wed, 11 Mar 2009 05:26:22 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9FDB03A6810 for ; Wed, 11 Mar 2009 05:26:21 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D705420FB5; Wed, 11 Mar 2009 13:26:56 +0100 (CET) X-AuditID: c1b4fb3e-af8a1bb0000023da-1a-49b7ae10d1b6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A2A05200FB; Wed, 11 Mar 2009 13:26:56 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 13:26:56 +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: Wed, 11 Mar 2009 13:26:30 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0019F797F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AAAnCqAAAoWh+AAAjrwAA== References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <0D5F89FAC29E2C41B98A6A762007F5D0019F797F@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Hadriel Kaplan" , "Shida Schubert" , X-OriginalArrivalTime: 11 Mar 2009 12:26:56.0444 (UTC) FILETIME=[AAD6A7C0:01C9A244] X-Brightmail-Tracker: AAAAAA== Cc: Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 12:26:23 -0000 Hi, We had a looooong discussion about that (ua-loose-route vs Target), and = I really hope we should not go back there now. I think we should focus on whether we want to have this in H-I, as = currently proposed, or as a separate header. Regards, Christer =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: 11. maaliskuuta 2009 13:32 > To: Hadriel Kaplan; Shida Schubert; sip@ietf.org > Cc: Mary Barnes > Subject: Re: [Sip] Fwd: I-D=20 > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >=20 > Just to expand on what Hadriel says, the SIP Forum is=20 > addressing the case where a request is delivered by a SIP=20 > Service Provider to a SIP-PBX, the SIP-PBX having registered=20 > with the SIP-SP. The SIP-PBX needs to be in possession of the=20 > target, in order to route onwards correctly within the=20 > enterprise. If only the SIP-PBX's contact URI is available in=20 > the Request-URI, the SIP-PBX would have to look elsewhere for=20 > the target. In accordance with recent SIP WG agreements, this=20 > would be the History-Info header field, but that requires the=20 > present extension. >=20 > Advantages of putting the target in the Request-URI for this=20 > particular situation: > - This is where the SIP-PBX would normally expect to find the=20 > target when a request is received from elsewhere (e.g.,=20 > another SIP-PBX within the enterprise), so it is reasonable=20 > also to expect it there when received from a SIP SP. > - SIPConnect 1.1 will not require History-Info for any other=20 > purpose, so it would make it a mandatory specification for=20 > SIPConnect 1.1 just in order to solve this particular=20 > problem, thereby raising the bar for SPs and SIP-PBXs wanting=20 > to comply with the spec. > - We would need to define procedures for what to do if=20 > History-Info is absent from a received request or if there is=20 > no entry marked as 'istarget'. > - SIPConnect 1.1 is due for completion in the next few weeks,=20 > and cannot wait the usual IETF cycle time for History-Info=20 > update to hit the RFC Editor's queue. > - If History-Info is used anyway (for its original purpose),=20 > the history revealed when a request comes from a SIP-SP via a=20 > SIP-PBX to another proxy and finally to a UAS would be=20 > unnecessarily complicated and therefore confusing, because=20 > the target would be replaced by a contact and would then=20 > appear again at the next hop. >=20 > John > =20 >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > Hadriel Kaplan > > Sent: 11 March 2009 06:55 > > To: Shida Schubert; sip@ietf.org List > > Cc: Mary Barnes > > Subject: Re: [Sip] Fwd: I-D > > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > >=20 > >=20 > > At the risk of opening up a topic we have already agreed on, but in=20 > > the spirit of open communication... [how's that for an opener!?] > >=20 > > Are we absolutely sure we want to put this target-URI in the=20 > > History-Info header? > >=20 > > I am not asking this because I think it's hard. I am=20 > asking because I=20 > > am not sure it will be used. Several of us from this same WG are=20 > > involved in the SIP-Forum's SIP-Connect profile, and when=20 > faced with=20 > > either using this new History-Info mechanism for a=20 > target-uri delivery=20 > > issue, vs. > > not, we chose not to. And we were mostly the same people who liked=20 > > the idea of putting it in History-Info in the IETF! > > (myself included) But I am concerned that when given a reasonable=20 > > opportunity to use a mechanism we ourselves promote when wearing a=20 > > different hat, we chose not to use it in practice. It doesn't bode=20 > > well. :( > >=20 > > -hadriel > > p.s. sorry Mary for raising this, but there isn't much=20 > email traffic=20 > > anyway. :) > >=20 > > ________________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > Shida Schubert > > Sent: Wednesday, March 11, 2009 2:13 AM > > To: sip@ietf.org List > >=20 > > We have submitted the updated target-uri draft based on the=20 > comments=20 > > submitted to the list and comments received at IETF73. > >=20 > > I have taken over as editor as Jonathan didn't have the cycles to=20 > > update the draft, with Francois, Christer and Hans Erick as=20 > additional=20 > > co-authors and great deal of help from Mary. > > =A0 > > The following summarizes the changes made to the target-uri=20 > document=20 > > 1. Added use-case for toll-free number back 2. Added definition of=20 > > "retarget" operation. > > 3. Removed a reference to URN > > 4. Added a text discussing the difference to P-Called-Party-Id 5.=20 > > Changed parameter name from "target" to "istarget" > > =A0 > > Note, that the target-uri document still contains the=20 > normative text=20 > > for the History-Info header. > > =A0 > > In addition, Mary (with Francois as co-author) has submitted a=20 > > rfc4244bis, with the following changes: > > 1. Incorporated the normative aspects of the target-uri=20 > document into=20 > > the existing normative text in RFC 4244 - the functionality is=20 > > virtually identical (as is some of the text) as the HI=20 > based solution=20 > > described in the target-uri document. =A0It's important that the=20 > > solution be integrated into RFC 4244 as it MUST work and be=20 > based on=20 > > the normative aspects of RFC 4244. > > 2. =A0Added the use cases from target-uri the the summary in the=20 > > overview of rfc4244bis. > > 3. Added an additional requirement to capture the "target-uri"=20 > > information. > > 4. Fixed an error in the RFC 4244 ABNF and added "retarget"=20 > parameter. > > 5. Added a more simplified example. > > =A0 > > =A0 > > We had some very long offline exchanges as to the best way=20 > forward and=20 > > remaining work for both documents. > > =A0 > > Some of the issues identified are: > >=20 > > ::Issues:: > > =A0=A0 1. Should we remove the normative text from target-uri=20 > and progress > > =A0=A0 =A0 =A0 4244bis along with the target-uri document to meet = the=20 > > chartered > > =A0=A0 =A0 =A0SIP WG milestone? > > =A0 > > =A0 > > =A0=A0 2. Name of the parameter. > > =A0=A0 =A0 =A0At the last meeting, parameter "target" was said = inappropriate > > =A0=A0 =A0 =A0because voicemail-uri spec already defines a parameter = called > > =A0=A0 =A0 =A0"target" which also can be found in hi-entry, thus = potentially > > =A0=A0 =A0 =A0causing confusion. > > =A0=A0 =A0=A0 > > =A0=A0 =A0 =A0Currently the target-uri draft uses "istarget" and=20 > 4244bis uses > > =A0=A0 =A0 =A0"retarget" =A0but we could never come to > > =A0=A0 =A0 =A0a consensus on what name is appropriate. =A0Other=20 > suggestions have > > =A0=A0 =A0 =A0included the following: > > =A0=A0 =A0 =A0"target-identity" (someone didn't like that "identity" = > > is also a SIP header) > > =A0=A0 =A0 =A0"reg-uri" =A0(can be paired with "mapped-uri" for item = 3 below) > > =A0=A0 =A0 =A0"aor" > > =A0=A0 =A0 =A0"jibberish" > > =A0=A0 =A0 =A0etc. > > =A0 > > =A0=A0 =A0 =A0One reason this is so difficult relates to the=20 > problem statement=20 > > in target-uri in that > > =A0=A0 =A0 =A0RFC 3261 doesn't differentiate the mechanism by which = the new > > =A0=A0 =A0 =A0(target) Request-URI is selected. =A0Another issue is=20 > that some of=20 > > the terminology in > > =A0=A0 =A0 =A0RFC 3261 is overloaded - e.g., "forwarding" refers = both to a=20 > > Proxy > > =A0=A0 =A0 =A0which does not have responsibility for the domain of = the=20 > > request-URI > > =A0=A0 =A0 =A0in the incoming request, thus the proxy just = "forwards"=20 > > the request to > > =A0=A0 =A0 =A0the next hop AND "forwarding" is used to describe the = process=20 > > whereby > > =A0=A0 =A0 =A0the outgoing request is built and "forwarded" to the=20 > next hop at=20 > > which > > =A0=A0 =A0 =A0point the proxy does not know how the new request-uri = was=20 > > selected. > > =A0=A0 =A0 =A0RFC 4244 has attempted to clarify the terms and=20 > attempts to use=20 > > "forward" > > =A0=A0 =A0 =A0in the context of the former situation and "retarget"=20 > > for the case whereby > > =A0=A0 =A0 =A0a proxy is responsible for the domain and thus can=20 > use a number=20 > > of > > =A0=A0 =A0 =A0mechanism to select the new target for the request - = e.g., a=20 > > REGISTRAR, > > =A0=A0 =A0 =A0configured data, etc. > >=20 > > =A03. =A0Related to the last point in item 2 above, it has been=20 > proposed=20 > > that > > =A0=A0 =A0 =A0we differentiate the hi-entries even more by defining=20 > separate=20 > > parameters > > =A0=A0 =A0 for registered and configured/mapped contacts. > > =A0=A0 =A0 Currently when the R-URI is translated to a URI which=20 > is either=20 > > derived > > =A0=A0 =A0 from location service lookup(registered by UA) or from = mapping > > =A0=A0 =A0 table, there is no differentiation as to how the URI=20 > was derived=20 > > once it is > > =A0=A0 =A0 added to the list of potential targets. > > =A0=A0 =A0=A0 > > =A0=A0 =A0 The general consensus of the authors of the two documents = was=20 > > that it may > > =A0=A0 =A0 be useful for some services to have the hi-entries tagged = with=20 > > the > > =A0=A0 =A0 more specific information. > > =A0 > > =A0=A0 =A0 And, of course, this gets us into another naming=20 > contest. In the=20 > > end, the naming > > =A0=A0 =A0 is not so important as long as the term isn't too=20 > overloaded and=20 > > it is defined > > =A0=A0 =A0 precisely in the document(s). > > =A0 > > We would appreciate WG feedback on these issues and any=20 > other comments=20 > > on the two documents prior to IETF-74. > > =A0 > > Regards, > > Shida and Mary. > >=20 > >=20 > >=20 > > Begin forwarded message: > > From:=A0Internet-Drafts@ietf.org > > Date:=A0March 10, 2009 2:30:01 AM JST > > To:=A0i-d-announce@ietf.org > > Subject:=A0I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > Reply-To:=A0internet-drafts@ietf.org > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : Delivery of Request-URI Targets to User Agents > > Author(s) : J. Rosenberg, H. van Elburg, C.=20 > > Holmberg, F. Audet, S. Schubert > > Filename : draft-rosenberg-sip-target-uri-delivery-01.txt > > Pages : 16 > > Date : 2009-3-9 > > =09 > > When a Session Initiation Protocol (SIP) proxy receives a request > > =A0=A0targeted at a URI identifying a user or resource it is = responsible > > =A0=A0for, the proxy translates the URI to a registered or = configured > > =A0=A0contact URI of an agent representing that user or=20 > resource. =A0In the > > =A0=A0process, the original URI is removed from the request. =A0 > Numerous use > > =A0=A0cases have arisen which require this information to be=20 > delivered to > > =A0=A0the user agent. =A0This document describes these use cases=20 > and defines > > =A0=A0an extension to the History-Info header field which=20 > allows it to be > > =A0=A0used to support those cases. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target > -uri-delivery-01.txt > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > Content-Type: text/plain
Content-ID:=20 > > <2009-3-9102756.I-D@ietf.org>

> > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories:=A0http://www.ietf.org/shadow.html or=A0 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 From christer.holmberg@ericsson.com Wed Mar 11 05:55:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710923A6BB5 for ; Wed, 11 Mar 2009 05:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.721 X-Spam-Level: X-Spam-Status: No, score=-5.721 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr3INK9ipiMH for ; Wed, 11 Mar 2009 05:55:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B6C583A6B9B for ; Wed, 11 Mar 2009 05:55:03 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A1CF820B5D; Wed, 11 Mar 2009 13:55:38 +0100 (CET) X-AuditID: c1b4fb3c-af00dbb000001b43-63-49b7b4cae53f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 793B0206DA; Wed, 11 Mar 2009 13:55:38 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 13:55:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 13:55:07 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAAbBt5A= References: <20090304151501.4951728C331@core3.amsl.com> From: "Christer Holmberg" To: "Mary Barnes" , "Francois Audet" X-OriginalArrivalTime: 11 Mar 2009 12:55:38.0100 (UTC) FILETIME=[AD068340:01C9A248] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 12:55:09 -0000 Hi, My first comment/question on the draft: eventhough there are lots of examples, do we really need 46 pages? Are we really making History-Info more clear if we still need that many pages? I know my comment is not that useful, since I don't propose what to change/remove, but just as a general comment. Regards, Christer > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 04 March 2009 15:15 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sip-rfc4244bis-00.txt > Pages : 49 > Date : 2009-03-04 >=20 > This document defines a standard mechanism for capturing the=20 > history information associated with a Session Initiation=20 > Protocol (SIP) request. This capability enables many=20 > enhanced services by providing the information as to how and=20 > why a call arrives at a specific application or user. This=20 > document defines a new optional SIP header, History-Info, for=20 > capturing the history information in requests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 From christer.holmberg@ericsson.com Wed Mar 11 06:19:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815283A6BBB for ; Wed, 11 Mar 2009 06:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8GCRHPowOF8 for ; Wed, 11 Mar 2009 06:19:33 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 621163A682B for ; Wed, 11 Mar 2009 06:19:33 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 92AAD2175A; Wed, 11 Mar 2009 14:20:08 +0100 (CET) X-AuditID: c1b4fb3e-ad89dbb0000023da-2c-49b7ba88f28f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 61682215D8; Wed, 11 Mar 2009 14:20:08 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 14:20:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 14:20:06 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-199-06.txt Thread-Index: AcmbMKe+xsFi6kj+QB+gB2v3KJUGbABMpvRQAEOYpKAADKsk4AEpp3Cg References: <20090302121502.4C42D3A6858@core3.amsl.com> From: "Christer Holmberg" To: "Bob Penfield" X-OriginalArrivalTime: 11 Mar 2009 13:20:08.0194 (UTC) FILETIME=[19450E20:01C9A24C] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-ietf-sip-199-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 13:19:34 -0000 Hi Bob,=20 >>>In fact, if the proxy is keeping track of early dialogs, under what=20 >>>circumstances would it not be "able to identify additional early=20 >>>dialogs which are terminated by the same non-2xx final response"? >> >>Just because the proxy keeps track of early dialogs, it doesn't=20 >>necessarily know that an error response on early dialog X also=20 >>terminates early dialog Y. In order to know that, the forking proxy=20 >>needs to know that early dialogs X and Y come from the same forking=20 >>proxy further down the path. >> >=20 >Of course it can. If the proxy forwarded the request to Z,=20 >and Z forked to X and Y, the provisional responses from X and=20 >Y that created the early dialogs would have the same=20 >branch-id. The error response from Z would have that same=20 >branch-id. The proxy would know that all early dialogs=20 >created by a 1xx with that branch-id would have terminated=20 >(i.e. both X and Y). But, the branch-id is part of the Via, which is removed by each entity when forwarding the response. So, the forking proxy is never going to get the branch-id inserted by Z, is it? >>>Section 8 (199 Early Dialog Terminated) seems out of place. >>>Shouldn't this be in the introduction? or in an "Overview Of=20 >>>Operation" between sections 3 and 4? >> >>I have tried to use other similar drafts as "template". >> >> >>>The text in Section 9 (Usage with SDP offer/answer) should be in=20 >>>section 5 (User Agent Server behavior). >> >>I think it is good to have a separate chapter. Of course, I could refer=20 >>to chapter 9 from chapter 5. >=20 >My point is that all too often behavior requirements (MUST,=20 >SHOULD, MAY, etc.) get buried is separate sections and folks=20 >can miss them. If all the requirements are in the applicable=20 >"behavior" section, they are easy to find and developers are less likely=20 >to miss them. If you want it to be a separate section, make=20 >it 5.1. All UAS requirements should be in section 5 or a=20 >subsection thereof. > >>>The statement in section 10 recommending that the UAS send >>>199 unreliably should be in section 5. >>> >>>The statement in section 10 forbidding proxies from sending >>>199 reliably should be in section 6 (Proxy behavior). >> >>Same as for offer/answer. >> >>Since the 199 procedures related to offer/answer and reliable responses=20 >>are special, I think it is good to have specific chapters for it. >>=20 >The requirements/restrictions for reliable provisional=20 >responses are very important. They could easily be missed by=20 >having them in a separate chapter in the back of the=20 >document. Again, all UAS behavior requirements should be in=20 >section 5 (or sub-section) and all proxy behavior=20 >requirements should be in chapter 6 (or sub-section). I'll think of something. But, as you ok with the text as such? It's only the location of the text which you have an issue with? Regards, Christer From mary.barnes@nortel.com Wed Mar 11 06:21:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF47328C1D5 for ; Wed, 11 Mar 2009 06:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bibd7n2Q2FJb for ; Wed, 11 Mar 2009 06:21:09 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A7CDF3A6B5E for ; Wed, 11 Mar 2009 06:21:09 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2BDLhg04346; Wed, 11 Mar 2009 13:21:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 08:24:00 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCA60A6@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAAbBt5AAATu6gA== References: <20090304151501.4951728C331@core3.amsl.com> From: "Mary Barnes" To: "Christer Holmberg" , "Francois Audet" Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 13:21:10 -0000 Hi Christer,=20 Yes, we can remove a lot of the extra examples in the appendix - that was what we had in mind for the next revision, since they all need to be updated (all of them are dated in that they use strict routing). Also, since there is now a document like target-uri that has better use cases, we really don't need so many in the protocol spec. So, perhaps, you can consider adding some detailed flows to target-uri? =20 And, you have to keep in mind that the normative text in 4244 is comprised of about 12 pages (7-18), so yes the size of the document is misleading in terms of what really has to be implemented Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Wednesday, March 11, 2009 7:55 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: sip@ietf.org Subject: RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Hi, My first comment/question on the draft: eventhough there are lots of examples, do we really need 46 pages? Are we really making History-Info more clear if we still need that many pages? I know my comment is not that useful, since I don't propose what to change/remove, but just as a general comment. Regards, Christer > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 04 March 2009 15:15 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sip-rfc4244bis-00.txt > Pages : 49 > Date : 2009-03-04 >=20 > This document defines a standard mechanism for capturing the history=20 > information associated with a Session Initiation Protocol (SIP)=20 > request. This capability enables many enhanced services by providing=20 > the information as to how and why a call arrives at a specific=20 > application or user. This document defines a new optional SIP header, > History-Info, for capturing the history information in requests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 From lists@ohlmeier.org Wed Mar 11 06:49:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F13F3A68CF for ; Wed, 11 Mar 2009 06:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXpJnNE90gHC for ; Wed, 11 Mar 2009 06:49:16 -0700 (PDT) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 34DE03A6823 for ; Wed, 11 Mar 2009 06:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id AC6757F97; Wed, 11 Mar 2009 14:49:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMhUHbGHmnYG; Wed, 11 Mar 2009 14:49:50 +0100 (CET) Received: from www.ohlmeier.com (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 326917F82; Wed, 11 Mar 2009 14:49:50 +0100 (CET) Received: from 192.100.130.229 (SquirrelMail authenticated user lando) by www.ohlmeier.com with HTTP; Wed, 11 Mar 2009 14:49:50 +0100 (CET) Message-ID: <2ec0d47f2557274d61ca48882a379aa1.squirrel@www.ohlmeier.com> In-Reply-To: <49B77BEB.4000501@iptel.org> References: <49AE593F.6080807@iptel.org> <20090307183313.GA4364@x61s.janakj.ryngle.net> <49B2F7F2.6030804@ohlmeier.org> <49B5006D.8050702@iptel.org> <49B63B9F.9000101@iptel.org> <49B77BEB.4000501@iptel.org> Date: Wed, 11 Mar 2009 14:49:50 +0100 (CET) From: "Nils Ohlmeier" To: "Raphael Coeffic" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Nils Ohlmeier , "sip@ietf.org" , Hadriel Kaplan Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 13:49:17 -0000 > Hadriel Kaplan wrote: >> >>> -----Original Message----- >>> From: Raphael Coeffic [mailto:rco@iptel.org] >>> Sent: Tuesday, March 10, 2009 6:06 AM >>> >>> Hadriel Kaplan wrote: >>> >>> Forcing registrations is the path that IMS went for, I believe. But if >>> you want to take advantage of this, you may have to deploy a little >>> more >>> IMS than you'd like to. >>> >> >> The concept and practice of "forcing" UA's, which have AoR's belonging >> to a domain, to REGISTER their contact binding for those AoR's in order >> to make calls, has been around a lot longer than IMS has. Invoking the >> "that sounds like IMS" defense is a cheap guilt-by-association argument, >> and not relevant. One might as well argue that using INVITE's or RTP >> "is the path that IMS went for". >> >> You keep making it sound like sending a SIP request which does not >> create a dialog is somehow a difficult mechanism to implement, or >> "forces" people to do something they don't want to. What is it forcing? >> >> > Well, it is not required as per RFC 3261 ;-) > >> You're looking for a means of authenticating a UA without being subject >> to a relay attack. Using a different SIP Method name, which can only be >> initiated by the client with the credentials, and one that UA's cannot >> be baited to provide by random third parties, is one solution to the >> problem. If you don't like the string "REGISTER", then how about >> "OPTIONS"? >> >> > No, I think you missunderstood me. I still think that requiring a > registration and checking the source IP and port against the registered > contact is a fair measure to take. However, it introduces more traffic > in some scenarios, where it is not necessarily needed. REGISTERs could > become the "background load" in the servers. This also puts a lot of > state into some proxies that does not need it, etc... > My concern is just that it seems like there is no better solution. Sure to create a Contact binding via an authenticated REGISTER is one possible solution. But I think this only works because you rely on the fact that REGISTERs are not being retargeted like INVITEs. Which then in the end means you simply can forget about authenticating all other requests, as long as the Contact or IP/port was successfully authenticated via the "one hop" REGISTER method (refer-to: IMS). The advantage of this solution is clearly that it can be easily deployed by hopefully most of the service providers today. But I believe the proper technical solution would be that the server authenticates itself in the challenge, plus adding protected informations to the challenge which allows the receiver of the challenge to verify that this challenge was/is targeted to himself. The dis-advantage is clearly that this would be only possible with extensions of the existing protocols. But we would/might gain other benefits by such a solution as well. Regards Nils Ohlmeier From mary.barnes@nortel.com Wed Mar 11 09:23:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2196228C144 for ; Wed, 11 Mar 2009 09:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7xOA8IJCsxa for ; Wed, 11 Mar 2009 09:23:52 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 12B1C28C0D9 for ; Wed, 11 Mar 2009 09:23:51 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2BGNvF23690; Wed, 11 Mar 2009 16:23:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 11:26:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCA66E4@zrc2hxm0.corp.nortel.com> In-Reply-To: <4CE1C789-127F-4495-A1C6-65EB3E2E9E54@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiE+DnTOrRhEI3TZuBywdic+rY4wAUfXyw References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <4CE1C789-127F-4495-A1C6-65EB3E2E9E54@softarmor.com> From: "Mary Barnes" To: "Dean Willis" , "Shida Schubert" Cc: sip@ietf.org Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 16:23:53 -0000 I don't think it should cause so much concern as I think it just requires clarifying text and we just need to agree to more precise terms: e.g., qualifying the use of "forward" with either "next hop forwarding" or "request forwarding" for this particular case. As long as we can be precise in 4244bis, then that should suffice for now, but whenever 3261 is updated or bised, then I think the clarifications should be included. Mary.=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Wednesday, March 11, 2009 1:38 AM To: Shida Schubert Cc: sip@ietf.org List; Barnes, Mary (RICH2:AR00) Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt On Mar 11, 2009, at 1:13 AM, Shida Schubert wrote: > > One reason this is so difficult relates to the problem statement > in target-uri in that > RFC 3261 doesn't differentiate the mechanism by which the new > (target) Request-URI is selected. Another issue is that some of > the terminology in > RFC 3261 is overloaded - e.g., "forwarding" refers both to a=20 > Proxy > which does not have responsibility for the domain of the=20 > request-URI > in the incoming request, thus the proxy just "forwards" the=20 > request to > the next hop AND "forwarding" is used to describe the process=20 > whereby > the outgoing request is built and "forwarded" to the next hop at > which > point the proxy does not know how the new request-uri was=20 > selected. > RFC 4244 has attempted to clarify the terms and attempts to use=20 > "forward" > in the context of the former situation and "retarget" for the=20 > case whereby > a proxy is responsible for the domain and thus can use a number=20 > of > mechanism to select the new target for the request - e.g., a=20 > REGISTRAR, > configured data, etc. > Thanks, Shida. I personally would not be averse to an Essential Correction that corrects the terminology in RFC 3261, but I suspect that will make many heads spin around elsewhere in the WG. -- Dean From mary.barnes@nortel.com Wed Mar 11 09:36:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406003A69C1 for ; Wed, 11 Mar 2009 09:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryWpB+CCqb47 for ; Wed, 11 Mar 2009 09:36:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CA0523A6AF8 for ; Wed, 11 Mar 2009 09:36:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2BGang06649; Wed, 11 Mar 2009 16:36:49 GMT 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: Wed, 11 Mar 2009 11:39:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AAAnCqAABTTs+A= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> From: "Mary Barnes" To: "Hadriel Kaplan" , "Shida Schubert" , Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 16:36:29 -0000 Yeah, we can define a new header and just ignore the use of a basic SIP = building block that the WG spent 2.5 years (note this doesn't include = the 2+ years spent on the doc as an individual and as a SIPPING WG = document ;) And, while we're at it, let's just go ahead and obsolete = 4244 altogether and standardize diversion (something the WG rejected = almost a decade ago). That will make one vendor and a handful of SPs = very happy and those of us that have implemented the specs can ripout = some code after while when we have some spare change to pay folks to do = so (and of course, this is after the folks that have not implemented = diversion actually implement it - there are actually some of those out = there).=20 As an aside, this is another fine example as to why we don't seem to = make great progress or produce specs that are deemed useful - we agree = on a way forward and then change our minds later (sometimes for good = reasons and sometimes because a shortcut seems easier or it's just = arbitrary based on the phase of the moon it seems). =20 Mary.=20 -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Wednesday, March 11, 2009 1:55 AM To: Shida Schubert; sip@ietf.org List Cc: Barnes, Mary (RICH2:AR00) Subject: RE: [Sip] Fwd: I-D = ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt At the risk of opening up a topic we have already agreed on, but in the = spirit of open communication... [how's that for an opener!?] Are we absolutely sure we want to put this target-URI in the = History-Info header? I am not asking this because I think it's hard. I am asking because I = am not sure it will be used. Several of us from this same WG are = involved in the SIP-Forum's SIP-Connect profile, and when faced with = either using this new History-Info mechanism for a target-uri delivery = issue, vs. not, we chose not to. And we were mostly the same people who = liked the idea of putting it in History-Info in the IETF! (myself = included) But I am concerned that when given a reasonable opportunity = to use a mechanism we ourselves promote when wearing a different hat, we = chose not to use it in practice. It doesn't bode well. :( -hadriel p.s. sorry Mary for raising this, but there isn't much email traffic = anyway. :) ________________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Shida Schubert Sent: Wednesday, March 11, 2009 2:13 AM To: sip@ietf.org List We have submitted the updated target-uri draft based on the comments = submitted to the list and comments received at IETF73.=A0 I have taken over as editor as Jonathan didn't have the cycles to update = the draft, with Francois, Christer and Hans Erick as additional = co-authors and great deal of help from Mary. =A0 =A0 The following summarizes the changes made to the target-uri document 1. = Added use-case for toll-free number back 2. Added definition of = "retarget" operation. 3. Removed a reference to URN 4. Added a text = discussing the difference to P-Called-Party-Id 5. Changed parameter name = from "target" to "istarget" =A0 Note, that the target-uri document still contains the normative text for = the History-Info header. =A0 In addition, Mary (with Francois as co-author) has submitted a = rfc4244bis, with the following changes: 1. Incorporated the normative aspects of the target-uri document into = the existing normative text in RFC 4244 - the functionality is virtually = identical (as is some of the text) as the HI based solution described in = the target-uri document. =A0It's important that the solution be = integrated into RFC 4244 as it MUST work and be based on the normative = aspects of RFC 4244. 2. =A0Added the use cases from target-uri the the summary in the = overview of rfc4244bis. 3. Added an additional requirement to capture the "target-uri" = information. 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. 5. Added a more simplified example. =A0 =A0 We had some very long offline exchanges as to the best way forward and remaining work for both documents. =A0 Some of the issues identified are: ::Issues:: =A0=A0 1. Should we remove the normative text from target-uri and = progress =A0=A0 =A0 =A0 4244bis along with the target-uri document to meet the = chartered =A0=A0 =A0 =A0SIP WG milestone?=A0 =A0 =A0 =A0=A0 2. Name of the parameter.=A0 =A0=A0 =A0 =A0At the last meeting, parameter "target" was said = inappropriate=A0 =A0=A0 =A0 =A0because voicemail-uri spec already defines a parameter = called=A0 =A0=A0 =A0 =A0"target" which also can be found in hi-entry, thus = potentially=A0 =A0=A0 =A0 =A0causing confusion. =A0=A0 =A0=A0 =A0=A0 =A0 =A0Currently the target-uri draft uses "istarget" and 4244bis = uses =A0=A0 =A0 =A0"retarget" =A0but we could never come to=A0 =A0=A0 =A0 =A0a consensus on what name is appropriate. =A0Other = suggestions have =A0=A0 =A0 =A0included the following: =A0=A0 =A0 =A0"target-identity" (someone didn't like that "identity" is = also a SIP header) =A0=A0 =A0 =A0"reg-uri" =A0(can be paired with "mapped-uri" for item 3 = below) =A0=A0 =A0 =A0"aor" =A0=A0 =A0 =A0"jibberish"=A0 =A0=A0 =A0 =A0etc. =A0 =A0=A0 =A0 =A0One reason this is so difficult relates to the problem = statement in target-uri in that =A0=A0 =A0 =A0RFC 3261 doesn't differentiate the mechanism by which the = new =A0=A0 =A0 =A0(target) Request-URI is selected. =A0Another issue is that = some of the terminology in =A0=A0 =A0 =A0RFC 3261 is overloaded - e.g., "forwarding" refers both to = a Proxy =A0=A0 =A0 =A0which does not have responsibility for the domain of the = request-URI =A0=A0 =A0 =A0in the incoming request, thus the proxy just "forwards" = the request to =A0=A0 =A0 =A0the next hop AND "forwarding" is used to describe the = process whereby =A0=A0 =A0 =A0the outgoing request is built and "forwarded" to the next = hop at which =A0=A0 =A0 =A0point the proxy does not know how the new request-uri was = selected. =A0=A0 =A0 =A0RFC 4244 has attempted to clarify the terms and attempts = to use "forward"=A0 =A0=A0 =A0 =A0in the context of the former situation and "retarget" for = the case whereby =A0=A0 =A0 =A0a proxy is responsible for the domain and thus can use a = number of=A0 =A0=A0 =A0 =A0mechanism to select the new target for the request - e.g., = a REGISTRAR,=A0 =A0=A0 =A0 =A0configured data, etc. =A0 =A03. =A0Related to the last point in item 2 above, it has been proposed = that =A0=A0 =A0 =A0we differentiate the hi-entries even more by defining = separate parameters =A0=A0 =A0 for registered and configured/mapped contacts.=A0 =A0=A0 =A0 Currently when the R-URI is translated to a URI which is = either derived=A0 =A0=A0 =A0 from location service lookup(registered by UA) or from = mapping=A0 =A0=A0 =A0 table, there is no differentiation as to how the URI was = derived once it is =A0=A0 =A0 added to the list of potential targets. =A0=A0 =A0=A0 =A0=A0 =A0 The general consensus of the authors of the two documents was = that it may=A0 =A0=A0 =A0 be useful for some services to have the hi-entries tagged = with the =A0=A0 =A0 more specific information.=A0 =A0 =A0=A0 =A0 And, of course, this gets us into another naming contest. In = the end, the naming =A0=A0 =A0 is not so important as long as the term isn't too overloaded = and it is defined =A0=A0 =A0 precisely in the document(s). =A0 We would appreciate WG feedback on these issues and any other comments = on the two documents prior to IETF-74. =A0 Regards, Shida and Mary. Begin forwarded message: From:=A0Internet-Drafts@ietf.org Date:=A0March 10, 2009 2:30:01 AM JST To:=A0i-d-announce@ietf.org Subject:=A0I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=A0 Reply-To:=A0internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=A0 directories. Title : Delivery of Request-URI Targets to User Agents Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. = Schubert Filename : draft-rosenberg-sip-target-uri-delivery-01.txt Pages : 16 Date : 2009-3-9 =09 When a Session Initiation Protocol (SIP) proxy receives a request =A0=A0targeted at a URI identifying a user or resource it is responsible =A0=A0for, the proxy translates the URI to a registered or configured =A0=A0contact URI of an agent representing that user or resource. =A0In = the =A0=A0process, the original URI is removed from the request. =A0Numerous = use =A0=A0cases have arisen which require this information to be delivered = to =A0=A0the user agent. =A0This document describes these use cases and = defines =A0=A0an extension to the History-Info header field which allows it to = be =A0=A0used to support those cases. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-delive= ry-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain
Content-ID: = <2009-3-9102756.I-D@ietf.org>

_______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories:=A0http://www.ietf.org/shadow.html or=A0ftp://ftp.ietf.org/ietf/1shadow-sites.txt From HKaplan@acmepacket.com Wed Mar 11 09:44:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B595D3A6881 for ; Wed, 11 Mar 2009 09:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCHQBBQ6+k4J for ; Wed, 11 Mar 2009 09:44:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3430E3A679F for ; Wed, 11 Mar 2009 09:44:03 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 12:44:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 11 Mar 2009 12:44:38 -0400 From: Hadriel Kaplan To: Christer Holmberg , "Elwell, John" , Shida Schubert , "sip@ietf.org" Date: Wed, 11 Mar 2009 12:44:37 -0400 Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AAAnCqAAAoWh+AAAjrwAAAITT8Q Message-ID: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <0D5F89FAC29E2C41B98A6A762007F5D0019F797F@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 16:44:08 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, March 11, 2009 8:27 AM > To: Elwell, John; Hadriel Kaplan; Shida Schubert; sip@ietf.org >=20 > We had a looooong discussion about that (ua-loose-route vs Target), and I > really hope we should not go back there now. I wouldn't have, were it not for the Sip-Forum experience. If a bunch of p= eople who spent time on the topic don't even want to use the mechanism, wha= t hopes do we have that it will succeed in the marketplace? =20 And don't get me wrong - it could have been in a "Target" header too and we= wouldn't have used that either, I think. Although part of the reason is b= ecause we know IP-PBX's actually support Jonathan's original ua-loose-route= concept (just without the Route header part), whereas I'm not so sure what= legacy endpoints will do with an AoR-req-uri; nor whether the req-uri woul= d ever survive end-to-end in Peering cases. =20 So I was in favor of doing a separate Header because it was "safer", in ter= ms of not breaking interoperability - but it's less chance for actually get= ting used, which in a way does break something too (customer expectations).= Ugh. Screwed either way. -hadriel From mary.barnes@nortel.com Wed Mar 11 09:49:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B853A6AA6 for ; Wed, 11 Mar 2009 09:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ3M16PbWFkm for ; Wed, 11 Mar 2009 09:49:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A04523A6A7D for ; Wed, 11 Mar 2009 09:49:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2BGoBF00524; Wed, 11 Mar 2009 16:50:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 11:52:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimA= References: <20090304151501.4951728C331@core3.amsl.com> From: "Mary Barnes" To: "Ian Elz" , "Francois Audet" Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 16:49:58 -0000 Ian, This is an interesting question. I need to think about it some more, but I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain. My initial thought is that we can't overrule the overall Privacy header. The thing is that the Privacy header doesn't preclude gathering the information and using within a domain AND if it were to not include an hi-entry when the request leaves the domain for which the proxy is responsible, the recipient can add the hi-entry for the current request-uri before it adds the new hi-entry. =20 Your PSTN example doesn't strictly map obviously to a SIP model and I would think you might consider the PSTN hop to be within the same domain for which the proxy (or gw, I guess) is responsible OR consider this a walled garden whereby the Privacy header doesn't apply. Which brings me to a more general question as to how you all deal with other headers when you do your mapping to the PSTN when there is a Privacy header? It would seem this problem isn't unique to History-Info, although I know little about the details of PSTN I/W. Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Wednesday, March 11, 2009 4:54 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 04 March 2009 15:15 To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From mary.barnes@nortel.com Wed Mar 11 10:00:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624B23A6A2B for ; Wed, 11 Mar 2009 10:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.368 X-Spam-Level: X-Spam-Status: No, score=-5.368 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aAlFYSyKXkt for ; Wed, 11 Mar 2009 10:00:07 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 23B333A69FC for ; Wed, 11 Mar 2009 10:00:07 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2BH0BF04080; Wed, 11 Mar 2009 17:00:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A26A.DDE885DB" Date: Wed, 11 Mar 2009 12:02:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiJ5zOiVysWQbQT/KF8j+gwmH1/wAQqKng References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" , "Shida Schubert" Cc: sip@ietf.org Subject: [Sip] Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:00:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A26A.DDE885DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And, I think the big issue with the terminology is that 4244bis is application agnostic, so it is tagging what happens to the URIs (why/how the specific URI was overwritten). Whereas, specific applications can derive information, such as what "is" the real "target" for the request, from the History-Info header. So, IMHO, it's a matter of the target-uri document specifying that the last entry tagged by whatever name we come up with "is" the real "target" for the request. I believe it's up to the applications to describe how they make use of the History-Info and not for the History-Info to describe how applications can use it. History-Info purely reflects what happened from a SIP Protocol perspective and should not imply any application semantics. Indeed the intent of section 5 of 4244 was to inform the applications how they should decribe their usage of the header.=20 =20 Mary.=20 Note: I changed the subject to hopefully make this topic easier to keep track of.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, March 11, 2009 3:59 AM To: Shida Schubert Cc: sip@ietf.org List; Barnes, Mary (RICH2:AR00) Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt One of the problems that made the discussion quite tedious is the complete inversed meaning of the terms "retarget" and "reroute" between 4244bis and target-uri factions have. Conclusion was that the terminology need to be properly defined and some attempt was made to start such activity. On 3. I have strong concerns when we start tagging the URI as to how they come about "retarget"/"mapped conficuration" etc. It is better to embellish them with a tag that just represents there meaning for example "istarget" or "hop". For the following reasons: 1. It is much more intuitive for the user of this information, its meaning can basically be guessed. 2. Such meaning also probably survives application in other problem spaces that we had not foreseen when introducing the concept. The solution that is described now in the target-URI delivery draft is not yet complete, it does not solve the freephone use case for example and in its current form it will deliver exactly the same target-URI as that which would be delivered by the P-Called-Party-ID header. Contrary to what the draft says. So some work is needed still. /Hans Erik van Elburg On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert wrote: We have submitted the updated target-uri draft based on the comments=20 submitted to the list and comments received at IETF73.=20 I have taken over as editor as Jonathan didn't have the cycles to=20 update the draft, with Francois, Christer and Hans Erick as additional=20 co-authors and great deal of help from Mary. =20 =20 The following summarizes the changes made to the target-uri document 1. Added use-case for toll-free number back 2. Added definition of "retarget" operation.=20 3. Removed a reference to URN 4. Added a text discussing the difference to P-Called-Party-Id 5. Changed parameter name from "target" to "istarget" =20 Note, that the target-uri document still contains the normative text for the History-Info header. =20 In addition, Mary (with Francois as co-author) has submitted a rfc4244bis, with the following changes: 1. Incorporated the normative aspects of the target-uri document into the existing normative text in RFC 4244 - the functionality is=20 virtually identical (as is some of the text) as the HI based solution=20 described in the target-uri document. It's important that the solution be integrated into RFC 4244 as it MUST work and be based on the normative aspects of RFC 4244. 2. Added the use cases from target-uri the the summary in the overview of rfc4244bis. 3. Added an additional requirement to capture the "target-uri" information. 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. 5. Added a more simplified example. =20 =20 We had some very long offline exchanges as to the best way forward and remaining work for both documents. =20 Some of the issues identified are: ::Issues:: 1. Should we remove the normative text from target-uri and progress 4244bis along with the target-uri document to meet the chartered SIP WG milestone?=20 =20 =20 2. Name of the parameter.=20 At the last meeting, parameter "target" was said inappropriate=20 because voicemail-uri spec already defines a parameter called=20 "target" which also can be found in hi-entry, thus potentially=20 causing confusion. =20 Currently the target-uri draft uses "istarget" and 4244bis uses "retarget" but we could never come to=20 a consensus on what name is appropriate. Other suggestions have included the following: "target-identity" (someone didn't like that "identity" is also a SIP header) "reg-uri" (can be paired with "mapped-uri" for item 3 below) "aor" "jibberish"=20 etc. =20 One reason this is so difficult relates to the problem statement in target-uri in that RFC 3261 doesn't differentiate the mechanism by which the new (target) Request-URI is selected. Another issue is that some of the terminology in RFC 3261 is overloaded - e.g., "forwarding" refers both to a Proxy which does not have responsibility for the domain of the request-URI in the incoming request, thus the proxy just "forwards" the request to the next hop AND "forwarding" is used to describe the process whereby the outgoing request is built and "forwarded" to the next hop at which point the proxy does not know how the new request-uri was selected. RFC 4244 has attempted to clarify the terms and attempts to use "forward"=20 in the context of the former situation and "retarget" for the case whereby a proxy is responsible for the domain and thus can use a number of=20 mechanism to select the new target for the request - e.g., a REGISTRAR,=20 configured data, etc. =20 3. Related to the last point in item 2 above, it has been proposed that we differentiate the hi-entries even more by defining separate parameters for registered and configured/mapped contacts.=20 Currently when the R-URI is translated to a URI which is either derived=20 from location service lookup(registered by UA) or from mapping=20 table, there is no differentiation as to how the URI was derived once it is added to the list of potential targets. =20 The general consensus of the authors of the two documents was that it may=20 be useful for some services to have the hi-entries tagged with the more specific information.=20 =20 And, of course, this gets us into another naming contest. In the end, the naming is not so important as long as the term isn't too overloaded and it is defined precisely in the document(s). =20 We would appreciate WG feedback on these issues and any other comments on the two documents prior to IETF-74. =20 Regards, Shida and Mary. Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 10, 2009 2:30:01 AM JST To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =09 =09 Title : Delivery of Request-URI Targets to User Agents Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert Filename : draft-rosenberg-sip-target-uri-delivery-01.txt Pages : 16 Date : 2009-3-9 =09 When a Session Initiation Protocol (SIP) proxy receives a request targeted at a URI identifying a user or resource it is responsible for, the proxy translates the URI to a registered or configured contact URI of an agent representing that user or resource. In the process, the original URI is removed from the request. Numerous use cases have arisen which require this information to be delivered to the user agent. This document describes these use cases and defines an extension to the History-Info header field which allows it to be used to support those cases. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-deliv ery-01.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 Content-Type: text/plain
Content-ID: <2009-3-9102756.I-D@ietf.org>

=20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C9A26A.DDE885DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
And, I=20 think the big issue with the terminology is that 4244bis is application=20 agnostic, so it is tagging what happens to the URIs (why/how the = specific URI=20 was overwritten).  Whereas, specific applications can derive = information,=20 such as what "is" the real "target" for the request, from = the History-Info=20 header.   So, IMHO, it's a matter of the target-uri document = specifying=20 that the last entry tagged by whatever name we come up with "is" the = real=20 "target" for the request.  I believe it's up to the applications to = describe how they make use of the History-Info and not for the = History-Info to=20 describe how applications can use it.  History-Info purely reflects = what=20 happened from a SIP Protocol perspective and should not imply=20 any application semantics. Indeed the intent of section 5 of 4244 = was to=20 inform the applications how they should decribe their usage of the = header.=20
 
Mary.=20
Note:=20 I changed the subject to hopefully make this topic easier to keep track = of.=20

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, March 11, = 2009 3:59=20 AM
To: Shida Schubert
Cc: sip@ietf.org List; Barnes, = Mary=20 (RICH2:AR00)
Subject: Re: [Sip] Fwd: I-D=20 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

One of the problems that made the discussion quite tedious is = the=20 complete inversed meaning of the terms "retarget" and "reroute" between = 4244bis=20 and target-uri factions have.

Conclusion was that the terminology = need to=20 be properly defined and some attempt was made to start such = activity.

On=20 3. I have strong concerns when we start tagging the URI as to how they = come=20 about "retarget"/"mapped conficuration" etc. It is better to embellish = them with=20 a tag that just represents there meaning for example "istarget" or = "hop". For=20 the following reasons:
1. It is much more intuitive for the user of = this=20 information, its meaning can basically be guessed.
2. Such meaning = also=20 probably survives application in other problem spaces that we had not = foreseen=20 when introducing the concept.

The solution that is  = described now in=20 the target-URI delivery draft is not yet complete, it does not solve the = freephone use case for example and in its current form it will deliver = exactly=20 the same target-URI as that which would be delivered by the =20 P-Called-Party-ID header. Contrary to what the draft says. So some work = is=20 needed still.

/Hans Erik van Elburg


On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert = <shida@ntt-at.com>=20 wrote:

We have submitted the updated target-uri draft based on the=20 comments 
submitted to the list and comments received at = IETF73. 

I have taken over as editor as Jonathan didn't have the cycles=20 to 
update the draft, with Francois, Christer and Hans Erick as=20 additional 
co-authors and great deal of help from Mary.  
 
The following summarizes the changes made to the target-uri=20 document
1. Added use-case for toll-free number back
2. Added definition of "retarget" operation. 
3. Removed a reference to URN
4. Added a text discussing the difference to = P-Called-Party-Id
5. Changed parameter name from "target" to "istarget"
 
Note, that the target-uri document still contains the normative = text for=20 the
History-Info header.
 
In addition, Mary (with Francois as co-author) has submitted = a
rfc4244bis, with the following changes:
1. Incorporated the normative aspects of the target-uri = document
into the existing normative text in RFC 4244 - the functionality=20 is 
virtually identical (as is some of the text) as the HI based=20 solution 
described in the target-uri document.  It's important that = the=20 solution
be integrated into RFC 4244 as it MUST work and be based on the=20 normative
aspects of RFC 4244.
2.  Added the use cases from target-uri the the = summary
in the overview of rfc4244bis.
3. Added an additional requirement to capture the "target-uri"=20 information.
4. Fixed an error in the RFC 4244 ABNF and added "retarget"=20 parameter.
5. Added a more simplified example.
 
 
We had some very long offline exchanges as to the best way = forward=20 and
remaining work for both documents.
 
Some of the issues identified are:

::Issues::
   1. Should we remove the normative text from = target-uri and=20 progress
       4244bis along with the target-uri = document to=20 meet the chartered
      SIP WG milestone? 
 
 
   2. Name of the parameter. 
      At the last meeting, parameter "target" = was=20 said inappropriate 
      because voicemail-uri spec already = defines a=20 parameter called 
      "target" which also can be found in = hi-entry,=20 thus potentially 
      causing confusion.
     
      Currently the target-uri draft uses = "istarget"=20 and 4244bis uses
      "retarget"  but we could never = come=20 to 
      a consensus on what name is = appropriate.=20  Other suggestions have
      included the following:
      "target-identity" (someone didn't like = that=20 "identity" is also a SIP header)
      "reg-uri"  (can be paired with=20 "mapped-uri" for item 3 below)
      "aor"
      "jibberish" 
      etc.
 
      One reason this is so difficult relates = to the=20 problem statement in target-uri in that
      RFC 3261 doesn't differentiate the = mechanism by=20 which the new
      (target) Request-URI is selected. =  Another=20 issue is that some of the terminology in
      RFC 3261 is overloaded - e.g., = "forwarding"=20 refers both to a Proxy
      which does not have responsibility for = the=20 domain of the request-URI
      in the incoming request, thus the proxy = just=20 "forwards" the request to
      the next hop AND "forwarding" is used = to=20 describe the process whereby
      the outgoing request is built and = "forwarded"=20 to the next hop at which
      point the proxy does not know how the = new=20 request-uri was selected.
      RFC 4244 has attempted to clarify the = terms and=20 attempts to use "forward" 
      in the context of the former situation = and=20 "retarget" for the case whereby
      a proxy is responsible for the domain = and thus=20 can use a number of 
      mechanism to select the new target for = the=20 request - e.g., a REGISTRAR, 
      configured data, etc.  

 3.  Related to the last point in item 2 above, it has = been=20 proposed that
      we differentiate the hi-entries even = more by=20 defining separate parameters
     for registered and configured/mapped=20 contacts. 
     Currently when the R-URI is translated to a = URI which=20 is either derived 
     from location service lookup(registered by = UA) or=20 from mapping 
     table, there is no differentiation as to how = the URI=20 was derived once it is
     added to the list of potential targets.
     
     The general consensus of the authors of the = two=20 documents was that it may 
     be useful for some services to have the = hi-entries=20 tagged with the
     more specific information. 
 
     And, of course, this gets us into another = naming=20 contest. In the end, the naming
     is not so important as long as the term isn't = too=20 overloaded and it is defined
     precisely in the document(s).
 
We would appreciate WG feedback on these issues and any other = comments=20 on
the two documents prior to IETF-74.
 
Regards,
Shida and Mary.



Begin forwarded message:
From: Internet-Drafts@ietf.org
Date: March 10, 2009 2:30:01 AM JST
To: i-d-announce@ietf.org
Subject: I-D=20 = ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt 

A New Internet-Draft is available from the on-line=20 Internet-Drafts 
directories.


Title=20 : Delivery of = Request-URI=20 Targets to User Agents
Author(s)=20 : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S.=20 Schubert
Filename :=20 draft-rosenberg-sip-target-uri-delivery-01.txt
Pages=20 : 16
Date=20 : 2009-3-9

When a Session Initiation = Protocol (SIP)=20 proxy receives a request
  targeted at a URI = identifying a user=20 or resource it is responsible
  for, the proxy = translates the=20 URI to a registered or configured
  contact URI of an = agent=20 representing that user or resource.  In = the
  process, the=20 original URI is removed from the request.  Numerous=20 use
  cases have arisen which require this information = to be=20 delivered to
  the user agent.  This document = describes=20 these use cases and defines
  an extension to the = History-Info=20 header field which allows it to be
  used to support = those=20 cases.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-t= arget-uri-delivery-01.txt

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

Below = is the=20 data which will enable a MIME compliant mail = reader
implementation to=20 automatically retrieve the ASCII version of=20 the
Internet-Draft.
Content-Type: = text/plain<BR>Content-ID: &lt;2009-3-9102756.I-D@ietf.org&gt;<BR><BR&g= t;
_______________________________________________
I-D-Announce = mailing=20 list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft=20 directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

______________________________________= _________
Sip=20 mailing list  https://www.ietf.org/mailman/listinfo/sip
This = list is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip

------_=_NextPart_001_01C9A26A.DDE885DB-- From mary.barnes@nortel.com Wed Mar 11 10:03:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DBCB3A692D for ; Wed, 11 Mar 2009 10:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.345 X-Spam-Level: X-Spam-Status: No, score=-5.345 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQBC0Fy4YiWN for ; Wed, 11 Mar 2009 10:03:48 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E92A43A68B5 for ; Wed, 11 Mar 2009 10:03:47 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2BH3qF07147; Wed, 11 Mar 2009 17:03:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A26B.63D0589F" Date: Wed, 11 Mar 2009 12:06:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCA6843@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiJ5zOiVysWQbQT/KF8j+gwmH1/wAQqKngAABN5gA= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> From: "Mary Barnes" To: "Mary Barnes" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:03:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A26B.63D0589F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW - in the end, I really don't care what we call the tag - the term just needs to be precisely defined and I'd rather it not be based on a term in RFC 3261 that is already overloaded and doesn't precisely match the semantics for the tag in 4244bis. ________________________________ From: Barnes, Mary (RICH2:AR00)=20 Sent: Wednesday, March 11, 2009 12:03 PM To: 'Hans Erik van Elburg'; Shida Schubert Cc: sip@ietf.org List Subject: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt And, I think the big issue with the terminology is that 4244bis is application agnostic, so it is tagging what happens to the URIs (why/how the specific URI was overwritten). Whereas, specific applications can derive information, such as what "is" the real "target" for the request, from the History-Info header. So, IMHO, it's a matter of the target-uri document specifying that the last entry tagged by whatever name we come up with "is" the real "target" for the request. I believe it's up to the applications to describe how they make use of the History-Info and not for the History-Info to describe how applications can use it. History-Info purely reflects what happened from a SIP Protocol perspective and should not imply any application semantics. Indeed the intent of section 5 of 4244 was to inform the applications how they should decribe their usage of the header.=20 =20 Mary.=20 Note: I changed the subject to hopefully make this topic easier to keep track of.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, March 11, 2009 3:59 AM To: Shida Schubert Cc: sip@ietf.org List; Barnes, Mary (RICH2:AR00) Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt One of the problems that made the discussion quite tedious is the complete inversed meaning of the terms "retarget" and "reroute" between 4244bis and target-uri factions have. Conclusion was that the terminology need to be properly defined and some attempt was made to start such activity. On 3. I have strong concerns when we start tagging the URI as to how they come about "retarget"/"mapped conficuration" etc. It is better to embellish them with a tag that just represents there meaning for example "istarget" or "hop". For the following reasons: 1. It is much more intuitive for the user of this information, its meaning can basically be guessed. 2. Such meaning also probably survives application in other problem spaces that we had not foreseen when introducing the concept. The solution that is described now in the target-URI delivery draft is not yet complete, it does not solve the freephone use case for example and in its current form it will deliver exactly the same target-URI as that which would be delivered by the P-Called-Party-ID header. Contrary to what the draft says. So some work is needed still. /Hans Erik van Elburg On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert wrote: We have submitted the updated target-uri draft based on the comments=20 submitted to the list and comments received at IETF73.=20 I have taken over as editor as Jonathan didn't have the cycles to=20 update the draft, with Francois, Christer and Hans Erick as additional=20 co-authors and great deal of help from Mary. =20 =20 The following summarizes the changes made to the target-uri document 1. Added use-case for toll-free number back 2. Added definition of "retarget" operation.=20 3. Removed a reference to URN 4. Added a text discussing the difference to P-Called-Party-Id 5. Changed parameter name from "target" to "istarget" =20 Note, that the target-uri document still contains the normative text for the History-Info header. =20 In addition, Mary (with Francois as co-author) has submitted a rfc4244bis, with the following changes: 1. Incorporated the normative aspects of the target-uri document into the existing normative text in RFC 4244 - the functionality is=20 virtually identical (as is some of the text) as the HI based solution=20 described in the target-uri document. It's important that the solution be integrated into RFC 4244 as it MUST work and be based on the normative aspects of RFC 4244. 2. Added the use cases from target-uri the the summary in the overview of rfc4244bis. 3. Added an additional requirement to capture the "target-uri" information. 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. 5. Added a more simplified example. =20 =20 We had some very long offline exchanges as to the best way forward and remaining work for both documents. =20 Some of the issues identified are: ::Issues:: 1. Should we remove the normative text from target-uri and progress 4244bis along with the target-uri document to meet the chartered SIP WG milestone?=20 =20 =20 2. Name of the parameter.=20 At the last meeting, parameter "target" was said inappropriate=20 because voicemail-uri spec already defines a parameter called=20 "target" which also can be found in hi-entry, thus potentially=20 causing confusion. =20 Currently the target-uri draft uses "istarget" and 4244bis uses "retarget" but we could never come to=20 a consensus on what name is appropriate. Other suggestions have included the following: "target-identity" (someone didn't like that "identity" is also a SIP header) "reg-uri" (can be paired with "mapped-uri" for item 3 below) "aor" "jibberish"=20 etc. =20 One reason this is so difficult relates to the problem statement in target-uri in that RFC 3261 doesn't differentiate the mechanism by which the new (target) Request-URI is selected. Another issue is that some of the terminology in RFC 3261 is overloaded - e.g., "forwarding" refers both to a Proxy which does not have responsibility for the domain of the request-URI in the incoming request, thus the proxy just "forwards" the request to the next hop AND "forwarding" is used to describe the process whereby the outgoing request is built and "forwarded" to the next hop at which point the proxy does not know how the new request-uri was selected. RFC 4244 has attempted to clarify the terms and attempts to use "forward"=20 in the context of the former situation and "retarget" for the case whereby a proxy is responsible for the domain and thus can use a number of=20 mechanism to select the new target for the request - e.g., a REGISTRAR,=20 configured data, etc. =20 3. Related to the last point in item 2 above, it has been proposed that we differentiate the hi-entries even more by defining separate parameters for registered and configured/mapped contacts.=20 Currently when the R-URI is translated to a URI which is either derived=20 from location service lookup(registered by UA) or from mapping=20 table, there is no differentiation as to how the URI was derived once it is added to the list of potential targets. =20 The general consensus of the authors of the two documents was that it may=20 be useful for some services to have the hi-entries tagged with the more specific information.=20 =20 And, of course, this gets us into another naming contest. In the end, the naming is not so important as long as the term isn't too overloaded and it is defined precisely in the document(s). =20 We would appreciate WG feedback on these issues and any other comments on the two documents prior to IETF-74. =20 Regards, Shida and Mary. Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 10, 2009 2:30:01 AM JST To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =09 =09 Title : Delivery of Request-URI Targets to User Agents Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert Filename : draft-rosenberg-sip-target-uri-delivery-01.txt Pages : 16 Date : 2009-3-9 =09 When a Session Initiation Protocol (SIP) proxy receives a request targeted at a URI identifying a user or resource it is responsible for, the proxy translates the URI to a registered or configured contact URI of an agent representing that user or resource. In the process, the original URI is removed from the request. Numerous use cases have arisen which require this information to be delivered to the user agent. This document describes these use cases and defines an extension to the History-Info header field which allows it to be used to support those cases. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-deliv ery-01.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 Content-Type: text/plain
Content-ID: <2009-3-9102756.I-D@ietf.org>

=20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C9A26B.63D0589F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
BTW - in the end, I really don't care = what we call=20 the tag - the term just needs to be precisely defined and I'd rather it = not be=20 based on a term in RFC 3261 that is already overloaded and doesn't = precisely=20 match the semantics for the tag in 4244bis.

From: Barnes, Mary (RICH2:AR00) =
Sent:=20 Wednesday, March 11, 2009 12:03 PM
To: 'Hans Erik van Elburg'; = Shida=20 Schubert
Cc: sip@ietf.org List
Subject: Terminology = (was RE:=20 [Sip] Fwd: I-D=20 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

And, I=20 think the big issue with the terminology is that 4244bis is application=20 agnostic, so it is tagging what happens to the URIs (why/how the = specific URI=20 was overwritten).  Whereas, specific applications can derive = information,=20 such as what "is" the real "target" for the request, from = the History-Info=20 header.   So, IMHO, it's a matter of the target-uri document = specifying=20 that the last entry tagged by whatever name we come up with "is" the = real=20 "target" for the request.  I believe it's up to the applications to = describe how they make use of the History-Info and not for the = History-Info to=20 describe how applications can use it.  History-Info purely reflects = what=20 happened from a SIP Protocol perspective and should not imply=20 any application semantics. Indeed the intent of section 5 of 4244 = was to=20 inform the applications how they should decribe their usage of the = header.=20
 
Mary.=20
Note:=20 I changed the subject to hopefully make this topic easier to keep track = of.=20

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, March 11, = 2009 3:59=20 AM
To: Shida Schubert
Cc: sip@ietf.org List; Barnes, = Mary=20 (RICH2:AR00)
Subject: Re: [Sip] Fwd: I-D=20 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

One of the problems that made the discussion quite tedious is = the=20 complete inversed meaning of the terms "retarget" and "reroute" between = 4244bis=20 and target-uri factions have.

Conclusion was that the terminology = need to=20 be properly defined and some attempt was made to start such = activity.

On=20 3. I have strong concerns when we start tagging the URI as to how they = come=20 about "retarget"/"mapped conficuration" etc. It is better to embellish = them with=20 a tag that just represents there meaning for example "istarget" or = "hop". For=20 the following reasons:
1. It is much more intuitive for the user of = this=20 information, its meaning can basically be guessed.
2. Such meaning = also=20 probably survives application in other problem spaces that we had not = foreseen=20 when introducing the concept.

The solution that is  = described now in=20 the target-URI delivery draft is not yet complete, it does not solve the = freephone use case for example and in its current form it will deliver = exactly=20 the same target-URI as that which would be delivered by the =20 P-Called-Party-ID header. Contrary to what the draft says. So some work = is=20 needed still.

/Hans Erik van Elburg


On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert = <shida@ntt-at.com>=20 wrote:

We have submitted the updated target-uri draft based on the=20 comments 
submitted to the list and comments received at = IETF73. 

I have taken over as editor as Jonathan didn't have the cycles=20 to 
update the draft, with Francois, Christer and Hans Erick as=20 additional 
co-authors and great deal of help from Mary.  
 
The following summarizes the changes made to the target-uri=20 document
1. Added use-case for toll-free number back
2. Added definition of "retarget" operation. 
3. Removed a reference to URN
4. Added a text discussing the difference to = P-Called-Party-Id
5. Changed parameter name from "target" to "istarget"
 
Note, that the target-uri document still contains the normative = text for=20 the
History-Info header.
 
In addition, Mary (with Francois as co-author) has submitted = a
rfc4244bis, with the following changes:
1. Incorporated the normative aspects of the target-uri = document
into the existing normative text in RFC 4244 - the functionality=20 is 
virtually identical (as is some of the text) as the HI based=20 solution 
described in the target-uri document.  It's important that = the=20 solution
be integrated into RFC 4244 as it MUST work and be based on the=20 normative
aspects of RFC 4244.
2.  Added the use cases from target-uri the the = summary
in the overview of rfc4244bis.
3. Added an additional requirement to capture the "target-uri"=20 information.
4. Fixed an error in the RFC 4244 ABNF and added "retarget"=20 parameter.
5. Added a more simplified example.
 
 
We had some very long offline exchanges as to the best way = forward=20 and
remaining work for both documents.
 
Some of the issues identified are:

::Issues::
   1. Should we remove the normative text from = target-uri and=20 progress
       4244bis along with the target-uri = document to=20 meet the chartered
      SIP WG milestone? 
 
 
   2. Name of the parameter. 
      At the last meeting, parameter "target" = was=20 said inappropriate 
      because voicemail-uri spec already = defines a=20 parameter called 
      "target" which also can be found in = hi-entry,=20 thus potentially 
      causing confusion.
     
      Currently the target-uri draft uses = "istarget"=20 and 4244bis uses
      "retarget"  but we could never = come=20 to 
      a consensus on what name is = appropriate.=20  Other suggestions have
      included the following:
      "target-identity" (someone didn't like = that=20 "identity" is also a SIP header)
      "reg-uri"  (can be paired with=20 "mapped-uri" for item 3 below)
      "aor"
      "jibberish" 
      etc.
 
      One reason this is so difficult relates = to the=20 problem statement in target-uri in that
      RFC 3261 doesn't differentiate the = mechanism by=20 which the new
      (target) Request-URI is selected. =  Another=20 issue is that some of the terminology in
      RFC 3261 is overloaded - e.g., = "forwarding"=20 refers both to a Proxy
      which does not have responsibility for = the=20 domain of the request-URI
      in the incoming request, thus the proxy = just=20 "forwards" the request to
      the next hop AND "forwarding" is used = to=20 describe the process whereby
      the outgoing request is built and = "forwarded"=20 to the next hop at which
      point the proxy does not know how the = new=20 request-uri was selected.
      RFC 4244 has attempted to clarify the = terms and=20 attempts to use "forward" 
      in the context of the former situation = and=20 "retarget" for the case whereby
      a proxy is responsible for the domain = and thus=20 can use a number of 
      mechanism to select the new target for = the=20 request - e.g., a REGISTRAR, 
      configured data, etc.  

 3.  Related to the last point in item 2 above, it has = been=20 proposed that
      we differentiate the hi-entries even = more by=20 defining separate parameters
     for registered and configured/mapped=20 contacts. 
     Currently when the R-URI is translated to a = URI which=20 is either derived 
     from location service lookup(registered by = UA) or=20 from mapping 
     table, there is no differentiation as to how = the URI=20 was derived once it is
     added to the list of potential targets.
     
     The general consensus of the authors of the = two=20 documents was that it may 
     be useful for some services to have the = hi-entries=20 tagged with the
     more specific information. 
 
     And, of course, this gets us into another = naming=20 contest. In the end, the naming
     is not so important as long as the term isn't = too=20 overloaded and it is defined
     precisely in the document(s).
 
We would appreciate WG feedback on these issues and any other = comments=20 on
the two documents prior to IETF-74.
 
Regards,
Shida and Mary.



Begin forwarded message:
From: Internet-Drafts@ietf.org
Date: March 10, 2009 2:30:01 AM JST
To: i-d-announce@ietf.org
Subject: I-D=20 = ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt 

A New Internet-Draft is available from the on-line=20 Internet-Drafts 
directories.


Title=20 : Delivery of = Request-URI=20 Targets to User Agents
Author(s)=20 : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S.=20 Schubert
Filename :=20 draft-rosenberg-sip-target-uri-delivery-01.txt
Pages=20 : 16
Date=20 : 2009-3-9

When a Session Initiation = Protocol (SIP)=20 proxy receives a request
  targeted at a URI = identifying a user=20 or resource it is responsible
  for, the proxy = translates the=20 URI to a registered or configured
  contact URI of an = agent=20 representing that user or resource.  In = the
  process, the=20 original URI is removed from the request.  Numerous=20 use
  cases have arisen which require this information = to be=20 delivered to
  the user agent.  This document = describes=20 these use cases and defines
  an extension to the = History-Info=20 header field which allows it to be
  used to support = those=20 cases.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-t= arget-uri-delivery-01.txt

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

Below = is the=20 data which will enable a MIME compliant mail = reader
implementation to=20 automatically retrieve the ASCII version of=20 the
Internet-Draft.
Content-Type: = text/plain<BR>Content-ID: &lt;2009-3-9102756.I-D@ietf.org&gt;<BR><BR&g= t;=20
_______________________________________________
I-D-Announce = mailing=20 list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft=20 directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

______________________________________= _________
Sip=20 mailing list  https://www.ietf.org/mailman/listinfo/sip
This = list is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip

------_=_NextPart_001_01C9A26B.63D0589F-- From HKaplan@acmepacket.com Wed Mar 11 10:04:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC023A69A0 for ; Wed, 11 Mar 2009 10:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzq2iZUW1HOQ for ; Wed, 11 Mar 2009 10:04:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 48FD03A6A2B for ; Wed, 11 Mar 2009 10:04:13 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 13:04:49 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 11 Mar 2009 13:04:48 -0400 From: Hadriel Kaplan To: Mary Barnes , Shida Schubert , "sip@ietf.org" Date: Wed, 11 Mar 2009 13:04:48 -0400 Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AAAnCqAABTTs+AAAKCL4A== Message-ID: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:04:14 -0000 I don't actually have much stake in Diversion - you know it wasn't us who i= mplemented it first, and it's a softswitch/PBX thing not SBC thing anyway -= I just hate having two ways of doing the same thing, or having to convert = between the (multiple) vendors that do one or the other. And before you th= row stones at me for it, you can look into your own product line and find t= hat there are products that only do Diversion and not Hist-Info. In fact s= everal vendors have a mixture of both across product lines, afaict. But anyway I'm not debating the merits of History-Info vs. Diversion. That= time has passed, and we will just have to live with both for a while, and = hopefully someday Hist-Info will win. I will be happy to convert between i= t and Diversion for now, just so it can be un-converted on the other side o= f the link, so that a piece of wire can claim to be standards-compliant. ;)= =20 I'm not even arguing for a new header. =20 I'm just saying something ain't right when we don't even want to use it in = practice. If we can't eat our own dog food, there's something wrong with t= he food. -hadriel > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, March 11, 2009 12:39 PM > To: Hadriel Kaplan; Shida Schubert; sip@ietf.org >=20 > Yeah, we can define a new header and just ignore the use of a basic SIP > building block that the WG spent 2.5 years (note this doesn't include th= e > 2+ years spent on the doc as an individual and as a SIPPING WG document ;= ) > And, while we're at it, let's just go ahead and obsolete 4244 altogether > and standardize diversion (something the WG rejected almost a decade ago)= . > That will make one vendor and a handful of SPs very happy and those of us > that have implemented the specs can ripout some code after while when we > have some spare change to pay folks to do so (and of course, this is afte= r > the folks that have not implemented diversion actually implement it - > there are actually some of those out there). >=20 > As an aside, this is another fine example as to why we don't seem to make > great progress or produce specs that are deemed useful - we agree on a wa= y > forward and then change our minds later (sometimes for good reasons and > sometimes because a shortcut seems easier or it's just arbitrary based on > the phase of the moon it seems). >=20 > Mary. From mary.barnes@nortel.com Wed Mar 11 10:17:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413B03A67D1 for ; Wed, 11 Mar 2009 10:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dldsQvoK7SWM for ; Wed, 11 Mar 2009 10:17:22 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B9C383A69F1 for ; Wed, 11 Mar 2009 10:17:21 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2BHHlg24335; Wed, 11 Mar 2009 17:17:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 12:20:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCA68A6@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AAAnCqAABTTs+AAAKCL4AAA0r6A References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Hadriel Kaplan" , "Shida Schubert" , Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:17:24 -0000 Well, we do advise the products to implement History-Info and the one that I was responsible for in the past does implement all three (including the remote-party-id solution). =20 On your last point, it's not clear to me the reason why folks haven't implemented it, other than that it's just in the pile of stuff that they haven't implemented. And, it's not all the members of SIP Forum that haven't implemented it (perhaps the subset that are currently contributing to the SIP Connect spec). There is a handful of vendors that interop with one of our products (that I know has implemented HI) that do implement it, as well. So, I don't think it's fair to say across the industry it has not been implemented. =20 Now, I can see folks not wanting to implement it from the perspective that there are already a number of core interop issues per your interop document, thus there's really no point in adding something like HI when the basics are broken. But, that's a broader problem and kinda takes us to Dean's tricycle analogy on the RAI list.=20 Mary.=20 -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Wednesday, March 11, 2009 12:05 PM To: Barnes, Mary (RICH2:AR00); Shida Schubert; sip@ietf.org Subject: RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I don't actually have much stake in Diversion - you know it wasn't us who implemented it first, and it's a softswitch/PBX thing not SBC thing anyway - I just hate having two ways of doing the same thing, or having to convert between the (multiple) vendors that do one or the other. And before you throw stones at me for it, you can look into your own product line and find that there are products that only do Diversion and not Hist-Info. In fact several vendors have a mixture of both across product lines, afaict. But anyway I'm not debating the merits of History-Info vs. Diversion. That time has passed, and we will just have to live with both for a while, and hopefully someday Hist-Info will win. I will be happy to convert between it and Diversion for now, just so it can be un-converted on the other side of the link, so that a piece of wire can claim to be standards-compliant. ;)=20 I'm not even arguing for a new header. =20 I'm just saying something ain't right when we don't even want to use it in practice. If we can't eat our own dog food, there's something wrong with the food. -hadriel > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, March 11, 2009 12:39 PM > To: Hadriel Kaplan; Shida Schubert; sip@ietf.org >=20 > Yeah, we can define a new header and just ignore the use of a basic=20 > SIP building block that the WG spent 2.5 years (note this doesn't=20 > include the > 2+ years spent on the doc as an individual and as a SIPPING WG=20 > 2+ document ;) > And, while we're at it, let's just go ahead and obsolete 4244=20 > altogether and standardize diversion (something the WG rejected almost a decade ago). > That will make one vendor and a handful of SPs very happy and those of > us that have implemented the specs can ripout some code after while=20 > when we have some spare change to pay folks to do so (and of course,=20 > this is after the folks that have not implemented diversion actually=20 > implement it - there are actually some of those out there). >=20 > As an aside, this is another fine example as to why we don't seem to=20 > make great progress or produce specs that are deemed useful - we agree > on a way forward and then change our minds later (sometimes for good=20 > reasons and sometimes because a shortcut seems easier or it's just=20 > arbitrary based on the phase of the moon it seems). >=20 > Mary. From HKaplan@acmepacket.com Wed Mar 11 10:56:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FC923A6925 for ; Wed, 11 Mar 2009 10:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8kL+5OF4B00 for ; Wed, 11 Mar 2009 10:56:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5B3723A684C for ; Wed, 11 Mar 2009 10:56:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 13:56:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 11 Mar 2009 13:56:42 -0400 From: Hadriel Kaplan To: Mary Barnes , Shida Schubert , "sip@ietf.org" Date: Wed, 11 Mar 2009 13:56:40 -0400 Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEIhBKxc7UjDJTr+/KDBXyydQ2AAAnCqAABTTs+AAAKCL4AAA0r6AAACo7cA= Message-ID: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1CCA68A6@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCA68A6@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:56:08 -0000 I never said across the industry it has not been implemented - I know it ha= s by some because we have to convert it for some. I think the reason it ha= sn't gained dominance is because Diversion was done first by many, and if i= t ain't broke they have no reason to fix it compared with other priorities;= or it just takes them years to do such things and get it deployed. =20 -hadriel > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, March 11, 2009 1:20 PM >=20 > Well, we do advise the products to implement History-Info and the one > that I was responsible for in the past does implement all three > (including the remote-party-id solution). >=20 > On your last point, it's not clear to me the reason why folks haven't > implemented it, other than that it's just in the pile of stuff that they > haven't implemented. And, it's not all the members of SIP Forum that > haven't implemented it (perhaps the subset that are currently > contributing to the SIP Connect spec). There is a handful of vendors > that interop with one of our products (that I know has implemented HI) > that do implement it, as well. So, I don't think it's fair to say across > the industry it has not been implemented. >=20 > Now, I can see folks not wanting to implement it from the perspective > that there are already a number of core interop issues per your interop > document, thus there's really no point in adding something like HI when > the basics are broken. But, that's a broader problem and kinda takes us > to Dean's tricycle analogy on the RAI list. >=20 > Mary. From theo@crazygreek.co.uk Wed Mar 11 11:19:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AA4B3A6BAD for ; Wed, 11 Mar 2009 11:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYQrAX9zNJ56 for ; Wed, 11 Mar 2009 11:19:27 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with SMTP id 9BA3D3A6BA4 for ; Wed, 11 Mar 2009 11:19:26 -0700 (PDT) Received: from source ([72.14.220.153]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSbgA0920OZDPDEN06M+LDUWJVy6Dsv2Y@postini.com; Wed, 11 Mar 2009 11:20:03 PDT Received: by fg-out-1718.google.com with SMTP id l26so36666fgb.0 for ; Wed, 11 Mar 2009 11:20:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.33.10 with SMTP id g10mr6150946fgg.44.1236795602986; Wed, 11 Mar 2009 11:20:02 -0700 (PDT) In-Reply-To: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com> Date: Wed, 11 Mar 2009 18:20:02 +0000 Message-ID: <167dfb9b0903111120u24ecfc67ya9abd7020db3f136@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 18:19:28 -0000 On Wed, Mar 11, 2009 at 5:04 PM, Hadriel Kaplan wrote: > If we can't eat our own dog food, there's something wrong with the food. or you've not yet worked out how to open the tin. i am strongly in support of this mechanism. ~ Theo From theo@crazygreek.co.uk Wed Mar 11 13:07:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C6E3A6BAA for ; Wed, 11 Mar 2009 13:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qNd2bAjmYNY for ; Wed, 11 Mar 2009 13:07:20 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id 598D63A6A5D for ; Wed, 11 Mar 2009 13:07:20 -0700 (PDT) Received: from source ([209.85.218.161]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSbgaHJG/7EDTfVPK0xS3SJ+n7mW2zZV8@postini.com; Wed, 11 Mar 2009 13:07:57 PDT Received: by bwz5 with SMTP id 5so157108bwz.13 for ; Wed, 11 Mar 2009 13:07:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.62.133 with SMTP id x5mr225845bkh.60.1236802075842; Wed, 11 Mar 2009 13:07:55 -0700 (PDT) In-Reply-To: <167dfb9b0903111120u24ecfc67ya9abd7020db3f136@mail.gmail.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com> <167dfb9b0903111120u24ecfc67ya9abd7020db3f136@mail.gmail.com> Date: Wed, 11 Mar 2009 20:07:55 +0000 Message-ID: <167dfb9b0903111307i69edba8ei826c5a44dba3d16d@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 20:07:21 -0000 On Wed, Mar 11, 2009 at 6:20 PM, Theo Zourzouvillys wrote: > or you've not yet worked out how to open the tin. > > i am strongly in support of this mechanism. sorry, too may lists, threads, and offlist discussions - and not enough sleep. i'm not trying to suggest that we should be working on mechanisms for opening tins (although will happily entertain any new mechanisms - there is currently only one practical way i am aware of opening tins, which means it doesn't meet SIPs minimum quota for "ways to do thing"); so let me reword my previous message so it makes sense to anyone other then me: i am strongly in favour of putting the target URI in HI. :) ~ Theo From HKaplan@acmepacket.com Wed Mar 11 13:50:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E913A6B47 for ; Wed, 11 Mar 2009 13:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2f0TbxvyW60 for ; Wed, 11 Mar 2009 13:50:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DAF653A6A74 for ; Wed, 11 Mar 2009 13:50:04 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 16:50:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 11 Mar 2009 16:50:40 -0400 From: Hadriel Kaplan To: Theo Zourzouvillys Date: Wed, 11 Mar 2009 16:50:39 -0400 Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmidgfdDPVx9TerS1CbfqDjAfVrEQAD9NQg Message-ID: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com> <167dfb9b0903111120u24ecfc67ya9abd7020db3f136@mail.gmail.com> In-Reply-To: <167dfb9b0903111120u24ecfc67ya9abd7020db3f136@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" , Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 20:50:06 -0000 > -----Original Message----- > From: Theo Zourzouvillys [mailto:theo@crazygreek.co.uk] > Sent: Wednesday, March 11, 2009 2:20 PM >=20 > On Wed, Mar 11, 2009 at 5:04 PM, Hadriel Kaplan > wrote: >=20 > > If we can't eat our own dog food, there's something wrong with the food= . >=20 > or you've not yet worked out how to open the tin. I think most everyone in the SIP Forum knows how the mechanism could work u= sing HI. The question was if we wanted to solve the issue using HI for the= SIP-Connect profile. I think the rationale for "no" was the feeling we ha= d on whether PBX's would actually support HI anytime soon, or whether in pr= actice we would actually be doing something different in deployment to actu= ally make calls work. (though I can't really speak for others - I could be= totally wrong on that, this was just the sense I got) Personally, I look at it from a motivation perspective: who has the motivat= ion to change to make something work? In the SIP-Connect case, the Service= Provider is the one selling the SIP-Trunk service, so to win the deal and = satisfy customers they've got more of the motivation/burden to make it work= . The SP's also have a large motivation to support as many IP-PBX vendors = as possible. Any changes we mandate of IP-PBX vendors will reduce the pool= of them that are "SIP-Connect compliant", which is not good. Especially w= hen what we're proposing basically works *now* in SIP-Trunk deployments - i= .e., there's running code. It doesn't quite work that way today within the= SP's domain on the wire, but as I said they have the motivation (and the a= bility) to change their side. -hadriel=20 From ietf.hanserik@gmail.com Wed Mar 11 14:39:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E8C3A6BA1 for ; Wed, 11 Mar 2009 14:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmhwSCGdDE76 for ; Wed, 11 Mar 2009 14:39:31 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 979473A688E for ; Wed, 11 Mar 2009 14:39:30 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 25so48734eya.31 for ; Wed, 11 Mar 2009 14:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BtmQYvLOV0dHL74V3Wwvi4anEh87+g/DBVRirE/uMLc=; b=O+3zMLqI/6YAYMuzy6yFUdNG04phcjxiQ7rv0V5e4f5Ai8xmo02PSw57Z0BMX6MJNg wArnuLh2CiCtpG0wSy6YV8Yy2V3UlOwftkMhalT47jr6SzcO6u4SFi9freuMElaoImEA 0VKzN6bmZqFaH2GWdRsfrWfQwZHaRKcCwkuSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Om55X7g+Dp2IP0puItgOeHCtNbPVjH6ROVeYCfnclD93u2yHH0sod6+wXJQ3odeNuN aYYb+XkycyvdUmfkbyPEzMx78TH2GJQlxCKOhtVaMm4/g2thKo1SJGK0y+l49F3oeWAM nUjV+/FvRpbbkre9qLAytXrIDahdXMLGFW8AA= Received: by 10.216.30.81 with SMTP id j59mr3701256wea.50.1236807606165; Wed, 11 Mar 2009 14:40:06 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 10sm398290eyd.3.2009.03.11.14.40.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 14:40:05 -0700 (PDT) Message-ID: <49B82FB4.4030002@gmail.com> Date: Wed, 11 Mar 2009 22:40:04 +0100 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mary Barnes References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 21:39:32 -0000 The target-uri concept when defined properly is entirely application agnostic. When one uses History-Info or another header as a vehicle for this information then it still can be considered application agnostic as any application can use this information as it likes. From SIP perspective all the Request-URI rewrites look the same, that is what brought us discussing this in the first place. /Hans Erik Mary Barnes wrote: > And, I think the big issue with the terminology is that 4244bis is > application agnostic, so it is tagging what happens to the URIs > (why/how the specific URI was overwritten). Whereas, specific > applications can derive information, such as what "is" the real > "target" for the request, from the History-Info header. So, IMHO, > it's a matter of the target-uri document specifying that the last > entry tagged by whatever name we come up with "is" the real "target" > for the request. I believe it's up to the applications to describe > how they make use of the History-Info and not for the History-Info to > describe how applications can use it. History-Info purely reflects > what happened from a SIP Protocol perspective and should not imply > any application semantics. Indeed the intent of section 5 of 4244 was > to inform the applications how they should decribe their usage of the > header. > > Mary. > Note: I changed the subject to hopefully make this topic easier to > keep track of. > > ------------------------------------------------------------------------ > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Wednesday, March 11, 2009 3:59 AM > *To:* Shida Schubert > *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) > *Subject:* Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > One of the problems that made the discussion quite tedious is the > complete inversed meaning of the terms "retarget" and "reroute" > between 4244bis and target-uri factions have. > > Conclusion was that the terminology need to be properly defined and > some attempt was made to start such activity. > > On 3. I have strong concerns when we start tagging the URI as to how > they come about "retarget"/"mapped conficuration" etc. It is better to > embellish them with a tag that just represents there meaning for > example "istarget" or "hop". For the following reasons: > 1. It is much more intuitive for the user of this information, its > meaning can basically be guessed. > 2. Such meaning also probably survives application in other problem > spaces that we had not foreseen when introducing the concept. > > The solution that is described now in the target-URI delivery draft > is not yet complete, it does not solve the freephone use case for > example and in its current form it will deliver exactly the same > target-URI as that which would be delivered by the P-Called-Party-ID > header. Contrary to what the draft says. So some work is needed still. > > /Hans Erik van Elburg > > > On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > wrote: > > > We have submitted the updated target-uri draft based on the comments > submitted to the list and comments received at IETF73. > > I have taken over as editor as Jonathan didn't have the cycles to > update the draft, with Francois, Christer and Hans Erick as > additional > co-authors and great deal of help from Mary. > > The following summarizes the changes made to the target-uri document > 1. Added use-case for toll-free number back > 2. Added definition of "retarget" operation. > 3. Removed a reference to URN > 4. Added a text discussing the difference to P-Called-Party-Id > 5. Changed parameter name from "target" to "istarget" > > Note, that the target-uri document still contains the normative > text for the > History-Info header. > > In addition, Mary (with Francois as co-author) has submitted a > rfc4244bis, with the following changes: > 1. Incorporated the normative aspects of the target-uri document > into the existing normative text in RFC 4244 - the functionality is > virtually identical (as is some of the text) as the HI based solution > described in the target-uri document. It's important that the > solution > be integrated into RFC 4244 as it MUST work and be based on the > normative > aspects of RFC 4244. > 2. Added the use cases from target-uri the the summary > in the overview of rfc4244bis. > 3. Added an additional requirement to capture the "target-uri" > information. > 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. > 5. Added a more simplified example. > > > We had some very long offline exchanges as to the best way forward and > remaining work for both documents. > > Some of the issues identified are: > > ::Issues:: > 1. Should we remove the normative text from target-uri and progress > 4244bis along with the target-uri document to meet the > chartered > SIP WG milestone? > > > 2. Name of the parameter. > At the last meeting, parameter "target" was said inappropriate > because voicemail-uri spec already defines a parameter called > "target" which also can be found in hi-entry, thus potentially > causing confusion. > > Currently the target-uri draft uses "istarget" and 4244bis uses > "retarget" but we could never come to > a consensus on what name is appropriate. Other suggestions have > included the following: > "target-identity" (someone didn't like that "identity" is > also a SIP header) > "reg-uri" (can be paired with "mapped-uri" for item 3 below) > "aor" > "jibberish" > etc. > > One reason this is so difficult relates to the problem > statement in target-uri in that > RFC 3261 doesn't differentiate the mechanism by which the new > (target) Request-URI is selected. Another issue is that > some of the terminology in > RFC 3261 is overloaded - e.g., "forwarding" refers both to a > Proxy > which does not have responsibility for the domain of the > request-URI > in the incoming request, thus the proxy just "forwards" the > request to > the next hop AND "forwarding" is used to describe the > process whereby > the outgoing request is built and "forwarded" to the next > hop at which > point the proxy does not know how the new request-uri was > selected. > RFC 4244 has attempted to clarify the terms and attempts to > use "forward" > in the context of the former situation and "retarget" for > the case whereby > a proxy is responsible for the domain and thus can use a > number of > mechanism to select the new target for the request - e.g., a > REGISTRAR, > configured data, etc. > > 3. Related to the last point in item 2 above, it has been > proposed that > we differentiate the hi-entries even more by defining > separate parameters > for registered and configured/mapped contacts. > Currently when the R-URI is translated to a URI which is > either derived > from location service lookup(registered by UA) or from mapping > table, there is no differentiation as to how the URI was > derived once it is > added to the list of potential targets. > > The general consensus of the authors of the two documents was > that it may > be useful for some services to have the hi-entries tagged > with the > more specific information. > > And, of course, this gets us into another naming contest. In > the end, the naming > is not so important as long as the term isn't too overloaded > and it is defined > precisely in the document(s). > > We would appreciate WG feedback on these issues and any other > comments on > the two documents prior to IETF-74. > > Regards, > Shida and Mary. > > > > Begin forwarded message: >> *From: *Internet-Drafts@ietf.org >> *Date: *March 10, 2009 2:30:01 AM JST >> *To: *i-d-announce@ietf.org >> *Subject: **I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * >> *Reply-To: *internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title >> : Delivery of Request-URI Targets to User Agents >> Author(s) >> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert >> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt >> Pages >> : 16 >> Date >> : 2009-3-9 >> >> When a Session Initiation Protocol (SIP) proxy receives a request >> targeted at a URI identifying a user or resource it is responsible >> for, the proxy translates the URI to a registered or configured >> contact URI of an agent representing that user or resource. In the >> process, the original URI is removed from the request. >> Numerous use >> cases have arisen which require this information to be delivered to >> the user agent. This document describes these use cases and >> defines >> an extension to the History-Info header field which allows it to be >> used to support those cases. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-delivery-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > Content-Type: text/plain
Content-ID: > <2009-3-9102756.I-D@ietf.org > >

>> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on current sip > Use sipping@ietf.org for new > developments on the application of sip > > From spencer@wonderhamster.org Wed Mar 11 14:49:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7403A6BD1 for ; Wed, 11 Mar 2009 14:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS+5iqXY0J6B for ; Wed, 11 Mar 2009 14:49:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id BFBA63A6BA1 for ; Wed, 11 Mar 2009 14:49:57 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LhWJo10fE-000ffU; Wed, 11 Mar 2009 17:50:32 -0400 Message-ID: <3F734CE81E924F38AB592888ABA64F5A@china.huawei.com> From: "Spencer Dawkins" To: "Hadriel Kaplan" , "Theo Zourzouvillys" References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><1ECE0EB50388174790F9694F77522CCF1CCA6750@zrc2hxm0.corp.nortel.com><167dfb9b0903111120u24ecfc67ya9abd7020db3f136@mail.gmail.com> Date: Wed, 11 Mar 2009 16:50:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18y5r/WTTg6XjF05z8BzLiRUc6TpYTo9Me9qGQ HHj201b6ZEmez2ZE6T3Iv/05fx8UAygmTm2T7u/j1LpZCpmkPs ZmwWX10HX5Ic7KY1uymGBupz6dWhfFi8HWhPXSVWww= Cc: sip@ietf.org, Mary Barnes Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 21:49:58 -0000 > I think most everyone in the SIP Forum knows how the mechanism could work > using HI. The question was if we wanted to solve the issue using HI for > the SIP-Connect profile. I think the rationale for "no" was the feeling > we had on whether PBX's would actually support HI anytime soon, or whether > in practice we would actually be doing something different in deployment > to actually make calls work. (though I can't really speak for others - I > could be totally wrong on that, this was just the sense I got) > Speaking only for myself, I thought that the obstacle for SIPconnect was that there was already a history-info-bis effort underway - we just weren't excited about requiring support for a mechanism that was being revised. It wasn't clear to me that we would be equally unexcited if 4244bis was approved for publication. But as Hadriel says, I could also be totally wrong about that. And other people don't have to be shy about explaining things to me. Thanks, Spencer > Personally, I look at it from a motivation perspective: who has the > motivation to change to make something work? In the SIP-Connect case, the > Service Provider is the one selling the SIP-Trunk service, so to win the > deal and satisfy customers they've got more of the motivation/burden to > make it work. The SP's also have a large motivation to support as many > IP-PBX vendors as possible. Any changes we mandate of IP-PBX vendors will > reduce the pool of them that are "SIP-Connect compliant", which is not > good. Especially when what we're proposing basically works *now* in > SIP-Trunk deployments - i.e., there's running code. It doesn't quite work > that way today within the SP's domain on the wire, but as I said they have > the motivation (and the ability) to change their side. > > -hadriel > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From ietf.hanserik@gmail.com Wed Mar 11 15:04:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8BF28C0F1 for ; Wed, 11 Mar 2009 15:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-em1WEeZgrW for ; Wed, 11 Mar 2009 15:04:12 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 1F24228C1A1 for ; Wed, 11 Mar 2009 15:04:11 -0700 (PDT) Received: by ewy25 with SMTP id 25so171094ewy.37 for ; Wed, 11 Mar 2009 15:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=GSWrwG5NAwrRjwWJnDTAjXeI3+T/9oIh8QMY7OJUU2U=; b=tAiUztasAlHPlKJVICizM+0G9D3xPsnN2BvO9+F2Q1ROmJYTS2dMrRd2B15Xou4mtv v7er0vRQkr79+xHhbG0V2Mvbn4tEvhd4alpDOO1h3k84aUlqG/Qmu6308LNDtWtj4WuD OFsMML5chWlhUdRh1ulMQCUYFBIZO1Ksx761c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VIGmECm7JadQXASfCGWc2V+KsHqzxi7brPGCXIqdS//6EVGfvVxg5YXMP2FbygVXVt MCuxejd2rbOt/Ikey84gqPkfEYMHMjhT4BI63+EQuagmo1MHSvnZt4h2WbKIOH4i5peO IZwzn+VsRZgigOp71T/j1WhWG9xesiEjWlAfg= Received: by 10.210.57.12 with SMTP id f12mr5841593eba.85.1236809087882; Wed, 11 Mar 2009 15:04:47 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 24sm419284eyx.4.2009.03.11.15.04.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 15:04:47 -0700 (PDT) Message-ID: <49B8357E.2040809@gmail.com> Date: Wed, 11 Mar 2009 23:04:46 +0100 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mary Barnes References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Ian Elz , Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 22:04:13 -0000 I believe in this case the History-Info application-agnosticness principle applies. Why should History-Info enforce something, that goes against the whishes of a domain that is adding a hi-entry and should be considered best equiped in judging what privacy rules apply for this specific entry. /Hans Erik Mary Barnes wrote: > Ian, > > This is an interesting question. I need to think about it some more, but > I don't like the "none" idea as it really must be up to the entity that > added the Privacy header to the request, as to whether it wants the HI > entries that it adds to go outside a domain. My initial thought is that > we can't overrule the overall Privacy header. The thing is that the > Privacy header doesn't preclude gathering the information and using > within a domain AND if it were to not include an hi-entry when the > request leaves the domain for which the proxy is responsible, the > recipient can add the hi-entry for the current request-uri before it > adds the new hi-entry. > > Your PSTN example doesn't strictly map obviously to a SIP model and I > would think you might consider the PSTN hop to be within the same domain > for which the proxy (or gw, I guess) is responsible OR consider this a > walled garden whereby the Privacy header doesn't apply. Which brings me > to a more general question as to how you all deal with other headers > when you do your mapping to the PSTN when there is a Privacy header? It > would seem this problem isn't unique to History-Info, although I know > little about the details of PSTN I/W. > > Regards, > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, March 11, 2009 4:54 AM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) > Cc: sip@ietf.org > Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > Mary, Francois, > > Section 4.1 of the draft allows for the addition of the Privacy header > parameter with a value of "history" to be included with the > hi-targeted-to-uri. > > Can this be extended to also allow the value "none". > > A node adding a H-I entry is allowed to specify the privacy value > "history" either in the Privacy header or as a header parameter > associated with the hi-targeted-to-uri. If the former action is taken by > one node this results in privacy for all history info header entries > even if this is not required. There is no way for privacy of an > individual H-I entry to be set to none if no Privacy is required for the > uri. > > This creates a specific problem when interworking with the PSTN where > the privacy is associated with each E.164 number included in the > protocol. If an INVITE is being mapped to ISUP and the H-I entries are > being used to map to redirection numbers then a single Privacy header > with the value "history" will result in all numbers being restricted. > > If the Privacy header parameter could include the value "none" then this > would explicitly indicate that the associated uri was allowed to be > presented. > > The ability to explicitly allow presentation of specific H-I entries may > also be useful in pure sip implementations. > > I don't believe that this change would create any backward compatibility > issues. The existing implementations will continue as deployed but new > implementations could explicitly set no privacy for a specific uri. > > There are no security issues other than those already defined in the > draft that an intervening node could modify an existing H-I entry. The > Privacy header value of "none" should only be included by the node in > the same manner as the existing inclusion of the "history" value. > > Ian Elz > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: 04 March 2009 15:15 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sip-rfc4244bis-00.txt > Pages : 49 > Date : 2009-03-04 > > 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 call arrives at a specific application > or user. This document defines a new optional SIP header, History-Info, > for capturing the history information in requests. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From mary.barnes@nortel.com Wed Mar 11 15:27:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796403A6AD7 for ; Wed, 11 Mar 2009 15:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.329 X-Spam-Level: X-Spam-Status: No, score=-5.329 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa0OTxfU6vHH for ; Wed, 11 Mar 2009 15:27:07 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CAD7E3A690A for ; Wed, 11 Mar 2009 15:27:06 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2BMRCF23862; Wed, 11 Mar 2009 22:27:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 17:30:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> In-Reply-To: <49B82FB4.4030002@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmikfQ3+MhMhB48QB2XpzJGhB2mBwABkfnw References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 22:27:08 -0000 So, by "target-uri concept" are you referring to the solution in the current target-uri draft or the application usage as such in the target-uri document (which is what I was referring to)? =20 Yes, the problem is that SIP doesn't differentiate the various mechanisms by which a request-URI may be changed, which is what some of the updated text in 4244bis is trying to do and why we need precise terms. I think we all agree that.=20 I honestly don't care what we call the tag, as long as we're clear about the functionality.=20 Mary.=20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, March 11, 2009 4:40 PM To: Barnes, Mary (RICH2:AR00) Cc: Shida Schubert; sip@ietf.org Subject: Re: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt The target-uri concept when defined properly is entirely application agnostic. When one uses History-Info or another header as a vehicle for this information then it still can be considered application agnostic as any application can use this information as it likes. From SIP perspective all the Request-URI rewrites look the same, that is what brought us discussing this in the first place. /Hans Erik Mary Barnes wrote: > And, I think the big issue with the terminology is that 4244bis is=20 > application agnostic, so it is tagging what happens to the URIs=20 > (why/how the specific URI was overwritten). Whereas, specific=20 > applications can derive information, such as what "is" the real > "target" for the request, from the History-Info header. So, IMHO,=20 > it's a matter of the target-uri document specifying that the last=20 > entry tagged by whatever name we come up with "is" the real "target" > for the request. I believe it's up to the applications to describe=20 > how they make use of the History-Info and not for the History-Info to=20 > describe how applications can use it. History-Info purely reflects=20 > what happened from a SIP Protocol perspective and should not imply any > application semantics. Indeed the intent of section 5 of 4244 was to=20 > inform the applications how they should decribe their usage of the=20 > header. > =20 > Mary. > Note: I changed the subject to hopefully make this topic easier to=20 > keep track of. > > ---------------------------------------------------------------------- > -- > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Wednesday, March 11, 2009 3:59 AM > *To:* Shida Schubert > *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) > *Subject:* Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > One of the problems that made the discussion quite tedious is the=20 > complete inversed meaning of the terms "retarget" and "reroute" > between 4244bis and target-uri factions have. > > Conclusion was that the terminology need to be properly defined and=20 > some attempt was made to start such activity. > > On 3. I have strong concerns when we start tagging the URI as to how=20 > they come about "retarget"/"mapped conficuration" etc. It is better to > embellish them with a tag that just represents there meaning for=20 > example "istarget" or "hop". For the following reasons: > 1. It is much more intuitive for the user of this information, its=20 > meaning can basically be guessed. > 2. Such meaning also probably survives application in other problem=20 > spaces that we had not foreseen when introducing the concept. > > The solution that is described now in the target-URI delivery draft=20 > is not yet complete, it does not solve the freephone use case for=20 > example and in its current form it will deliver exactly the same=20 > target-URI as that which would be delivered by the P-Called-Party-ID=20 > header. Contrary to what the draft says. So some work is needed still. > > /Hans Erik van Elburg > > > On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > wrote: > > > We have submitted the updated target-uri draft based on the comments=20 > submitted to the list and comments received at IETF73.=20 > > I have taken over as editor as Jonathan didn't have the cycles to=20 > update the draft, with Francois, Christer and Hans Erick as > additional=20 > co-authors and great deal of help from Mary. =20 > =20 > The following summarizes the changes made to the target-uri document > 1. Added use-case for toll-free number back > 2. Added definition of "retarget" operation.=20 > 3. Removed a reference to URN > 4. Added a text discussing the difference to P-Called-Party-Id > 5. Changed parameter name from "target" to "istarget" > =20 > Note, that the target-uri document still contains the normative > text for the > History-Info header. > =20 > In addition, Mary (with Francois as co-author) has submitted a > rfc4244bis, with the following changes: > 1. Incorporated the normative aspects of the target-uri document > into the existing normative text in RFC 4244 - the functionality is=20 > virtually identical (as is some of the text) as the HI based solution=20 > described in the target-uri document. It's important that the > solution > be integrated into RFC 4244 as it MUST work and be based on the > normative > aspects of RFC 4244. > 2. Added the use cases from target-uri the the summary > in the overview of rfc4244bis. > 3. Added an additional requirement to capture the "target-uri" > information. > 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. > 5. Added a more simplified example. > =20 > =20 > We had some very long offline exchanges as to the best way forward and > remaining work for both documents. > =20 > Some of the issues identified are: > > ::Issues:: > 1. Should we remove the normative text from target-uri and progress > 4244bis along with the target-uri document to meet the > chartered > SIP WG milestone?=20 > =20 > =20 > 2. Name of the parameter.=20 > At the last meeting, parameter "target" was said inappropriate=20 > because voicemail-uri spec already defines a parameter called=20 > "target" which also can be found in hi-entry, thus potentially=20 > causing confusion. > =20 > Currently the target-uri draft uses "istarget" and 4244bis uses > "retarget" but we could never come to=20 > a consensus on what name is appropriate. Other suggestions have > included the following: > "target-identity" (someone didn't like that "identity" is > also a SIP header) > "reg-uri" (can be paired with "mapped-uri" for item 3 below) > "aor" > "jibberish"=20 > etc. > =20 > One reason this is so difficult relates to the problem > statement in target-uri in that > RFC 3261 doesn't differentiate the mechanism by which the new > (target) Request-URI is selected. Another issue is that > some of the terminology in > RFC 3261 is overloaded - e.g., "forwarding" refers both to a > Proxy > which does not have responsibility for the domain of the > request-URI > in the incoming request, thus the proxy just "forwards" the > request to > the next hop AND "forwarding" is used to describe the > process whereby > the outgoing request is built and "forwarded" to the next > hop at which > point the proxy does not know how the new request-uri was > selected. > RFC 4244 has attempted to clarify the terms and attempts to > use "forward"=20 > in the context of the former situation and "retarget" for > the case whereby > a proxy is responsible for the domain and thus can use a > number of=20 > mechanism to select the new target for the request - e.g., a > REGISTRAR,=20 > configured data, etc. =20 > > 3. Related to the last point in item 2 above, it has been > proposed that > we differentiate the hi-entries even more by defining > separate parameters > for registered and configured/mapped contacts.=20 > Currently when the R-URI is translated to a URI which is > either derived=20 > from location service lookup(registered by UA) or from mapping=20 > table, there is no differentiation as to how the URI was > derived once it is > added to the list of potential targets. > =20 > The general consensus of the authors of the two documents was > that it may=20 > be useful for some services to have the hi-entries tagged > with the > more specific information.=20 > =20 > And, of course, this gets us into another naming contest. In > the end, the naming > is not so important as long as the term isn't too overloaded > and it is defined > precisely in the document(s). > =20 > We would appreciate WG feedback on these issues and any other > comments on > the two documents prior to IETF-74. > =20 > Regards, > Shida and Mary. > > > > Begin forwarded message: >> *From: *Internet-Drafts@ietf.org >> *Date: *March 10, 2009 2:30:01 AM JST >> *To: *i-d-announce@ietf.org >> *Subject: **I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * >> *Reply-To: *internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> >> >> Title >> : Delivery of Request-URI Targets to User Agents >> Author(s) >> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert >> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt >> Pages >> : 16 >> Date >> : 2009-3-9 >> >> When a Session Initiation Protocol (SIP) proxy receives a request >> targeted at a URI identifying a user or resource it is responsible >> for, the proxy translates the URI to a registered or configured >> contact URI of an agent representing that user or resource. In the >> process, the original URI is removed from the request. >> Numerous use >> cases have arisen which require this information to be delivered to >> the user agent. This document describes these use cases and >> defines >> an extension to the History-Info header field which allows it to be >> used to support those cases. >> >> A URL for this Internet-Draft is: >> =20 >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-de >> livery-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > Content-Type: text/plain
Content-ID: > <2009-3-9102756.I-D@ietf.org > >

>> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on current sip > Use sipping@ietf.org for new > developments on the application of sip > > From mary.barnes@nortel.com Wed Mar 11 15:40:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08BD63A6BA1 for ; Wed, 11 Mar 2009 15:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhtbuILv7za1 for ; Wed, 11 Mar 2009 15:40:41 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A98E63A6AD7 for ; Wed, 11 Mar 2009 15:40:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2BMeuF26211; Wed, 11 Mar 2009 22:40:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 17:43:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCF9839@zrc2hxm0.corp.nortel.com> In-Reply-To: <49B8357E.2040809@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: AcmilXHktBatMHeqQMOnx1ZHfxdInQAA4AEg References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> <49B8357E.2040809@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sip@ietf.org, Ian Elz , Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 22:40:43 -0000 I'm not sure if I'm clear on your concern here - what is the "something" in the "Why should History-Info enforce..."?=20 If by the "something" you mean removing the history-info header (if it's session or header level privacy), we have to go back to the fundamental History-Info solution requirements and consider the functionality provided by the Privacy header in RFC 3324. This isn't about application-agnostic or not. The information in the hi-entries can be considered of the same ilk as the other information that is intended to be kept private by the use of the Privacy header, thus if the request indicates session or header levels of privacy, the proxy SHOULD NOT forward the hi-entries. Note, it's a SHOULD NOT. If your network configuration is such that there is no privacy issue with sharing that information, then you can document as such and explain why it's perfectly okay to forward the hi-entries.=20 However, per my note below, even if the prior hop strips out information that is appropriate to the next domain, the last hi-entry can be added by that next hop proxy to preserve the information before that proxy might change the request-uri.=20 Mary.=20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, March 11, 2009 5:05 PM To: Barnes, Mary (RICH2:AR00) Cc: Ian Elz; Audet, Francois (SC100:3055); sip@ietf.org Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt I believe in this case the History-Info application-agnosticness principle applies. Why should History-Info enforce something, that goes against the whishes of a domain that is adding a hi-entry and should be considered best equiped in judging what privacy rules apply for this specific entry. /Hans Erik Mary Barnes wrote: > Ian, > > This is an interesting question. I need to think about it some more,=20 > but I don't like the "none" idea as it really must be up to the entity > that added the Privacy header to the request, as to whether it wants=20 > the HI entries that it adds to go outside a domain. My initial thought > is that we can't overrule the overall Privacy header. The thing is=20 > that the Privacy header doesn't preclude gathering the information and > using within a domain AND if it were to not include an hi-entry when=20 > the request leaves the domain for which the proxy is responsible, the=20 > recipient can add the hi-entry for the current request-uri before it=20 > adds the new hi-entry. > > Your PSTN example doesn't strictly map obviously to a SIP model and I=20 > would think you might consider the PSTN hop to be within the same=20 > domain for which the proxy (or gw, I guess) is responsible OR consider > this a walled garden whereby the Privacy header doesn't apply. Which=20 > brings me to a more general question as to how you all deal with other > headers when you do your mapping to the PSTN when there is a Privacy=20 > header? It would seem this problem isn't unique to History-Info,=20 > although I know little about the details of PSTN I/W. > > Regards, > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, March 11, 2009 4:54 AM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) > Cc: sip@ietf.org > Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > Mary, Francois, > > Section 4.1 of the draft allows for the addition of the Privacy header > parameter with a value of "history" to be included with the=20 > hi-targeted-to-uri. > > Can this be extended to also allow the value "none". > > A node adding a H-I entry is allowed to specify the privacy value=20 > "history" either in the Privacy header or as a header parameter=20 > associated with the hi-targeted-to-uri. If the former action is taken=20 > by one node this results in privacy for all history info header=20 > entries even if this is not required. There is no way for privacy of=20 > an individual H-I entry to be set to none if no Privacy is required=20 > for the uri. > > This creates a specific problem when interworking with the PSTN where=20 > the privacy is associated with each E.164 number included in the=20 > protocol. If an INVITE is being mapped to ISUP and the H-I entries are > being used to map to redirection numbers then a single Privacy header=20 > with the value "history" will result in all numbers being restricted. > > If the Privacy header parameter could include the value "none" then=20 > this would explicitly indicate that the associated uri was allowed to=20 > be presented. > > The ability to explicitly allow presentation of specific H-I entries=20 > may also be useful in pure sip implementations. > > I don't believe that this change would create any backward=20 > compatibility issues. The existing implementations will continue as=20 > deployed but new implementations could explicitly set no privacy for a specific uri. > > There are no security issues other than those already defined in the=20 > draft that an intervening node could modify an existing H-I entry. The > Privacy header value of "none" should only be included by the node in=20 > the same manner as the existing inclusion of the "history" value. > > Ian Elz > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 04 March 2009 15:15 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sip-rfc4244bis-00.txt > Pages : 49 > Date : 2009-03-04 > > This document defines a standard mechanism for capturing the history=20 > information associated with a Session Initiation Protocol (SIP) request. > This capability enables many enhanced services by providing the=20 > information as to how and why a call arrives at a specific application > or user. This document defines a new optional SIP header,=20 > History-Info, for capturing the history information in requests. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip > =20 From ietf.hanserik@gmail.com Wed Mar 11 16:01:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B18328C23C for ; Wed, 11 Mar 2009 16:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+Z9aph3ygoH for ; Wed, 11 Mar 2009 16:01:05 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 16F9B28C239 for ; Wed, 11 Mar 2009 16:01:03 -0700 (PDT) Received: by ewy25 with SMTP id 25so184455ewy.37 for ; Wed, 11 Mar 2009 16:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hZ5jVjxImqfPQaG0SAJ76aDQM+PDyqB3qfOE8fKwnPA=; b=j2c+qZ2YKDqr+oPF0iJl8rq5WNHBSvPiPikOsXIHvx0XSYWMccMRpKtzoOEYJjf+Sf /Wa0M4YpJAMw3PFbGkA/9zCzG3I3EL9l+3jLBOEjxw4R52gV12sWEfYPCinrLM/JdMsh Uz3KfhYaYKnud1lBiMYcXU7Rw2btSFJgCuxLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HJBKKgh/IE+sBrZqG6F7hGpIpVSRTZgP7uXWe54DCFe7SLtQhcgU1GYWU9tOMGnVNZ NSqyVcOCrBR8xrDsGamAfPJl0DpVQkWwo5MnTmfaJTsK3UVxXS0CRyH/59aEnC2CsQFl kWEX5NWh+/gRCYQ5yBp9O4wW6ENx6DxEFg7Q4= Received: by 10.211.180.15 with SMTP id h15mr5913920ebp.28.1236812499925; Wed, 11 Mar 2009 16:01:39 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 23sm452082eya.56.2009.03.11.16.01.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 16:01:39 -0700 (PDT) Message-ID: <49B842D2.3030607@gmail.com> Date: Thu, 12 Mar 2009 00:01:38 +0100 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mary Barnes References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> <49B8357E.2040809@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9839@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCF9839@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Ian Elz , Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 23:01:06 -0000 When a proxy1 adds a Privacy header with the value history, then why should a proxy 2 not be able to say: fine but I override the general privacy rule for the specific hi-entry that I add or am responsible for? I was reacting to "I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain." /Hans Erik Mary Barnes wrote: > I'm not sure if I'm clear on your concern here - what is the "something" > in the "Why should History-Info enforce..."? > > If by the "something" you mean removing the history-info header (if it's > session or header level privacy), we have to go back to the fundamental > History-Info solution requirements and consider the functionality > provided by the Privacy header in RFC 3324. This isn't about > application-agnostic or not. The information in the hi-entries can be > considered of the same ilk as the other information that is intended to > be kept private by the use of the Privacy header, thus if the request > indicates session or header levels of privacy, the proxy SHOULD NOT > forward the hi-entries. Note, it's a SHOULD NOT. If your network > configuration is such that there is no privacy issue with sharing that > information, then you can document as such and explain why it's > perfectly okay to forward the hi-entries. > > However, per my note below, even if the prior hop strips out information > that is appropriate to the next domain, the last hi-entry can be added > by that next hop proxy to preserve the information before that proxy > might change the request-uri. > > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 5:05 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Ian Elz; Audet, Francois (SC100:3055); sip@ietf.org > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > I believe in this case the History-Info application-agnosticness > principle applies. > > Why should History-Info enforce something, that goes against the whishes > of a domain that is adding a hi-entry and should be considered best > equiped in judging what privacy rules apply for this specific entry. > > /Hans Erik > > Mary Barnes wrote: > >> Ian, >> >> This is an interesting question. I need to think about it some more, >> but I don't like the "none" idea as it really must be up to the entity >> > > >> that added the Privacy header to the request, as to whether it wants >> the HI entries that it adds to go outside a domain. My initial thought >> > > >> is that we can't overrule the overall Privacy header. The thing is >> that the Privacy header doesn't preclude gathering the information and >> > > >> using within a domain AND if it were to not include an hi-entry when >> the request leaves the domain for which the proxy is responsible, the >> recipient can add the hi-entry for the current request-uri before it >> adds the new hi-entry. >> >> Your PSTN example doesn't strictly map obviously to a SIP model and I >> would think you might consider the PSTN hop to be within the same >> domain for which the proxy (or gw, I guess) is responsible OR consider >> > > >> this a walled garden whereby the Privacy header doesn't apply. Which >> brings me to a more general question as to how you all deal with other >> > > >> headers when you do your mapping to the PSTN when there is a Privacy >> header? It would seem this problem isn't unique to History-Info, >> although I know little about the details of PSTN I/W. >> >> Regards, >> Mary. >> >> -----Original Message----- >> From: Ian Elz [mailto:ian.elz@ericsson.com] >> Sent: Wednesday, March 11, 2009 4:54 AM >> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) >> Cc: sip@ietf.org >> Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >> >> Mary, Francois, >> >> Section 4.1 of the draft allows for the addition of the Privacy header >> > > >> parameter with a value of "history" to be included with the >> hi-targeted-to-uri. >> >> Can this be extended to also allow the value "none". >> >> A node adding a H-I entry is allowed to specify the privacy value >> "history" either in the Privacy header or as a header parameter >> associated with the hi-targeted-to-uri. If the former action is taken >> by one node this results in privacy for all history info header >> entries even if this is not required. There is no way for privacy of >> an individual H-I entry to be set to none if no Privacy is required >> for the uri. >> >> This creates a specific problem when interworking with the PSTN where >> the privacy is associated with each E.164 number included in the >> protocol. If an INVITE is being mapped to ISUP and the H-I entries are >> > > >> being used to map to redirection numbers then a single Privacy header >> with the value "history" will result in all numbers being restricted. >> >> If the Privacy header parameter could include the value "none" then >> this would explicitly indicate that the associated uri was allowed to >> be presented. >> >> The ability to explicitly allow presentation of specific H-I entries >> may also be useful in pure sip implementations. >> >> I don't believe that this change would create any backward >> compatibility issues. The existing implementations will continue as >> deployed but new implementations could explicitly set no privacy for a >> > specific uri. > >> There are no security issues other than those already defined in the >> draft that an intervening node could modify an existing H-I entry. The >> > > >> Privacy header value of "none" should only be included by the node in >> the same manner as the existing inclusion of the "history" value. >> >> Ian Elz >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: 04 March 2009 15:15 >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : An Extension to the Session Initiation >> Protocol (SIP) for Request History Information >> Author(s) : M. Barnes, F. Audet >> Filename : draft-barnes-sip-rfc4244bis-00.txt >> Pages : 49 >> Date : 2009-03-04 >> >> 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 call arrives at a specific application >> > > >> or user. This document defines a new optional SIP header, >> History-Info, for capturing the history information in requests. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> From fluffy@cisco.com Wed Mar 11 16:06:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428143A6BDA for ; Wed, 11 Mar 2009 16:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgkFjTtWadof for ; Wed, 11 Mar 2009 16:06:25 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 47ADF28C104 for ; Wed, 11 Mar 2009 16:06:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,346,1233532800"; d="scan'208";a="140601232" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Mar 2009 23:07:02 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2BN72TP027254; Wed, 11 Mar 2009 16:07:02 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2BN70RW014662; Wed, 11 Mar 2009 23:07:01 GMT From: Cullen Jennings To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001984302@GBNTHT12009MSX.gb002.siemens.net> Impp: xmpp:cullenfluffyjennings@jabber.org References: <0D5F89FAC29E2C41B98A6A762007F5D001984302@GBNTHT12009MSX.gb002.siemens.net> Message-Id: <29682BF0-403F-426F-A635-FC3F94BBEA1C@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 17:07:00 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3728; t=1236812822; x=1237676822; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Seeking=20consensus=20on=20draf t-elwell-sip-e2e-identity-important |Sender:=20; bh=nafzmJ1YphUJJTyvwtp88pM+ccJt7rb2lbnNQDEUwIA=; b=JfLCc+6ZlU3n/zhYvc1nCz3z2kSyUjzcU4PNCPVkzPMe4ZWzxtl0JPncWK m3tqxDYmDqfKr5sOOB+7Bp16oeI30vcY4aejzaAkJKxFh0QPGrg/ncHD1EJ6 LWhDnSGCo1; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP List , Jon Peterson Subject: Re: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 23:06:26 -0000 I continue to believe that we need to to come to some common understanding of the security problem we are trying to solve and the constraints on that solution. On one of the close to last phones calls involving this draft I asked everyone one on the call what they thought the problem was. I got no common answer. There is a lot of good information in this draft related to the problem and solutions, but I don't believe this draft gets to what problem we are trying to solve thus making it very hard to answer a question like if the solution should involve changing m line or not. If we all agreed the problem was, just for example, stop MITM from listening to phone calls while still allowing intermediaries to do media steering, then I think we could get there. I know the problem is much more complicated than I just said - I'm not suggesting that my above statement is the right problem statement but just that it is closer to level we should be looking at the problem at. Cullen On Mar 3, 2009, at 9:46 AM, Elwell, John wrote: > Draft 03: > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > includes for the first time an analysis of changes to SIP requests by > B2BUAs (section 8). Also the Conclusions (section 9) have been > extended. > > I and a number of people who have assisted in revising this draft > would > like to seek consensus on a number of the points. We aim to ask these > questions in San Francisco, but obviously it would help to get > opinions > from the list in advance. > > 1. Tolerance to changes of certain elements as a SIP request is > forwarded through intermediate domains. > > Section 8 analyses a number of elements of SIP messages that are > signed > by the present RFC 4474 solution to end-to-end (or near end-to-end) > authenticated identification. For some elements it claims that any > solution for end-to-end authenticated identification needs to be > tolerant of changes by intermediate domains, since there appear to be > valid reasons why B2BUAs (including but not limited to SBCs) change > these elements. Picking on some of these: > > A) Is there agreement that a solution needs to be tolerant of > changes to > IP addresses and ports in c- and m-lines in SDP? In other words, that > intermediate domains can legitimately modify these fields (e.g., for > media steering) and a solution is needed for end-to-end authenticated > identification in such circumstances? > > B) Is there agreement that a solution needs to be tolerant of > changes to > Contact (addr-spec), Call-Id (call-id) and CSeq (digit) header fields? > In other words, that intermediate domains can legitimately modify > these > fields (e.g., for topology hiding) and a solution is needed for > end-to-end authenticated identification in such circumstances? > > C) Is there agreement that a solution does not need to be tolerant of > changes to the addr-spec of From and To header fields? In other words, > that intermediate domains should not modify these fields and can > expect > to break end-to-end authenticated identification if they do so? > > > 2. Are people in broad agreement with the conclusions in section 9 > concerning the importance of end-to-end identification and in > particular > end-to-end authenticated identification? > > John > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From mary.barnes@nortel.com Wed Mar 11 16:28:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DDF3A67DB for ; Wed, 11 Mar 2009 16:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoPk5evJMu5s for ; Wed, 11 Mar 2009 16:28:42 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 15E783A6962 for ; Wed, 11 Mar 2009 16:28:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2BNSuF06440; Wed, 11 Mar 2009 23:28:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 18:31:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCF98F2@zrc2hxm0.corp.nortel.com> In-Reply-To: <49B842D2.3030607@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: AcminWQRJ7TrVLh1StynqUnOOMpJ8QAAVS0Q References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com><49B8357E.2040809@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9839@zrc2hxm0.corp.nortel.com> <49B842D2.3030607@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sip@ietf.org, Ian Elz , Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 23:28:43 -0000 And, if you have a network whereby you believe that none of the information that Proxy 2 will put in hi-entries reveals any information that is considered private, then you can set your flag, or whatever and not drop the hi-entries when they leave that domain - that's why it's a SHOULD NOT - i.e., don't do it unless you've evaluated why it's okay to do it in that case. It is clearly documented in 4244 that there is indeed a loss of information when you use the Privacy header versus tagging individual hi-entries with the privacy header. Now, we could add a Recommendation that the Privacy header be used only to tag individual entries.=20 Yes, I agree the "none" is not a good idea (and conflicts with the Privacy header) as it kindof overrides it, so to speak.=20 Mary.=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: Wednesday, March 11, 2009 6:02 PM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org; Ian Elz; Audet, Francois (SC100:3055) Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt When a proxy1 adds a Privacy header with the value history, then why should a proxy 2 not be able to say: fine but I override the general privacy rule for the specific hi-entry that I add or am responsible for? I was reacting to "I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain." /Hans Erik Mary Barnes wrote: > I'm not sure if I'm clear on your concern here - what is the "something" > in the "Why should History-Info enforce..."?=20 > > If by the "something" you mean removing the history-info header (if=20 > it's session or header level privacy), we have to go back to the=20 > fundamental History-Info solution requirements and consider the=20 > functionality provided by the Privacy header in RFC 3324. This isn't=20 > about application-agnostic or not. The information in the hi-entries=20 > can be considered of the same ilk as the other information that is=20 > intended to be kept private by the use of the Privacy header, thus if=20 > the request indicates session or header levels of privacy, the proxy=20 > SHOULD NOT forward the hi-entries. Note, it's a SHOULD NOT. If your=20 > network configuration is such that there is no privacy issue with=20 > sharing that information, then you can document as such and explain=20 > why it's perfectly okay to forward the hi-entries. > > However, per my note below, even if the prior hop strips out=20 > information that is appropriate to the next domain, the last hi-entry=20 > can be added by that next hop proxy to preserve the information before > that proxy might change the request-uri. > > Mary.=20 > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 5:05 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Ian Elz; Audet, Francois (SC100:3055); sip@ietf.org > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > I believe in this case the History-Info application-agnosticness=20 > principle applies. > > Why should History-Info enforce something, that goes against the=20 > whishes of a domain that is adding a hi-entry and should be considered > best equiped in judging what privacy rules apply for this specific entry. > > /Hans Erik > > Mary Barnes wrote: > =20 >> Ian, >> >> This is an interesting question. I need to think about it some more,=20 >> but I don't like the "none" idea as it really must be up to the=20 >> entity >> =20 > > =20 >> that added the Privacy header to the request, as to whether it wants=20 >> the HI entries that it adds to go outside a domain. My initial=20 >> thought >> =20 > > =20 >> is that we can't overrule the overall Privacy header. The thing is=20 >> that the Privacy header doesn't preclude gathering the information=20 >> and >> =20 > > =20 >> using within a domain AND if it were to not include an hi-entry when=20 >> the request leaves the domain for which the proxy is responsible, the >> recipient can add the hi-entry for the current request-uri before it=20 >> adds the new hi-entry. >> >> Your PSTN example doesn't strictly map obviously to a SIP model and I >> would think you might consider the PSTN hop to be within the same=20 >> domain for which the proxy (or gw, I guess) is responsible OR=20 >> consider >> =20 > > =20 >> this a walled garden whereby the Privacy header doesn't apply. Which=20 >> brings me to a more general question as to how you all deal with=20 >> other >> =20 > > =20 >> headers when you do your mapping to the PSTN when there is a Privacy=20 >> header? It would seem this problem isn't unique to History-Info,=20 >> although I know little about the details of PSTN I/W. >> >> Regards, >> Mary.=20 >> >> -----Original Message----- >> From: Ian Elz [mailto:ian.elz@ericsson.com] >> Sent: Wednesday, March 11, 2009 4:54 AM >> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) >> Cc: sip@ietf.org >> Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >> >> Mary, Francois, >> >> Section 4.1 of the draft allows for the addition of the Privacy=20 >> header >> =20 > > =20 >> parameter with a value of "history" to be included with the=20 >> hi-targeted-to-uri. >> >> Can this be extended to also allow the value "none". >> >> A node adding a H-I entry is allowed to specify the privacy value=20 >> "history" either in the Privacy header or as a header parameter=20 >> associated with the hi-targeted-to-uri. If the former action is taken >> by one node this results in privacy for all history info header=20 >> entries even if this is not required. There is no way for privacy of=20 >> an individual H-I entry to be set to none if no Privacy is required=20 >> for the uri. >> >> This creates a specific problem when interworking with the PSTN where >> the privacy is associated with each E.164 number included in the=20 >> protocol. If an INVITE is being mapped to ISUP and the H-I entries=20 >> are >> =20 > > =20 >> being used to map to redirection numbers then a single Privacy header >> with the value "history" will result in all numbers being restricted. >> >> If the Privacy header parameter could include the value "none" then=20 >> this would explicitly indicate that the associated uri was allowed to >> be presented. >> >> The ability to explicitly allow presentation of specific H-I entries=20 >> may also be useful in pure sip implementations. >> >> I don't believe that this change would create any backward=20 >> compatibility issues. The existing implementations will continue as=20 >> deployed but new implementations could explicitly set no privacy for=20 >> a >> =20 > specific uri. > =20 >> There are no security issues other than those already defined in the=20 >> draft that an intervening node could modify an existing H-I entry.=20 >> The >> =20 > > =20 >> Privacy header value of "none" should only be included by the node in >> the same manner as the existing inclusion of the "history" value. >> >> Ian Elz >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 >> Internet-Drafts@ietf.org >> Sent: 04 March 2009 15:15 >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> >> Title : An Extension to the Session Initiation >> Protocol (SIP) for Request History Information >> Author(s) : M. Barnes, F. Audet >> Filename : draft-barnes-sip-rfc4244bis-00.txt >> Pages : 49 >> Date : 2009-03-04 >> >> This document defines a standard mechanism for capturing the history=20 >> information associated with a Session Initiation Protocol (SIP) >> =20 > request. > =20 >> This capability enables many enhanced services by providing the=20 >> information as to how and why a call arrives at a specific=20 >> application >> =20 > > =20 >> or user. This document defines a new optional SIP header,=20 >> History-Info, for capturing the history information in requests. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.tx >> t >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip >> =20 >> =20 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From ietf.hanserik@gmail.com Wed Mar 11 16:41:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990403A6822 for ; Wed, 11 Mar 2009 16:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_DELIVY=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz7iC6Z0R6CZ for ; Wed, 11 Mar 2009 16:41:39 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 8DECA3A67DB for ; Wed, 11 Mar 2009 16:41:38 -0700 (PDT) Received: by ewy25 with SMTP id 25so192339ewy.37 for ; Wed, 11 Mar 2009 16:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=SbFECrNJSiKX2prehst4d82n9EGUbUwdocNo8phWa2g=; b=LRorjxYNSxPsQLS6R36QRSuDRyme3qgFoilQeLqmxv+Af6nnhhlA+GE59apKcaSSWA 1UKw9d7jNd9aOK9mQRmAcEfNYIK8YlgKrbpBgwiIdgCTEXgPdKFvhpA0XxwraQhyVnKM /aKC/NnpHaAHQxfqUkLw5QqyI8GSF3OVPY5js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cF6MVFLT2ev9Wm7X9G90yxL7+p9NRb6m+Cs2HSZDmeiVar3iVdVvYWF1q9eiFj351g U7BA6EmZBy9r7E+wfFhTD8lEEsDOMI/+ynChSRXA5847comgyn5Um0bvcqjcRSPGcfNO P4yoWRDmuf4gdoXyEzVG/D1djQcKilpaNK1UQ= Received: by 10.210.62.3 with SMTP id k3mr4837083eba.4.1236814934251; Wed, 11 Mar 2009 16:42:14 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 23sm11806eya.56.2009.03.11.16.42.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 16:42:13 -0700 (PDT) Message-ID: <49B84C55.5070107@gmail.com> Date: Thu, 12 Mar 2009 00:42:13 +0100 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mary Barnes References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 23:41:40 -0000 I was talking about the concept. The use cases only describe cases where the target-uri (lets call that current target from now) has been lost when an initial request for a dialog or standalone request arrives at the UAS. What has been lost is the current target of the request: Current target The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. This defintion only makes sense when the following definitions are used: Name: A name is a moniker for an entity which refers to it in a way which reveals nothing about where it is in a network. In SIP, tel URI which doesn't represent the location of the entity is a name. Address: An address is an identifier for an entity which describes it by its location on the network. In SIP, the SIP URI itself is a form of address because the host part of the URI, the only mandatory part of the URI besides the scheme itself, indicates the location of a SIP server that can be used to handle the request. Route: Finally, a route is a sequence of SIP entities (including the UA itself!) which are traversed in order to forward a request to an address or name. Retarget (other term might be needed, as this is highly confusing): A Request-URI rewrite operation that changes the target identity of the request. Reroute (other term might be needed): A Request-URI rewrite operation that does not change the current target of the request, but determines the route/next hop taken to reach the target-identity. /Hans Erik Mary Barnes wrote: > So, by "target-uri concept" are you referring to the solution in the > current target-uri draft or the application usage as such in the > target-uri document (which is what I was referring to)? > > Yes, the problem is that SIP doesn't differentiate the various > mechanisms by which a request-URI may be changed, which is what some of > the updated text in 4244bis is trying to do and why we need precise > terms. I think we all agree that. > > I honestly don't care what we call the tag, as long as we're clear about > the functionality. > > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 4:40 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > The target-uri concept when defined properly is entirely application > agnostic. > > When one uses History-Info or another header as a vehicle for this > information then it still can be considered application agnostic as any > application can use this information as it likes. > > From SIP perspective all the Request-URI rewrites look the same, that > is what brought us discussing this in the first place. > > /Hans Erik > > Mary Barnes wrote: > >> And, I think the big issue with the terminology is that 4244bis is >> application agnostic, so it is tagging what happens to the URIs >> (why/how the specific URI was overwritten). Whereas, specific >> applications can derive information, such as what "is" the real >> "target" for the request, from the History-Info header. So, IMHO, >> it's a matter of the target-uri document specifying that the last >> entry tagged by whatever name we come up with "is" the real "target" >> for the request. I believe it's up to the applications to describe >> how they make use of the History-Info and not for the History-Info to >> describe how applications can use it. History-Info purely reflects >> what happened from a SIP Protocol perspective and should not imply any >> > > >> application semantics. Indeed the intent of section 5 of 4244 was to >> inform the applications how they should decribe their usage of the >> header. >> >> Mary. >> Note: I changed the subject to hopefully make this topic easier to >> keep track of. >> >> ---------------------------------------------------------------------- >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Wednesday, March 11, 2009 3:59 AM >> *To:* Shida Schubert >> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) >> *Subject:* Re: [Sip] Fwd: I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >> >> One of the problems that made the discussion quite tedious is the >> complete inversed meaning of the terms "retarget" and "reroute" >> between 4244bis and target-uri factions have. >> >> Conclusion was that the terminology need to be properly defined and >> some attempt was made to start such activity. >> >> On 3. I have strong concerns when we start tagging the URI as to how >> they come about "retarget"/"mapped conficuration" etc. It is better to >> > > >> embellish them with a tag that just represents there meaning for >> example "istarget" or "hop". For the following reasons: >> 1. It is much more intuitive for the user of this information, its >> meaning can basically be guessed. >> 2. Such meaning also probably survives application in other problem >> spaces that we had not foreseen when introducing the concept. >> >> The solution that is described now in the target-URI delivery draft >> is not yet complete, it does not solve the freephone use case for >> example and in its current form it will deliver exactly the same >> target-URI as that which would be delivered by the P-Called-Party-ID >> header. Contrary to what the draft says. So some work is needed still. >> >> /Hans Erik van Elburg >> >> >> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > > wrote: >> >> >> We have submitted the updated target-uri draft based on the >> > comments > >> submitted to the list and comments received at IETF73. >> >> I have taken over as editor as Jonathan didn't have the cycles to >> update the draft, with Francois, Christer and Hans Erick as >> additional >> co-authors and great deal of help from Mary. >> >> The following summarizes the changes made to the target-uri >> > document > >> 1. Added use-case for toll-free number back >> 2. Added definition of "retarget" operation. >> 3. Removed a reference to URN >> 4. Added a text discussing the difference to P-Called-Party-Id >> 5. Changed parameter name from "target" to "istarget" >> >> Note, that the target-uri document still contains the normative >> text for the >> History-Info header. >> >> In addition, Mary (with Francois as co-author) has submitted a >> rfc4244bis, with the following changes: >> 1. Incorporated the normative aspects of the target-uri document >> into the existing normative text in RFC 4244 - the functionality >> > is > >> virtually identical (as is some of the text) as the HI based >> > solution > >> described in the target-uri document. It's important that the >> solution >> be integrated into RFC 4244 as it MUST work and be based on the >> normative >> aspects of RFC 4244. >> 2. Added the use cases from target-uri the the summary >> in the overview of rfc4244bis. >> 3. Added an additional requirement to capture the "target-uri" >> information. >> 4. Fixed an error in the RFC 4244 ABNF and added "retarget" >> > parameter. > >> 5. Added a more simplified example. >> >> >> We had some very long offline exchanges as to the best way forward >> > and > >> remaining work for both documents. >> >> Some of the issues identified are: >> >> ::Issues:: >> 1. Should we remove the normative text from target-uri and >> > progress > >> 4244bis along with the target-uri document to meet the >> chartered >> SIP WG milestone? >> >> >> 2. Name of the parameter. >> At the last meeting, parameter "target" was said >> > inappropriate > >> because voicemail-uri spec already defines a parameter >> > called > >> "target" which also can be found in hi-entry, thus >> > potentially > >> causing confusion. >> >> Currently the target-uri draft uses "istarget" and 4244bis >> > uses > >> "retarget" but we could never come to >> a consensus on what name is appropriate. Other suggestions >> > have > >> included the following: >> "target-identity" (someone didn't like that "identity" is >> also a SIP header) >> "reg-uri" (can be paired with "mapped-uri" for item 3 >> > below) > >> "aor" >> "jibberish" >> etc. >> >> One reason this is so difficult relates to the problem >> statement in target-uri in that >> RFC 3261 doesn't differentiate the mechanism by which the >> > new > >> (target) Request-URI is selected. Another issue is that >> some of the terminology in >> RFC 3261 is overloaded - e.g., "forwarding" refers both to a >> Proxy >> which does not have responsibility for the domain of the >> request-URI >> in the incoming request, thus the proxy just "forwards" the >> request to >> the next hop AND "forwarding" is used to describe the >> process whereby >> the outgoing request is built and "forwarded" to the next >> hop at which >> point the proxy does not know how the new request-uri was >> selected. >> RFC 4244 has attempted to clarify the terms and attempts to >> use "forward" >> in the context of the former situation and "retarget" for >> the case whereby >> a proxy is responsible for the domain and thus can use a >> number of >> mechanism to select the new target for the request - e.g., a >> REGISTRAR, >> configured data, etc. >> >> 3. Related to the last point in item 2 above, it has been >> proposed that >> we differentiate the hi-entries even more by defining >> separate parameters >> for registered and configured/mapped contacts. >> Currently when the R-URI is translated to a URI which is >> either derived >> from location service lookup(registered by UA) or from >> > mapping > >> table, there is no differentiation as to how the URI was >> derived once it is >> added to the list of potential targets. >> >> The general consensus of the authors of the two documents was >> that it may >> be useful for some services to have the hi-entries tagged >> with the >> more specific information. >> >> And, of course, this gets us into another naming contest. In >> the end, the naming >> is not so important as long as the term isn't too overloaded >> and it is defined >> precisely in the document(s). >> >> We would appreciate WG feedback on these issues and any other >> comments on >> the two documents prior to IETF-74. >> >> Regards, >> Shida and Mary. >> >> >> >> Begin forwarded message: >> >>> *From: *Internet-Drafts@ietf.org >>> > > >>> *Date: *March 10, 2009 2:30:01 AM JST >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D >>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * >>> *Reply-To: *internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line >>> > Internet-Drafts > >>> directories. >>> >>> >>> Title >>> : Delivery of Request-URI Targets to User Agents >>> Author(s) >>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert >>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt >>> Pages >>> : 16 >>> Date >>> : 2009-3-9 >>> >>> When a Session Initiation Protocol (SIP) proxy receives a request >>> targeted at a URI identifying a user or resource it is >>> > responsible > >>> for, the proxy translates the URI to a registered or configured >>> contact URI of an agent representing that user or resource. In >>> > the > >>> process, the original URI is removed from the request. >>> Numerous use >>> cases have arisen which require this information to be >>> > delivered to > >>> the user agent. This document describes these use cases and >>> defines >>> an extension to the History-Info header field which allows it >>> > to be > >>> used to support those cases. >>> >>> A URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-de >>> livery-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> Content-Type: text/plain
Content-ID: >> <2009-3-9102756.I-D@ietf.org >> >

>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on current >> > sip > >> Use sipping@ietf.org for new >> developments on the application of sip >> >> >> From ietf.hanserik@gmail.com Wed Mar 11 16:55:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599293A6825 for ; Wed, 11 Mar 2009 16:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWyR91aXgJhs for ; Wed, 11 Mar 2009 16:55:04 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id 58A073A67A5 for ; Wed, 11 Mar 2009 16:55:04 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so55409nfh.39 for ; Wed, 11 Mar 2009 16:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=lu+zI3WbRtW/AEwBu3mqZcL8cNMmB+DSYqjPNFhz3kU=; b=oTSHQtkQyM9ZwoFb+o0vio2ac2XjHIwoz0lgSFcfEOILJcrfVuY5U3/zM9O53A3EMv 9yIAwnPWqFScJqquZ7Oh8x+P2MgKg21JZYGHPUm08ByRlLedNzH5oyZ9QpYCwG9NnSne xBWTCS3JiGBvzXuhNEWC4OBfFfk5rmHyKlSgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FGbg1Hukjm6Sn6Xq1P++HwJZpr/1wOXwoGkLOIBtdV6EdSyA3XDZzMqrftC+kQ9t05 fqhtY0u7sPdiErn6yN6Zrx+0IJ/ztpY6OLyPLImglSXDZX6WpUS4p8v6aOC68jKyDxB1 nhplRO/7KDuVJWtA7B5g44v2WyFpyZ/9tjx3o= Received: by 10.216.13.74 with SMTP id a52mr3733011wea.145.1236815740009; Wed, 11 Mar 2009 16:55:40 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 33sm44445nfu.9.2009.03.11.16.55.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 16:55:39 -0700 (PDT) Message-ID: <49B84F7B.1040009@gmail.com> Date: Thu, 12 Mar 2009 00:55:39 +0100 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mary Barnes References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com><49B8357E.2040809@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9839@zrc2hxm0.corp.nortel.com> <49B842D2.3030607@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF98F2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCF98F2@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Ian Elz , Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 23:55:06 -0000 But you do not have control over a previously visited proxy using the header. Why should that one dictate the privacy needs of the next hop proxy in the same domain? I dont think there is a conflict it is just adding some higher level of granularity in controlling the privacy of specific entries. /Hans Erik Mary Barnes wrote: > And, if you have a network whereby you believe that none of the > information that Proxy 2 will put in hi-entries reveals any information > that is considered private, then you can set your flag, or whatever and > not drop the hi-entries when they leave that domain - that's why it's a > SHOULD NOT - i.e., don't do it unless you've evaluated why it's okay to > do it in that case. It is clearly documented in 4244 that there is > indeed a loss of information when you use the Privacy header versus > tagging individual hi-entries with the privacy header. Now, we could add > a Recommendation that the Privacy header be used only to tag individual > entries. > > Yes, I agree the "none" is not a good idea (and conflicts with the > Privacy header) as it kindof overrides it, so to speak. > > Mary. > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Hans Erik van Elburg > Sent: Wednesday, March 11, 2009 6:02 PM > To: Barnes, Mary (RICH2:AR00) > Cc: sip@ietf.org; Ian Elz; Audet, Francois (SC100:3055) > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > When a proxy1 adds a Privacy header with the value history, then why > should a proxy 2 not be able to say: fine but I override the general > privacy rule for the specific hi-entry that I add or am responsible for? > > I was reacting to "I don't like the "none" idea as it really must be up > to the entity that added the Privacy header to the request, as to > whether it wants the HI entries that it adds to go outside a domain." > > /Hans Erik > > Mary Barnes wrote: > >> I'm not sure if I'm clear on your concern here - what is the >> > "something" > >> in the "Why should History-Info enforce..."? >> >> If by the "something" you mean removing the history-info header (if >> it's session or header level privacy), we have to go back to the >> fundamental History-Info solution requirements and consider the >> functionality provided by the Privacy header in RFC 3324. This isn't >> about application-agnostic or not. The information in the hi-entries >> can be considered of the same ilk as the other information that is >> intended to be kept private by the use of the Privacy header, thus if >> the request indicates session or header levels of privacy, the proxy >> SHOULD NOT forward the hi-entries. Note, it's a SHOULD NOT. If your >> network configuration is such that there is no privacy issue with >> sharing that information, then you can document as such and explain >> why it's perfectly okay to forward the hi-entries. >> >> However, per my note below, even if the prior hop strips out >> information that is appropriate to the next domain, the last hi-entry >> can be added by that next hop proxy to preserve the information before >> > > >> that proxy might change the request-uri. >> >> Mary. >> >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Wednesday, March 11, 2009 5:05 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Ian Elz; Audet, Francois (SC100:3055); sip@ietf.org >> Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt >> >> I believe in this case the History-Info application-agnosticness >> principle applies. >> >> Why should History-Info enforce something, that goes against the >> whishes of a domain that is adding a hi-entry and should be considered >> > > >> best equiped in judging what privacy rules apply for this specific >> > entry. > >> /Hans Erik >> >> Mary Barnes wrote: >> >> >>> Ian, >>> >>> This is an interesting question. I need to think about it some more, >>> but I don't like the "none" idea as it really must be up to the >>> entity >>> >>> >> >> >>> that added the Privacy header to the request, as to whether it wants >>> the HI entries that it adds to go outside a domain. My initial >>> thought >>> >>> >> >> >>> is that we can't overrule the overall Privacy header. The thing is >>> that the Privacy header doesn't preclude gathering the information >>> and >>> >>> >> >> >>> using within a domain AND if it were to not include an hi-entry when >>> the request leaves the domain for which the proxy is responsible, the >>> > > >>> recipient can add the hi-entry for the current request-uri before it >>> adds the new hi-entry. >>> >>> Your PSTN example doesn't strictly map obviously to a SIP model and I >>> > > >>> would think you might consider the PSTN hop to be within the same >>> domain for which the proxy (or gw, I guess) is responsible OR >>> consider >>> >>> >> >> >>> this a walled garden whereby the Privacy header doesn't apply. Which >>> brings me to a more general question as to how you all deal with >>> other >>> >>> >> >> >>> headers when you do your mapping to the PSTN when there is a Privacy >>> header? It would seem this problem isn't unique to History-Info, >>> although I know little about the details of PSTN I/W. >>> >>> Regards, >>> Mary. >>> >>> -----Original Message----- >>> From: Ian Elz [mailto:ian.elz@ericsson.com] >>> Sent: Wednesday, March 11, 2009 4:54 AM >>> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) >>> Cc: sip@ietf.org >>> Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >>> >>> Mary, Francois, >>> >>> Section 4.1 of the draft allows for the addition of the Privacy >>> header >>> >>> >> >> >>> parameter with a value of "history" to be included with the >>> hi-targeted-to-uri. >>> >>> Can this be extended to also allow the value "none". >>> >>> A node adding a H-I entry is allowed to specify the privacy value >>> "history" either in the Privacy header or as a header parameter >>> associated with the hi-targeted-to-uri. If the former action is taken >>> > > >>> by one node this results in privacy for all history info header >>> entries even if this is not required. There is no way for privacy of >>> an individual H-I entry to be set to none if no Privacy is required >>> for the uri. >>> >>> This creates a specific problem when interworking with the PSTN where >>> > > >>> the privacy is associated with each E.164 number included in the >>> protocol. If an INVITE is being mapped to ISUP and the H-I entries >>> are >>> >>> >> >> >>> being used to map to redirection numbers then a single Privacy header >>> > > >>> with the value "history" will result in all numbers being restricted. >>> >>> If the Privacy header parameter could include the value "none" then >>> this would explicitly indicate that the associated uri was allowed to >>> > > >>> be presented. >>> >>> The ability to explicitly allow presentation of specific H-I entries >>> may also be useful in pure sip implementations. >>> >>> I don't believe that this change would create any backward >>> compatibility issues. The existing implementations will continue as >>> deployed but new implementations could explicitly set no privacy for >>> a >>> >>> >> specific uri. >> >> >>> There are no security issues other than those already defined in the >>> draft that an intervening node could modify an existing H-I entry. >>> The >>> >>> >> >> >>> Privacy header value of "none" should only be included by the node in >>> > > >>> the same manner as the existing inclusion of the "history" value. >>> >>> Ian Elz >>> >>> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>> Internet-Drafts@ietf.org >>> Sent: 04 March 2009 15:15 >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : An Extension to the Session Initiation >>> Protocol (SIP) for Request History Information >>> Author(s) : M. Barnes, F. Audet >>> Filename : draft-barnes-sip-rfc4244bis-00.txt >>> Pages : 49 >>> Date : 2009-03-04 >>> >>> 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 call arrives at a specific >>> application >>> >>> >> >> >>> or user. This document defines a new optional SIP header, >>> History-Info, for capturing the history information in requests. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.tx >>> t >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >>> >>> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > From mary.barnes@nortel.com Wed Mar 11 17:41:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E40B3A67D4 for ; Wed, 11 Mar 2009 17:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmY3LuZdCSjC for ; Wed, 11 Mar 2009 17:40:58 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 71C6B3A69FD for ; Wed, 11 Mar 2009 17:40:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2C0fDo18305; Thu, 12 Mar 2009 00:41:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 19:44:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCF99C0@zrc2hxm0.corp.nortel.com> In-Reply-To: <49B84F7B.1040009@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: AcmipOP2rZGgXgSqSgqhiyX/LWiC8AABemTA References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com><49B8357E.2040809@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9839@zrc2hxm0.corp.nortel.com> <49B842D2.3030607@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF98F2@zrc2hxm0.corp.nortel.com> <49B84F7B.1040009@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sip@ietf.org, Ian Elz , Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 00:41:00 -0000 Responses below [MB]. -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, March 11, 2009 6:56 PM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org; Ian Elz; Audet, Francois (SC100:3055) Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt But you do not have control over a previously visited proxy using the header. Why should that one dictate the privacy needs of the next hop proxy in the same domain? [MB] If the Privacy header is for the request as a whole (i.e., it's not tagged against a specific hi-entry), then by the definition of the header in RFC 3323 (with the addition of the priv-value=3D"history"), it does apply to how the handled is request at every node. And, again, it is a SHOULD NOT, so it is possible that there might be conditions under which you don't want to "dictate the privacy needs..." - you just need to specify the conditions. Also, within the same domain, the hi-entries are NOT removed even if the Privacy header is used. If Proxy 1 and Proxy 2 are responsible for the same domain, then you don't remove the hi-entries until you leave that domain. [/MB] I dont think there is a conflict it is just adding some higher level of granularity in controlling the privacy of specific entries. [MB] I had interpreted the "none" to be used with the Privacy header (for the whole request, not just specific hi-entries), so that the specific entry can be forwarded outside a domain. [/MB] /Hans Erik Mary Barnes wrote: > And, if you have a network whereby you believe that none of the=20 > information that Proxy 2 will put in hi-entries reveals any=20 > information that is considered private, then you can set your flag, or > whatever and not drop the hi-entries when they leave that domain -=20 > that's why it's a SHOULD NOT - i.e., don't do it unless you've=20 > evaluated why it's okay to do it in that case. It is clearly=20 > documented in 4244 that there is indeed a loss of information when you > use the Privacy header versus tagging individual hi-entries with the=20 > privacy header. Now, we could add a Recommendation that the Privacy=20 > header be used only to tag individual entries. > > Yes, I agree the "none" is not a good idea (and conflicts with the=20 > Privacy header) as it kindof overrides it, so to speak. > > Mary.=20 > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > Hans Erik van Elburg > Sent: Wednesday, March 11, 2009 6:02 PM > To: Barnes, Mary (RICH2:AR00) > Cc: sip@ietf.org; Ian Elz; Audet, Francois (SC100:3055) > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > When a proxy1 adds a Privacy header with the value history, then why=20 > should a proxy 2 not be able to say: fine but I override the general=20 > privacy rule for the specific hi-entry that I add or am responsible for? > > I was reacting to "I don't like the "none" idea as it really must be=20 > up to the entity that added the Privacy header to the request, as to=20 > whether it wants the HI entries that it adds to go outside a domain." > > /Hans Erik > > Mary Barnes wrote: > =20 >> I'm not sure if I'm clear on your concern here - what is the >> =20 > "something" > =20 >> in the "Why should History-Info enforce..."?=20 >> >> If by the "something" you mean removing the history-info header (if=20 >> it's session or header level privacy), we have to go back to the=20 >> fundamental History-Info solution requirements and consider the=20 >> functionality provided by the Privacy header in RFC 3324. This isn't=20 >> about application-agnostic or not. The information in the hi-entries >> can be considered of the same ilk as the other information that is=20 >> intended to be kept private by the use of the Privacy header, thus if >> the request indicates session or header levels of privacy, the proxy=20 >> SHOULD NOT forward the hi-entries. Note, it's a SHOULD NOT. If your=20 >> network configuration is such that there is no privacy issue with=20 >> sharing that information, then you can document as such and explain=20 >> why it's perfectly okay to forward the hi-entries. >> >> However, per my note below, even if the prior hop strips out=20 >> information that is appropriate to the next domain, the last hi-entry >> can be added by that next hop proxy to preserve the information=20 >> before >> =20 > > =20 >> that proxy might change the request-uri. >> >> Mary.=20 >> >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Wednesday, March 11, 2009 5:05 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Ian Elz; Audet, Francois (SC100:3055); sip@ietf.org >> Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt >> >> I believe in this case the History-Info application-agnosticness=20 >> principle applies. >> >> Why should History-Info enforce something, that goes against the=20 >> whishes of a domain that is adding a hi-entry and should be=20 >> considered >> =20 > > =20 >> best equiped in judging what privacy rules apply for this specific >> =20 > entry. > =20 >> /Hans Erik >> >> Mary Barnes wrote: >> =20 >> =20 >>> Ian, >>> >>> This is an interesting question. I need to think about it some more, >>> but I don't like the "none" idea as it really must be up to the=20 >>> entity >>> =20 >>> =20 >> =20 >> =20 >>> that added the Privacy header to the request, as to whether it wants >>> the HI entries that it adds to go outside a domain. My initial=20 >>> thought >>> =20 >>> =20 >> =20 >> =20 >>> is that we can't overrule the overall Privacy header. The thing is=20 >>> that the Privacy header doesn't preclude gathering the information=20 >>> and >>> =20 >>> =20 >> =20 >> =20 >>> using within a domain AND if it were to not include an hi-entry when >>> the request leaves the domain for which the proxy is responsible,=20 >>> the >>> =20 > > =20 >>> recipient can add the hi-entry for the current request-uri before it >>> adds the new hi-entry. >>> >>> Your PSTN example doesn't strictly map obviously to a SIP model and=20 >>> I >>> =20 > > =20 >>> would think you might consider the PSTN hop to be within the same=20 >>> domain for which the proxy (or gw, I guess) is responsible OR=20 >>> consider >>> =20 >>> =20 >> =20 >> =20 >>> this a walled garden whereby the Privacy header doesn't apply. Which >>> brings me to a more general question as to how you all deal with=20 >>> other >>> =20 >>> =20 >> =20 >> =20 >>> headers when you do your mapping to the PSTN when there is a Privacy >>> header? It would seem this problem isn't unique to History-Info,=20 >>> although I know little about the details of PSTN I/W. >>> >>> Regards, >>> Mary.=20 >>> >>> -----Original Message----- >>> From: Ian Elz [mailto:ian.elz@ericsson.com] >>> Sent: Wednesday, March 11, 2009 4:54 AM >>> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) >>> Cc: sip@ietf.org >>> Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >>> >>> Mary, Francois, >>> >>> Section 4.1 of the draft allows for the addition of the Privacy=20 >>> header >>> =20 >>> =20 >> =20 >> =20 >>> parameter with a value of "history" to be included with the=20 >>> hi-targeted-to-uri. >>> >>> Can this be extended to also allow the value "none". >>> >>> A node adding a H-I entry is allowed to specify the privacy value=20 >>> "history" either in the Privacy header or as a header parameter=20 >>> associated with the hi-targeted-to-uri. If the former action is=20 >>> taken >>> =20 > > =20 >>> by one node this results in privacy for all history info header=20 >>> entries even if this is not required. There is no way for privacy of >>> an individual H-I entry to be set to none if no Privacy is required=20 >>> for the uri. >>> >>> This creates a specific problem when interworking with the PSTN=20 >>> where >>> =20 > > =20 >>> the privacy is associated with each E.164 number included in the=20 >>> protocol. If an INVITE is being mapped to ISUP and the H-I entries=20 >>> are >>> =20 >>> =20 >> =20 >> =20 >>> being used to map to redirection numbers then a single Privacy=20 >>> header >>> =20 > > =20 >>> with the value "history" will result in all numbers being restricted. >>> >>> If the Privacy header parameter could include the value "none" then=20 >>> this would explicitly indicate that the associated uri was allowed=20 >>> to >>> =20 > > =20 >>> be presented. >>> >>> The ability to explicitly allow presentation of specific H-I entries >>> may also be useful in pure sip implementations. >>> >>> I don't believe that this change would create any backward=20 >>> compatibility issues. The existing implementations will continue as=20 >>> deployed but new implementations could explicitly set no privacy for >>> a >>> =20 >>> =20 >> specific uri. >> =20 >> =20 >>> There are no security issues other than those already defined in the >>> draft that an intervening node could modify an existing H-I entry. >>> The >>> =20 >>> =20 >> =20 >> =20 >>> Privacy header value of "none" should only be included by the node=20 >>> in >>> =20 > > =20 >>> the same manner as the existing inclusion of the "history" value. >>> >>> Ian Elz >>> >>> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 >>> Internet-Drafts@ietf.org >>> Sent: 04 March 2009 15:15 >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>> directories. >>> >>> Title : An Extension to the Session Initiation >>> Protocol (SIP) for Request History Information >>> Author(s) : M. Barnes, F. Audet >>> Filename : draft-barnes-sip-rfc4244bis-00.txt >>> Pages : 49 >>> Date : 2009-03-04 >>> >>> This document defines a standard mechanism for capturing the history >>> information associated with a Session Initiation Protocol (SIP) >>> =20 >>> =20 >> request. >> =20 >> =20 >>> This capability enables many enhanced services by providing the=20 >>> information as to how and why a call arrives at a specific=20 >>> application >>> =20 >>> =20 >> =20 >> =20 >>> or user. This document defines a new optional SIP header,=20 >>> History-Info, for capturing the history information in requests. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.t >>> x >>> t >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader=20 >>> implementation to automatically retrieve the ASCII version of the=20 >>> Internet-Draft. >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use=20 >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>> sipping@ietf.org for new developments on the application of sip >>> =20 >>> =20 >>> =20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip > =20 From mary.barnes@nortel.com Wed Mar 11 18:31:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0D53A6856 for ; Wed, 11 Mar 2009 18:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaFCPwmouz6v for ; Wed, 11 Mar 2009 18:31:05 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C107C3A6AF3 for ; Wed, 11 Mar 2009 18:31:04 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2C1VTI14981; Thu, 12 Mar 2009 01:31:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 20:33:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> In-Reply-To: <49B84C55.5070107@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiowNJbenlSmU/RXqXp4+x8CxDCQACM/4w References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:31:06 -0000 Responses below [MB]. -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, March 11, 2009 6:42 PM To: Barnes, Mary (RICH2:AR00) Cc: Shida Schubert; sip@ietf.org Subject: Re: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I was talking about the concept. The use cases only describe cases where the target-uri (lets call that current target from now) has been lost when an initial request for a dialog or standalone request arrives at the UAS. [MB] And I think this is where the terminology confusion starts - I don't think of the "lost" target-uri as being the "current" target. In my mind, the "current" target is reflected by the last hi-entry and the request-uri in the incoming request at the UAS. If the entity that sent the request was the entity that added the last hi-entry, then the uri in that hi-entry is the same as the request-URI in the SIP request that arrives at the UAS. I refer to the "lost" uri as the one that was "retargeted" - that's the one the UAS wants to pull from the hi-entries in the incoming request. That hi-entry was not the one that was just added by the entity that built the request just received by the UAS. That hi-entry is tagged with whatever name we are going to tag it with BEFORE the request is forwarded (using the term forward per section 16.6 of RFC 3261). That tag is added once the target set of potential candidates for the new request uri are determined in section 16.5 of 3261 (with "target set" being a 3261 term), just before the request is forwarded in section 16.6 to one of those targets. A new hi-entry (which will be the last hi-entry in the request received by the UAS) is added in section 16.6 of 3261 as the request is forwarded. At this point in time, the lost information is in the previous hi-entry when the outgoing request is sent. [/MB]=20 What has been lost is the current target of the request: [MB] Right - at which point in my mind, it's no longer the current target ;) Maybe we call it "lost". [/MB] Current target The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. [MB] I don't think this definition fits what you want - i.e., if there is no retargeting, then none of the hi-entries are tagged - i.e., you won't have your concept of current. The way it works is that if no hi-entries are tagged, then you know that there was no retargeting, thus you know the request-uri has not been lost. [/MB] This defintion only makes sense when the following definitions are used: Name: A name is a moniker for an entity which refers to it in a way which reveals nothing about where it is in a network. In SIP, tel URI which doesn't represent the location of the entity is a name. =20 Address: An address is an identifier for an entity which describes it by its location on the network. In SIP, the SIP URI itself is a form of address because the host part of the URI, the only mandatory part of the URI besides the scheme itself, indicates the location of a SIP server that can be used to handle the request. Route: Finally, a route is a sequence of SIP entities (including the UA=20 itself!) which are traversed in order to forward a request to an address or name. Retarget (other term might be needed, as this is highly confusing): A Request-URI rewrite operation that changes the target identity of the request. Reroute (other term might be needed): A Request-URI rewrite operation that does not change the current=20 target of the request, but determines the route/next hop taken to=20 reach the target-identity. /Hans Erik Mary Barnes wrote: > So, by "target-uri concept" are you referring to the solution in the=20 > current target-uri draft or the application usage as such in the > target-uri document (which is what I was referring to)? =20 > > Yes, the problem is that SIP doesn't differentiate the various=20 > mechanisms by which a request-URI may be changed, which is what some=20 > of the updated text in 4244bis is trying to do and why we need precise > terms. I think we all agree that. > > I honestly don't care what we call the tag, as long as we're clear=20 > about the functionality. > > Mary.=20 > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 4:40 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D=20 > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > The target-uri concept when defined properly is entirely application=20 > agnostic. > > When one uses History-Info or another header as a vehicle for this=20 > information then it still can be considered application agnostic as=20 > any application can use this information as it likes. > > From SIP perspective all the Request-URI rewrites look the same, that > is what brought us discussing this in the first place. > > /Hans Erik > > Mary Barnes wrote: > =20 >> And, I think the big issue with the terminology is that 4244bis is=20 >> application agnostic, so it is tagging what happens to the URIs=20 >> (why/how the specific URI was overwritten). Whereas, specific=20 >> applications can derive information, such as what "is" the real >> "target" for the request, from the History-Info header. So, IMHO,=20 >> it's a matter of the target-uri document specifying that the last=20 >> entry tagged by whatever name we come up with "is" the real "target" >> for the request. I believe it's up to the applications to describe=20 >> how they make use of the History-Info and not for the History-Info to >> describe how applications can use it. History-Info purely reflects=20 >> what happened from a SIP Protocol perspective and should not imply=20 >> any >> =20 > > =20 >> application semantics. Indeed the intent of section 5 of 4244 was to=20 >> inform the applications how they should decribe their usage of the=20 >> header. >> =20 >> Mary. >> Note: I changed the subject to hopefully make this topic easier to=20 >> keep track of. >> >> --------------------------------------------------------------------- >> - >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Wednesday, March 11, 2009 3:59 AM >> *To:* Shida Schubert >> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) >> *Subject:* Re: [Sip] Fwd: I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >> >> One of the problems that made the discussion quite tedious is the=20 >> complete inversed meaning of the terms "retarget" and "reroute" >> between 4244bis and target-uri factions have. >> >> Conclusion was that the terminology need to be properly defined and=20 >> some attempt was made to start such activity. >> >> On 3. I have strong concerns when we start tagging the URI as to how=20 >> they come about "retarget"/"mapped conficuration" etc. It is better=20 >> to >> =20 > > =20 >> embellish them with a tag that just represents there meaning for=20 >> example "istarget" or "hop". For the following reasons: >> 1. It is much more intuitive for the user of this information, its=20 >> meaning can basically be guessed. >> 2. Such meaning also probably survives application in other problem=20 >> spaces that we had not foreseen when introducing the concept. >> >> The solution that is described now in the target-URI delivery draft=20 >> is not yet complete, it does not solve the freephone use case for=20 >> example and in its current form it will deliver exactly the same=20 >> target-URI as that which would be delivered by the P-Called-Party-ID >> header. Contrary to what the draft says. So some work is needed still. >> >> /Hans Erik van Elburg >> >> >> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > > wrote: >> >> >> We have submitted the updated target-uri draft based on the >> =20 > comments > =20 >> submitted to the list and comments received at IETF73.=20 >> >> I have taken over as editor as Jonathan didn't have the cycles to >> update the draft, with Francois, Christer and Hans Erick as >> additional=20 >> co-authors and great deal of help from Mary. =20 >> =20 >> The following summarizes the changes made to the target-uri >> =20 > document > =20 >> 1. Added use-case for toll-free number back >> 2. Added definition of "retarget" operation.=20 >> 3. Removed a reference to URN >> 4. Added a text discussing the difference to P-Called-Party-Id >> 5. Changed parameter name from "target" to "istarget" >> =20 >> Note, that the target-uri document still contains the normative >> text for the >> History-Info header. >> =20 >> In addition, Mary (with Francois as co-author) has submitted a >> rfc4244bis, with the following changes: >> 1. Incorporated the normative aspects of the target-uri document >> into the existing normative text in RFC 4244 - the functionality >> =20 > is > =20 >> virtually identical (as is some of the text) as the HI based >> =20 > solution > =20 >> described in the target-uri document. It's important that the >> solution >> be integrated into RFC 4244 as it MUST work and be based on the >> normative >> aspects of RFC 4244. >> 2. Added the use cases from target-uri the the summary >> in the overview of rfc4244bis. >> 3. Added an additional requirement to capture the "target-uri" >> information. >> 4. Fixed an error in the RFC 4244 ABNF and added "retarget" >> =20 > parameter. > =20 >> 5. Added a more simplified example. >> =20 >> =20 >> We had some very long offline exchanges as to the best way=20 >> forward >> =20 > and > =20 >> remaining work for both documents. >> =20 >> Some of the issues identified are: >> >> ::Issues:: >> 1. Should we remove the normative text from target-uri and >> =20 > progress > =20 >> 4244bis along with the target-uri document to meet the >> chartered >> SIP WG milestone?=20 >> =20 >> =20 >> 2. Name of the parameter.=20 >> At the last meeting, parameter "target" was said >> =20 > inappropriate > =20 >> because voicemail-uri spec already defines a parameter >> =20 > called > =20 >> "target" which also can be found in hi-entry, thus >> =20 > potentially > =20 >> causing confusion. >> =20 >> Currently the target-uri draft uses "istarget" and 4244bis >> =20 > uses > =20 >> "retarget" but we could never come to=20 >> a consensus on what name is appropriate. Other suggestions >> =20 > have > =20 >> included the following: >> "target-identity" (someone didn't like that "identity" is >> also a SIP header) >> "reg-uri" (can be paired with "mapped-uri" for item 3 >> =20 > below) > =20 >> "aor" >> "jibberish"=20 >> etc. >> =20 >> One reason this is so difficult relates to the problem >> statement in target-uri in that >> RFC 3261 doesn't differentiate the mechanism by which the >> =20 > new > =20 >> (target) Request-URI is selected. Another issue is that >> some of the terminology in >> RFC 3261 is overloaded - e.g., "forwarding" refers both to a >> Proxy >> which does not have responsibility for the domain of the >> request-URI >> in the incoming request, thus the proxy just "forwards" the >> request to >> the next hop AND "forwarding" is used to describe the >> process whereby >> the outgoing request is built and "forwarded" to the next >> hop at which >> point the proxy does not know how the new request-uri was >> selected. >> RFC 4244 has attempted to clarify the terms and attempts to >> use "forward"=20 >> in the context of the former situation and "retarget" for >> the case whereby >> a proxy is responsible for the domain and thus can use a >> number of=20 >> mechanism to select the new target for the request - e.g., a >> REGISTRAR,=20 >> configured data, etc. =20 >> >> 3. Related to the last point in item 2 above, it has been >> proposed that >> we differentiate the hi-entries even more by defining >> separate parameters >> for registered and configured/mapped contacts.=20 >> Currently when the R-URI is translated to a URI which is >> either derived=20 >> from location service lookup(registered by UA) or from >> =20 > mapping > =20 >> table, there is no differentiation as to how the URI was >> derived once it is >> added to the list of potential targets. >> =20 >> The general consensus of the authors of the two documents was >> that it may=20 >> be useful for some services to have the hi-entries tagged >> with the >> more specific information.=20 >> =20 >> And, of course, this gets us into another naming contest. In >> the end, the naming >> is not so important as long as the term isn't too overloaded >> and it is defined >> precisely in the document(s). >> =20 >> We would appreciate WG feedback on these issues and any other >> comments on >> the two documents prior to IETF-74. >> =20 >> Regards, >> Shida and Mary. >> >> >> >> Begin forwarded message: >> =20 >>> *From: *Internet-Drafts@ietf.org >>> =20 > > =20 >>> *Date: *March 10, 2009 2:30:01 AM JST >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D >>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * >>> *Reply-To: *internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line >>> =20 > Internet-Drafts > =20 >>> directories. >>> >>> >>> Title >>> : Delivery of Request-URI Targets to User Agents >>> Author(s) >>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert >>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt >>> Pages >>> : 16 >>> Date >>> : 2009-3-9 >>> >>> When a Session Initiation Protocol (SIP) proxy receives a request >>> targeted at a URI identifying a user or resource it is >>> =20 > responsible > =20 >>> for, the proxy translates the URI to a registered or configured >>> contact URI of an agent representing that user or resource. =20 >>> In >>> =20 > the > =20 >>> process, the original URI is removed from the request. >>> Numerous use >>> cases have arisen which require this information to be >>> =20 > delivered to > =20 >>> the user agent. This document describes these use cases and >>> defines >>> an extension to the History-Info header field which allows it >>> =20 > to be > =20 >>> used to support those cases. >>> >>> A URL for this Internet-Draft is: >>> =20 >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d >>> e >>> livery-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> =20 >> Content-Type: text/plain
Content-ID: >> <2009-3-9102756.I-D@ietf.org >> >

>> =20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> =20 >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on=20 >> current >> =20 > sip > =20 >> Use sipping@ietf.org for new >> developments on the application of sip >> >> >> =20 From gao.yang2@zte.com.cn Wed Mar 11 20:40:47 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B767A28C169; Wed, 11 Mar 2009 20:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.352 X-Spam-Level: X-Spam-Status: No, score=-89.352 tagged_above=-999 required=5 tests=[AWL=-1.459, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JabJSZRZGwNx; Wed, 11 Mar 2009 20:40:46 -0700 (PDT) Received: from mail.zte.com.cn (mx1.zte.no [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id E349B3A6912; Wed, 11 Mar 2009 20:40:41 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.6843256625; Thu, 12 Mar 2009 12:04:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2C3fM22095543; Thu, 12 Mar 2009 11:41:22 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: From: gao.yang2@zte.com.cn To: "Christer Holmberg" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Thu, 12 Mar 2009 11:41:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-12 11:41:16, Serialize complete at 2009-03-12 11:41:16 Content-Type: multipart/alternative; boundary="=_alternative 0014415F48257577_=" X-MAIL: mse1.zte.com.cn n2C3fM22095543 Cc: SIP , SIPPING , sip-bounces@ietf.org, Brett Tate Subject: [Sip] =?gb2312?b?tPC4tDogUmU6ICAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUi?= =?gb2312?b?IGRpc2N1c3Npb24=?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 03:40:47 -0000 This is a multipart message in MIME format. --=_alternative 0014415F48257577_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiC439HvL7nMzfjI7bz+v6q3otK7 sr8v1tDQxNHQvr/Uui/W0NDLzajRtg0KIFRlbCAgICA6IDg3MjExDQogTVNOICAgIDogdHpneW5l d0Bob3RtYWlsLmNvbQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQogQWRkciAgIDrE z76pytDT6ruozKjH+NfPvqO7qMK3Nji6xSAyMTAwMTINCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQoNCg0KDQoiQ2hyaXN0ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+IA0Kt6K8/sjLOiAgc2lwLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDMt MTAgMjM6MTUNCg0KytW8/sjLDQoiQnJldHQgVGF0ZSIgPGJyZXR0QGJyb2Fkc29mdC5jb20+LCAi U0lQUElORyIgPHNpcHBpbmdAaWV0Zi5vcmc+LCAiU0lQIiANCjxzaXBAaWV0Zi5vcmc+DQqzrcvN DQoNCtb3zOINClJlOiBbU2lwXSAiVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUiIGRpc2N1c3Npb24N Cg0KDQoNCg0KDQoNCg0KSGksIA0KDQo+PlJlZ2FyZGluZyB5b3VyIHNlY29uZCBidWxsZXQsIEkg ZG9uJ3QgZXZlbiB0aGluayB0aGF0IG9uZSBzaG91bGQgc2VuZCANCj4+Im5lc3RlZCIgVVBEQVRF cywgaWYgdGhleSBkb24ndCBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggdGhlIA0KPj5yZS1JTlZJ VEUuIEkgdGhpbmsgdGhhdCBpcyBiYWQgYXBwbGljYXRpb24gZGVzaWduLg0KPj5Ob24tcmVsYXRl ZCBjaGFuZ2VzIHNob3VsZCBiZSBkb25lIG91dHNpZGUgdGhlIHJlLUlOVklURSB0cmFuc2FjdGlv bi4NCj4gIA0KPlNlbmRpbmcgVVBEQVRFIHBlciBSRkMgNDAyOCB0byByZWZyZXNoIG9yIGF1ZGl0 IHRoZSBkaWFsb2cgaXMgDQo+b25lIG9mIHRoZSB0aW1lcyBVUERBVEUgbWF5IGJlIHRyaWVkIHdo aWxlIGEgcmUtSU5WSVRFIGlzIG9jY3VycmluZy4NCg0KVHJ1ZSwgYnV0IG5vcm1hbGx5IHRob3Nl IFVQREFURXMgYXJlIG5vdCBnb2luZyB0byBtb2RpZnkgc2Vzc2lvbiANCnBhcmFtZXRlcnMuDQoN ClNvLCB5ZXMsIGl0IG1heSBoYXBwZW4sIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCByZWNvbW1lbmQg YWdhaW5zdCBkb2luZyBzby4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNpcCBtYWlsaW5nIGxpc3QgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQpUaGlzIGxpc3QgaXMgZm9y IE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNClVzZSBzaXAtaW1wbGVt ZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQpVc2Ug c2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24g b2Ygc2lwDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhl IHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4g c2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9m IHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMg dHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUg YWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFz ZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNz ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUg QW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0014415F48257577_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KILjf0e8vuczN+MjtvP6/qrei0ruyvy/W0NDE0dC+v9S6L9bQ 0MvNqNG2PGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBNU04gJm5ic3A7ICZu YnNwOzogdHpneW5ld0Bob3RtYWlsLmNvbTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNv bS5jbjxicj4NCiBBZGRyICZuYnNwOyA6xM++qcrQ0+q7qMyox/jXz76ju6jCtzY4usUgMjEwMDEy PGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7Q2hyaXN0ZXIgSG9s bWJlcmcmcXVvdDsNCiZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PC9iPiA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7 c2lwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAwOS0wMy0xMCAyMzoxNTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtCcmV0dCBUYXRlJnF1b3Q7ICZsdDticmV0dEBi cm9hZHNvZnQuY29tJmd0OywNCiZxdW90O1NJUFBJTkcmcXVvdDsgJmx0O3NpcHBpbmdAaWV0Zi5v cmcmZ3Q7LCAmcXVvdDtTSVAmcXVvdDsgJmx0O3NpcEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbU2lwXSAm cXVvdDtVUERBVEUgZHVyaW5nIFJlLUlOVklURSZxdW90Ow0KZGlzY3Vzc2lvbjwvZm9udD48L3Rh YmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KSGks IDxicj4NCjxicj4NCiZndDsmZ3Q7UmVnYXJkaW5nIHlvdXIgc2Vjb25kIGJ1bGxldCwgSSBkb24n dCBldmVuIHRoaW5rIHRoYXQgb25lIHNob3VsZA0Kc2VuZCA8YnI+DQomZ3Q7Jmd0OyZxdW90O25l c3RlZCZxdW90OyZuYnNwO1VQREFURXMsIGlmIHRoZXkgZG9uJ3QgaGF2ZSBhbnl0aGluZyB0bw0K ZG8gd2l0aCB0aGUgPGJyPg0KJmd0OyZndDtyZS1JTlZJVEUuIEkgdGhpbmsgdGhhdCBpcyBiYWQg YXBwbGljYXRpb24gZGVzaWduLjxicj4NCiZndDsmZ3Q7Tm9uLXJlbGF0ZWQgY2hhbmdlcyBzaG91 bGQgYmUgZG9uZSBvdXRzaWRlIHRoZSByZS1JTlZJVEUgdHJhbnNhY3Rpb24uPGJyPg0KJmd0OyAm bmJzcDs8YnI+DQomZ3Q7U2VuZGluZyBVUERBVEUgcGVyIFJGQyA0MDI4IHRvIHJlZnJlc2ggb3Ig YXVkaXQgdGhlIGRpYWxvZyBpcyA8YnI+DQomZ3Q7b25lIG9mIHRoZSB0aW1lcyBVUERBVEUgbWF5 IGJlIHRyaWVkIHdoaWxlIGEgcmUtSU5WSVRFIGlzIG9jY3VycmluZy48YnI+DQo8YnI+DQpUcnVl LCBidXQgbm9ybWFsbHkgdGhvc2UgVVBEQVRFcyBhcmUgbm90IGdvaW5nIHRvIG1vZGlmeSBzZXNz aW9uIHBhcmFtZXRlcnMuPGJyPg0KPGJyPg0KU28sIHllcywgaXQgbWF5IGhhcHBlbiwgYnV0IEkg dGhpbmsgd2Ugc2hvdWxkIHJlY29tbWVuZCBhZ2FpbnN0IGRvaW5nIHNvLjxicj4NCjxicj4NClJl Z2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClNpcCBtYWlsaW5nIGxpc3QgJm5ic3A7 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXA8YnI+DQpUaGlzIGxpc3Qg aXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2w8YnI+DQpVc2Ug c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50 IHNpcDxicj4NClVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRo ZSBhcHBsaWNhdGlvbiBvZiBzaXA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhl Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt YWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZu YnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNw O21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Bl cm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNw O29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRo aXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0 ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQm bmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8m bmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNw O3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2lu Jm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5h dG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5i c3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNw O3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZu YnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRp LVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0014415F48257577_=-- From gao.yang2@zte.com.cn Wed Mar 11 20:46:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1163A69E6; Wed, 11 Mar 2009 20:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.173 X-Spam-Level: X-Spam-Status: No, score=-93.173 tagged_above=-999 required=5 tests=[AWL=2.385, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_SPAM=3.798, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g0zOWYscLCX; Wed, 11 Mar 2009 20:46:28 -0700 (PDT) Received: from mail.zte.com.cn (mail.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 2A59F28C16F; Wed, 11 Mar 2009 20:46:21 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.4453668360; Thu, 12 Mar 2009 12:10:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2C3kxbT098796; Thu, 12 Mar 2009 11:46:59 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) From: gao.yang2@zte.com.cn To: "SIP" , "SIPPING" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Thu, 12 Mar 2009 11:46:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-12 11:46:53, Serialize complete at 2009-03-12 11:46:53 Content-Type: multipart/alternative; boundary="=_alternative 0014C4A448257577_=" X-MAIL: mse1.zte.com.cn n2C3kxbT098796 Cc: Gonzalo Camarillo , Christer Holmberg Subject: [Sip] One chart //"UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 03:46:29 -0000 This is a multipart message in MIME format. --=_alternative 0014C4A448257577_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 ICAgICAgVUFDICAgICAgICAgICAgICAgICAgIFVBUw0KICAgICAgIHwgc2Vzc2lvbiBlc3RhYmxp c2hlZCB8DQogICAgICAgfDw9PT09PT09PT09PT09PT09PT09PnwNCiAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgIHwgRjEgIHJlLUlOVklURSAoU0RQKSB8DQogICAgICAgfC0t LS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICB8IEYyIDF4eC1yZWwgKFNEUCkgICAgfA0KICAg ICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgfCBGMyAgIFVQREFURSAgICAgICAg IHwNCiAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tfCBUYXJnZXQgcmVmcmVzaGluZw0KICAg ICAgIHwgRjQgMnh4IFVQVCAgICAgICAgICB8DQogICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0t PnwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwgRjUvNiBDYW5jZWwv MjAwT0sgICB8DQogICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICB8IEY3ICAg IDQ4NyBJTlYgICAgICAgfA0KICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAg fCBGNyAgICAgQUNLICAgICAgICAgIHwNCiAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0K ICAgICAgIHwgRjggIHJlLUlOVklURSAoU0RQKSB8DQogICAgICAgfC0tLS0tLS0tLS0tLS0tLS0t LS0tPnwgVXNpbmcgd2hpY2ggZGlhbG9nIHN0YXRlDQoNCkYzL0Y0IGlzIGFib3V0IHRhcmdldCBy ZWZyZXNoaW5nLg0KDQpBbmQgaWYgVUFDIHNlbmRzIENhbmNlbKOsIFVBUyBzZW5kcyA0ODcuIFRo ZSBmaXJzdCBSZS1JTlZJVEUgaXMgZGlzY2FyZGVkLg0KDQpCdXQgaWYgVUFDIHNlbmRzIGFub3Ro ZXIgUmUtSU5WSVRFLCB3aGljaCBkaWFsb2cgc3RhdGUgc2hvdWxkIGl0IHVzZT8NCg0KSSB0aGlu ayBpcyB0aGUgb25lIHJlZnJlc2hlZCBieSBGMy4gVGhhdCdzIHRoZSBtZXJpdCBvZiByZWdhcmRp bmcgDQpVUERBVEUvMjAwT0sncyBhdG9taWNpdHkuDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0014C4A448257577_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IFVBQyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgVUFTPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IHNlc3Npb24NCmVzdGFibGlzaGVkIHw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wmbHQ7PT09PT09PT09PT09PT09PT09PSZndDt8PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBGMSAmbmJzcDtyZS1JTlZJVEUNCihTRFApIHw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3wtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IEYy IDF4eC1yZWwNCihTRFApICZuYnNwOyAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jmx0Oy0tLS0tLS0t LS0tLS0tLS0tLS0tfDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBGMyAmbmJzcDsNClVQREFURSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0t LXwNClRhcmdldCByZWZyZXNoaW5nPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IEY0IDJ4eA0KVVBUICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0tLS0tLS0t LS0tLS0mZ3Q7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wg RjUvNiBDYW5jZWwvMjAwT0sNCiZuYnNwOyB8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0tLS0tLS0t LS0tLS0mZ3Q7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBGNyAmbmJzcDsNCiZuYnNwOzQ4NyBJTlYgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLXw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3wgRjcgJm5ic3A7DQombmJzcDsgQUNLICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fCBGOCAmbmJzcDtyZS1JTlZJVEUNCihTRFApIHw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wt LS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8DQpVc2luZyB3aGljaCBkaWFsb2cgc3RhdGU8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkYzL0Y0IGlzIGFib3V0 IHRhcmdldCByZWZyZXNoaW5nLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+QW5kIGlmIFVBQyBzZW5kcyBDYW5jZWyjrCBVQVMgc2VuZHMNCjQ4Ny4gVGhl IGZpcnN0IFJlLUlOVklURSBpcyBkaXNjYXJkZWQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CdXQgaWYgVUFDIHNlbmRzIGFub3RoZXIgUmUtSU5WSVRF LA0Kd2hpY2ggZGlhbG9nIHN0YXRlIHNob3VsZCBpdCB1c2U/PC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5rIGlzIHRoZSBvbmUgcmVmcmVzaGVk IGJ5IEYzLg0KVGhhdCdzIHRoZSBtZXJpdCBvZiByZWdhcmRpbmcgVVBEQVRFLzIwME9LJ3MgYXRv bWljaXR5LjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3By ZT4= --=_alternative 0014C4A448257577_=-- From christer.holmberg@ericsson.com Thu Mar 12 00:30:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E633A69FD; Thu, 12 Mar 2009 00:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.731 X-Spam-Level: X-Spam-Status: No, score=-5.731 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBwgpZ4OxqAB; Thu, 12 Mar 2009 00:30:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 914A53A6853; Thu, 12 Mar 2009 00:30:54 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 494A521613; Thu, 12 Mar 2009 08:31:30 +0100 (CET) X-AuditID: c1b4fb3e-ad89dbb0000023da-33-49b8ba5288b8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0A83220367; Thu, 12 Mar 2009 08:31:30 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 08:31:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A2E4.8BEE6710" Date: Thu, 12 Mar 2009 08:31:24 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: One chart //"UPDATE during Re-INVITE" discussion Thread-Index: AcmixTPH1ywTipzDRuy5Y61VXkxapwAHxArQ References: From: "Christer Holmberg" To: , "SIP" , "SIPPING" X-OriginalArrivalTime: 12 Mar 2009 07:31:29.0772 (UTC) FILETIME=[8F54EAC0:01C9A2E4] X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: Re: [Sip] One chart //"UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 07:30:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A2E4.8BEE6710 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit In my opinion 487 should trigger whatever actions/rollback that any other non-200 response sent by the UAS would. Regards, Christer ________________________________ From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn] Sent: 12. maaliskuuta 2009 5:47 To: SIP; SIPPING Cc: Christer Holmberg; Gonzalo Camarillo Subject: One chart //"UPDATE during Re-INVITE" discussion UAC UAS | session established | |<===================>| | | | F1 re-INVITE (SDP) | |-------------------->| | F2 1xx-rel (SDP) | |<--------------------| | F3 UPDATE | |<--------------------| Target refreshing | F4 2xx UPT | |-------------------->| | | | F5/6 Cancel/200OK | |-------------------->| | F7 487 INV | |<--------------------| | F7 ACK | |-------------------->| | F8 re-INVITE (SDP) | |-------------------->| Using which dialog state F3/F4 is about target refreshing. And if UAC sends Cancel$B!$(J UAS sends 487. The first Re-INVITE is discarded. But if UAC sends another Re-INVITE, which dialog state should it use? I think is the one refreshed by F3. That's the merit of regarding UPDATE/200OK's atomicity. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01C9A2E4.8BEE6710 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit
In my opinion 487 should trigger whatever actions/rollback that any other non-200 response sent by the UAS would.
 
Regards,
 
Christer

From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: 12. maaliskuuta 2009 5:47
To: SIP; SIPPING
Cc: Christer Holmberg; Gonzalo Camarillo
Subject: One chart //"UPDATE during Re-INVITE" discussion


      UAC                   UAS
       | session established |
       |<===================>|
       |                     |
       | F1  re-INVITE (SDP) |
       |-------------------->|
       | F2 1xx-rel (SDP)    |
       |<--------------------|
       | F3   UPDATE         |
       |<--------------------| Target refreshing
       | F4 2xx UPT          |
       |-------------------->|
       |                     |
       | F5/6 Cancel/200OK   |
       |-------------------->|
       | F7    487 INV       |
       |<--------------------|
       | F7     ACK          |
       |-------------------->|
       | F8  re-INVITE (SDP) |
       |-------------------->| Using which dialog state

F3/F4 is about target refreshing.

And if UAC sends Cancel$B!$(B UAS sends 487. The first Re-INVITE is discarded.

But if UAC sends another Re-INVITE, which dialog state should it use?

I think is the one refreshed by F3. That's the merit of regarding UPDATE/200OK's atomicity. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01C9A2E4.8BEE6710-- From gao.yang2@zte.com.cn Thu Mar 12 00:41:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B723A6A88; Thu, 12 Mar 2009 00:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.979 X-Spam-Level: X-Spam-Status: No, score=-89.979 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_SPAM=3.798, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JandjSDgAZvp; Thu, 12 Mar 2009 00:41:08 -0700 (PDT) Received: from mail.zte.com.cn (mx1.zte.no [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 603CC3A6A30; Thu, 12 Mar 2009 00:41:05 -0700 (PDT) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.4453668360; Thu, 12 Mar 2009 16:04:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2C7fEZM036860; Thu, 12 Mar 2009 15:41:14 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: From: gao.yang2@zte.com.cn To: "Christer Holmberg" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: Sender: gao.yang2@zte.com.cn Date: Thu, 12 Mar 2009 15:40:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-12 15:41:03, Serialize complete at 2009-03-12 15:41:03 Content-Type: multipart/alternative; boundary="=_alternative 002A352548257577_=" X-MAIL: mse1.zte.com.cn n2C7fEZM036860 Cc: SIP , SIPPING , Gonzalo Camarillo Subject: [Sip] =?gb2312?b?tPC4tDogUkU6IE9uZSBjaGFydCAgLy8iVVBEQVRFIGR1cmlu?= =?gb2312?b?ZyBSZS1JTlZJVEUiIGRpc2N1c3Npb24=?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 07:41:09 -0000 This is a multipart message in MIME format. --=_alternative 002A352548257577_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkganVzdCBtZWFuIHRoYXQgaWYgd2UgdHJlYXQgRjMgYXMgc3ViLXRyYW5zYWN0aW9u IG9mIEYxLCB0aGVuIGFmdGVyIA0KRjcoQUNLKSwgVUFDIGNhbiBkaXNjYXJkIHJlZnJlc2hlZCBk aWFsb2cgc3RhdGUgaW4gRjMuDQoNCkFuZCBpdCBtYXkgbWFrZSB0aGUgdHdvIHBhcnRzIGNhbiBu b3QgY29tbXVuaWNhdGUgYW55bW9yZSBpbiBjdXJyZW50IA0KZGlhbG9nLg0KDQpBbmQgSU1PLCB0 aGlzIGlzIGEgY291bnRlcmV2aWRlbmNlIGZvciB0cmVhdGluZyBhbGwgVVBEQVRFKGR1cmluZyAN ClJlLUlOVklURSkgYXMgc3ViLXRyYW5zYWN0aW9uIG9mIFJlLUlOVklURS4NCg0KR2FvDQoNCg0K DQoNCg0KIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PiANCjIwMDktMDMtMTIgMTU6MzENCg0KytW8/sjLDQo8Z2FvLnlhbmcyQHp0ZS5jb20uY24+LCAi U0lQIiA8c2lwQGlldGYub3JnPiwgIlNJUFBJTkciIDxzaXBwaW5nQGlldGYub3JnPg0Ks63LzQ0K IkdvbnphbG8gQ2FtYXJpbGxvIiA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPg0K1vfM 4g0KUkU6IE9uZSBjaGFydCAgLy8iVVBEQVRFIGR1cmluZyBSZS1JTlZJVEUiIGRpc2N1c3Npb24N Cg0KDQoNCg0KDQoNCkluIG15IG9waW5pb24gNDg3IHNob3VsZCB0cmlnZ2VyIHdoYXRldmVyIGFj dGlvbnMvcm9sbGJhY2sgdGhhdCBhbnkgb3RoZXIgDQpub24tMjAwIHJlc3BvbnNlIHNlbnQgYnkg dGhlIFVBUyB3b3VsZC4NCiANClJlZ2FyZHMsDQogDQpDaHJpc3Rlcg0KDQpGcm9tOiBnYW8ueWFu ZzJAenRlLmNvbS5jbiBbbWFpbHRvOmdhby55YW5nMkB6dGUuY29tLmNuXSANClNlbnQ6IDEyLiBt YWFsaXNrdXV0YSAyMDA5IDU6NDcNClRvOiBTSVA7IFNJUFBJTkcNCkNjOiBDaHJpc3RlciBIb2xt YmVyZzsgR29uemFsbyBDYW1hcmlsbG8NClN1YmplY3Q6IE9uZSBjaGFydCAvLyJVUERBVEUgZHVy aW5nIFJlLUlOVklURSIgZGlzY3Vzc2lvbg0KDQoNCiAgICAgIFVBQyAgICAgICAgICAgICAgICAg ICBVQVMgDQogICAgICAgfCBzZXNzaW9uIGVzdGFibGlzaGVkIHwgDQogICAgICAgfDw9PT09PT09 PT09PT09PT09PT09PnwgDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAg fCBGMSAgcmUtSU5WSVRFIChTRFApIHwgDQogICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwg DQogICAgICAgfCBGMiAxeHgtcmVsIChTRFApICAgIHwgDQogICAgICAgfDwtLS0tLS0tLS0tLS0t LS0tLS0tLXwgDQogICAgICAgfCBGMyAgIFVQREFURSAgICAgICAgIHwgDQogICAgICAgfDwtLS0t LS0tLS0tLS0tLS0tLS0tLXwgVGFyZ2V0IHJlZnJlc2hpbmcgDQogICAgICAgfCBGNCAyeHggVVBU ICAgICAgICAgIHwgDQogICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgDQogICAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgfCBGNS82IENhbmNlbC8yMDBPSyAgIHwgDQog ICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgDQogICAgICAgfCBGNyAgICA0ODcgSU5WICAg ICAgIHwgDQogICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLXwgDQogICAgICAgfCBGNyAgICAg QUNLICAgICAgICAgIHwgDQogICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgDQogICAgICAg fCBGOCAgcmUtSU5WSVRFIChTRFApIHwgDQogICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwg VXNpbmcgd2hpY2ggZGlhbG9nIHN0YXRlIA0KDQpGMy9GNCBpcyBhYm91dCB0YXJnZXQgcmVmcmVz aGluZy4gDQoNCkFuZCBpZiBVQUMgc2VuZHMgQ2FuY2Vso6wgVUFTIHNlbmRzIDQ4Ny4gVGhlIGZp cnN0IFJlLUlOVklURSBpcyBkaXNjYXJkZWQuIA0KDQoNCkJ1dCBpZiBVQUMgc2VuZHMgYW5vdGhl ciBSZS1JTlZJVEUsIHdoaWNoIGRpYWxvZyBzdGF0ZSBzaG91bGQgaXQgdXNlPyANCg0KSSB0aGlu ayBpcyB0aGUgb25lIHJlZnJlc2hlZCBieSBGMy4gVGhhdCdzIHRoZSBtZXJpdCBvZiByZWdhcmRp bmcgDQpVUERBVEUvMjAwT0sncyBhdG9taWNpdHkuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQpz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMu DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQoN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg== --=_alternative 002A352548257577_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBqdXN0IG1lYW4gdGhhdCBpZiB3ZSB0 cmVhdCBGMyBhcyBzdWItdHJhbnNhY3Rpb24NCm9mIEYxLCB0aGVuIGFmdGVyIEY3KEFDSyksIFVB QyBjYW4gZGlzY2FyZCByZWZyZXNoZWQgZGlhbG9nIHN0YXRlIGluIEYzLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIGl0IG1heSBtYWtlIHRoZSB0 d28gcGFydHMgY2FuIG5vdA0KY29tbXVuaWNhdGUgYW55bW9yZSBpbiBjdXJyZW50IGRpYWxvZy48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZCBJTU8s IHRoaXMgaXMgYSBjb3VudGVyZXZpZGVuY2UgZm9yDQp0cmVhdGluZyBhbGwgVVBEQVRFKGR1cmlu ZyBSZS1JTlZJVEUpIGFzIHN1Yi10cmFuc2FjdGlvbiBvZiBSZS1JTlZJVEUuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7 Q2hyaXN0ZXIgSG9sbWJlcmcmcXVvdDsNCiZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAw OS0wMy0xMiAxNTozMTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mbHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7LCAmcXVvdDtTSVAmcXVv dDsNCiZsdDtzaXBAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtTSVBQSU5HJnF1b3Q7ICZsdDtzaXBwaW5n QGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7R29uemFsbyBDYW1hcmlsbG8m cXVvdDsgJmx0O2dvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbSZndDs8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJFOiBPbmUgY2hhcnQgJm5ic3A7Ly8mcXVvdDtVUERBVEUgZHVyaW5nDQpSZS1JTlZJ VEUmcXVvdDsgZGlzY3Vzc2lvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5JbiBteSBvcGluaW9uIDQ4 NyBzaG91bGQgdHJpZ2dlcg0Kd2hhdGV2ZXIgYWN0aW9ucy9yb2xsYmFjayB0aGF0IGFueSBvdGhl ciBub24tMjAwIHJlc3BvbnNlIHNlbnQgYnkgdGhlIFVBUw0Kd291bGQuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPlJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0iQXJpYWwiPkNocmlzdGVyPC9mb250Pg0KPGJyPg0KPGJyPg0KPGhyPjxm b250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBnYW8ueWFuZzJAenRlLmNvbS5j biBbbWFpbHRvOmdhby55YW5nMkB6dGUuY29tLmNuXQ0KPGI+PGJyPg0KU2VudDo8L2I+IDEyLiBt YWFsaXNrdXV0YSAyMDA5IDU6NDc8Yj48YnI+DQpUbzo8L2I+IFNJUDsgU0lQUElORzxiPjxicj4N CkNjOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmc7IEdvbnphbG8gQ2FtYXJpbGxvPGI+PGJyPg0KU3Vi amVjdDo8L2I+IE9uZSBjaGFydCAvLyZxdW90O1VQREFURSBkdXJpbmcgUmUtSU5WSVRFJnF1b3Q7 IGRpc2N1c3Npb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7VUFDICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyBVQVM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8IHNlc3Npb24gZXN0YWJsaXNoZWQgfDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jmx0Oz09PT09PT09PT09PT09PT09PT0m Z3Q7fDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgfDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7IHwgRjEgJm5ic3A7cmUtSU5WSVRFIChTRFApIHw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBGMiAxeHgtcmVsIChT RFApICZuYnNwOyAmbmJzcDt8PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS18PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgRjMgJm5ic3A7IFVQREFURSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfCBUYXJnZXQgcmVmcmVzaGluZzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IEY0IDJ4eCBV UFQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IHw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 IEY1LzYgQ2FuY2VsLzIwME9LICZuYnNwOyB8PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgRjcgJm5ic3A7ICZuYnNwOzQ4 NyBJTlYgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tfDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IEY3ICZuYnNwOyAmbmJzcDsg QUNLICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7fDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgRjggJm5i c3A7cmUtSU5WSVRFIChTRFApIHw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgfC0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgVXNpbmcgd2hpY2ggZGlhbG9n IHN0YXRlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KRjMvRjQgaXMgYWJvdXQgdGFy Z2V0IHJlZnJlc2hpbmcuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQW5kIGlmIFVB QyBzZW5kcyBDYW5jZWyjrCBVQVMgc2VuZHMgNDg3LiBUaGUgZmlyc3QgUmUtSU5WSVRFIGlzIGRp c2NhcmRlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpCdXQgaWYgVUFDIHNlbmRz IGFub3RoZXIgUmUtSU5WSVRFLCB3aGljaCBkaWFsb2cgc3RhdGUgc2hvdWxkIGl0IHVzZT88L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJIHRoaW5rIGlzIHRoZSBvbmUgcmVmcmVzaGVk IGJ5IEYzLiBUaGF0J3MgdGhlIG1lcml0IG9mIHJlZ2FyZGluZyBVUERBVEUvMjAwT0sncw0KYXRv bWljaXR5LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+PHR0Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxicj4NCjwvdHQ+ PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1 cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5l ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3By b3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4m bmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZp ZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZu YnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5k Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZu YnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55 Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZu YnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7 Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5i c3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5i c3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25v dGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3Nh Z2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu ZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2Jl ZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0m bmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002A352548257577_=-- From ietf.hanserik@gmail.com Thu Mar 12 01:34:01 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1593A6B08 for ; Thu, 12 Mar 2009 01:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.072 X-Spam-Level: X-Spam-Status: No, score=0.072 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_DELIVY=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvrWTV56tucJ for ; Thu, 12 Mar 2009 01:33:59 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 2579B3A68F7 for ; Thu, 12 Mar 2009 01:33:57 -0700 (PDT) Received: by ewy25 with SMTP id 25so269535ewy.37 for ; Thu, 12 Mar 2009 01:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pwq5nnIZopjORUz+H5Quk7KuuF7fglqhazEF/d/Dlwg=; b=t7mYBC5rBbO667o5ZXrUtoGpIFv+ftj1CC59A8iJJfZs2ghkMfPzJZukI1rIjsln+c ErmS47q0hE4+H55T5pFgAZcFqnlLgqDKRO/kjdy6qSnz6iyLLBsYxBm05EHQxJCxnKij eaQt1VNWa4HTVfuy4RUcV624n1DW1xMXI+3Qg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Bx9ZisKGcBFLZZJwUYW1nX1yihGM8qvJYFdPFxhE90vl2/k8OLmrn+iMxd1gfBtKv0 GeX8GSC10C119x60sheE8gSOyLzOwCn8xDGZEFmcxQghKtceLB1YyiTBrSEaOFIEWpDS WzknYsHqO4Q+MeKunJy9U4IxEkKWfTPUj772E= MIME-Version: 1.0 Received: by 10.210.127.13 with SMTP id z13mr5139971ebc.93.1236846874519; Thu, 12 Mar 2009 01:34:34 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> Date: Thu, 12 Mar 2009 09:34:34 +0100 Message-ID: <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> From: Hans Erik van Elburg To: Mary Barnes Content-Type: multipart/alternative; boundary=0015174c10a098e9240464e7daf9 Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 08:34:01 -0000 --0015174c10a098e9240464e7daf9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, because you are using the 3261 use of target and the 4244bis introduced definition of retarget. I thought it was clear that we need other words as those definitions don't match the target-uri drafts use of the terms. Also they do not suffice to provide a solution for the use cases in the target-uri draft. The 3261 text you refer to is exactly about the case where the home proxy overwrites the Request-URI with a new target. This target is teh registered contact address. And hence this would be what target-uri calls a hop or a route. This case and this is where it gets confusing is not a "retarget" in the target-uri draft use of the term. The target-uri draft states: "To avoid confusion, we refer to a SIP URI that is an address for a user or resource as a "target" and a SIP URI that is a hop for reaching that user as a "hop". Apparently that does not suffice to avoid confusion. As for the tagging, speaking about the solution before agreeing on the terminology and the problem it should solve is meaningless. /Hans Erik van Elburg On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes wrote: > Responses below [MB]. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 6:42 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > I was talking about the concept. > > The use cases only describe cases where the target-uri (lets call that > current target from now) has been lost when an initial request for a > dialog or standalone request arrives at the UAS. > [MB] And I think this is where the terminology confusion starts - I > don't think of the "lost" target-uri as being the "current" target. In > my mind, the "current" target is reflected by the last hi-entry and the > request-uri in the incoming request at the UAS. If the entity that sent > the request was the entity that added the last hi-entry, then the uri in > that hi-entry is the same as the request-URI in the SIP request that > arrives at the UAS. I refer to the "lost" uri as the one that was > "retargeted" - that's the one the UAS wants to pull from the hi-entries > in the incoming request. That hi-entry was not the one that was just > added by the entity that built the request just received by the UAS. > That hi-entry is tagged with whatever name we are going to tag it with > BEFORE the request is forwarded (using the term forward per section 16.6 > of RFC 3261). That tag is added once the target set of potential > candidates for the new request uri are determined in section 16.5 of > 3261 (with "target set" being a 3261 term), just before the request is > forwarded in section 16.6 to one of those targets. A new hi-entry > (which will be the last hi-entry in the request received by the UAS) is > added in section 16.6 of 3261 as the request is forwarded. At this > point in time, the lost information is in the previous hi-entry when the > outgoing request is sent. [/MB] > > What has been lost is the current target of the request: > [MB] Right - at which point in my mind, it's no longer the current > target ;) Maybe we call it "lost". [/MB] > > > Current target > > The current target of an initial request for a dialog or standalone > request is the name or address to which the request is targeted, i.e. > either the initial target inserted in the Request-URI by the UAC that > originates the request, or when a retarget occurred, the target > provided in that retarget operation. Reroute and translation > operations never change the current target. > > [MB] I don't think this definition fits what you want - i.e., if there > is no retargeting, then none of the hi-entries are tagged - i.e., you > won't have your concept of current. The way it works is that if no > hi-entries are tagged, then you know that there was no retargeting, thus > you know the request-uri has not been lost. [/MB] > > This defintion only makes sense when the following definitions are used: > > Name: > > A name is a moniker for an entity which refers to it in a way which > > reveals nothing about where it is in a network. In SIP, tel URI > > which doesn't represent the location of the entity is a name. > > > Address: > > An address is an identifier for an entity which describes it by its > > location on the network. In SIP, the SIP URI itself is a form of > > address because the host part of the URI, the only mandatory part of > > the URI besides the scheme itself, indicates the location of a SIP > > server that can be used to handle the request. > > Route: > > Finally, a route is a sequence of SIP entities (including the UA > itself!) which are > > traversed in order to forward a request to an address or name. > > Retarget (other term might be needed, as this is highly confusing): > > A Request-URI rewrite operation that changes the target identity of > the request. > > Reroute (other term might be needed): > > A Request-URI rewrite operation that does not change the current > target of the request, but determines the route/next hop taken to > reach the target-identity. > > /Hans Erik > > Mary Barnes wrote: > > So, by "target-uri concept" are you referring to the solution in the > > current target-uri draft or the application usage as such in the > > target-uri document (which is what I was referring to)? > > > > Yes, the problem is that SIP doesn't differentiate the various > > mechanisms by which a request-URI may be changed, which is what some > > of the updated text in 4244bis is trying to do and why we need precise > > > terms. I think we all agree that. > > > > I honestly don't care what we call the tag, as long as we're clear > > about the functionality. > > > > Mary. > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: Wednesday, March 11, 2009 4:40 PM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Shida Schubert; sip@ietf.org > > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > The target-uri concept when defined properly is entirely application > > agnostic. > > > > When one uses History-Info or another header as a vehicle for this > > information then it still can be considered application agnostic as > > any application can use this information as it likes. > > > > From SIP perspective all the Request-URI rewrites look the same, that > > > is what brought us discussing this in the first place. > > > > /Hans Erik > > > > Mary Barnes wrote: > > > >> And, I think the big issue with the terminology is that 4244bis is > >> application agnostic, so it is tagging what happens to the URIs > >> (why/how the specific URI was overwritten). Whereas, specific > >> applications can derive information, such as what "is" the real > >> "target" for the request, from the History-Info header. So, IMHO, > >> it's a matter of the target-uri document specifying that the last > >> entry tagged by whatever name we come up with "is" the real "target" > >> for the request. I believe it's up to the applications to describe > >> how they make use of the History-Info and not for the History-Info to > > >> describe how applications can use it. History-Info purely reflects > >> what happened from a SIP Protocol perspective and should not imply > >> any > >> > > > > > >> application semantics. Indeed the intent of section 5 of 4244 was to > >> inform the applications how they should decribe their usage of the > >> header. > >> > >> Mary. > >> Note: I changed the subject to hopefully make this topic easier to > >> keep track of. > >> > >> --------------------------------------------------------------------- > >> - > >> -- > >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > >> *Sent:* Wednesday, March 11, 2009 3:59 AM > >> *To:* Shida Schubert > >> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) > >> *Subject:* Re: [Sip] Fwd: I-D > >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > >> > >> One of the problems that made the discussion quite tedious is the > >> complete inversed meaning of the terms "retarget" and "reroute" > >> between 4244bis and target-uri factions have. > >> > >> Conclusion was that the terminology need to be properly defined and > >> some attempt was made to start such activity. > >> > >> On 3. I have strong concerns when we start tagging the URI as to how > >> they come about "retarget"/"mapped conficuration" etc. It is better > >> to > >> > > > > > >> embellish them with a tag that just represents there meaning for > >> example "istarget" or "hop". For the following reasons: > >> 1. It is much more intuitive for the user of this information, its > >> meaning can basically be guessed. > >> 2. Such meaning also probably survives application in other problem > >> spaces that we had not foreseen when introducing the concept. > >> > >> The solution that is described now in the target-URI delivery draft > >> is not yet complete, it does not solve the freephone use case for > >> example and in its current form it will deliver exactly the same > >> target-URI as that which would be delivered by the P-Called-Party-ID > > >> header. Contrary to what the draft says. So some work is needed > still. > >> > >> /Hans Erik van Elburg > >> > >> > >> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert >> > wrote: > >> > >> > >> We have submitted the updated target-uri draft based on the > >> > > comments > > > >> submitted to the list and comments received at IETF73. > >> > >> I have taken over as editor as Jonathan didn't have the cycles to > > >> update the draft, with Francois, Christer and Hans Erick as > >> additional > >> co-authors and great deal of help from Mary. > >> > >> The following summarizes the changes made to the target-uri > >> > > document > > > >> 1. Added use-case for toll-free number back > >> 2. Added definition of "retarget" operation. > >> 3. Removed a reference to URN > >> 4. Added a text discussing the difference to P-Called-Party-Id > >> 5. Changed parameter name from "target" to "istarget" > >> > >> Note, that the target-uri document still contains the normative > >> text for the > >> History-Info header. > >> > >> In addition, Mary (with Francois as co-author) has submitted a > >> rfc4244bis, with the following changes: > >> 1. Incorporated the normative aspects of the target-uri document > >> into the existing normative text in RFC 4244 - the functionality > >> > > is > > > >> virtually identical (as is some of the text) as the HI based > >> > > solution > > > >> described in the target-uri document. It's important that the > >> solution > >> be integrated into RFC 4244 as it MUST work and be based on the > >> normative > >> aspects of RFC 4244. > >> 2. Added the use cases from target-uri the the summary > >> in the overview of rfc4244bis. > >> 3. Added an additional requirement to capture the "target-uri" > >> information. > >> 4. Fixed an error in the RFC 4244 ABNF and added "retarget" > >> > > parameter. > > > >> 5. Added a more simplified example. > >> > >> > >> We had some very long offline exchanges as to the best way > >> forward > >> > > and > > > >> remaining work for both documents. > >> > >> Some of the issues identified are: > >> > >> ::Issues:: > >> 1. Should we remove the normative text from target-uri and > >> > > progress > > > >> 4244bis along with the target-uri document to meet the > >> chartered > >> SIP WG milestone? > >> > >> > >> 2. Name of the parameter. > >> At the last meeting, parameter "target" was said > >> > > inappropriate > > > >> because voicemail-uri spec already defines a parameter > >> > > called > > > >> "target" which also can be found in hi-entry, thus > >> > > potentially > > > >> causing confusion. > >> > >> Currently the target-uri draft uses "istarget" and 4244bis > >> > > uses > > > >> "retarget" but we could never come to > >> a consensus on what name is appropriate. Other suggestions > >> > > have > > > >> included the following: > >> "target-identity" (someone didn't like that "identity" is > >> also a SIP header) > >> "reg-uri" (can be paired with "mapped-uri" for item 3 > >> > > below) > > > >> "aor" > >> "jibberish" > >> etc. > >> > >> One reason this is so difficult relates to the problem > >> statement in target-uri in that > >> RFC 3261 doesn't differentiate the mechanism by which the > >> > > new > > > >> (target) Request-URI is selected. Another issue is that > >> some of the terminology in > >> RFC 3261 is overloaded - e.g., "forwarding" refers both to > a > >> Proxy > >> which does not have responsibility for the domain of the > >> request-URI > >> in the incoming request, thus the proxy just "forwards" the > >> request to > >> the next hop AND "forwarding" is used to describe the > >> process whereby > >> the outgoing request is built and "forwarded" to the next > >> hop at which > >> point the proxy does not know how the new request-uri was > >> selected. > >> RFC 4244 has attempted to clarify the terms and attempts to > >> use "forward" > >> in the context of the former situation and "retarget" for > >> the case whereby > >> a proxy is responsible for the domain and thus can use a > >> number of > >> mechanism to select the new target for the request - e.g., > a > >> REGISTRAR, > >> configured data, etc. > >> > >> 3. Related to the last point in item 2 above, it has been > >> proposed that > >> we differentiate the hi-entries even more by defining > >> separate parameters > >> for registered and configured/mapped contacts. > >> Currently when the R-URI is translated to a URI which is > >> either derived > >> from location service lookup(registered by UA) or from > >> > > mapping > > > >> table, there is no differentiation as to how the URI was > >> derived once it is > >> added to the list of potential targets. > >> > >> The general consensus of the authors of the two documents > was > >> that it may > >> be useful for some services to have the hi-entries tagged > >> with the > >> more specific information. > >> > >> And, of course, this gets us into another naming contest. In > >> the end, the naming > >> is not so important as long as the term isn't too overloaded > >> and it is defined > >> precisely in the document(s). > >> > >> We would appreciate WG feedback on these issues and any other > >> comments on > >> the two documents prior to IETF-74. > >> > >> Regards, > >> Shida and Mary. > >> > >> > >> > >> Begin forwarded message: > >> > >>> *From: *Internet-Drafts@ietf.org > >>> > > > > > >>> *Date: *March 10, 2009 2:30:01 AM JST > >>> *To: *i-d-announce@ietf.org > >>> *Subject: **I-D > >>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * > >>> *Reply-To: *internet-drafts@ietf.org > >>> > >>> > >>> A New Internet-Draft is available from the on-line > >>> > > Internet-Drafts > > > >>> directories. > >>> > >>> > >>> Title > >>> : Delivery of Request-URI Targets to User Agents > >>> Author(s) > >>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. > Schubert > >>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt > >>> Pages > >>> : 16 > >>> Date > >>> : 2009-3-9 > >>> > >>> When a Session Initiation Protocol (SIP) proxy receives a > request > >>> targeted at a URI identifying a user or resource it is > >>> > > responsible > > > >>> for, the proxy translates the URI to a registered or > configured > >>> contact URI of an agent representing that user or resource. > >>> In > >>> > > the > > > >>> process, the original URI is removed from the request. > >>> Numerous use > >>> cases have arisen which require this information to be > >>> > > delivered to > > > >>> the user agent. This document describes these use cases and > >>> defines > >>> an extension to the History-Info header field which allows it > >>> > > to be > > > >>> used to support those cases. > >>> > >>> A URL for this Internet-Draft is: > >>> > >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d > >>> e > >>> livery-01.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of > the > >>> Internet-Draft. > >>> > >> Content-Type: text/plain
Content-ID: > >> <2009-3-9102756.I-D@ietf.org > >> >

> >> > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu > >> for questions on > >> current > >> > > sip > > > >> Use sipping@ietf.org for new > >> developments on the application of sip > >> > >> > >> > --0015174c10a098e9240464e7daf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, because you are using the 3261 use of target and the 4244bis introduce= d definition of retarget. I thought it was clear that we need other words a= s those definitions don't match the target-uri drafts use of the terms.= Also they do not suffice to provide a solution for the use cases in the ta= rget-uri draft.

The 3261 text you refer to is exactly about the case where the home pro= xy overwrites the Request-URI with a new target. This target is teh registe= red contact address. And hence this would be what target-uri calls a hop or= a route. This case and this is where it gets confusing is not a "reta= rget" in the target-uri draft use of the term.

The target-uri draft states:
   "To avoi=
d confusion, we
   refer to a SIP URI that is an address for a user or r=
esource as a
   "target" and a SIP URI that is a hop for reach=
ing that user as a

   "hop".

Apparently that does not suffice to avoid = confusion.

As for the tagging, speaking about the solution before ag= reeing on the terminology and the problem it should solve is meaningless.
/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 2:33 AM, Mary Ba= rnes <mary.b= arnes@nortel.com> wrote:
Responses below [MB].

-----Original Message-----
From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, March 11, 2009 6:42 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Shida Schubert; sip@ietf.org
Subject: Re: Terminology (was RE: [Sip] Fwd: I-D
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

I was talking about the concept.

The use cases only describe =A0cases where the target-uri (lets call that current target from now) has been lost when an initial request for a
dialog or standalone request arrives at the UAS.
[MB] And I think this is where the terminology confusion starts - I don't think of the "lost" target-uri as being the "curre= nt" target. In
my mind, the "current" target is reflected by the last hi-entry a= nd the
request-uri in the incoming request at the UAS. If the entity that sent
the request was the entity that added the last hi-entry, then the uri in that hi-entry is the same as the request-URI in the SIP request that
arrives at the UAS. I refer to the "lost" uri as the one that was=
"retargeted" - that's the one the UAS wants to pull from the = hi-entries
in the incoming request. That hi-entry was not the one that was just
added by the entity that built the request just received by the UAS.
That hi-entry is tagged with whatever name we are going to tag it with
BEFORE the request is forwarded (using the term forward per section 16.6 of RFC 3261). =A0That tag is added once the target set of potential
candidates for the new request uri are determined in section 16.5 of
3261 (with "target set" being a 3261 term), just before the reque= st is
forwarded in section 16.6 to one of those targets. =A0A new hi-entry
(which will be the last hi-entry in the request received by the UAS) is
added in section 16.6 of 3261 as the request is forwarded. =A0At this
point in time, the lost information is in the previous hi-entry when the outgoing request is sent. [/MB]

What has been lost is the current target of the request:
[MB] Right - at which point in my mind, it's no longer the curren= t
target ;) Maybe we call it "lost". [/MB]


=A0 =A0 =A0Current target

=A0 The current target of an initial request for a dialog or standalone =A0 request is the name or address to which the request is targeted, i.e.<= br> =A0 either the initial target inserted in the Request-URI by the UAC that<= br> =A0 originates the request, or when a retarget occurred, the target
=A0 provided in that retarget operation. =A0Reroute and translation
=A0 operations never change the current target.

[MB] I don't think this definition fits what you want - i.e., if = there
is no retargeting, then none of the hi-entries are tagged - i.e., you
won't have your concept of current. The way it works is that if no
hi-entries are tagged, then you know that there was no retargeting, thus you know the request-uri has not been lost. [/MB]

This defintion only makes sense when the following definitions are used:
Name:

=A0 A name is a moniker for an entity which refers to it in a way which
=A0 reveals nothing about where it is in a network. =A0In SIP, tel URI

=A0 which doesn't represent the location of the entity is a name.


Address:

=A0 An address is an identifier for an entity which describes it by its
=A0 location on the network. =A0In SIP, the SIP URI itself is a form of
=A0 address because the host part of the URI, the only mandatory part of
=A0 the URI besides the scheme itself, indicates the location of a SIP

=A0 server that can be used to handle the request.

Route:

=A0 Finally, a route is a =A0 sequence of SIP entities (including the UA itself!) which are

=A0traversed in order to forward a request to an address or name.

Retarget (other term might be needed, as this is highly confusing):

=A0 =A0A Request-URI rewrite operation that changes the target identity of=
the request.

Reroute (other term might be needed):

=A0 =A0A Request-URI rewrite operation that does not change the current target of the request, but =A0 =A0 determines the route/next hop taken to reach the target-identity.

/Hans Erik

Mary Barnes wrote:
> So, by "target-uri concept" are you referring to the solutio= n in the
> current target-uri draft or the application usage as such in the
> target-uri document (which is what I was referring to)?
>
> Yes, the problem is that SIP doesn't differentiate the various
> mechanisms by which a request-URI may be changed, which is what some > of the updated text in 4244bis is trying to do and why we need precise=

> terms. I think we all agree that.
>
> I honestly don't care what we call the tag, as long as we're c= lear
> about the functionality.
>
> Mary.
>
> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: Wednesday, March 11, 2009 4:40 PM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D
> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
> The target-uri concept when defined properly is entirely application > agnostic.
>
> When one uses History-Info or another header as a vehicle for this
> information then it still can be considered application agnostic as > any application can use this information as it likes.
>
> =A0From SIP perspective all the Request-URI rewrites look the same, th= at

> is what brought us discussing this in the first place.
>
> /Hans Erik
>
> Mary Barnes wrote:
>
>> And, I think the big issue with the terminology is that 4244bis is=
>> application agnostic, so it is tagging what happens to the URIs >> (why/how the specific URI was overwritten). =A0Whereas, specific >> applications can derive information, such as what "is" t= he real
>> "target" for the request, from the History-Info header. = =A0 So, IMHO,
>> it's a matter of the target-uri document specifying that the l= ast
>> entry tagged by whatever name we come up with "is" the r= eal "target"
>> for the request. =A0I believe it's up to the applications to d= escribe
>> how they make use of the History-Info and not for the History-Info= to

>> describe how applications can use it. =A0History-Info purely refle= cts
>> what happened from a SIP Protocol perspective and should not imply=
>> any
>>
>
>
>> application semantics. Indeed the intent of section 5 of 4244 was = to
>> inform the applications how they should decribe their usage of the=
>> header.
>>
>> Mary.
>> Note: I changed the subject to hopefully make this topic easier to=
>> keep track of.
>>
>> ------------------------------------------------------------------= ---
>> -
>> --
>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
>> *Sent:* Wednesday, March 11, 2009 3:59 AM
>> *To:* Shida Schubert
>> *Cc:* sip@ietf.org List; Barne= s, Mary (RICH2:AR00)
>> *Subject:* Re: [Sip] Fwd: I-D
>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>>
>> One of the problems that made the discussion quite tedious is the<= br> >> complete inversed meaning of the terms "retarget" and &q= uot;reroute"
>> between 4244bis and target-uri factions have.
>>
>> Conclusion was that the terminology need to be properly defined an= d
>> some attempt was made to start such activity.
>>
>> On 3. I have strong concerns when we start tagging the URI as to h= ow
>> they come about "retarget"/"mapped conficuration&qu= ot; etc. It is better
>> to
>>
>
>
>> embellish them with a tag that just represents there meaning for >> example "istarget" or "hop". For the following= reasons:
>> 1. It is much more intuitive for the user of this information, its=
>> meaning can basically be guessed.
>> 2. Such meaning also probably survives application in other proble= m
>> spaces that we had not foreseen when introducing the concept.
>>
>> The solution that is =A0described now in the target-URI delivery d= raft
>> is not yet complete, it does not solve the freephone use case for<= br> >> example and in its current form it will deliver exactly the same >> target-URI as that which would be delivered by the =A0P-Called-Par= ty-ID

>> header. Contrary to what the draft says. So some work is needed still.
>>
>> /Hans Erik van Elburg
>>
>>
>> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert <shida@ntt-at.com
>> <mailto:shida@ntt-at.com>> wrote:
>>
>>
>> =A0 =A0 We have submitted the updated target-uri draft based on th= e
>>
> comments
>
>> =A0 =A0 submitted to the list and comments received at IETF73.
>>
>> =A0 =A0 I have taken over as editor as Jonathan didn't have th= e cycles to

>> =A0 =A0 update the draft, with Francois, Christer and Hans Erick a= s
>> =A0 =A0 additional
>> =A0 =A0 co-authors and great deal of help from Mary.
>>
>> =A0 =A0 The following summarizes the changes made to the target-ur= i
>>
> document
>
>> =A0 =A0 1. Added use-case for toll-free number back
>> =A0 =A0 2. Added definition of "retarget" operation.
>> =A0 =A0 3. Removed a reference to URN
>> =A0 =A0 4. Added a text discussing the difference to P-Called-Part= y-Id
>> =A0 =A0 5. Changed parameter name from "target" to "= ;istarget"
>>
>> =A0 =A0 Note, that the target-uri document still contains the norm= ative
>> =A0 =A0 text for the
>> =A0 =A0 History-Info header.
>>
>> =A0 =A0 In addition, Mary (with Francois as co-author) has submitt= ed a
>> =A0 =A0 rfc4244bis, with the following changes:
>> =A0 =A0 1. Incorporated the normative aspects of the target-uri do= cument
>> =A0 =A0 into the existing normative text in RFC 4244 - the functio= nality
>>
> is
>
>> =A0 =A0 virtually identical (as is some of the text) as the HI bas= ed
>>
> solution
>
>> =A0 =A0 described in the target-uri document. =A0It's importan= t that the
>> =A0 =A0 solution
>> =A0 =A0 be integrated into RFC 4244 as it MUST work and be based o= n the
>> =A0 =A0 normative
>> =A0 =A0 aspects of RFC 4244.
>> =A0 =A0 2. =A0Added the use cases from target-uri the the summary<= br> >> =A0 =A0 in the overview of rfc4244bis.
>> =A0 =A0 3. Added an additional requirement to capture the "ta= rget-uri"
>> =A0 =A0 information.
>> =A0 =A0 4. Fixed an error in the RFC 4244 ABNF and added "ret= arget"
>>
> parameter.
>
>> =A0 =A0 5. Added a more simplified example.
>>
>>
>> =A0 =A0 We had some very long offline exchanges as to the best way=
>> forward
>>
> and
>
>> =A0 =A0 remaining work for both documents.
>>
>> =A0 =A0 Some of the issues identified are:
>>
>> =A0 =A0 ::Issues::
>> =A0 =A0 =A0 =A01. Should we remove the normative text from target-= uri and
>>
> progress
>
>> =A0 =A0 =A0 =A0 =A0 =A04244bis along with the target-uri document = to meet the
>> =A0 =A0 chartered
>> =A0 =A0 =A0 =A0 =A0 SIP WG milestone?
>>
>>
>> =A0 =A0 =A0 =A02. Name of the parameter.
>> =A0 =A0 =A0 =A0 =A0 At the last meeting, parameter "target&qu= ot; was said
>>
> inappropriate
>
>> =A0 =A0 =A0 =A0 =A0 because voicemail-uri spec already defines a p= arameter
>>
> called
>
>> =A0 =A0 =A0 =A0 =A0 "target" which also can be found in = hi-entry, thus
>>
> potentially
>
>> =A0 =A0 =A0 =A0 =A0 causing confusion.
>>
>> =A0 =A0 =A0 =A0 =A0 Currently the target-uri draft uses "ista= rget" and 4244bis
>>
> uses
>
>> =A0 =A0 =A0 =A0 =A0 "retarget" =A0but we could never com= e to
>> =A0 =A0 =A0 =A0 =A0 a consensus on what name is appropriate. =A0Ot= her suggestions
>>
> have
>
>> =A0 =A0 =A0 =A0 =A0 included the following:
>> =A0 =A0 =A0 =A0 =A0 "target-identity" (someone didn'= t like that "identity" is
>> =A0 =A0 also a SIP header)
>> =A0 =A0 =A0 =A0 =A0 "reg-uri" =A0(can be paired with &qu= ot;mapped-uri" for item 3
>>
> below)
>
>> =A0 =A0 =A0 =A0 =A0 "aor"
>> =A0 =A0 =A0 =A0 =A0 "jibberish"
>> =A0 =A0 =A0 =A0 =A0 etc.
>>
>> =A0 =A0 =A0 =A0 =A0 One reason this is so difficult relates to the= problem
>> =A0 =A0 statement in target-uri in that
>> =A0 =A0 =A0 =A0 =A0 RFC 3261 doesn't differentiate the mechani= sm by which the
>>
> new
>
>> =A0 =A0 =A0 =A0 =A0 (target) Request-URI is selected. =A0Another i= ssue is that
>> =A0 =A0 some of the terminology in
>> =A0 =A0 =A0 =A0 =A0 RFC 3261 is overloaded - e.g., "forwardin= g" refers both to
a
>> =A0 =A0 Proxy
>> =A0 =A0 =A0 =A0 =A0 which does not have responsibility for the dom= ain of the
>> =A0 =A0 request-URI
>> =A0 =A0 =A0 =A0 =A0 in the incoming request, thus the proxy just &= quot;forwards" the
>> =A0 =A0 request to
>> =A0 =A0 =A0 =A0 =A0 the next hop AND "forwarding" is use= d to describe the
>> =A0 =A0 process whereby
>> =A0 =A0 =A0 =A0 =A0 the outgoing request is built and "forwar= ded" to the next
>> =A0 =A0 hop at which
>> =A0 =A0 =A0 =A0 =A0 point the proxy does not know how the new requ= est-uri was
>> =A0 =A0 selected.
>> =A0 =A0 =A0 =A0 =A0 RFC 4244 has attempted to clarify the terms an= d attempts to
>> =A0 =A0 use "forward"
>> =A0 =A0 =A0 =A0 =A0 in the context of the former situation and &qu= ot;retarget" for
>> =A0 =A0 the case whereby
>> =A0 =A0 =A0 =A0 =A0 a proxy is responsible for the domain and thus= can use a
>> =A0 =A0 number of
>> =A0 =A0 =A0 =A0 =A0 mechanism to select the new target for the req= uest - e.g.,
a
>> =A0 =A0 REGISTRAR,
>> =A0 =A0 =A0 =A0 =A0 configured data, etc.
>>
>> =A0 =A0 =A03. =A0Related to the last point in item 2 above, it has= been
>> =A0 =A0 proposed that
>> =A0 =A0 =A0 =A0 =A0 we differentiate the hi-entries even more by d= efining
>> =A0 =A0 separate parameters
>> =A0 =A0 =A0 =A0 =A0for registered and configured/mapped contacts.<= br> >> =A0 =A0 =A0 =A0 =A0Currently when the R-URI is translated to a URI= which is
>> =A0 =A0 either derived
>> =A0 =A0 =A0 =A0 =A0from location service lookup(registered by UA) = or from
>>
> mapping
>
>> =A0 =A0 =A0 =A0 =A0table, there is no differentiation as to how th= e URI was
>> =A0 =A0 derived once it is
>> =A0 =A0 =A0 =A0 =A0added to the list of potential targets.
>>
>> =A0 =A0 =A0 =A0 =A0The general consensus of the authors of the two= documents
was
>> =A0 =A0 that it may
>> =A0 =A0 =A0 =A0 =A0be useful for some services to have the hi-entr= ies tagged
>> =A0 =A0 with the
>> =A0 =A0 =A0 =A0 =A0more specific information.
>>
>> =A0 =A0 =A0 =A0 =A0And, of course, this gets us into another namin= g contest. In
>> =A0 =A0 the end, the naming
>> =A0 =A0 =A0 =A0 =A0is not so important as long as the term isn'= ;t too overloaded
>> =A0 =A0 and it is defined
>> =A0 =A0 =A0 =A0 =A0precisely in the document(s).
>>
>> =A0 =A0 We would appreciate WG feedback on these issues and any ot= her
>> =A0 =A0 comments on
>> =A0 =A0 the two documents prior to IETF-74.
>>
>> =A0 =A0 Regards,
>> =A0 =A0 Shida and Mary.
>>
>>
>>
>> =A0 =A0 Begin forwarded message:
>>
>>> =A0 =A0 *From: *In= ternet-Drafts@ietf.org
>>>
> <mailto:Internet-Drafts= @ietf.org>
>
>>> =A0 =A0 *Date: *March 10, 2009 2:30:01 AM JST
>>> =A0 =A0 *To: *i-d-ann= ounce@ietf.org <mailto:i-d-= announce@ietf.org>
>>> =A0 =A0 *Subject: **I-D
>>> =A0 =A0 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt = *
>>> =A0 =A0 *Reply-To: *internet-drafts@ietf.org
>>> =A0 =A0 <mailto:internet-drafts@ietf.org>
>>>
>>> =A0 =A0 A New Internet-Draft is available from the on-line
>>>
> Internet-Drafts
>
>>> =A0 =A0 directories.
>>>
>>>
>>> =A0 =A0 Title
>>> =A0 =A0 : Delivery of Request-URI Targets to User Agents
>>> =A0 =A0 Author(s)
>>> =A0 =A0 : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, = S.
Schubert
>>> =A0 =A0 Filename : draft-rosenberg-sip-target-uri-delivery-01.= txt
>>> =A0 =A0 Pages
>>> =A0 =A0 : 16
>>> =A0 =A0 Date
>>> =A0 =A0 : 2009-3-9
>>>
>>> =A0 =A0 When a Session Initiation Protocol (SIP) proxy receive= s a
request
>>> =A0 =A0 =A0 targeted at a URI identifying a user or resource i= t is
>>>
> responsible
>
>>> =A0 =A0 =A0 for, the proxy translates the URI to a registered = or
configured
>>> =A0 =A0 =A0 contact URI of an agent representing that user or = resource.
>>> In
>>>
> the
>
>>> =A0 =A0 =A0 process, the original URI is removed from the requ= est.
>>> =A0 =A0 =A0Numerous use
>>> =A0 =A0 =A0 cases have arisen which require this information t= o be
>>>
> delivered to
>
>>> =A0 =A0 =A0 the user agent. =A0This document describes these u= se cases and
>>> =A0 =A0 defines
>>> =A0 =A0 =A0 an extension to the History-Info header field whic= h allows it
>>>
> to be
>
>>> =A0 =A0 =A0 used to support those cases.
>>>
>>> =A0 =A0 A URL for this Internet-Draft is:
>>>
>>> http://www.ietf.org/internet-drafts/dr= aft-rosenberg-sip-target-uri-d
>>> e
>>> livery-01.txt
>>>
>>> =A0 =A0 Internet-Drafts are also available by anonymous FTP at= :
>>> =A0 =A0 ftp://ftp.ietf.org/internet-drafts/
>>>
>>> =A0 =A0 Below is the data which will enable a MIME compliant m= ail reader
>>> =A0 =A0 implementation to automatically retrieve the ASCII ver= sion of
the
>>> =A0 =A0 Internet-Draft.
>>>
>> =A0 =A0 Content-Type: text/plain<BR>Content-ID:
>> =A0 =A0 &l= t;2009-3-9102756.I-D@ietf.org
>> =A0 =A0 <mailto:= 2009-3-9102756.I-D@ietf.org>&gt;<BR><BR>
>>
>>> =A0 =A0 _______________________________________________
>>> =A0 =A0 I-D-Announce mailing list
>>> =A0 =A0 I-D-Announce@= ietf.org <mailto:I-D-Announ= ce@ietf.org>
>>> =A0 =A0 https://www.ietf.org/mailman/listinfo/i-d-announ= ce
>>> =A0 =A0 Internet-Draft directories: http://www.ietf.org/shadow.html
>>> =A0 =A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>> =A0 =A0 _______________________________________________
>> =A0 =A0 Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip=
>> =A0 =A0 This list is for NEW development of the core SIP Protocol<= br> >> =A0 =A0 Use si= p-implementors@cs.columbia.edu
>> =A0 =A0 <mailto:sip-implementors@cs.columbia.edu> for questions on
>> current
>>
> sip
>
>> =A0 =A0 Use sipping@ietf.org <mailto:sipping@ietf.org> = for new
>> =A0 =A0 developments on the application of sip
>>
>>
>>

--0015174c10a098e9240464e7daf9-- From john.elwell@siemens.com Thu Mar 12 04:08:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8993A6A58 for ; Thu, 12 Mar 2009 04:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, MANGLED_DELIVY=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsPDaYqdhlZX for ; Thu, 12 Mar 2009 04:08:23 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7BA293A6868 for ; Thu, 12 Mar 2009 04:08:22 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGE00K4Z4AU36@siemenscomms.co.uk> for sip@ietf.org; Thu, 12 Mar 2009 11:08:58 +0000 (GMT) Date: Thu, 12 Mar 2009 11:08:57 +0000 From: "Elwell, John" In-reply-to: <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> To: Hans Erik van Elburg , Mary Barnes Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: Acmi7W8JoLngjlXtTEqklOfh2jQOhQAFOLMw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 11:08:29 -0000 If 'istarget' is used only to identify the value that was overwritten in the Request-URI by a contact URI, an alternative approach would be to flag the contact URI H-I entry as 'iscontact'. Then the UAS would just need to look for the most recent H-I entry that is not marked 'iscontact'. John ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 12 March 2009 08:35 To: Mary Barnes Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Yes, because you are using the 3261 use of target and the 4244bis introduced definition of retarget. I thought it was clear that we need other words as those definitions don't match the target-uri drafts use of the terms. Also they do not suffice to provide a solution for the use cases in the target-uri draft. =09 The 3261 text you refer to is exactly about the case where the home proxy overwrites the Request-URI with a new target. This target is teh registered contact address. And hence this would be what target-uri calls a hop or a route. This case and this is where it gets confusing is not a "retarget" in the target-uri draft use of the term. =09 The target-uri draft states: =09 "To avoid confusion, we refer to a SIP URI that is an address for a user or resource as a "target" and a SIP URI that is a hop for reaching that user as a =09 "hop". =09 Apparently that does not suffice to avoid confusion. =09 As for the tagging, speaking about the solution before agreeing on the terminology and the problem it should solve is meaningless. =09 /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes wrote: =09 Responses below [MB]. =09 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] =09 Sent: Wednesday, March 11, 2009 6:42 PM To: Barnes, Mary (RICH2:AR00) Cc: Shida Schubert; sip@ietf.org Subject: Re: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 I was talking about the concept. =09 The use cases only describe cases where the target-uri (lets call that current target from now) has been lost when an initial request for a dialog or standalone request arrives at the UAS. =09 [MB] And I think this is where the terminology confusion starts - I don't think of the "lost" target-uri as being the "current" target. In my mind, the "current" target is reflected by the last hi-entry and the request-uri in the incoming request at the UAS. If the entity that sent the request was the entity that added the last hi-entry, then the uri in that hi-entry is the same as the request-URI in the SIP request that arrives at the UAS. I refer to the "lost" uri as the one that was "retargeted" - that's the one the UAS wants to pull from the hi-entries in the incoming request. That hi-entry was not the one that was just added by the entity that built the request just received by the UAS. That hi-entry is tagged with whatever name we are going to tag it with BEFORE the request is forwarded (using the term forward per section 16.6 of RFC 3261). That tag is added once the target set of potential candidates for the new request uri are determined in section 16.5 of 3261 (with "target set" being a 3261 term), just before the request is forwarded in section 16.6 to one of those targets. A new hi-entry (which will be the last hi-entry in the request received by the UAS) is added in section 16.6 of 3261 as the request is forwarded. At this point in time, the lost information is in the previous hi-entry when the outgoing request is sent. [/MB] =09 What has been lost is the current target of the request: =09 [MB] Right - at which point in my mind, it's no longer the current target ;) Maybe we call it "lost". [/MB] =09 Current target =09 The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. =09 =09 [MB] I don't think this definition fits what you want - i.e., if there is no retargeting, then none of the hi-entries are tagged - i.e., you won't have your concept of current. The way it works is that if no hi-entries are tagged, then you know that there was no retargeting, thus you know the request-uri has not been lost. [/MB] =09 This defintion only makes sense when the following definitions are used: =09 Name: =09 A name is a moniker for an entity which refers to it in a way which =09 reveals nothing about where it is in a network. In SIP, tel URI =09 which doesn't represent the location of the entity is a name. =09 =09 Address: =09 An address is an identifier for an entity which describes it by its =09 location on the network. In SIP, the SIP URI itself is a form of =09 address because the host part of the URI, the only mandatory part of =09 the URI besides the scheme itself, indicates the location of a SIP =09 server that can be used to handle the request. =09 Route: =09 Finally, a route is a sequence of SIP entities (including the UA itself!) which are =09 traversed in order to forward a request to an address or name. =09 Retarget (other term might be needed, as this is highly confusing): =09 A Request-URI rewrite operation that changes the target identity of the request. =09 Reroute (other term might be needed): =09 A Request-URI rewrite operation that does not change the current target of the request, but determines the route/next hop taken to reach the target-identity. =09 /Hans Erik =09 Mary Barnes wrote: > So, by "target-uri concept" are you referring to the solution in the > current target-uri draft or the application usage as such in the > target-uri document (which is what I was referring to)? > > Yes, the problem is that SIP doesn't differentiate the various > mechanisms by which a request-URI may be changed, which is what some > of the updated text in 4244bis is trying to do and why we need precise =09 > terms. I think we all agree that. > > I honestly don't care what we call the tag, as long as we're clear > about the functionality. > > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 4:40 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > The target-uri concept when defined properly is entirely application > agnostic. > > When one uses History-Info or another header as a vehicle for this > information then it still can be considered application agnostic as > any application can use this information as it likes. > > From SIP perspective all the Request-URI rewrites look the same, that =09 > is what brought us discussing this in the first place. > > /Hans Erik > > Mary Barnes wrote: > >> And, I think the big issue with the terminology is that 4244bis is >> application agnostic, so it is tagging what happens to the URIs >> (why/how the specific URI was overwritten). Whereas, specific >> applications can derive information, such as what "is" the real >> "target" for the request, from the History-Info header. So, IMHO, >> it's a matter of the target-uri document specifying that the last >> entry tagged by whatever name we come up with "is" the real "target" >> for the request. I believe it's up to the applications to describe >> how they make use of the History-Info and not for the History-Info to =09 >> describe how applications can use it. History-Info purely reflects >> what happened from a SIP Protocol perspective and should not imply >> any >> > > >> application semantics. Indeed the intent of section 5 of 4244 was to >> inform the applications how they should decribe their usage of the >> header. >> >> Mary. >> Note: I changed the subject to hopefully make this topic easier to >> keep track of. >> >> --------------------------------------------------------------------- >> - >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Wednesday, March 11, 2009 3:59 AM >> *To:* Shida Schubert >> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) >> *Subject:* Re: [Sip] Fwd: I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >> >> One of the problems that made the discussion quite tedious is the >> complete inversed meaning of the terms "retarget" and "reroute" >> between 4244bis and target-uri factions have. >> >> Conclusion was that the terminology need to be properly defined and >> some attempt was made to start such activity. >> >> On 3. I have strong concerns when we start tagging the URI as to how >> they come about "retarget"/"mapped conficuration" etc. It is better >> to >> > > >> embellish them with a tag that just represents there meaning for >> example "istarget" or "hop". For the following reasons: >> 1. It is much more intuitive for the user of this information, its >> meaning can basically be guessed. >> 2. Such meaning also probably survives application in other problem >> spaces that we had not foreseen when introducing the concept. >> >> The solution that is described now in the target-URI delivery draft >> is not yet complete, it does not solve the freephone use case for >> example and in its current form it will deliver exactly the same >> target-URI as that which would be delivered by the P-Called-Party-ID =09 >> header. Contrary to what the draft says. So some work is needed still. >> >> /Hans Erik van Elburg >> >> >> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > > wrote: >> >> >> We have submitted the updated target-uri draft based on the >> > comments > >> submitted to the list and comments received at IETF73. >> >> I have taken over as editor as Jonathan didn't have the cycles to =09 >> update the draft, with Francois, Christer and Hans Erick as >> additional >> co-authors and great deal of help from Mary. >> >> The following summarizes the changes made to the target-uri >> > document > >> 1. Added use-case for toll-free number back >> 2. Added definition of "retarget" operation. >> 3. Removed a reference to URN >> 4. Added a text discussing the difference to P-Called-Party-Id >> 5. Changed parameter name from "target" to "istarget" >> >> Note, that the target-uri document still contains the normative >> text for the >> History-Info header. >> >> In addition, Mary (with Francois as co-author) has submitted a >> rfc4244bis, with the following changes: >> 1. Incorporated the normative aspects of the target-uri document >> into the existing normative text in RFC 4244 - the functionality >> > is > >> virtually identical (as is some of the text) as the HI based >> > solution > >> described in the target-uri document. It's important that the >> solution >> be integrated into RFC 4244 as it MUST work and be based on the >> normative >> aspects of RFC 4244. >> 2. Added the use cases from target-uri the the summary >> in the overview of rfc4244bis. >> 3. Added an additional requirement to capture the "target-uri" >> information. >> 4. Fixed an error in the RFC 4244 ABNF and added "retarget" >> > parameter. > >> 5. Added a more simplified example. >> >> >> We had some very long offline exchanges as to the best way >> forward >> > and > >> remaining work for both documents. >> >> Some of the issues identified are: >> >> ::Issues:: >> 1. Should we remove the normative text from target-uri and >> > progress > >> 4244bis along with the target-uri document to meet the >> chartered >> SIP WG milestone? >> >> >> 2. Name of the parameter. >> At the last meeting, parameter "target" was said >> > inappropriate > >> because voicemail-uri spec already defines a parameter >> > called > >> "target" which also can be found in hi-entry, thus >> > potentially > >> causing confusion. >> >> Currently the target-uri draft uses "istarget" and 4244bis >> > uses > >> "retarget" but we could never come to >> a consensus on what name is appropriate. Other suggestions >> > have > >> included the following: >> "target-identity" (someone didn't like that "identity" is >> also a SIP header) >> "reg-uri" (can be paired with "mapped-uri" for item 3 >> > below) > >> "aor" >> "jibberish" >> etc. >> >> One reason this is so difficult relates to the problem >> statement in target-uri in that >> RFC 3261 doesn't differentiate the mechanism by which the >> > new > >> (target) Request-URI is selected. Another issue is that >> some of the terminology in >> RFC 3261 is overloaded - e.g., "forwarding" refers both to a >> Proxy >> which does not have responsibility for the domain of the >> request-URI >> in the incoming request, thus the proxy just "forwards" the >> request to >> the next hop AND "forwarding" is used to describe the >> process whereby >> the outgoing request is built and "forwarded" to the next >> hop at which >> point the proxy does not know how the new request-uri was >> selected. >> RFC 4244 has attempted to clarify the terms and attempts to >> use "forward" >> in the context of the former situation and "retarget" for >> the case whereby >> a proxy is responsible for the domain and thus can use a >> number of >> mechanism to select the new target for the request - e.g., a >> REGISTRAR, >> configured data, etc. >> >> 3. Related to the last point in item 2 above, it has been >> proposed that >> we differentiate the hi-entries even more by defining >> separate parameters >> for registered and configured/mapped contacts. >> Currently when the R-URI is translated to a URI which is >> either derived >> from location service lookup(registered by UA) or from >> > mapping > >> table, there is no differentiation as to how the URI was >> derived once it is >> added to the list of potential targets. >> >> The general consensus of the authors of the two documents was >> that it may >> be useful for some services to have the hi-entries tagged >> with the >> more specific information. >> >> And, of course, this gets us into another naming contest. In >> the end, the naming >> is not so important as long as the term isn't too overloaded >> and it is defined >> precisely in the document(s). >> >> We would appreciate WG feedback on these issues and any other >> comments on >> the two documents prior to IETF-74. >> >> Regards, >> Shida and Mary. >> >> >> >> Begin forwarded message: >> >>> *From: *Internet-Drafts@ietf.org >>> > > >>> *Date: *March 10, 2009 2:30:01 AM JST >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D >>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * >>> *Reply-To: *internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line >>> > Internet-Drafts > >>> directories. >>> >>> >>> Title >>> : Delivery of Request-URI Targets to User Agents >>> Author(s) >>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert >>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt >>> Pages >>> : 16 >>> Date >>> : 2009-3-9 >>> >>> When a Session Initiation Protocol (SIP) proxy receives a request >>> targeted at a URI identifying a user or resource it is >>> > responsible > >>> for, the proxy translates the URI to a registered or configured >>> contact URI of an agent representing that user or resource. >>> In >>> > the > >>> process, the original URI is removed from the request. >>> Numerous use >>> cases have arisen which require this information to be >>> > delivered to > >>> the user agent. This document describes these use cases and >>> defines >>> an extension to the History-Info header field which allows it >>> > to be > >>> used to support those cases. >>> >>> A URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d >>> e >>> livery-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> Content-Type: text/plain
Content-ID: >> <2009-3-9102756.I-D@ietf.org =20 >> >

>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current >> > sip > >> Use sipping@ietf.org for new >> developments on the application of sip >> >> >> =09 From christer.holmberg@ericsson.com Thu Mar 12 04:48:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025283A69C0; Thu, 12 Mar 2009 04:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3zD2ddi-vWY; Thu, 12 Mar 2009 04:48:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 081EC3A693D; Thu, 12 Mar 2009 04:48:50 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 25DF4206FB; Thu, 12 Mar 2009 12:49:26 +0100 (CET) X-AuditID: c1b4fb3c-ae80cbb000001b43-f3-49b8f6c50bee Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E30F821543; Thu, 12 Mar 2009 12:49:25 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 12:49:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A308.86F02CF0" Date: Thu, 12 Mar 2009 12:48:57 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: One chart //"UPDATE during Re-INVITE" discussion Thread-Index: Acmi5fd0IMydjGVxQ7yJMSIfo+xCugAIf+WQ References: From: "Christer Holmberg" To: X-OriginalArrivalTime: 12 Mar 2009 11:49:11.0397 (UTC) FILETIME=[8F2DA950:01C9A308] X-Brightmail-Tracker: AAAAAA== Cc: SIP , SIPPING , Gonzalo Camarillo Subject: Re: [Sip] One chart //"UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 11:48:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A308.86F02CF0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Hi, =20 If the UAC receives the 487 and can't fallback to the pre-reINVITE = state, it sends a new re-INVITE with something that it DOES supports. = That is also described in Gonzalo's draft, I belive. =20 And, you could have the same problem if the target refresh was done = already in the re-INVITE/18x. If the UAC then sends CANCEL, and can't = fall back, it will have to send a new re-INVITE. =20 I also think it is bad practise to do a target refresh in a nested = UPDATE, but that's a separate issue. =20 Regards, =20 Christer =20 ________________________________ From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: 12. maaliskuuta 2009 9:41 To: Christer Holmberg Cc: Gonzalo Camarillo; SIP; SIPPING Subject: =B4=F0=B8=B4: RE: One chart //"UPDATE during Re-INVITE" = discussion =09 =09 Hi,=20 =09 I just mean that if we treat F3 as sub-transaction of F1, then after = F7(ACK), UAC can discard refreshed dialog state in F3.=20 =09 And it may make the two parts can not communicate anymore in current = dialog.=20 =09 And IMO, this is a counterevidence for treating all UPDATE(during = Re-INVITE) as sub-transaction of Re-INVITE.=20 =09 Gao=20 =09 =09 =09 =09 =09 "Christer Holmberg" =20 2009-03-12 15:31=20 =CA=D5=BC=FE=C8=CB , "SIP" , "SIPPING" = =20 =B3=AD=CB=CD "Gonzalo Camarillo" =20 =D6=F7=CC=E2 RE: One chart //"UPDATE during Re-INVITE" discussion =09 In my opinion 487 should trigger whatever actions/rollback that any = other non-200 response sent by the UAS would.=20 =20 Regards,=20 =20 Christer=20 =09 =09 ________________________________ From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: 12. maaliskuuta 2009 5:47 To: SIP; SIPPING Cc: Christer Holmberg; Gonzalo Camarillo Subject: One chart //"UPDATE during Re-INVITE" discussion =09 =09 UAC UAS=20 | session established |=20 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=20 | |=20 | F1 re-INVITE (SDP) |=20 |-------------------->|=20 | F2 1xx-rel (SDP) |=20 |<--------------------|=20 | F3 UPDATE |=20 |<--------------------| Target refreshing=20 | F4 2xx UPT |=20 |-------------------->|=20 | |=20 | F5/6 Cancel/200OK |=20 |-------------------->|=20 | F7 487 INV |=20 |<--------------------|=20 | F7 ACK |=20 |-------------------->|=20 | F8 re-INVITE (SDP) |=20 |-------------------->| Using which dialog state=20 =09 F3/F4 is about target refreshing.=20 =09 And if UAC sends Cancel=A3=AC UAS sends 487. The first Re-INVITE is = discarded.=20 =09 But if UAC sends another Re-INVITE, which dialog state should it use?=20 =09 I think is the one refreshed by F3. That's the merit of regarding = UPDATE/200OK's atomicity.=20 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. =09 =09 =09 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01C9A308.86F02CF0 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
If the UAC receives the 487 and can't fallback = to the=20 pre-reINVITE state, it sends a new re-INVITE with something that it=20 DOES supports. That is also described in Gonzalo's draft, I=20 belive.
 
And, you could have the same problem if the = target refresh=20 was done already in the re-INVITE/18x. If the UAC then sends CANCEL, and = can't=20 fall back, it will have to send a new re-INVITE.
 
I also think it is bad practise to do a target = refresh in a=20 nested UPDATE, but that's a separate issue.
 
Regards,
 
Christer
 
From: gao.yang2@zte.com.cn=20 [mailto:gao.yang2@zte.com.cn]
Sent: 12. maaliskuuta 2009=20 9:41
To: Christer Holmberg
Cc: Gonzalo Camarillo; = SIP;=20 SIPPING
Subject: =B4=F0=B8=B4: RE: One chart //"UPDATE = during Re-INVITE"=20 discussion


Hi, =

I just mean that if we treat F3 as = sub-transaction of=20 F1, then after F7(ACK), UAC can discard refreshed dialog state in = F3.=20

And it may make the two parts = can not=20 communicate anymore in current dialog.

And IMO, this is a counterevidence for treating all = UPDATE(during=20 Re-INVITE) as sub-transaction of Re-INVITE.

Gao




"Christer = Holmberg"=20 <christer.holmberg@ericsson.com>

2009-03-12 15:31

=CA=D5=BC=FE=C8=CB
<gao.yang2@zte.com.cn>,=20 "SIP" <sip@ietf.org>, "SIPPING"=20 <sipping@ietf.org>=20
=B3=AD=CB=CD
"Gonzalo Camarillo"=20 <gonzalo.camarillo@ericsson.com>=20
=D6=F7=CC=E2
RE: One chart =  //"UPDATE=20 during Re-INVITE" = discussion

=




In my opinion 487 should trigger whatever = actions/rollback=20 that any other non-200 response sent by the UAS would. =
 
Regards,
 =20
Christer

From: gao.yang2@zte.com.cn=20 [mailto:gao.yang2@zte.com.cn]
Sent: 12. maaliskuuta 2009=20 5:47
To: SIP; SIPPING
Cc: Christer Holmberg; = Gonzalo=20 Camarillo
Subject: One chart //"UPDATE during Re-INVITE"=20 discussion


     UAC     =    =20           UAS=20
      | = session=20 established |
      = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
   =20   |                 =    =20 |
      | F1  re-INVITE (SDP) = |
   =20   |-------------------->|=20
      | F2 = 1xx-rel=20 (SDP)    | =
     =20 |<--------------------| =
      | F3   UPDATE =  =20       | =
      = |<--------------------|=20 Target refreshing
      | F4 2xx UPT =    =20      | =
     =20 |-------------------->| =
      |     =    =20             |
    =   | F5/6=20 Cancel/200OK   | =
     =20 |-------------------->| =
      | F7   =  487 INV=20       | =
     =20 |<--------------------| =
      | F7     = ACK  =20        | =
     =20 |-------------------->| =
      | F8 =  re-INVITE (SDP)=20 |
      |-------------------->| Using = which dialog=20 state

F3/F4 is about target refreshing.

And if UAC = sends Cancel=A3=AC=20 UAS sends 487. The first Re-INVITE is discarded.

But if UAC = sends another=20 Re-INVITE, which dialog state should it use?

I think is = the one=20 refreshed by F3. That's the merit of regarding UPDATE/200OK's=20 atomicity. =

--------------------------------------------------------
= ZTE=20 Information Security Notice: The information contained in this mail is = solely=20 property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy = and are=20 not permitted to disclose the contents of this communication to=20 others.
This email and any files transmitted with it are = confidential and=20 intended solely for the use of the individual or entity to whom they = are=20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are = those of=20 the individual sender.
This message has been scanned for viruses = and Spam=20 by ZTE Anti-Spam = system.


-------------------------------------=
-------------------
ZTE Information Security Notice: The information=
 contained in this mail is solely prop=
erty of the sender's organization. This mai=
l communication is confidential. Recipients name=
d above are obligated to maintain secrecy&n=
bsp;and are not permitted to disclose the&n=
bsp;contents of this communication to others.
This email and any files transmitted with&n=
bsp;it are confidential and intended solely =
;for the use of the individual or enti=
ty to whom they are addressed. If you&=
nbsp;have received this email in error plea=
se notify the originator of the message.&nb=
sp;Any views expressed in this message are&=
nbsp;those of the individual sender.
This message has been scanned for viruses&n=
bsp;and Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01C9A308.86F02CF0-- From john.elwell@siemens.com Thu Mar 12 04:51:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4653A6905 for ; Thu, 12 Mar 2009 04:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, FRT_LOLITA1=1.865] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm8gt7WJIWMg for ; Thu, 12 Mar 2009 04:51:26 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7F1133A68FD for ; Thu, 12 Mar 2009 04:51:25 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGE00M4P6API3@siemenscomms.co.uk> for sip@ietf.org; Thu, 12 Mar 2009 11:52:01 +0000 (GMT) Date: Thu, 12 Mar 2009 11:52:03 +0000 From: "Elwell, John" In-reply-to: <29682BF0-403F-426F-A635-FC3F94BBEA1C@cisco.com> To: Cullen Jennings Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001A27B42@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important Thread-Index: AcminhhXeLdOa0aVTMyZd+ejO5qtEAAadbyA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001984302@GBNTHT12009MSX.gb002.siemens.net> <29682BF0-403F-426F-A635-FC3F94BBEA1C@cisco.com> Cc: SIP List , Jon Peterson Subject: Re: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 11:51:29 -0000 Cullen, > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 11 March 2009 23:07 > To: Elwell, John > Cc: SIP List; Jon Peterson > Subject: Re: [Sip] Seeking consensus on=20 > draft-elwell-sip-e2e-identity-important >=20 >=20 > I continue to believe that we need to to come to some common =20 > understanding of the security problem we are trying to solve and the =20 > constraints on that solution. On one of the close to last=20 > phones calls =20 > involving this draft I asked everyone one on the call what they =20 > thought the problem was. I got no common answer. >=20 > There is a lot of good information in this draft related to the =20 > problem and solutions, but I don't believe this draft gets to what =20 > problem we are trying to solve thus making it very hard to answer a =20 > question like if the solution should involve changing m line or not. =20 > If we all agreed the problem was, just for example, stop MITM from =20 > listening to phone calls while still allowing intermediaries to do =20 > media steering, then I think we could get there. [JRE] That may be a good way to express it. At present, in section 9, it expresses the problem in terms of: "Loss of end-to-end authenticated identification caused by the breaking of SIP Identity signatures on non-E.164-based SIP URIs by B2BUAs in intermediate domains performing legitimate functions such as media steering." and a slightly different statement for the E.164-based case. Then in section 10 it tries to state the requirement in terms of a third party, user 3, which is the MitM in your formulation. So that is not 100 miles away from your suggestion. When working on slides for IETF74, I will try to take this into account and provide a better problems statement. Other input welcome. John > I know the=20 > problem is =20 > much more complicated than I just said - I'm not suggesting that my =20 > above statement is the right problem statement but just that it is =20 > closer to level we should be looking at the problem at. >=20 > Cullen >=20 >=20 > On Mar 3, 2009, at 9:46 AM, Elwell, John wrote: >=20 > > Draft 03: > >=20 > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > includes for the first time an analysis of changes to SIP=20 > requests by > > B2BUAs (section 8). Also the Conclusions (section 9) have been =20 > > extended. > > > > I and a number of people who have assisted in revising this draft =20 > > would > > like to seek consensus on a number of the points. We aim to=20 > ask these > > questions in San Francisco, but obviously it would help to get =20 > > opinions > > from the list in advance. > > > > 1. Tolerance to changes of certain elements as a SIP request is > > forwarded through intermediate domains. > > > > Section 8 analyses a number of elements of SIP messages that are =20 > > signed > > by the present RFC 4474 solution to end-to-end (or near end-to-end) > > authenticated identification. For some elements it claims that any > > solution for end-to-end authenticated identification needs to be > > tolerant of changes by intermediate domains, since there=20 > appear to be > > valid reasons why B2BUAs (including but not limited to SBCs) change > > these elements. Picking on some of these: > > > > A) Is there agreement that a solution needs to be tolerant of =20 > > changes to > > IP addresses and ports in c- and m-lines in SDP? In other=20 > words, that > > intermediate domains can legitimately modify these fields (e.g., for > > media steering) and a solution is needed for end-to-end=20 > authenticated > > identification in such circumstances? > > > > B) Is there agreement that a solution needs to be tolerant of =20 > > changes to > > Contact (addr-spec), Call-Id (call-id) and CSeq (digit)=20 > header fields? > > In other words, that intermediate domains can legitimately modify =20 > > these > > fields (e.g., for topology hiding) and a solution is needed for > > end-to-end authenticated identification in such circumstances? > > > > C) Is there agreement that a solution does not need to be=20 > tolerant of > > changes to the addr-spec of From and To header fields? In=20 > other words, > > that intermediate domains should not modify these fields and can =20 > > expect > > to break end-to-end authenticated identification if they do so? > > > > > > 2. Are people in broad agreement with the conclusions in section 9 > > concerning the importance of end-to-end identification and in =20 > > particular > > end-to-end authenticated identification? > > > > John > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 From brett@broadsoft.com Thu Mar 12 04:56:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AC83A6A1C; Thu, 12 Mar 2009 04:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMDZ12d2Ftct; Thu, 12 Mar 2009 04:56:32 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 9A9B53A68FD; Thu, 12 Mar 2009 04:56:32 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 12 Mar 2009 04:57:08 -0700 From: Brett Tate To: "gao.yang2@zte.com.cn" , SIP , SIPPING Date: Thu, 12 Mar 2009 04:57:06 -0700 Thread-Topic: [Sip] One chart //"UPDATE during Re-INVITE" discussion Thread-Index: AcmixVEtRpTN8qlMQLOZYgPVP++E7wAQwjgw Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10B4A05310@mbx02.citservers.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9B2A061A1137254BBE4F4B2CD843646A10B4A05310mbx02citserve_" MIME-Version: 1.0 Subject: Re: [Sip] One chart //"UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 11:56:38 -0000 --_000_9B2A061A1137254BBE4F4B2CD843646A10B4A05310mbx02citserve_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Data (like Contact, Session-Expires, and etcetera) that was successfully up= dated by F3/F4 still apply after F7. Thus F8 data should reflect (and can = attempt to modify) adjustments made during F3/F4. From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of gao.y= ang2@zte.com.cn Sent: Wednesday, March 11, 2009 11:47 PM To: SIP; SIPPING Cc: Gonzalo Camarillo; Christer Holmberg Subject: [Sip] One chart //"UPDATE during Re-INVITE" discussion UAC UAS | session established | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | F1 re-INVITE (SDP) | |-------------------->| | F2 1xx-rel (SDP) | |<--------------------| | F3 UPDATE | |<--------------------| Target refreshing | F4 2xx UPT | |-------------------->| | | | F5/6 Cancel/200OK | |-------------------->| | F7 487 INV | |<--------------------| | F7 ACK | |-------------------->| | F8 re-INVITE (SDP) | |-------------------->| Using which dialog state F3/F4 is about target refreshing. And if UAC sends Cancel=1B$B!$=1B(B UAS sends 487. The first Re-INVITE is d= iscarded. But if UAC sends another Re-INVITE, which dialog state should it use? I think is the one refreshed by F3. That's the merit of regarding UPDATE/20= 0OK's atomicity. --_000_9B2A061A1137254BBE4F4B2CD843646A10B4A05310mbx02citserve_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Data (like Contact, Session-Expires, and etcetera) that was = successfully updated by F3/F4 still apply after F7.  Thus F8 data should reflect (a= nd can attempt to modify) adjustments made during F3/F4.

 

 

From: sip-bounces@i= etf.org [mailto:sip-bounces@ietf.org] On Behalf Of gao.yang2@zte.com.cn
Sent: Wednesday, March 11, 2009 11:47 PM
To: SIP; SIPPING
Cc: Gonzalo Camarillo; Christer Holmberg
Subject: [Sip] One chart //"UPDATE during Re-INVITE" discussion

 


  &n= bsp;   UAC                   U= AS
  &n= bsp;    | session established |
  &n= bsp;    |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >|
  &n= bsp;    |                 &nbs= p;   |
  &n= bsp;    | F1  re-INVITE (SDP) |
  &n= bsp;    |-------------------->|
  &n= bsp;    | F2 1xx-rel (SDP)    |
  &n= bsp;    |<--------------------|
  &n= bsp;    | F3   UPDATE         |
  &n= bsp;    |<--------------------| Target refreshing
  &n= bsp;    | F4 2xx UPT          |
  &n= bsp;    |-------------------->|
  &n= bsp;    |                 &nbs= p;   |
  &n= bsp;    | F5/6 Cancel/200OK   |
  &n= bsp;    |-------------------->|
  &n= bsp;    | F7    487 INV       |
  &n= bsp;    |<--------------------|
  &n= bsp;    | F7     ACK          |
  &n= bsp;    |-------------------->|
  &n= bsp;    | F8  re-INVITE (SDP) |
  &n= bsp;    |-------------------->| Using which dialog state
F3/F4 is = about target refreshing.

And if UA= C sends Cancel=1B$B!$=1B(J UAS sends 487.= The first Re-INVITE is discarded.

But if UA= C sends another Re-INVITE, which dialog state should it use?

I think i= s the one refreshed by F3. That's the merit of regarding UPDATE/200OK's atomicity= . 

 
--_000_9B2A061A1137254BBE4F4B2CD843646A10B4A05310mbx02citserve_-- From ietf.hanserik@gmail.com Thu Mar 12 05:56:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD1328C128 for ; Thu, 12 Mar 2009 05:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, MANGLED_DELIVY=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDQBASCiMWgP for ; Thu, 12 Mar 2009 05:55:59 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id DC33228C104 for ; Thu, 12 Mar 2009 05:55:58 -0700 (PDT) Received: by ewy25 with SMTP id 25so345863ewy.37 for ; Thu, 12 Mar 2009 05:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8Em/8rCpPXlUQxdBfUgp8aM8vKysxna/nrjsYuTwtjM=; b=aMFBC1p1lTQ7HvzhcKUjt8NsCcTLcKhLwykB6/BB6ik8Aq8MavJEkOtx/7SJMsceYJ r0kPujBwugbRzXVYbZbEMvWt0MXEwMJHvQ5cEd0PoXzHZ3NvmMSifHbw0exe0VcekvCI 8V8r8cNCRtCZxtWTac6hQSobXhjeRLZG5qaAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a1BkIWZ9+Mdf+IzBha1Cutc+hWTaYIzOwNgwhhuvDfddTU1erEnODV4w5VbaLG4Ezn gV4qFFXfUF0w3qEdBLmFkyBg8kH9hY34JswYt/nbrznT5zAcQ/JdEO+FlaZdR5At3NHY LqjsSSFPPQA2MfBMeRS4dbZonXAds+yySrFIk= MIME-Version: 1.0 Received: by 10.210.20.17 with SMTP id 17mr6461194ebt.21.1236862595493; Thu, 12 Mar 2009 05:56:35 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 12 Mar 2009 13:56:35 +0100 Message-ID: <9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174be732a3eec90464eb8327 Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 12:56:02 -0000 --0015174be732a3eec90464eb8327 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit But that does not solve the freephone service use case. Freephone represents a use case where the R-URI is replaced with an AoR of user B - not with the contact of user B. A calls Bfreephonenumber routed the B (AOR) routed to B's contact. The target-uri draft is interested in obtaining: Bfreephonenumber as that is what A used to reach B. So what we like to see that B UA receives is something like H-I: Bfreephone; "istarget",\ B,\ contact-B So you want to get Bfreephonenumber and not B. In certain situations you are also interested in B, I guess that PBX's would interested in that to deliver to the correct user. We could distinguish them like: H-I: Bfreephone; "istarget",\ B,"aor"\ contact-B BR, /Hans Erik van Elburg On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John wrote: > If 'istarget' is used only to identify the value that was overwritten in > the Request-URI by a contact URI, an alternative approach would be to > flag the contact URI H-I entry as 'iscontact'. Then the UAS would just > need to look for the most recent H-I entry that is not marked > 'iscontact'. > > John > > > ________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: 12 March 2009 08:35 > To: Mary Barnes > Cc: sip@ietf.org > Subject: Re: [Sip] Terminology (was RE: Fwd: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > Yes, because you are using the 3261 use of target and the > 4244bis introduced definition of retarget. I thought it was clear that > we need other words as those definitions don't match the target-uri > drafts use of the terms. Also they do not suffice to provide a solution > for the use cases in the target-uri draft. > > The 3261 text you refer to is exactly about the case where the > home proxy overwrites the Request-URI with a new target. This target is > teh registered contact address. And hence this would be what target-uri > calls a hop or a route. This case and this is where it gets confusing is > not a "retarget" in the target-uri draft use of the term. > > The target-uri draft states: > > "To avoid confusion, we > refer to a SIP URI that is an address for a user or resource > as a > "target" and a SIP URI that is a hop for reaching that user > as a > > "hop". > > > Apparently that does not suffice to avoid confusion. > > As for the tagging, speaking about the solution before agreeing > on the terminology and the problem it should solve is meaningless. > > /Hans Erik van Elburg > > > > On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes > wrote: > > > Responses below [MB]. > > > -----Original Message----- > From: Hans Erik van Elburg > [mailto:ietf.hanserik@gmail.com] > > Sent: Wednesday, March 11, 2009 6:42 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > I was talking about the concept. > > The use cases only describe cases where the target-uri > (lets call that > current target from now) has been lost when an initial > request for a > dialog or standalone request arrives at the UAS. > > [MB] And I think this is where the terminology confusion > starts - I > don't think of the "lost" target-uri as being the > "current" target. In > my mind, the "current" target is reflected by the last > hi-entry and the > request-uri in the incoming request at the UAS. If the > entity that sent > the request was the entity that added the last hi-entry, > then the uri in > that hi-entry is the same as the request-URI in the SIP > request that > arrives at the UAS. I refer to the "lost" uri as the one > that was > "retargeted" - that's the one the UAS wants to pull from > the hi-entries > in the incoming request. That hi-entry was not the one > that was just > added by the entity that built the request just received > by the UAS. > That hi-entry is tagged with whatever name we are going > to tag it with > BEFORE the request is forwarded (using the term forward > per section 16.6 > of RFC 3261). That tag is added once the target set of > potential > candidates for the new request uri are determined in > section 16.5 of > 3261 (with "target set" being a 3261 term), just before > the request is > forwarded in section 16.6 to one of those targets. A > new hi-entry > (which will be the last hi-entry in the request received > by the UAS) is > added in section 16.6 of 3261 as the request is > forwarded. At this > point in time, the lost information is in the previous > hi-entry when the > outgoing request is sent. [/MB] > > > What has been lost is the current target of the request: > > [MB] Right - at which point in my mind, it's no longer > the current > target ;) Maybe we call it "lost". [/MB] > > > > Current target > > The current target of an initial request for a dialog > or standalone > request is the name or address to which the request is > targeted, i.e. > either the initial target inserted in the Request-URI > by the UAC that > originates the request, or when a retarget occurred, > the target > provided in that retarget operation. Reroute and > translation > operations never change the current target. > > > [MB] I don't think this definition fits what you want - > i.e., if there > is no retargeting, then none of the hi-entries are > tagged - i.e., you > won't have your concept of current. The way it works is > that if no > hi-entries are tagged, then you know that there was no > retargeting, thus > you know the request-uri has not been lost. [/MB] > > > This defintion only makes sense when the following > definitions are used: > > Name: > > A name is a moniker for an entity which refers to it > in a way which > > reveals nothing about where it is in a network. In > SIP, tel URI > > which doesn't represent the location of the entity is > a name. > > > Address: > > An address is an identifier for an entity which > describes it by its > > location on the network. In SIP, the SIP URI itself > is a form of > > address because the host part of the URI, the only > mandatory part of > > the URI besides the scheme itself, indicates the > location of a SIP > > server that can be used to handle the request. > > Route: > > Finally, a route is a sequence of SIP entities > (including the UA > itself!) which are > > traversed in order to forward a request to an address > or name. > > Retarget (other term might be needed, as this is highly > confusing): > > A Request-URI rewrite operation that changes the > target identity of > the request. > > Reroute (other term might be needed): > > A Request-URI rewrite operation that does not change > the current > target of the request, but determines the route/next > hop taken to > reach the target-identity. > > /Hans Erik > > Mary Barnes wrote: > > So, by "target-uri concept" are you referring to the > solution in the > > current target-uri draft or the application usage as > such in the > > target-uri document (which is what I was referring > to)? > > > > Yes, the problem is that SIP doesn't differentiate the > various > > mechanisms by which a request-URI may be changed, > which is what some > > of the updated text in 4244bis is trying to do and why > we need precise > > > terms. I think we all agree that. > > > > I honestly don't care what we call the tag, as long as > we're clear > > about the functionality. > > > > Mary. > > > > -----Original Message----- > > From: Hans Erik van Elburg > [mailto:ietf.hanserik@gmail.com] > > Sent: Wednesday, March 11, 2009 4:40 PM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Shida Schubert; sip@ietf.org > > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > The target-uri concept when defined properly is > entirely application > > agnostic. > > > > When one uses History-Info or another header as a > vehicle for this > > information then it still can be considered > application agnostic as > > any application can use this information as it likes. > > > > From SIP perspective all the Request-URI rewrites > look the same, that > > > is what brought us discussing this in the first place. > > > > /Hans Erik > > > > Mary Barnes wrote: > > > >> And, I think the big issue with the terminology is > that 4244bis is > >> application agnostic, so it is tagging what happens > to the URIs > >> (why/how the specific URI was overwritten). Whereas, > specific > >> applications can derive information, such as what > "is" the real > >> "target" for the request, from the History-Info > header. So, IMHO, > >> it's a matter of the target-uri document specifying > that the last > >> entry tagged by whatever name we come up with "is" > the real "target" > >> for the request. I believe it's up to the > applications to describe > >> how they make use of the History-Info and not for the > History-Info to > > >> describe how applications can use it. History-Info > purely reflects > >> what happened from a SIP Protocol perspective and > should not imply > >> any > >> > > > > > >> application semantics. Indeed the intent of section 5 > of 4244 was to > >> inform the applications how they should decribe their > usage of the > >> header. > >> > >> Mary. > >> Note: I changed the subject to hopefully make this > topic easier to > >> keep track of. > >> > >> > --------------------------------------------------------------------- > >> - > >> -- > >> *From:* Hans Erik van Elburg > [mailto:ietf.hanserik@gmail.com] > >> *Sent:* Wednesday, March 11, 2009 3:59 AM > >> *To:* Shida Schubert > >> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) > >> *Subject:* Re: [Sip] Fwd: I-D > >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > >> > >> One of the problems that made the discussion quite > tedious is the > >> complete inversed meaning of the terms "retarget" and > "reroute" > >> between 4244bis and target-uri factions have. > >> > >> Conclusion was that the terminology need to be > properly defined and > >> some attempt was made to start such activity. > >> > >> On 3. I have strong concerns when we start tagging > the URI as to how > >> they come about "retarget"/"mapped conficuration" > etc. It is better > >> to > >> > > > > > >> embellish them with a tag that just represents there > meaning for > >> example "istarget" or "hop". For the following > reasons: > >> 1. It is much more intuitive for the user of this > information, its > >> meaning can basically be guessed. > >> 2. Such meaning also probably survives application in > other problem > >> spaces that we had not foreseen when introducing the > concept. > >> > >> The solution that is described now in the target-URI > delivery draft > >> is not yet complete, it does not solve the freephone > use case for > >> example and in its current form it will deliver > exactly the same > >> target-URI as that which would be delivered by the > P-Called-Party-ID > > >> header. Contrary to what the draft says. So some work > is needed > still. > >> > >> /Hans Erik van Elburg > >> > >> > >> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > >> > wrote: > >> > >> > >> We have submitted the updated target-uri draft > based on the > >> > > comments > > > >> submitted to the list and comments received at > IETF73. > >> > >> I have taken over as editor as Jonathan didn't > have the cycles to > > >> update the draft, with Francois, Christer and > Hans Erick as > >> additional > >> co-authors and great deal of help from Mary. > >> > >> The following summarizes the changes made to the > target-uri > >> > > document > > > >> 1. Added use-case for toll-free number back > >> 2. Added definition of "retarget" operation. > >> 3. Removed a reference to URN > >> 4. Added a text discussing the difference to > P-Called-Party-Id > >> 5. Changed parameter name from "target" to > "istarget" > >> > >> Note, that the target-uri document still contains > the normative > >> text for the > >> History-Info header. > >> > >> In addition, Mary (with Francois as co-author) > has submitted a > >> rfc4244bis, with the following changes: > >> 1. Incorporated the normative aspects of the > target-uri document > >> into the existing normative text in RFC 4244 - > the functionality > >> > > is > > > >> virtually identical (as is some of the text) as > the HI based > >> > > solution > > > >> described in the target-uri document. It's > important that the > >> solution > >> be integrated into RFC 4244 as it MUST work and > be based on the > >> normative > >> aspects of RFC 4244. > >> 2. Added the use cases from target-uri the the > summary > >> in the overview of rfc4244bis. > >> 3. Added an additional requirement to capture the > "target-uri" > >> information. > >> 4. Fixed an error in the RFC 4244 ABNF and added > "retarget" > >> > > parameter. > > > >> 5. Added a more simplified example. > >> > >> > >> We had some very long offline exchanges as to the > best way > >> forward > >> > > and > > > >> remaining work for both documents. > >> > >> Some of the issues identified are: > >> > >> ::Issues:: > >> 1. Should we remove the normative text from > target-uri and > >> > > progress > > > >> 4244bis along with the target-uri document > to meet the > >> chartered > >> SIP WG milestone? > >> > >> > >> 2. Name of the parameter. > >> At the last meeting, parameter "target" was > said > >> > > inappropriate > > > >> because voicemail-uri spec already defines > a parameter > >> > > called > > > >> "target" which also can be found in > hi-entry, thus > >> > > potentially > > > >> causing confusion. > >> > >> Currently the target-uri draft uses > "istarget" and 4244bis > >> > > uses > > > >> "retarget" but we could never come to > >> a consensus on what name is appropriate. > Other suggestions > >> > > have > > > >> included the following: > >> "target-identity" (someone didn't like that > "identity" is > >> also a SIP header) > >> "reg-uri" (can be paired with "mapped-uri" > for item 3 > >> > > below) > > > >> "aor" > >> "jibberish" > >> etc. > >> > >> One reason this is so difficult relates to > the problem > >> statement in target-uri in that > >> RFC 3261 doesn't differentiate the > mechanism by which the > >> > > new > > > >> (target) Request-URI is selected. Another > issue is that > >> some of the terminology in > >> RFC 3261 is overloaded - e.g., "forwarding" > refers both to > a > >> Proxy > >> which does not have responsibility for the > domain of the > >> request-URI > >> in the incoming request, thus the proxy > just "forwards" the > >> request to > >> the next hop AND "forwarding" is used to > describe the > >> process whereby > >> the outgoing request is built and > "forwarded" to the next > >> hop at which > >> point the proxy does not know how the new > request-uri was > >> selected. > >> RFC 4244 has attempted to clarify the terms > and attempts to > >> use "forward" > >> in the context of the former situation and > "retarget" for > >> the case whereby > >> a proxy is responsible for the domain and > thus can use a > >> number of > >> mechanism to select the new target for the > request - e.g., > a > >> REGISTRAR, > >> configured data, etc. > >> > >> 3. Related to the last point in item 2 above, > it has been > >> proposed that > >> we differentiate the hi-entries even more > by defining > >> separate parameters > >> for registered and configured/mapped > contacts. > >> Currently when the R-URI is translated to a > URI which is > >> either derived > >> from location service lookup(registered by > UA) or from > >> > > mapping > > > >> table, there is no differentiation as to how > the URI was > >> derived once it is > >> added to the list of potential targets. > >> > >> The general consensus of the authors of the > two documents > was > >> that it may > >> be useful for some services to have the > hi-entries tagged > >> with the > >> more specific information. > >> > >> And, of course, this gets us into another > naming contest. In > >> the end, the naming > >> is not so important as long as the term > isn't too overloaded > >> and it is defined > >> precisely in the document(s). > >> > >> We would appreciate WG feedback on these issues > and any other > >> comments on > >> the two documents prior to IETF-74. > >> > >> Regards, > >> Shida and Mary. > >> > >> > >> > >> Begin forwarded message: > >> > >>> *From: *Internet-Drafts@ietf.org > >>> > > > > > >>> *Date: *March 10, 2009 2:30:01 AM JST > >>> *To: *i-d-announce@ietf.org > > >>> *Subject: **I-D > >>> > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * > >>> *Reply-To: *internet-drafts@ietf.org > >>> > >>> > >>> A New Internet-Draft is available from the > on-line > >>> > > Internet-Drafts > > > >>> directories. > >>> > >>> > >>> Title > >>> : Delivery of Request-URI Targets to User Agents > >>> Author(s) > >>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. > Audet, S. > Schubert > >>> Filename : > draft-rosenberg-sip-target-uri-delivery-01.txt > >>> Pages > >>> : 16 > >>> Date > >>> : 2009-3-9 > >>> > >>> When a Session Initiation Protocol (SIP) proxy > receives a > request > >>> targeted at a URI identifying a user or > resource it is > >>> > > responsible > > > >>> for, the proxy translates the URI to a > registered or > configured > >>> contact URI of an agent representing that user > or resource. > >>> In > >>> > > the > > > >>> process, the original URI is removed from the > request. > >>> Numerous use > >>> cases have arisen which require this > information to be > >>> > > delivered to > > > >>> the user agent. This document describes these > use cases and > >>> defines > >>> an extension to the History-Info header field > which allows it > >>> > > to be > > > >>> used to support those cases. > >>> > >>> A URL for this Internet-Draft is: > >>> > >>> > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d > >>> e > >>> livery-01.txt > >>> > >>> Internet-Drafts are also available by anonymous > FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME > compliant mail reader > >>> implementation to automatically retrieve the > ASCII version of > the > >>> Internet-Draft. > >>> > >> Content-Type: text/plain
Content-ID: > >> <2009-3-9102756.I-D@ietf.org > > > > >> >

> >> > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > > >>> > https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: > http://www.ietf.org/shadow.html > >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >> _______________________________________________ > >> Sip mailing list > https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP > Protocol > >> Use sip-implementors@cs.columbia.edu > >> for > questions on > >> current > >> > > sip > > > >> Use sipping@ietf.org > for new > >> developments on the application of sip > >> > >> > >> > > > > --0015174be732a3eec90464eb8327 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable But that does not solve the freephone service use case. Fr= eephone represents a use case where the R-URI is replaced with an AoR of us= er B - not with the contact of user B.

A calls Bfreephonenumber rou= ted the B (AOR) routed to B's contact.

The target-uri draft is interested in obtaining: Bfreephonenumber as th= at is what A used to reach B.

So what we like to see that B UA recei= ves is something like
=A0=A0=A0 H-I:=A0 Bfreephone; "istarget"= ,\
=A0=A0=A0 =A0=A0=A0 B,\
=A0=A0=A0 =A0=A0=A0 contact-B

So you want= to get Bfreephonenumber and not B.

In certain situations you are also interested in B, I guess that=A0 PBX's would interested in that to deliver to the correct user. We could distinguish them like:
=A0=A0=A0 H-I:=A0 Bfreephone; "istarget",\
=A0=A0=A0 =A0=A0=A0 B,"aor"\
=A0=A0=A0 =A0=A0=A0 contact-B

BR,
/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 12:08 PM, Elwell= , John <joh= n.elwell@siemens.com> wrote:
If 'istarget' is used only to identify the value that was overwritt= en in
the Request-URI by a contact URI, an alternative approach would be to
flag the contact URI H-I entry as 'iscontact'. Then the UAS would j= ust
need to look for the most recent H-I entry that is not marked
'iscontact'.

John


________________________________

=A0 =A0 =A0 =A0From: sip-bounces@i= etf.org [mailto:sip-bounces@iet= f.org] On
Behalf Of Hans Erik van Elburg
=A0 =A0 =A0 =A0Sent: 12 March 2009 08:35
=A0 =A0 =A0 =A0To: Mary Barnes
=A0 =A0 =A0 =A0Cc: sip@ietf.org
=A0 =A0 =A0 =A0Subject: Re: [Sip] Terminology (was RE: Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


=A0 =A0 =A0 =A0Yes, because you are using the 3261 use of target and the 4244bis introduced definition of retarget. I thought it was clear that
we need other words as those definitions don't match the target-uri
drafts use of the terms. Also they do not suffice to provide a solution
for the use cases in the target-uri draft.

=A0 =A0 =A0 =A0The 3261 text you refer to is exactly about the case where = the
home proxy overwrites the Request-URI with a new target. This target is
teh registered contact address. And hence this would be what target-uri
calls a hop or a route. This case and this is where it gets confusing is not a "retarget" in the target-uri draft use of the term.

=A0 =A0 =A0 =A0The target-uri draft states:

=A0 =A0 =A0 =A0 =A0 "To avoid confusion, we
=A0 =A0 =A0 =A0 =A0 refer to a SIP URI that is an address for a user or re= source
as a
=A0 =A0 =A0 =A0 =A0 "target" and a SIP URI that is a hop for rea= ching that user
as a

=A0 =A0 =A0 =A0 =A0 "hop".


=A0 =A0 =A0 =A0Apparently that does not suffice to avoid confusion.

=A0 =A0 =A0 =A0As for the tagging, speaking about the solution before agre= eing
on the terminology and the problem it should solve is meaningless.

=A0 =A0 =A0 =A0/Hans Erik van Elburg



=A0 =A0 =A0 =A0On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes
<mary.barnes@nortel.com>= ; wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Responses below [MB].


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-----Original Message-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0From: Hans Erik van Elburg
[mailto:ietf.hanserik@gmail.com<= /a>]

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sent: Wednesday, March 11, 2009 6:42 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To: Barnes, Mary (RICH2:AR00)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cc: Shida Schubert; sip@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject: Re: Terminology (was RE: [Sip] Fwd= : I-D
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ACTION:draft-rosenberg-sip-target-uri-deliv= ery-01.txt


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I was talking about the concept.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The use cases only describe =A0cases where = the target-uri
(lets call that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0current target from now) has been lost when= an initial
request for a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dialog or standalone request arrives at the= UAS.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] And I think this is where the terminol= ogy confusion
starts - I
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0don't think of the "lost" tar= get-uri as being the
"current" target. In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my mind, the "current" target is = reflected by the last
hi-entry and the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request-uri in the incoming request at the = UAS. If the
entity that sent
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the request was the entity that added the l= ast hi-entry,
then the uri in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that hi-entry is the same as the request-UR= I in the SIP
request that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0arrives at the UAS. I refer to the "lo= st" uri as the one
that was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"retargeted" - that's the one= the UAS wants to pull from
the hi-entries
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in the incoming request. That hi-entry was = not the one
that was just
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0added by the entity that built the request = just received
by the UAS.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0That hi-entry is tagged with whatever name = we are going
to tag it with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BEFORE the request is forwarded (using the = term forward
per section 16.6
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of RFC 3261). =A0That tag is added once the= target set of
potential
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0candidates for the new request uri are dete= rmined in
section 16.5 of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03261 (with "target set" being a 3= 261 term), just before
the request is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0forwarded in section 16.6 to one of those t= argets. =A0A
new hi-entry
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(which will be the last hi-entry in the req= uest received
by the UAS) is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0added in section 16.6 of 3261 as the reques= t is
forwarded. =A0At this
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0point in time, the lost information is in t= he previous
hi-entry when the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0outgoing request is sent. [/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0What has been lost is the current target of= the request:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] Right - at which point in my mind, it&= #39;s no longer
the current
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target ;) Maybe we call it "lost"= . [/MB]



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Current target

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The current target of an initial reques= t for a dialog
or standalone
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request is the name or address to which= the request is
targeted, i.e.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0either the initial target inserted in t= he Request-URI
by the UAC that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0originates the request, or when a retar= get occurred,
the target
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0provided in that retarget operation. = =A0Reroute and
translation
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0operations never change the current tar= get.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] I don't think this definition fits= what you want -
i.e., if there
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is no retargeting, then none of the hi-entr= ies are
tagged - i.e., you
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0won't have your concept of current. The= way it works is
that if no
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hi-entries are tagged, then you know that t= here was no
retargeting, thus
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0you know the request-uri has not been lost.= [/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This defintion only makes sense when the fo= llowing
definitions are used:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Name:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A name is a moniker for an entity which= refers to it
in a way which

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reveals nothing about where it is in a = network. =A0In
SIP, tel URI

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0which doesn't represent the locatio= n of the entity is
a name.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Address:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0An address is an identifier for an enti= ty which
describes it by its

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0location on the network. =A0In SIP, the= SIP URI itself
is a form of

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0address because the host part of the UR= I, the only
mandatory part of

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the URI besides the scheme itself, indi= cates the
location of a SIP

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0server that can be used to handle the r= equest.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Route:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Finally, a route is a =A0 sequence of S= IP entities
(including the UA
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0itself!) which are

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 traversed in order to forward a request to= an address
or name.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Retarget (other term might be needed, as th= is is highly
confusing):

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A Request-URI rewrite operation that c= hanges the
target identity of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the request.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Reroute (other term might be needed):

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A Request-URI rewrite operation that d= oes not change
the current
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target of the request, but =A0 =A0 determin= es the route/next
hop taken to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reach the target-identity.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/Hans Erik

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mary Barnes wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> So, by "target-uri concept" = are you referring to the
solution in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> current target-uri draft or the applic= ation usage as
such in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> target-uri document (which is what I w= as referring
to)?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Yes, the problem is that SIP doesn'= ;t differentiate the
various
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> mechanisms by which a request-URI may = be changed,
which is what some
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> of the updated text in 4244bis is tryi= ng to do and why
we need precise

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> terms. I think we all agree that.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> I honestly don't care what we call= the tag, as long as
we're clear
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> about the functionality.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Mary.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> -----Original Message-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> From: Hans Erik van Elburg
[mailto:ietf.hanserik@gmail.com<= /a>]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Sent: Wednesday, March 11, 2009 4:40 P= M
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> To: Barnes, Mary (RICH2:AR00)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Cc: Shida Schubert; sip@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Subject: Re: Terminology (was RE: [Sip= ] Fwd: I-D
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> ACTION:draft-rosenberg-sip-target-uri-= delivery-01.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> The target-uri concept when defined pr= operly is
entirely application
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> agnostic.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> When one uses History-Info or another = header as a
vehicle for this
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> information then it still can be consi= dered
application agnostic as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> any application can use this informati= on as it likes.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0From SIP perspective all the Reques= t-URI rewrites
look the same, that

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> is what brought us discussing this in = the first place.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> /Hans Erik
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Mary Barnes wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> And, I think the big issue with th= e terminology is
that 4244bis is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> application agnostic, so it is tag= ging what happens
to the URIs
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> (why/how the specific URI was over= written). =A0Whereas,
specific
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> applications can derive informatio= n, such as what
"is" the real
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> "target" for the request= , from the History-Info
header. =A0 So, IMHO,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> it's a matter of the target-ur= i document specifying
that the last
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> entry tagged by whatever name we c= ome up with "is"
the real "target"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> for the request. =A0I believe it&#= 39;s up to the
applications to describe
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> how they make use of the History-I= nfo and not for the
History-Info to

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> describe how applications can use = it. =A0History-Info
purely reflects
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> what happened from a SIP Protocol = perspective and
should not imply
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> any
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> application semantics. Indeed the = intent of section 5
of 4244 was to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> inform the applications how they s= hould decribe their
usage of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> header.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> Mary.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> Note: I changed the subject to hop= efully make this
topic easier to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> keep track of.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
---------------------------------------------------------------------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> -
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> --
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> *From:* Hans Erik van Elburg
[mailto:ietf.hanserik@gmail.com<= /a>]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> *Sent:* Wednesday, March 11, 2009 = 3:59 AM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> *To:* Shida Schubert
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> *Subject:* Re: [Sip] Fwd: I-D
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> ACTION:draft-rosenberg-sip-target-= uri-delivery-01.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> One of the problems that made the = discussion quite
tedious is the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> complete inversed meaning of the t= erms "retarget" and
"reroute"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> between 4244bis and target-uri fac= tions have.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> Conclusion was that the terminolog= y need to be
properly defined and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> some attempt was made to start suc= h activity.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> On 3. I have strong concerns when = we start tagging
the URI as to how
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> they come about "retarget&quo= t;/"mapped conficuration"
etc. It is better
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> embellish them with a tag that jus= t represents there
meaning for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> example "istarget" or &q= uot;hop". For the following
reasons:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> 1. It is much more intuitive for t= he user of this
information, its
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> meaning can basically be guessed.<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> 2. Such meaning also probably surv= ives application in
other problem
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> spaces that we had not foreseen wh= en introducing the
concept.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> The solution that is =A0described = now in the target-URI
delivery draft
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> is not yet complete, it does not s= olve the freephone
use case for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> example and in its current form it= will deliver
exactly the same
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> target-URI as that which would be = delivered by the
P-Called-Party-ID

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> header. Contrary to what the draft= says. So some work
is needed
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> /Hans Erik van Elburg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> On Wed, Mar 11, 2009 at 7:13 AM, S= hida Schubert
<shida@ntt-at.com
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> <mailto:shida@ntt-at.com>> wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 We have submitted the upda= ted target-uri draft
based on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> comments
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 submitted to the list and = comments received at
IETF73.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 I have taken over as edito= r as Jonathan didn't
have the cycles to

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 update the draft, with Fra= ncois, Christer and
Hans Erick as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 additional
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 co-authors and great deal = of help from Mary.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 The following summarizes t= he changes made to the
target-uri
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> document
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 1. Added use-case for toll= -free number back
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 2. Added definition of &qu= ot;retarget" operation.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 3. Removed a reference to = URN
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 4. Added a text discussing= the difference to
P-Called-Party-Id
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 5. Changed parameter name = from "target" to
"istarget"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Note, that the target-uri = document still contains
the normative
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 text for the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 History-Info header.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 In addition, Mary (with Fr= ancois as co-author)
has submitted a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 rfc4244bis, with the follo= wing changes:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 1. Incorporated the normat= ive aspects of the
target-uri document
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 into the existing normativ= e text in RFC 4244 -
the functionality
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 virtually identical (as is= some of the text) as
the HI based
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> solution
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 described in the target-ur= i document. =A0It's
important that the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 solution
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 be integrated into RFC 424= 4 as it MUST work and
be based on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 normative
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 aspects of RFC 4244.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 2. =A0Added the use cases = from target-uri the the
summary
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 in the overview of rfc4244= bis.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 3. Added an additional req= uirement to capture the
"target-uri"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 information.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 4. Fixed an error in the R= FC 4244 ABNF and added
"retarget"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> parameter.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 5. Added a more simplified= example.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 We had some very long offl= ine exchanges as to the
best way
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> forward
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 remaining work for both do= cuments.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Some of the issues identif= ied are:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 ::Issues::
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A01. Should we remove= the normative text from
target-uri and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> progress
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 =A04244bis alo= ng with the target-uri document
to meet the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 chartered
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 SIP WG milesto= ne?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A02. Name of the para= meter.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 At the last me= eting, parameter "target" was
said
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> inappropriate
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 because voicem= ail-uri spec already defines
a parameter
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> called
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 "target&q= uot; which also can be found in
hi-entry, thus
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> potentially
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 causing confus= ion.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 Currently the = target-uri draft uses
"istarget" and 4244bis
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> uses
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 "retarget= " =A0but we could never come to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 a consensus on= what name is appropriate.
Other suggestions
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> have
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 included the f= ollowing:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 "target-i= dentity" (someone didn't like that
"identity" is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 also a SIP header)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 "reg-uri&= quot; =A0(can be paired with "mapped-uri"
for item 3
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> below)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 "aor"= ;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 "jibberis= h"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 etc.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 One reason thi= s is so difficult relates to
the problem
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 statement in target-uri in= that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 RFC 3261 doesn= 't differentiate the
mechanism by which the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> new
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 (target) Reque= st-URI is selected. =A0Another
issue is that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 some of the terminology in=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 RFC 3261 is ov= erloaded - e.g., "forwarding"
refers both to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Proxy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 which does not= have responsibility for the
domain of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 request-URI
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 in the incomin= g request, thus the proxy
just "forwards" the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 request to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 the next hop A= ND "forwarding" is used to
describe the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 process whereby
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 the outgoing r= equest is built and
"forwarded" to the next
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 hop at which
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 point the prox= y does not know how the new
request-uri was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 selected.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 RFC 4244 has a= ttempted to clarify the terms
and attempts to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 use "forward" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 in the context= of the former situation and
"retarget" for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 the case whereby
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 a proxy is res= ponsible for the domain and
thus can use a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 number of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 mechanism to s= elect the new target for the
request - e.g.,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 REGISTRAR,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 configured dat= a, etc.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A03. =A0Related to the la= st point in item 2 above,
it has been
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 proposed that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0 we differentia= te the hi-entries even more
by defining
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 separate parameters
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0for registered = and configured/mapped
contacts.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0Currently when = the R-URI is translated to a
URI which is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 either derived
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0from location s= ervice lookup(registered by
UA) or from
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> mapping
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0table, there is= no differentiation as to how
the URI was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 derived once it is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0added to the li= st of potential targets.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0The general con= sensus of the authors of the
two documents
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 that it may
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0be useful for s= ome services to have the
hi-entries tagged
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 with the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0more specific i= nformation.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0And, of course,= this gets us into another
naming contest. In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 the end, the naming
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0is not so impor= tant as long as the term
isn't too overloaded
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 and it is defined
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 =A0 =A0 =A0precisely in th= e document(s).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 We would appreciate WG fee= dback on these issues
and any other
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 comments on
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 the two documents prior to= IETF-74.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Shida and Mary.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Begin forwarded message: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 *From: *Internet-Drafts@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> <mailto:Internet-Drafts@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 *Date: *March 10, 2009= 2:30:01 AM JST
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 *To: *i-d-announce@ietf.org
<mailto:i-d-announce@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 *Subject: **I-D
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt *
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 *Reply-To: *internet-drafts@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 <mailto:internet-drafts@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 A New Internet-Draft i= s available from the
on-line
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Internet-Drafts
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 directories.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Title
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 : Delivery of Request-= URI Targets to User Agents
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Author(s)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 : J. Rosenberg, H. van= Elburg, C. Holmberg, F.
Audet, S.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Schubert
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Filename :
draft-rosenberg-sip-target-uri-delivery-01.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Pages
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 : 16
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Date
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 : 2009-3-9
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 When a Session Initiat= ion Protocol (SIP) proxy
receives a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 targeted at a URI = identifying a user or
resource it is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> responsible
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 for, the proxy tra= nslates the URI to a
registered or
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0configured
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 contact URI of an = agent representing that user
or resource.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> In
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 process, the origi= nal URI is removed from the
request.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0Numerous use
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 cases have arisen = which require this
information to be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> delivered to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 the user agent. = =A0This document describes these
use cases and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 defines
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 an extension to th= e History-Info header field
which allows it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> to be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 =A0 used to support th= ose cases.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 A URL for this Interne= t-Draft is:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
http://www.ietf.org/internet-drafts/draft-rosenberg= -sip-target-uri-d
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> e
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> livery-01.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Internet-Drafts are al= so available by anonymous
FTP at:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 ftp://ftp.ietf.org/internet-dra= fts/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Below is the data whic= h will enable a MIME
compliant mail reader
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 implementation to auto= matically retrieve the
ASCII version of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Internet-Draft.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Content-Type: text/plain&l= t;BR>Content-ID:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 &lt;2009-3-9102756.I-D@ietf.org
<mailto:lt%3B2009-3-9102756.I-D@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> = =A0 =A0 <mailto:2009-3-91= 02756.I-D@ietf.org>&gt;<BR><BR>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 ______________________= _________________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 I-D-Announce mailing l= ist
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 I-D-Announce@ietf.org
<mailto:I-D-Announce@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
https://www.ietf.org/mailman/listinfo/i-d-announce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 Internet-Draft directo= ries:
http://www.ie= tf.org/shadow.html
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>> =A0 =A0 or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 __________________________= _____________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Sip mailing list
htt= ps://www.ietf.org/mailman/listinfo/sip
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 This list is for NEW devel= opment of the core SIP
Protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Use sip-implementors@cs.columbia.edu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 <mailto:sip-implementors@cs.columbia.edu&g= t; for
questions on
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> current
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> sip
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 Use sipping@ietf.org <mailto:sipping@ietf.org>
for new
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> =A0 =A0 developments on the applic= ation of sip
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>




--0015174be732a3eec90464eb8327-- From gao.yang.seu@hotmail.com Thu Mar 12 06:29:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0387F3A692A; Thu, 12 Mar 2009 06:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.113 X-Spam-Level: *** X-Spam-Status: No, score=3.113 tagged_above=-999 required=5 tests=[AWL=1.904, BAYES_00=-2.599, CN_BODY_512=0.757, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyRWvy6MZvaF; Thu, 12 Mar 2009 06:29:10 -0700 (PDT) Received: from bay0-omc3-s24.bay0.hotmail.com (bay0-omc3-s24.bay0.hotmail.com [65.54.246.224]) by core3.amsl.com (Postfix) with ESMTP id F2D943A685C; Thu, 12 Mar 2009 06:29:09 -0700 (PDT) Received: from BAY115-W32 ([65.54.250.132]) by bay0-omc3-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 06:29:48 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f61ba4a5-411e-40ac-9907-f2490f41711f_" X-Originating-IP: [117.88.170.62] From: gaoyang To: , Date: Thu, 12 Mar 2009 13:29:47 +0000 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2009 13:29:48.0114 (UTC) FILETIME=[9D579320:01C9A316] X-Mailman-Approved-At: Thu, 12 Mar 2009 06:36:25 -0700 Cc: sip@ietf.org, sipping@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [Sip] [Sipping] One chart //"UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:29:16 -0000 --_f61ba4a5-411e-40ac-9907-f2490f41711f_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit I am Gao. And comments inline. Date: Thu, 12 Mar 2009 12:48:57 +0100 From: christer.holmberg@ericsson.com To: gao.yang2@zte.com.cn CC: sip@ietf.org; sipping@ietf.org; gonzalo.camarillo@ericsson.com Subject: Re: [Sipping] One chart //"UPDATE during Re-INVITE" discussion Hi, If the UAC receives the 487 and can't fallback to the pre-reINVITE state, it sends a new re-INVITE with something that it DOES supports. That is also described in Gonzalo's draft, I belive. [Gao] I just mean that the UAC can only use the old dialog state by Gonzalo's draft. Do you think so? And Re-INVITE using the old dialog state can not be processed by UAS. It is a serious problem. And, you could have the same problem if the target refresh was done already in the re-INVITE/18x. If the UAC then sends CANCEL, and can't fall back, it will have to send a new re-INVITE. [Gao] If the target fresh is in Re-INVITE(and there is no F3/F4), the new dialog state is rejected by UAS. And F8 MUST uses old dialog state. It is clear. I also think it is bad practise to do a target refresh in a nested UPDATE, but that's a separate issue. [Gao] When UAC send Re-INVITE and UAS moves to a new access network while Re-INVITE in pending state, UAS will send the target refresh UPDATE. It is a real situation. Regards, Christer From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn] Sent: 12. maaliskuuta 2009 9:41 To: Christer Holmberg Cc: Gonzalo Camarillo; SIP; SIPPING Subject: : RE: One chart //"UPDATE during Re-INVITE" discussion Hi, I just mean that if we treat F3 as sub-transaction of F1, then after F7(ACK), UAC can discard refreshed dialog state in F3. And it may make the two parts can not communicate anymore in current dialog. And IMO, this is a counterevidence for treating all UPDATE(during Re-INVITE) as sub-transaction of Re-INVITE. Gao "Christer Holmberg" 2009-03-12 15:31 ռ , "SIP" , "SIPPING" "Gonzalo Camarillo" RE: One chart //"UPDATE during Re-INVITE" discussion In my opinion 487 should trigger whatever actions/rollback that any other non-200 response sent by the UAS would. Regards, Christer From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn] Sent: 12. maaliskuuta 2009 5:47 To: SIP; SIPPING Cc: Christer Holmberg; Gonzalo Camarillo Subject: One chart //"UPDATE during Re-INVITE" discussion UAC UAS | session established | |<===================>| | | | F1 re-INVITE (SDP) | |-------------------->| | F2 1xx-rel (SDP) | |<--------------------| | F3 UPDATE | |<--------------------| Target refreshing | F4 2xx UPT | |-------------------->| | | | F5/6 Cancel/200OK | |-------------------->| | F7 487 INV | |<--------------------| | F7 ACK | |-------------------->| | F8 re-INVITE (SDP) | |-------------------->| Using which dialog state F3/F4 is about target refreshing. And if UAC sends Cancel UAS sends 487. The first Re-INVITE is discarded. But if UAC sends another Re-INVITE, which dialog state should it use? I think is the one refreshed by F3. That's the merit of regarding UPDATE/200OK's atomicity. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _________________________________________________________________ Windows Live йҳ° MSN http://im.live.cn/ --_f61ba4a5-411e-40ac-9907-f2490f41711f_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit  
I am Gao. And comments inline.
 
Date: Thu, 12 Mar 2009 12:48:57 +0100
From: christer.holmberg@ericsson.com
To: gao.yang2@zte.com.cn
CC: sip@ietf.org; sipping@ietf.org; gonzalo.camarillo@ericsson.com
Subject: Re: [Sipping] One chart //"UPDATE during Re-INVITE" discussion

Hi,
 
If the UAC receives the 487 and can't fallback to the pre-reINVITE state, it sends a new re-INVITE with something that it DOES supports. That is also described in Gonzalo's draft, I belive.
 
[Gao] I just mean that the UAC can only use the old dialog state by Gonzalo's draft. Do you think so?
And Re-INVITE using the old dialog state can not be processed by UAS. It is a serious problem.
 
 
And, you could have the same problem if the target refresh was done already in the re-INVITE/18x. If the UAC then sends CANCEL, and can't fall back, it will have to send a new re-INVITE.
 
[Gao] If the target fresh is in Re-INVITE(and there is no F3/F4), the new dialog state is rejected by UAS. And F8 MUST uses old dialog state. It is clear.
 
I also think it is bad practise to do a target refresh in a nested UPDATE, but that's a separate issue.
 
[Gao] When UAC send Re-INVITE and UAS moves to a new access network while Re-INVITE in pending state, UAS will send the target refresh UPDATE. It is a real situation.
 
Regards,
 
Christer
 
From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: 12. maaliskuuta 2009 9:41
To: Christer Holmberg
Cc: Gonzalo Camarillo; SIP; SIPPING
Subject: : RE: One chart //"UPDATE during Re-INVITE" discussion


Hi,

I just mean that if we treat F3 as sub-transaction of F1, then after F7(ACK), UAC can discard refreshed dialog state in F3.

And it may make the two parts can not communicate anymore in current dialog.

And IMO, this is a counterevidence for treating all UPDATE(during Re-INVITE) as sub-transaction of Re-INVITE.

Gao




"Christer Holmberg" <christer.holmberg@ericsson.com> 2009-03-12 15:31
ռ
<gao.yang2@zte.com.cn>, "SIP" <sip@ietf.org>, "SIPPING" <sipping@ietf.org>
"Gonzalo Camarillo" <gonzalo.camarillo@ericsson.com>
RE: One chart  //"UPDATE during Re-INVITE" discussion





In my opinion 487 should trigger whatever actions/rollback that any other non-200 response sent by the UAS would.
 
Regards,
 
Christer

From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: 12. maaliskuuta 2009 5:47
To: SIP; SIPPING
Cc: Christer Holmberg; Gonzalo Camarillo
Subject: One chart //"UPDATE during Re-INVITE" discussion


     UAC                   UAS
      | session established |
      |<===================>|
      |                     |
      | F1  re-INVITE ( SDP) |
      |-------------------->|
      | F2 1xx-rel (SDP)    |
      |<--------------------|
      | F3   UPDATE         |
      |<--------------------| Target refreshing
      | F4 2xx UPT          |
      |-------------------->|
      |                     |
      | F5/6 Cancel/200OK   |
      |-------------------->|
      | F7    487 INV       |
      |<--------------------|
      | F7     ACK          |
      |-------------------->|
      | F8  re-INVITE (SDP) |
      |-------------------->| Using which dialog state

F3/F4 is about target refreshing.

And if UAC sends Cancel UAS sends 487. The first Re-INVITE is discarded.

But if UAC sends another Re-INVITE, which dialog state should it use?

I think is the one refreshed by F3. That's the merit of regarding UPDATE/200OK's atomicity.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

΢ͼʵʱ·ΪʡIJʱ䣡 鿴 --_f61ba4a5-411e-40ac-9907-f2490f41711f_-- From gao.yang.seu@hotmail.com Thu Mar 12 06:35:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B502F3A68FD; Thu, 12 Mar 2009 06:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.073 X-Spam-Level: *** X-Spam-Status: No, score=3.073 tagged_above=-999 required=5 tests=[AWL=1.732, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLC4R6PM4q6O; Thu, 12 Mar 2009 06:35:39 -0700 (PDT) Received: from bay0-omc1-s28.bay0.hotmail.com (bay0-omc1-s28.bay0.hotmail.com [65.54.246.100]) by core3.amsl.com (Postfix) with ESMTP id 07E9C3A6868; Thu, 12 Mar 2009 06:35:39 -0700 (PDT) Received: from BAY115-W52 ([65.54.250.152]) by bay0-omc1-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 06:36:16 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_2cb9de26-3d06-45d8-9ba0-44155d6f534d_" X-Originating-IP: [117.88.170.62] From: gaoyang To: , , , Date: Thu, 12 Mar 2009 13:36:16 +0000 Importance: Normal In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A10B4A05310@mbx02.citservers.local> References: <9B2A061A1137254BBE4F4B2CD843646A10B4A05310@mbx02.citservers.local> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2009 13:36:16.0891 (UTC) FILETIME=[85123CB0:01C9A317] X-Mailman-Approved-At: Thu, 12 Mar 2009 06:36:55 -0700 Subject: Re: [Sip] [Sipping] One chart //"UPDATE during Re-INVITE" discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:35:44 -0000 --_2cb9de26-3d06-45d8-9ba0-44155d6f534d_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi, I have same thought about it as yours. But in Ganzalo's draft, the new dialog state MUST be discarded by 4xx of Re-INVITE. The main branching is about the relationship of Re-INVITE and UPDATE. I have seen your supporting of view 2. Abd we need more people to show their standpoint. Gao From: brett@broadsoft.com To: gao.yang2@zte.com.cn; sip@ietf.org; sipping@ietf.org Date: Thu, 12 Mar 2009 04:57:06 -0700 Subject: Re: [Sipping] [Sip] One chart //"UPDATE during Re-INVITE" discussion Data (like Contact, Session-Expires, and etcetera) that was successfully updated by F3/F4 still apply after F7. Thus F8 data should reflect (and can attempt to modify) adjustments made during F3/F4. From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of gao.yang2@zte.com.cn Sent: Wednesday, March 11, 2009 11:47 PM To: SIP; SIPPING Cc: Gonzalo Camarillo; Christer Holmberg Subject: [Sip] One chart //"UPDATE during Re-INVITE" discussion UAC UAS | session established | |<===================>| | | | F1 re-INVITE (SDP) | |-------------------->| | F2 1xx-rel (SDP) | |<--------------------| | F3 UPDATE | |<--------------------| Target refreshing | F4 2xx UPT | |-------------------->| | | | F5/6 Cancel/200OK | |-------------------->| | F7 487 INV | |<--------------------| | F7 ACK | |-------------------->| | F8 re-INVITE (SDP) | |-------------------->| Using which dialog state F3/F4 is about target refreshing. And if UAC sends Cancel UAS sends 487. The first Re-INVITE is discarded. But if UAC sends another Re-INVITE, which dialog state should it use? I think is the one refreshed by F3. That's the merit of regarding UPDATE/200OK's atomicity. _________________________________________________________________ MSN ħ飬ıĶԻʱ http://im.live.cn/emoticons/ --_2cb9de26-3d06-45d8-9ba0-44155d6f534d_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit  
Hi,
 
I have same thought about it as yours.
 
But in Ganzalo's draft, the new dialog state MUST be discarded by 4xx of Re-INVITE.

The main branching is about the relationship of Re-INVITE and UPDATE. I have seen your supporting of view 2. Abd we need more people to show their standpoint.
 
Gao
 
From: brett@broadsoft.com
To: gao.yang2@zte.com.cn; sip@ietf.org; sipping@ietf.org
Date: Thu, 12 Mar 2009 04:57:06 -0700
Subject: Re: [Sipping] [Sip] One chart //"UPDATE during Re-INVITE" discussion

Data (like Contact, Session-Expires, and etcetera) that was successfully updated by F3/F4 still apply after F7.  Thus F8 data should reflect (and can attempt to modify) adjustments made during F3/F4.

 

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of gao.yang2@zte.com.cn
Sent: Wednesday, March 11, 2009 11:47 PM
To: SIP; SIPPING
Cc: Gonzalo Camarillo; Christer Holmberg
Subject: [Sip] One chart //"UPDATE during Re-INVITE" discussion

 


      UAC                   UAS
       | session established |
       |<===================>|
       |                     |
       | F1  re-INVITE (SDP) |
       |-------------------->|
&nbs p;      | F2 1xx-rel (SDP)    |
       |<--------------------|
       | F3   UPDATE         |
       |<--------------------| Target refreshing
       | F4 2xx UPT          |
       |-------------------->|
       |                     |
       | F5/6 Cancel/200OK   |
       |-------------------->|
       | F7    487 INV       |
       |<--------------------|
       | F7     ACK          |
       |-------------------->|
       | F8  re-INVITE (SDP) |
       |-------------------->| Using which dialog state

F3/F4 is about target refreshing.

And if UAC sends Cancel UAS sends 487. The first Re-INVITE is discarded.

But if UAC sends another Re-INVITE, which dialog state should it use?

I think is the one refreshed by F3. That's the merit of regarding UPDATE/200OK's atomicity. 

 

MSN ܣ MSN ȫȶ ھأ --_2cb9de26-3d06-45d8-9ba0-44155d6f534d_-- From john.elwell@siemens.com Thu Mar 12 06:30:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE733A692A for ; Thu, 12 Mar 2009 06:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[AWL=-2.018, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, MANGLED_DELIVY=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmLXJsUJhaR9 for ; Thu, 12 Mar 2009 06:30:14 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id DA4A33A6837 for ; Thu, 12 Mar 2009 06:30:12 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGE00518AVAIT@siemenscomms.co.uk> for sip@ietf.org; Thu, 12 Mar 2009 13:30:47 +0000 (GMT) Date: Thu, 12 Mar 2009 13:30:43 +0000 From: "Elwell, John" In-reply-to: <9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> To: Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001A27C50@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C9A316.BF9DD2CC" Thread-Topic: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjEo9cACSfdpORRgqN7inoq6qTugABBxGA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> X-Mailman-Approved-At: Thu, 12 Mar 2009 06:37:41 -0700 Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:30:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A316.BF9DD2CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hans Erik, =20 The way I interpreted the 01 draft, you would not get the freephone number anyway. If that is a requirement, then I accept my suggestion won't suffice. =20 John ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 12 March 2009 12:57 To: Elwell, John Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 But that does not solve the freephone service use case. Freephone represents a use case where the R-URI is replaced with an AoR of user B - not with the contact of user B.=20 =09 A calls Bfreephonenumber routed the B (AOR) routed to B's contact. =09 The target-uri draft is interested in obtaining: Bfreephonenumber as that is what A used to reach B. =09 So what we like to see that B UA receives is something like H-I: Bfreephone; "istarget",\ B,\ contact-B =09 So you want to get Bfreephonenumber and not B. =09 In certain situations you are also interested in B, I guess that PBX's would interested in that to deliver to the correct user. We could distinguish them like: H-I: Bfreephone; "istarget",\ B,"aor"\ contact-B =09 BR, /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John wrote: =09 If 'istarget' is used only to identify the value that was overwritten in the Request-URI by a contact URI, an alternative approach would be to flag the contact URI H-I entry as 'iscontact'. Then the UAS would just need to look for the most recent H-I entry that is not marked 'iscontact'. =09 John =09 =09 ________________________________ =09 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 12 March 2009 08:35 To: Mary Barnes Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 Yes, because you are using the 3261 use of target and the 4244bis introduced definition of retarget. I thought it was clear that we need other words as those definitions don't match the target-uri drafts use of the terms. Also they do not suffice to provide a solution for the use cases in the target-uri draft. =09 The 3261 text you refer to is exactly about the case where the home proxy overwrites the Request-URI with a new target. This target is teh registered contact address. And hence this would be what target-uri calls a hop or a route. This case and this is where it gets confusing is not a "retarget" in the target-uri draft use of the term. =09 The target-uri draft states: =09 "To avoid confusion, we refer to a SIP URI that is an address for a user or resource as a "target" and a SIP URI that is a hop for reaching that user as a =09 "hop". =09 =09 Apparently that does not suffice to avoid confusion. =09 As for the tagging, speaking about the solution before agreeing on the terminology and the problem it should solve is meaningless. =09 /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes wrote: =09 =09 Responses below [MB]. =09 =09 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] =09 Sent: Wednesday, March 11, 2009 6:42 PM To: Barnes, Mary (RICH2:AR00) Cc: Shida Schubert; sip@ietf.org Subject: Re: Terminology (was RE: [Sip] Fwd: I-D =09 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 I was talking about the concept. =09 The use cases only describe cases where the target-uri (lets call that current target from now) has been lost when an initial request for a dialog or standalone request arrives at the UAS. =09 [MB] And I think this is where the terminology confusion starts - I don't think of the "lost" target-uri as being the "current" target. In my mind, the "current" target is reflected by the last hi-entry and the request-uri in the incoming request at the UAS. If the entity that sent the request was the entity that added the last hi-entry, then the uri in that hi-entry is the same as the request-URI in the SIP request that arrives at the UAS. I refer to the "lost" uri as the one that was "retargeted" - that's the one the UAS wants to pull from the hi-entries in the incoming request. That hi-entry was not the one that was just added by the entity that built the request just received by the UAS. That hi-entry is tagged with whatever name we are going to tag it with BEFORE the request is forwarded (using the term forward per section 16.6 of RFC 3261). That tag is added once the target set of potential candidates for the new request uri are determined in section 16.5 of 3261 (with "target set" being a 3261 term), just before the request is forwarded in section 16.6 to one of those targets. A new hi-entry (which will be the last hi-entry in the request received by the UAS) is added in section 16.6 of 3261 as the request is forwarded. At this point in time, the lost information is in the previous hi-entry when the outgoing request is sent. [/MB] =09 =09 What has been lost is the current target of the request: =09 [MB] Right - at which point in my mind, it's no longer the current target ;) Maybe we call it "lost". [/MB] =09 =09 =09 Current target =09 The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. =09 =09 [MB] I don't think this definition fits what you want - i.e., if there is no retargeting, then none of the hi-entries are tagged - i.e., you won't have your concept of current. The way it works is that if no hi-entries are tagged, then you know that there was no retargeting, thus you know the request-uri has not been lost. [/MB] =09 =09 This defintion only makes sense when the following definitions are used: =09 Name: =09 A name is a moniker for an entity which refers to it in a way which =09 reveals nothing about where it is in a network. In SIP, tel URI =09 which doesn't represent the location of the entity is a name. =09 =09 Address: =09 An address is an identifier for an entity which describes it by its =09 location on the network. In SIP, the SIP URI itself is a form of =09 address because the host part of the URI, the only mandatory part of =09 the URI besides the scheme itself, indicates the location of a SIP =09 server that can be used to handle the request. =09 Route: =09 Finally, a route is a sequence of SIP entities (including the UA itself!) which are =09 traversed in order to forward a request to an address or name. =09 Retarget (other term might be needed, as this is highly confusing): =09 A Request-URI rewrite operation that changes the target identity of the request. =09 Reroute (other term might be needed): =09 A Request-URI rewrite operation that does not change the current target of the request, but determines the route/next hop taken to reach the target-identity. =09 /Hans Erik =09 Mary Barnes wrote: > So, by "target-uri concept" are you referring to the solution in the > current target-uri draft or the application usage as such in the > target-uri document (which is what I was referring to)? > > Yes, the problem is that SIP doesn't differentiate the various > mechanisms by which a request-URI may be changed, which is what some > of the updated text in 4244bis is trying to do and why we need precise =09 > terms. I think we all agree that. > > I honestly don't care what we call the tag, as long as we're clear > about the functionality. > > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 4:40 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > The target-uri concept when defined properly is entirely application > agnostic. > > When one uses History-Info or another header as a vehicle for this > information then it still can be considered application agnostic as > any application can use this information as it likes. > > From SIP perspective all the Request-URI rewrites look the same, that =09 > is what brought us discussing this in the first place. > > /Hans Erik > > Mary Barnes wrote: > >> And, I think the big issue with the terminology is that 4244bis is >> application agnostic, so it is tagging what happens to the URIs >> (why/how the specific URI was overwritten). Whereas, specific >> applications can derive information, such as what "is" the real >> "target" for the request, from the History-Info header. So, IMHO, >> it's a matter of the target-uri document specifying that the last >> entry tagged by whatever name we come up with "is" the real "target" >> for the request. I believe it's up to the applications to describe >> how they make use of the History-Info and not for the History-Info to =09 >> describe how applications can use it. History-Info purely reflects >> what happened from a SIP Protocol perspective and should not imply >> any >> > > >> application semantics. Indeed the intent of section 5 of 4244 was to >> inform the applications how they should decribe their usage of the >> header. >> >> Mary. >> Note: I changed the subject to hopefully make this topic easier to >> keep track of. >> >> =09 --------------------------------------------------------------------- >> - >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Wednesday, March 11, 2009 3:59 AM >> *To:* Shida Schubert >> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) >> *Subject:* Re: [Sip] Fwd: I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >> >> One of the problems that made the discussion quite tedious is the >> complete inversed meaning of the terms "retarget" and "reroute" >> between 4244bis and target-uri factions have. >> >> Conclusion was that the terminology need to be properly defined and >> some attempt was made to start such activity. >> >> On 3. I have strong concerns when we start tagging the URI as to how >> they come about "retarget"/"mapped conficuration" etc. It is better >> to >> > > >> embellish them with a tag that just represents there meaning for >> example "istarget" or "hop". For the following reasons: >> 1. It is much more intuitive for the user of this information, its >> meaning can basically be guessed. >> 2. Such meaning also probably survives application in other problem >> spaces that we had not foreseen when introducing the concept. >> >> The solution that is described now in the target-URI delivery draft >> is not yet complete, it does not solve the freephone use case for >> example and in its current form it will deliver exactly the same >> target-URI as that which would be delivered by the P-Called-Party-ID =09 >> header. Contrary to what the draft says. So some work is needed still. >> >> /Hans Erik van Elburg >> >> >> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > > wrote: >> >> >> We have submitted the updated target-uri draft based on the >> > comments > >> submitted to the list and comments received at IETF73. >> >> I have taken over as editor as Jonathan didn't have the cycles to =09 >> update the draft, with Francois, Christer and Hans Erick as >> additional >> co-authors and great deal of help from Mary. >> >> The following summarizes the changes made to the target-uri >> > document > >> 1. Added use-case for toll-free number back >> 2. Added definition of "retarget" operation. >> 3. Removed a reference to URN >> 4. Added a text discussing the difference to P-Called-Party-Id >> 5. Changed parameter name from "target" to "istarget" >> >> Note, that the target-uri document still contains the normative >> text for the >> History-Info header. >> >> In addition, Mary (with Francois as co-author) has submitted a >> rfc4244bis, with the following changes: >> 1. Incorporated the normative aspects of the target-uri document >> into the existing normative text in RFC 4244 - the functionality >> > is > >> virtually identical (as is some of the text) as the HI based >> > solution > >> described in the target-uri document. It's important that the >> solution >> be integrated into RFC 4244 as it MUST work and be based on the >> normative >> aspects of RFC 4244. >> 2. Added the use cases from target-uri the the summary >> in the overview of rfc4244bis. >> 3. Added an additional requirement to capture the "target-uri" >> information. >> 4. Fixed an error in the RFC 4244 ABNF and added "retarget" >> > parameter. > >> 5. Added a more simplified example. >> >> >> We had some very long offline exchanges as to the best way >> forward >> > and > >> remaining work for both documents. >> >> Some of the issues identified are: >> >> ::Issues:: >> 1. Should we remove the normative text from target-uri and >> > progress > >> 4244bis along with the target-uri document to meet the >> chartered >> SIP WG milestone? >> >> >> 2. Name of the parameter. >> At the last meeting, parameter "target" was said >> > inappropriate > >> because voicemail-uri spec already defines a parameter >> > called > >> "target" which also can be found in hi-entry, thus >> > potentially > >> causing confusion. >> >> Currently the target-uri draft uses "istarget" and 4244bis >> > uses > >> "retarget" but we could never come to >> a consensus on what name is appropriate. Other suggestions >> > have > >> included the following: >> "target-identity" (someone didn't like that "identity" is >> also a SIP header) >> "reg-uri" (can be paired with "mapped-uri" for item 3 >> > below) > >> "aor" >> "jibberish" >> etc. >> >> One reason this is so difficult relates to the problem >> statement in target-uri in that >> RFC 3261 doesn't differentiate the mechanism by which the >> > new > >> (target) Request-URI is selected. Another issue is that >> some of the terminology in >> RFC 3261 is overloaded - e.g., "forwarding" refers both to a >> Proxy >> which does not have responsibility for the domain of the >> request-URI >> in the incoming request, thus the proxy just "forwards" the >> request to >> the next hop AND "forwarding" is used to describe the >> process whereby >> the outgoing request is built and "forwarded" to the next >> hop at which >> point the proxy does not know how the new request-uri was >> selected. >> RFC 4244 has attempted to clarify the terms and attempts to >> use "forward" >> in the context of the former situation and "retarget" for >> the case whereby >> a proxy is responsible for the domain and thus can use a >> number of >> mechanism to select the new target for the request - e.g., a >> REGISTRAR, >> configured data, etc. >> >> 3. Related to the last point in item 2 above, it has been >> proposed that >> we differentiate the hi-entries even more by defining >> separate parameters >> for registered and configured/mapped contacts. >> Currently when the R-URI is translated to a URI which is >> either derived >> from location service lookup(registered by UA) or from >> > mapping > >> table, there is no differentiation as to how the URI was >> derived once it is >> added to the list of potential targets. >> >> The general consensus of the authors of the two documents was >> that it may >> be useful for some services to have the hi-entries tagged >> with the >> more specific information. >> >> And, of course, this gets us into another naming contest. In >> the end, the naming >> is not so important as long as the term isn't too overloaded >> and it is defined >> precisely in the document(s). >> >> We would appreciate WG feedback on these issues and any other >> comments on >> the two documents prior to IETF-74. >> >> Regards, >> Shida and Mary. >> >> >> >> Begin forwarded message: >> >>> *From: *Internet-Drafts@ietf.org >>> > > >>> *Date: *March 10, 2009 2:30:01 AM JST >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D >>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * >>> *Reply-To: *internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line >>> > Internet-Drafts > >>> directories. >>> >>> >>> Title >>> : Delivery of Request-URI Targets to User Agents >>> Author(s) >>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert >>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt >>> Pages >>> : 16 >>> Date >>> : 2009-3-9 >>> >>> When a Session Initiation Protocol (SIP) proxy receives a request >>> targeted at a URI identifying a user or resource it is >>> > responsible > >>> for, the proxy translates the URI to a registered or configured >>> contact URI of an agent representing that user or resource. >>> In >>> > the > >>> process, the original URI is removed from the request. >>> Numerous use >>> cases have arisen which require this information to be >>> > delivered to > >>> the user agent. This document describes these use cases and >>> defines >>> an extension to the History-Info header field which allows it >>> > to be > >>> used to support those cases. >>> >>> A URL for this Internet-Draft is: >>> >>> =09 http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d >>> e >>> livery-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> Content-Type: text/plain
Content-ID: >> <2009-3-9102756.I-D@ietf.org =20 =09 > =09 >> >

>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current >> > sip > >> Use sipping@ietf.org for new >> developments on the application of sip >> >> >> =09 =09 =09 =09 ------_=_NextPart_001_01C9A316.BF9DD2CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hans Erik,
 
The way I interpreted the 01 draft, you would not get = the=20 freephone number anyway. If that is a requirement, then I accept my = suggestion=20 won't suffice.
 
John

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: 12 March 2009=20 12:57
To: Elwell, John
Cc: = sip@ietf.org
Subject:=20 Re: [Sip] Terminology (was RE: Fwd:=20 = I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

But that does not solve the freephone service use case.=20 Freephone represents a use case where the R-URI is replaced with an = AoR of=20 user B - not with the contact of user B.

A calls = Bfreephonenumber=20 routed the B (AOR) routed to B's contact.

The target-uri draft = is=20 interested in obtaining: Bfreephonenumber as that is what A used to = reach=20 B.

So what we like to see that B UA receives is something=20 like
    H-I:  Bfreephone;=20 "istarget",\
       =20 B,\
        contact-B

So you = want to=20 get Bfreephonenumber and not B.

In certain situations you are = also=20 interested in B, I guess that  PBX's would interested in that to = deliver=20 to the correct user. We could distinguish them = like:
   =20 H-I:  Bfreephone; "istarget",\
    =    =20 B,"aor"\
        = contact-B

BR,/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 12:08 PM, Elwell, = John <john.elwell@siemens.com>=20 wrote:
If=20 'istarget' is used only to identify the value that was overwritten = in
the=20 Request-URI by a contact URI, an alternative approach would be = to
flag=20 the contact URI H-I entry as 'iscontact'. Then the UAS would = just
need to=20 look for the most recent H-I entry that is not=20 = marked
'iscontact'.

John


___________________________= _____

 =20      From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] = On
Behalf Of=20 Hans Erik van Elburg
       Sent: 12 March = 2009=20 08:35
       To: Mary Barnes
    =  =20  Cc: sip@ietf.org
  =  =20    Subject: Re: [Sip] Terminology (was RE:=20 Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


       Yes, because you = are using=20 the 3261 use of target and the
4244bis introduced definition of = retarget.=20 I thought it was clear that
we need other words as those = definitions=20 don't match the target-uri
drafts use of the terms. Also they do = not=20 suffice to provide a solution
for the use cases in the target-uri = draft.

       The 3261 text you refer to = is=20 exactly about the case where the
home proxy overwrites the = Request-URI=20 with a new target. This target is
teh registered contact address. = And=20 hence this would be what target-uri
calls a hop or a route. This = case and=20 this is where it gets confusing is
not a "retarget" in the = target-uri=20 draft use of the term.

       The = target-uri=20 draft states:

          "To avoid = confusion,=20 we
          refer to a SIP URI that is = an=20 address for a user or resource
as a
      =    =20 "target" and a SIP URI that is a hop for reaching that user
as=20 a

          "hop".


  =  =20    Apparently that does not suffice to avoid=20 confusion.

       As for the tagging, = speaking=20 about the solution before agreeing
on the terminology and the = problem it=20 should solve is meaningless.

       /Hans = Erik=20 van Elburg



       On Thu, Mar 12, = 2009 at=20 2:33 AM, Mary Barnes
<mary.barnes@nortel.com>=20 wrote:


             =20  Responses below [MB].


        =  =20      -----Original Message-----
    =  =20          From: Hans Erik van = Elburg
[mailto:ietf.hanserik@gmail.com]
<= BR> =20              Sent: Wednesday, = March 11,=20 2009 6:42 PM
              =  To:=20 Barnes, Mary (RICH2:AR00)
          =  =20    Cc: Shida Schubert; sip@ietf.org
    =    =20        Subject: Re: Terminology (was RE: [Sip] = Fwd:=20 I-D
             =20 =  ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


&n= bsp;=20              I was talking about = the=20 concept.

              =  The=20 use cases only describe  cases where the target-uri
(lets = call=20 that
              =  current=20 target from now) has been lost when an initial
request for = a
 =20              dialog or standalone = request=20 arrives at the UAS.

            =  =20  [MB] And I think this is where the terminology = confusion
starts -=20 I
               don't = think of=20 the "lost" target-uri as being the
"current" target. In
  =  =20            my mind, the "current" = target is=20 reflected by the last
hi-entry and the
      =  =20        request-uri in the incoming request at = the UAS.=20 If the
entity that sent
          =  =20    the request was the entity that added the last=20 hi-entry,
then the uri in
          =  =20    that hi-entry is the same as the request-URI in the=20 SIP
request that
            =  =20  arrives at the UAS. I refer to the "lost" uri as the = one
that=20 was
              =  "retargeted" -=20 that's the one the UAS wants to pull from
the = hi-entries
   =20            in the incoming request. = That=20 hi-entry was not the one
that was just
      =  =20        added by the entity that built the = request just=20 received
by the UAS.
            =  =20  That hi-entry is tagged with whatever name we are going
to = tag it=20 with
              =  BEFORE the=20 request is forwarded (using the term forward
per section = 16.6
 =20              of RFC 3261). =  That tag=20 is added once the target set of
potential
      =  =20        candidates for the new request uri are = determined=20 in
section 16.5 of
            =  =20  3261 (with "target set" being a 3261 term), just before
the = request=20 is
              =  forwarded in=20 section 16.6 to one of those targets.  A
new = hi-entry
 =20              (which will be the = last=20 hi-entry in the request received
by the UAS) is
    =  =20          added in section 16.6 of 3261 as = the=20 request is
forwarded.  At this
      =    =20      point in time, the lost information is in the=20 previous
hi-entry when the
          =  =20    outgoing request is sent. [/MB]


  =    =20          What has been lost is the current = target=20 of the request:

            =  =20  [MB] Right - at which point in my mind, it's no longer
the=20 current
              =  target ;)=20 Maybe we call it "lost". [/MB]



      =  =20             Current = target

 =20                The current = target of=20 an initial request for a dialog
or standalone
    =  =20            request is the name or = address to=20 which the request is
targeted, i.e.
      =    =20        either the initial target inserted in the = Request-URI
by the UAC that
          =  =20      originates the request, or when a retarget=20 occurred,
the target
            =  =20    provided in that retarget operation.  Reroute=20 and
translation
            =  =20    operations never change the current = target.


 =20              [MB] I don't think = this=20 definition fits what you want -
i.e., if there
    =  =20          is no retargeting, then none of = the=20 hi-entries are
tagged - i.e., you
        =  =20      won't have your concept of current. The way it = works=20 is
that if no
              =  hi-entries are tagged, then you know that there was = no
retargeting,=20 thus
               you = know the=20 request-uri has not been lost. [/MB]


      =  =20        This defintion only makes sense when the=20 following
definitions are used:

      =    =20      Name:

          =  =20      A name is a moniker for an entity which refers = to=20 it
in a way which

          =    =20    reveals nothing about where it is in a network.=20  In
SIP, tel URI

          =  =20      which doesn't represent the location of the = entity=20 is
a name.


            =  =20  Address:

            =  =20    An address is an identifier for an entity = which
describes it=20 by its

              =  =20  location on the network.  In SIP, the SIP URI = itself
is a form=20 of

               =20  address because the host part of the URI, the = only
mandatory part=20 of

                =  the=20 URI besides the scheme itself, indicates the
location of a=20 SIP

               =20  server that can be used to handle the request.

  =  =20            Route:

    =  =20            Finally, a route is a =  =20 sequence of SIP entities
(including the UA
    =    =20        itself!) which are

    =  =20           traversed in order to forward a = request=20 to an address
or name.

          =  =20    Retarget (other term might be needed, as this is=20 highly
confusing):

          =  =20       A Request-URI rewrite operation that changes=20 the
target identity of
          =  =20    the request.

          =  =20    Reroute (other term might be needed):

  =  =20               A Request-URI = rewrite=20 operation that does not change
the current
    =    =20        target of the request, but    =20 determines the route/next
hop taken to
      =  =20        reach the target-identity.

  =  =20            /Hans Erik

  =  =20            Mary Barnes = wrote:
   =20            > So, by "target-uri = concept"=20 are you referring to the
solution in the
      =  =20        > current target-uri draft or the = application=20 usage as
such in the
            =  =20  > target-uri document (which is what I was=20 referring
to)?
            =  =20  >
              =  >=20 Yes, the problem is that SIP doesn't differentiate = the
various
 =20              > mechanisms by = which a=20 request-URI may be changed,
which is what some
    =  =20          > of the updated text in = 4244bis is=20 trying to do and why
we need precise

      =  =20        > terms. I think we all agree = that.
 =20              >
  =    =20          > I honestly don't care what we = call=20 the tag, as long as
we're clear
        =  =20      > about the functionality.
    =  =20          >
      =    =20      > Mary.
          =  =20    >
            =  =20  > -----Original Message-----
        =  =20      > From: Hans Erik van Elburg
[mailto:ietf.hanserik@gmail.com]
&= nbsp;=20              > Sent: = Wednesday, March=20 11, 2009 4:40 PM
              =  > To: Barnes, Mary (RICH2:AR00)
      =  =20        > Cc: Shida Schubert; sip@ietf.org
    =    =20        > Subject: Re: Terminology (was RE: = [Sip] Fwd:=20 I-D
               >=20 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
  =  =20            >
    =    =20        > The target-uri concept when defined = properly=20 is
entirely application
          =  =20    > agnostic.
          =  =20    >
            =  =20  > When one uses History-Info or another header as = a
vehicle for=20 this
               >=20 information then it still can be considered
application agnostic=20 as
               > = any=20 application can use this information as it likes.
    =  =20          >
      =    =20      >  From SIP perspective all the = Request-URI=20 rewrites
look the same, that

        =  =20      > is what brought us discussing this in the = first=20 place.
             =20  >
              =  >=20 /Hans Erik
             =20  >
              =  >=20 Mary Barnes wrote:
            =  =20  >
             =20  >> And, I think the big issue with the terminology = is
that=20 4244bis is
             =20  >> application agnostic, so it is tagging what = happens
to the=20 URIs
              =  >>=20 (why/how the specific URI was overwritten).=20  Whereas,
specific
          =  =20    >> applications can derive information, such as=20 what
"is" the real
            =  =20  >> "target" for the request, from the = History-Info
header.=20   So, IMHO,
              =  >> it's a matter of the target-uri document = specifying
that=20 the last
              =  >>=20 entry tagged by whatever name we come up with "is"
the real=20 "target"
              =  >>=20 for the request.  I believe it's up to the
applications to=20 describe
              =  >>=20 how they make use of the History-Info and not for = the
History-Info=20 to

              =  >>=20 describe how applications can use it.  History-Info
purely=20 reflects
              =  >>=20 what happened from a SIP Protocol perspective and
should not=20 imply
              =  >>=20 any
             =20  >>
             =20  >
             =20  >
             =20  >> application semantics. Indeed the intent of section = 5
of=20 4244 was to
             =20  >> inform the applications how they should decribe=20 their
usage of the
            =  =20  >> header.
            =  =20  >>
             =20  >> Mary.
            =  =20  >> Note: I changed the subject to hopefully make = this
topic=20 easier to
              =  >>=20 keep track of.
             =20  >>
             =20 =  >>
-------------------------------------------------------= --------------
 =20              >> -
  =  =20            >> --
  =    =20          >> *From:* Hans Erik van=20 Elburg
[mailto:ietf.hanserik@gmail.com]
&= nbsp;=20              >> *Sent:* = Wednesday,=20 March 11, 2009 3:59 AM
            =  =20  >> *To:* Shida Schubert
        =  =20      >> *Cc:* sip@ietf.org List; Barnes, Mary=20 (RICH2:AR00)
             =20  >> *Subject:* Re: [Sip] Fwd: I-D
      =  =20        >>=20 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
  =  =20            >>
    =  =20          >> One of the problems that = made the=20 discussion quite
tedious is the
        =  =20      >> complete inversed meaning of the terms=20 "retarget" and
"reroute"
          =  =20    >> between 4244bis and target-uri factions=20 have.
             =20  >>
             =20  >> Conclusion was that the terminology need to = be
properly=20 defined and
             =20  >> some attempt was made to start such = activity.
 =20              >>
  =  =20            >> On 3. I have = strong=20 concerns when we start tagging
the URI as to how
    =  =20          >> they come about=20 "retarget"/"mapped conficuration"
etc. It is better
  =  =20            >> to
  =    =20          >>
      =  =20        >
        =    =20    >
            =  =20  >> embellish them with a tag that just represents=20 there
meaning for
            =  =20  >> example "istarget" or "hop". For the=20 following
reasons:
            =  =20  >> 1. It is much more intuitive for the user of=20 this
information, its
          =    =20  >> meaning can basically be guessed.
    =  =20          >> 2. Such meaning also = probably=20 survives application in
other problem
      =  =20        >> spaces that we had not foreseen = when=20 introducing the
concept.
          =  =20    >>
            =  =20  >> The solution that is  described now in the=20 target-URI
delivery draft
          =  =20    >> is not yet complete, it does not solve the=20 freephone
use case for
          =  =20    >> example and in its current form it will=20 deliver
exactly the same
          =  =20    >> target-URI as that which would be delivered by = the
P-Called-Party-ID

          =  =20    >> header. Contrary to what the draft says. So = some=20 work
is needed
            =  =20  still.
             =20  >>
             =20  >> /Hans Erik van Elburg
        =  =20      >>
          =  =20    >>
            =  =20  >> On Wed, Mar 11, 2009 at 7:13 AM, Shida = Schubert
<shida@ntt-at.com
  =    =20          >> <mailto:shida@ntt-at.com>> = wrote:
 =20              >>
  =  =20            >>
    =  =20          >>     We have = submitted=20 the updated target-uri draft
based on the
      =  =20        >>
        =  =20      > comments
        =  =20      >
          =    =20  >>     submitted to the list and comments = received=20 at
IETF73.
             =20  >>
             =20  >>     I have taken over as editor as Jonathan = didn't
have the cycles to

        =  =20      >>     update the draft, with = Francois,=20 Christer and
Hans Erick as
          =  =20    >>     additional
    =  =20          >>     co-authors = and=20 great deal of help from Mary.
          =  =20    >>
            =  =20  >>     The following summarizes the changes = made to=20 the
target-uri
            =  =20  >>
             =20  > document
            =  =20  >
             =20  >>     1. Added use-case for toll-free number=20 back
              =  >>=20     2. Added definition of "retarget" operation.
  =  =20            >>     3. = Removed a=20 reference to URN
              =  >>     4. Added a text discussing the = difference=20 to
P-Called-Party-Id
            =  =20  >>     5. Changed parameter name from "target" = to
"istarget"
              =  >>
             =20  >>     Note, that the target-uri document = still=20 contains
the normative
          =  =20    >>     text for the
    =  =20          >>     = History-Info=20 header.
             =20  >>
             =20  >>     In addition, Mary (with Francois as=20 co-author)
has submitted a
          =  =20    >>     rfc4244bis, with the following=20 changes:
              =  >>=20     1. Incorporated the normative aspects of = the
target-uri=20 document
              =  >>=20     into the existing normative text in RFC 4244 -
the=20 functionality
             =20  >>
             =20  > is
             =20  >
             =20  >>     virtually identical (as is some of the = text)=20 as
the HI based
            =  =20  >>
             =20  > solution
            =  =20  >
             =20  >>     described in the target-uri document.=20  It's
important that the
        =  =20      >>     solution
    =  =20          >>     be = integrated into=20 RFC 4244 as it MUST work and
be based on the
    =  =20          >>     = normative
 =20              >>   =  =20 aspects of RFC 4244.
            =  =20  >>     2.  Added the use cases from = target-uri=20 the the
summary
            =  =20  >>     in the overview of = rfc4244bis.
   =20            >>     3. = Added an=20 additional requirement to capture the
"target-uri"
  =  =20            >>    =20 information.
             =20  >>     4. Fixed an error in the RFC 4244 ABNF = and=20 added
"retarget"
            =  =20  >>
             =20  > parameter.
            =  =20  >
             =20  >>     5. Added a more simplified = example.
 =20              >>
  =  =20            >>
    =  =20          >>     We had some = very=20 long offline exchanges as to the
best way
      =  =20        >> forward
      =  =20        >>
        =  =20      > and
          =  =20    >
            =  =20  >>     remaining work for both = documents.
 =20              >>
  =  =20            >>     Some = of the=20 issues identified are:
            =  =20  >>
             =20  >>     ::Issues::
      =  =20        >>        1. = Should we=20 remove the normative text from
target-uri and
    =  =20          >>
      =  =20        > progress
      =  =20        >
        =    =20    >>           =  4244bis along=20 with the target-uri document
to meet the
      =  =20        >>     = chartered
   =20            >>     =  =20     SIP WG milestone?
        =    =20    >>
            =  =20  >>
             =20  >>        2. Name of the=20 parameter.
             =20  >>           At the last = meeting,=20 parameter "target" was
said
          =  =20    >>
            =  =20  > inappropriate
          =    =20  >
             =20  >>           because = voicemail-uri spec=20 already defines
a parameter
          =  =20    >>
            =  =20  > called
            =  =20  >
             =20  >>           "target" which = also can be=20 found in
hi-entry, thus
          =  =20    >>
            =  =20  > potentially
            =  =20  >
             =20  >>           causing=20 confusion.
             =20  >>
             =20  >>           Currently the = target-uri=20 draft uses
"istarget" and 4244bis
        =  =20      >>
          =  =20    > uses
            =  =20  >
             =20  >>           "retarget" =  but we=20 could never come to
            =  =20  >>           a consensus on = what name=20 is appropriate.
Other suggestions
        =  =20      >>
          =  =20    > have
            =  =20  >
             =20  >>           included the=20 following:
             =20  >>           "target-identity" = (someone=20 didn't like that
"identity" is
        =  =20      >>     also a SIP = header)
 =20              >>   =  =20       "reg-uri"  (can be paired with = "mapped-uri"
for=20 item 3
             =20  >>
             =20  > below)
            =  =20  >
             =20  >>           "aor"
  =  =20            >>     =  =20     "jibberish"
          =  =20    >>           = etc.
 =20              >>
  =  =20            >>     =  =20     One reason this is so difficult relates to
the=20 problem
              =  >>=20     statement in target-uri in that
    =    =20        >>         =   RFC=20 3261 doesn't differentiate the
mechanism by which the
  =  =20            >>
    =  =20          > new
      =  =20        >
        =    =20    >>           (target)=20 Request-URI is selected.  Another
issue is that
  =  =20            >>     some = of the=20 terminology in
             =20  >>           RFC 3261 is = overloaded -=20 e.g., "forwarding"
refers both to
        =  =20      a
            =  =20  >>     Proxy
        =  =20      >>           = which does=20 not have responsibility for the
domain of the
    =  =20          >>    =20 request-URI
             =20  >>           in the incoming = request,=20 thus the proxy
just "forwards" the
        =  =20      >>     request to
  =  =20            >>     =  =20     the next hop AND "forwarding" is used to
describe=20 the
              =  >>=20     process whereby
          =  =20    >>           the = outgoing=20 request is built and
"forwarded" to the next
    =  =20          >>     hop at=20 which
              =  >>=20           point the proxy does not know how = the=20 new
request-uri was
            =  =20  >>     selected.
      =    =20      >>           RFC = 4244 has=20 attempted to clarify the terms
and attempts to
    =  =20          >>     use=20 "forward"
              =  >>=20           in the context of the former = situation=20 and
"retarget" for
            =  =20  >>     the case whereby
    =    =20        >>         =   a=20 proxy is responsible for the domain and
thus can use a
  =  =20            >>     = number=20 of
              =  >>  =20         mechanism to select the new target for=20 the
request - e.g.,
            =  =20  a
              =  >>=20     REGISTRAR,
          =    =20  >>           configured data,=20 etc.
             =20  >>
             =20  >>      3.  Related to the last = point in=20 item 2 above,
it has been
          =  =20    >>     proposed that
    =  =20          >>       =  =20   we differentiate the hi-entries even more
by = defining
 =20              >>   =  =20 separate parameters
            =  =20  >>          for registered and=20 configured/mapped
contacts.
          =  =20    >>          Currently = when the=20 R-URI is translated to a
URI which is
      =  =20        >>     either = derived
 =20              >>   =  =20      from location service lookup(registered = by
UA) or=20 from
             =20  >>
             =20  > mapping
            =  =20  >
             =20  >>          table, there is no=20 differentiation as to how
the URI was
      =  =20        >>     derived once it=20 is
              =  >>  =20        added to the list of potential = targets.
 =20              >>
  =  =20            >>     =  =20    The general consensus of the authors of the
two=20 documents
             =20  was
              =  >>=20     that it may
          =  =20    >>          be useful = for some=20 services to have the
hi-entries tagged
      =  =20        >>     with the
  =  =20            >>     =  =20    more specific information.
      =  =20        >>
        =  =20      >>          And, = of=20 course, this gets us into another
naming contest. In
  =  =20            >>     the = end, the=20 naming
              =  >>=20          is not so important as long as the = term
isn't too overloaded
          =  =20    >>     and it is defined
  =  =20            >>     =  =20    precisely in the document(s).
      =  =20        >>
        =  =20      >>     We would appreciate WG = feedback=20 on these issues
and any other
        =  =20      >>     comments on
  =  =20            >>     the = two=20 documents prior to IETF-74.
          =  =20    >>
            =  =20  >>     Regards,
        =  =20      >>     Shida and Mary.
  =  =20            >>
    =  =20          >>
      =  =20        >>
        =  =20      >>     Begin forwarded=20 message:
             =20  >>
             =20  >>>     *From: *Internet-Drafts@ietf.org
=  =20             =  >>>
 =20              > <mailto:Internet-Drafts@ietf.org>=
 =20              >
  =    =20          >>>     *Date: = *March=20 10, 2009 2:30:01 AM JST
            =  =20  >>>     *To: *i-d-announce@ietf.org
<ma= ilto:i-d-announce@ietf.org>
&n= bsp;=20              >>>   =  =20 *Subject: **I-D
             =20 =  >>>
ACTION:draft-rosenberg-sip-target-uri-delivery-01.t= xt=20 *
              =  >>>=20     *Reply-To: *internet-drafts@ietf.org
=  =20              >>>   =  =20 <mailto:internet-drafts@ietf.org>=
 =20             =  >>>
 =20              >>>   =   A=20 New Internet-Draft is available from the
on-line
    =  =20          >>>
    =  =20          > Internet-Drafts
  =  =20            >
    =    =20        >>>     = directories.
 =20             =  >>>
 =20             =  >>>
 =20              >>>   =  =20 Title
              =  >>>=20     : Delivery of Request-URI Targets to User = Agents
 =20              >>>   =  =20 Author(s)
             =20  >>>     : J. Rosenberg, H. van Elburg, C. = Holmberg,=20 F.
Audet, S.
             =20  Schubert
             =20  >>>     Filename=20 :
draft-rosenberg-sip-target-uri-delivery-01.txt
    =  =20          >>>     = Pages
 =20              >>>   =   :=20 16
              =  >>>=20     Date
            =  =20  >>>     : 2009-3-9
      =  =20        >>>
      =  =20        >>>     When a Session = Initiation Protocol (SIP) proxy
receives a
    =    =20        request
        =  =20      >>>       targeted at a = URI=20 identifying a user or
resource it is
      =  =20        >>>
      =  =20        > responsible
      =  =20        >
        =    =20    >>>       for, the proxy = translates the=20 URI to a
registered or
          =  =20    configured
            =  =20  >>>       contact URI of an agent = representing=20 that user
or resource.
          =  =20    >>> In
          =  =20    >>>
          =  =20    > the
            =  =20  >
             =20  >>>       process, the original URI is = removed=20 from the
request.
            =  =20  >>>      Numerous use
    =  =20          >>>       = cases=20 have arisen which require this
information to be
    =  =20          >>>
    =  =20          > delivered to
    =  =20          >
      =    =20      >>>       the user = agent.=20  This document describes these
use cases and
  =    =20          >>>    =20 defines
             =20  >>>       an extension to the = History-Info=20 header field
which allows it
        =    =20    >>>
          =  =20    > to be
            =  =20  >
             =20  >>>       used to support those=20 cases.
             =20  >>>
            =  =20  >>>     A URL for this Internet-Draft = is:
 =20             =  >>>
 =20              >>>
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-t= arget-uri-d
 =20              >>> = e
 =20              >>>=20 livery-01.txt
             =20  >>>
            =  =20  >>>     Internet-Drafts are also available = by=20 anonymous
FTP at:
            =  =20  >>>     ftp://ftp.ietf.org/internet-drafts/
  =  =20            >>>
  =  =20            >>>     = Below is=20 the data which will enable a MIME
compliant mail reader
  =  =20            >>>    =20 implementation to automatically retrieve the
ASCII version = of
 =20              the
    =  =20          >>>    =20 Internet-Draft.
             =20  >>>
            =  =20  >>     Content-Type:=20 text/plain<BR>Content-ID:
        =    =20    >>     &lt;2009-3-9102756.I-D@ie= tf.org
<mailto:lt%3B2009-3-9102756.I-= D@ietf.org>
             =20  >>     <mailto:2009-3-9102756.I-D@ietf.org>&gt;<BR><BR>
 =20              >>
  =  =20            >>>    =20 _______________________________________________
    =  =20          >>>     = I-D-Announce=20 mailing list
             =20  >>>     I-D-Announce@ietf.org
<ma= ilto:I-D-Announce@ietf.org>
&n= bsp;=20              >>>
https://www.ietf.org/mailman/listinfo/i-d-announce =20              >>>   =  =20 Internet-Draft directories:
http://www.ietf.org/shadow.html
    =  =20          >>>     or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
  =  =20            >>>
  =  =20            >>    =20 _______________________________________________
    =  =20          >>     Sip mailing = list
https://www.ietf.org/mailman/listinfo/sip
  =  =20            >>     This = list is=20 for NEW development of the core SIP
Protocol
    =  =20          >>     Use sip-implementors@cs.colu= mbia.edu
 =20              >>   =  =20 <mailto:sip-implementors@cs.colu= mbia.edu>=20 for
questions on
            =  =20  >> current
            =  =20  >>
             =20  > sip
             =20  >
             =20  >>     Use sipping@ietf.org <mailto:sipping@ietf.org>
for = new
 =20              >>   =  =20 developments on the application of sip
      =    =20      >>
          =  =20    >>
            =  =20 =  >>




------_=_NextPart_001_01C9A316.BF9DD2CC-- From ian.elz@ericsson.com Thu Mar 12 06:40:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AAD3A69CA for ; Thu, 12 Mar 2009 06:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRKlNAN2rUJd for ; Thu, 12 Mar 2009 06:40:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CBC683A68C8 for ; Thu, 12 Mar 2009 06:40:46 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6FC8921996; Thu, 12 Mar 2009 14:41:21 +0100 (CET) X-AuditID: c1b4fb3c-ac808bb000001b43-e5-49b910f2aa7a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 83DE821ED7; Thu, 12 Mar 2009 14:41:06 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 14:41:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 14:42:37 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-barnes-sip-rfc4244bis-00.txt thread-index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sA== References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Mary Barnes" X-OriginalArrivalTime: 12 Mar 2009 13:41:04.0100 (UTC) FILETIME=[3042DA40:01C9A318] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:40:51 -0000 Mary, (Written after reading your discussion with Hans Erik.) First an apology for not making it clear in my original email that a value of "none" in a Privacy header parameter in a History-Info entry was only applicable to the uri contained in the hi-targeted-to-uri. I only suggested using the value "none" as this is a value defined for the Privacy header which explicitly indicates that privacy is not required. Any other value with the meaning of explicitly indicating that there is no privacy required for the specific uri could be used. With regard to your second paragraph below I understand that the SIP and PSTN models do not align. You are correct in your assumption that this problem is not unique for History-Info. The problem also arises with the Referred-By header.=20 I have raised this for History-Info at this time as your new draft presents an opportunity to correct this problem for the H-I case. The general SIP privacy issue arises as when the Privacy header was defined the concept of carrying third party identities in the SIP messages was not defined. This came later with the REFER Request and the associated Referred-By header and the History-Info header.=20 We should take what opportunities arise to discuss and correct this if there is a will to make these changes. Ian Elz Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 11 March 2009 16:53 To: Ian Elz; Francois Audet Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, This is an interesting question. I need to think about it some more, but I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain. My initial thought is that we can't overrule the overall Privacy header. The thing is that the Privacy header doesn't preclude gathering the information and using within a domain AND if it were to not include an hi-entry when the request leaves the domain for which the proxy is responsible, the recipient can add the hi-entry for the current request-uri before it adds the new hi-entry. =20 Your PSTN example doesn't strictly map obviously to a SIP model and I would think you might consider the PSTN hop to be within the same domain for which the proxy (or gw, I guess) is responsible OR consider this a walled garden whereby the Privacy header doesn't apply. Which brings me to a more general question as to how you all deal with other headers when you do your mapping to the PSTN when there is a Privacy header? It would seem this problem isn't unique to History-Info, although I know little about the details of PSTN I/W. Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Wednesday, March 11, 2009 4:54 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 04 March 2009 15:15 To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From mary.barnes@nortel.com Thu Mar 12 06:43:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4983A697E for ; Thu, 12 Mar 2009 06:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l37THtZ8CmfZ for ; Thu, 12 Mar 2009 06:42:59 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 25BE23A677D for ; Thu, 12 Mar 2009 06:42:53 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2CDhR024944; Thu, 12 Mar 2009 13:43:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 08:46:00 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: Acmi7W8JoLngjlXtTEqklOfh2jQOhQAFOLMwAAUwySA= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> A<0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> From: "Mary Barnes" To: "Elwell, John" , "Hans Erik van Elburg" Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:43:06 -0000 Yeah, we did looked at that approach, BUT there are two problems: 1) It doesn't take into account the case where it's just a proxy hop to a new domain - i.e., those also won't be tagged. We also considered just flagging those proxy hops, but then you still get into trouble with the last entry as that isn't what you want - you typically want the previous entry, which takes us to the next problem. =20 2) You are then back to assuming that the one you want is one back from the current hi-entry. I thought the whole point was to have it obviously tagged.=20 I am struggling with why tagging the ones, that we truly know are lost, at the point we know they're lost won't work? Isn't that the information that is really desired? =20 I think the 'iscontact' tag is a fine name - I just think we need to use that in the manner currently specified in 4244bis for the "retarget" flag.=20 As far as Hans Erik's point about not discussing implementation, I don't think not discussing implementation is at all helpful. I think the problem statement is already fairly well laid out in the target-uri draft. And, if you plan on using History-Info as the solution, we MUST understand how it works now and we MUST understand how the proposed solution works within the existing History-Info processing structure - it's the just the same as we do with any new SIP header. And, indeed it was the same thing that was done for the History-Info header to make sure it was consistent with RFC 3261. The terminology is an issue and I just think it takes precise wording ONCE we all understand the implementation - it's got to be compatible with 3261 processing (now, we can suggest some clarifications to that text and again, the definitions that are currently in 4244bis are an attempt to do so). That all said, we can certainly name the tag now and the 'iscontact' does work for me. Mary.=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: Thursday, March 12, 2009 6:09 AM To: Hans Erik van Elburg; Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org Subject: RE: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt If 'istarget' is used only to identify the value that was overwritten in the Request-URI by a contact URI, an alternative approach would be to flag the contact URI H-I entry as 'iscontact'. Then the UAS would just need to look for the most recent H-I entry that is not marked 'iscontact'. John ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 12 March 2009 08:35 To: Mary Barnes Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Yes, because you are using the 3261 use of target and the 4244bis introduced definition of retarget. I thought it was clear that we need other words as those definitions don't match the target-uri drafts use of the terms. Also they do not suffice to provide a solution for the use cases in the target-uri draft. =09 The 3261 text you refer to is exactly about the case where the home proxy overwrites the Request-URI with a new target. This target is teh registered contact address. And hence this would be what target-uri calls a hop or a route. This case and this is where it gets confusing is not a "retarget" in the target-uri draft use of the term. =09 The target-uri draft states: =09 "To avoid confusion, we refer to a SIP URI that is an address for a user or resource as a "target" and a SIP URI that is a hop for reaching that user as a =09 "hop". =09 Apparently that does not suffice to avoid confusion. =09 As for the tagging, speaking about the solution before agreeing on the terminology and the problem it should solve is meaningless. =09 /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes wrote: =09 Responses below [MB]. =09 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] =09 Sent: Wednesday, March 11, 2009 6:42 PM To: Barnes, Mary (RICH2:AR00) Cc: Shida Schubert; sip@ietf.org Subject: Re: Terminology (was RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 I was talking about the concept. =09 The use cases only describe cases where the target-uri (lets call that current target from now) has been lost when an initial request for a dialog or standalone request arrives at the UAS. =09 [MB] And I think this is where the terminology confusion starts - I don't think of the "lost" target-uri as being the "current" target. In my mind, the "current" target is reflected by the last hi-entry and the request-uri in the incoming request at the UAS. If the entity that sent the request was the entity that added the last hi-entry, then the uri in that hi-entry is the same as the request-URI in the SIP request that arrives at the UAS. I refer to the "lost" uri as the one that was "retargeted" - that's the one the UAS wants to pull from the hi-entries in the incoming request. That hi-entry was not the one that was just added by the entity that built the request just received by the UAS. That hi-entry is tagged with whatever name we are going to tag it with BEFORE the request is forwarded (using the term forward per section 16.6 of RFC 3261). That tag is added once the target set of potential candidates for the new request uri are determined in section 16.5 of 3261 (with "target set" being a 3261 term), just before the request is forwarded in section 16.6 to one of those targets. A new hi-entry (which will be the last hi-entry in the request received by the UAS) is added in section 16.6 of 3261 as the request is forwarded. At this point in time, the lost information is in the previous hi-entry when the outgoing request is sent. [/MB] =09 What has been lost is the current target of the request: =09 [MB] Right - at which point in my mind, it's no longer the current target ;) Maybe we call it "lost". [/MB] =09 Current target =09 The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. =09 =09 [MB] I don't think this definition fits what you want - i.e., if there is no retargeting, then none of the hi-entries are tagged - i.e., you won't have your concept of current. The way it works is that if no hi-entries are tagged, then you know that there was no retargeting, thus you know the request-uri has not been lost. [/MB] =09 This defintion only makes sense when the following definitions are used: =09 Name: =09 A name is a moniker for an entity which refers to it in a way which =09 reveals nothing about where it is in a network. In SIP, tel URI =09 which doesn't represent the location of the entity is a name. =09 =09 Address: =09 An address is an identifier for an entity which describes it by its =09 location on the network. In SIP, the SIP URI itself is a form of =09 address because the host part of the URI, the only mandatory part of =09 the URI besides the scheme itself, indicates the location of a SIP =09 server that can be used to handle the request. =09 Route: =09 Finally, a route is a sequence of SIP entities (including the UA itself!) which are =09 traversed in order to forward a request to an address or name. =09 Retarget (other term might be needed, as this is highly confusing): =09 A Request-URI rewrite operation that changes the target identity of the request. =09 Reroute (other term might be needed): =09 A Request-URI rewrite operation that does not change the current target of the request, but determines the route/next hop taken to reach the target-identity. =09 /Hans Erik =09 Mary Barnes wrote: > So, by "target-uri concept" are you referring to the solution in the > current target-uri draft or the application usage as such in the > target-uri document (which is what I was referring to)? > > Yes, the problem is that SIP doesn't differentiate the various > mechanisms by which a request-URI may be changed, which is what some > of the updated text in 4244bis is trying to do and why we need precise =09 > terms. I think we all agree that. > > I honestly don't care what we call the tag, as long as we're clear > about the functionality. > > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 4:40 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > The target-uri concept when defined properly is entirely application > agnostic. > > When one uses History-Info or another header as a vehicle for this > information then it still can be considered application agnostic as > any application can use this information as it likes. > > From SIP perspective all the Request-URI rewrites look the same, that =09 > is what brought us discussing this in the first place. > > /Hans Erik > > Mary Barnes wrote: > >> And, I think the big issue with the terminology is that 4244bis is >> application agnostic, so it is tagging what happens to the URIs >> (why/how the specific URI was overwritten). Whereas, specific >> applications can derive information, such as what "is" the real >> "target" for the request, from the History-Info header. So, IMHO, >> it's a matter of the target-uri document specifying that the last >> entry tagged by whatever name we come up with "is" the real "target" >> for the request. I believe it's up to the applications to describe >> how they make use of the History-Info and not for the History-Info to =09 >> describe how applications can use it. History-Info purely reflects >> what happened from a SIP Protocol perspective and should not imply >> any >> > > >> application semantics. Indeed the intent of section 5 of 4244 was to >> inform the applications how they should decribe their usage of the >> header. >> >> Mary. >> Note: I changed the subject to hopefully make this topic easier to >> keep track of. >> >> --------------------------------------------------------------------- >> - >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Wednesday, March 11, 2009 3:59 AM >> *To:* Shida Schubert >> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) >> *Subject:* Re: [Sip] Fwd: I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >> >> One of the problems that made the discussion quite tedious is the >> complete inversed meaning of the terms "retarget" and "reroute" >> between 4244bis and target-uri factions have. >> >> Conclusion was that the terminology need to be properly defined and >> some attempt was made to start such activity. >> >> On 3. I have strong concerns when we start tagging the URI as to how >> they come about "retarget"/"mapped conficuration" etc. It is better >> to >> > > >> embellish them with a tag that just represents there meaning for >> example "istarget" or "hop". For the following reasons: >> 1. It is much more intuitive for the user of this information, its >> meaning can basically be guessed. >> 2. Such meaning also probably survives application in other problem >> spaces that we had not foreseen when introducing the concept. >> >> The solution that is described now in the target-URI delivery draft >> is not yet complete, it does not solve the freephone use case for >> example and in its current form it will deliver exactly the same >> target-URI as that which would be delivered by the P-Called-Party-ID =09 >> header. Contrary to what the draft says. So some work is needed still. >> >> /Hans Erik van Elburg >> >> >> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > > wrote: >> >> >> We have submitted the updated target-uri draft based on the >> > comments > >> submitted to the list and comments received at IETF73. >> >> I have taken over as editor as Jonathan didn't have the cycles to =09 >> update the draft, with Francois, Christer and Hans Erick as >> additional >> co-authors and great deal of help from Mary. >> >> The following summarizes the changes made to the target-uri >> > document > >> 1. Added use-case for toll-free number back >> 2. Added definition of "retarget" operation. >> 3. Removed a reference to URN >> 4. Added a text discussing the difference to P-Called-Party-Id >> 5. Changed parameter name from "target" to "istarget" >> >> Note, that the target-uri document still contains the normative >> text for the >> History-Info header. >> >> In addition, Mary (with Francois as co-author) has submitted a >> rfc4244bis, with the following changes: >> 1. Incorporated the normative aspects of the target-uri document >> into the existing normative text in RFC 4244 - the functionality >> > is > >> virtually identical (as is some of the text) as the HI based >> > solution > >> described in the target-uri document. It's important that the >> solution >> be integrated into RFC 4244 as it MUST work and be based on the >> normative >> aspects of RFC 4244. >> 2. Added the use cases from target-uri the the summary >> in the overview of rfc4244bis. >> 3. Added an additional requirement to capture the "target-uri" >> information. >> 4. Fixed an error in the RFC 4244 ABNF and added "retarget" >> > parameter. > >> 5. Added a more simplified example. >> >> >> We had some very long offline exchanges as to the best way >> forward >> > and > >> remaining work for both documents. >> >> Some of the issues identified are: >> >> ::Issues:: >> 1. Should we remove the normative text from target-uri and >> > progress > >> 4244bis along with the target-uri document to meet the >> chartered >> SIP WG milestone? >> >> >> 2. Name of the parameter. >> At the last meeting, parameter "target" was said >> > inappropriate > >> because voicemail-uri spec already defines a parameter >> > called > >> "target" which also can be found in hi-entry, thus >> > potentially > >> causing confusion. >> >> Currently the target-uri draft uses "istarget" and 4244bis >> > uses > >> "retarget" but we could never come to >> a consensus on what name is appropriate. Other suggestions >> > have > >> included the following: >> "target-identity" (someone didn't like that "identity" is >> also a SIP header) >> "reg-uri" (can be paired with "mapped-uri" for item 3 >> > below) > >> "aor" >> "jibberish" >> etc. >> >> One reason this is so difficult relates to the problem >> statement in target-uri in that >> RFC 3261 doesn't differentiate the mechanism by which the >> > new > >> (target) Request-URI is selected. Another issue is that >> some of the terminology in >> RFC 3261 is overloaded - e.g., "forwarding" refers both to a >> Proxy >> which does not have responsibility for the domain of the >> request-URI >> in the incoming request, thus the proxy just "forwards" the >> request to >> the next hop AND "forwarding" is used to describe the >> process whereby >> the outgoing request is built and "forwarded" to the next >> hop at which >> point the proxy does not know how the new request-uri was >> selected. >> RFC 4244 has attempted to clarify the terms and attempts to >> use "forward" >> in the context of the former situation and "retarget" for >> the case whereby >> a proxy is responsible for the domain and thus can use a >> number of >> mechanism to select the new target for the request - e.g., a >> REGISTRAR, >> configured data, etc. >> >> 3. Related to the last point in item 2 above, it has been >> proposed that >> we differentiate the hi-entries even more by defining >> separate parameters >> for registered and configured/mapped contacts. >> Currently when the R-URI is translated to a URI which is >> either derived >> from location service lookup(registered by UA) or from >> > mapping > >> table, there is no differentiation as to how the URI was >> derived once it is >> added to the list of potential targets. >> >> The general consensus of the authors of the two documents was >> that it may >> be useful for some services to have the hi-entries tagged >> with the >> more specific information. >> >> And, of course, this gets us into another naming contest. In >> the end, the naming >> is not so important as long as the term isn't too overloaded >> and it is defined >> precisely in the document(s). >> >> We would appreciate WG feedback on these issues and any other >> comments on >> the two documents prior to IETF-74. >> >> Regards, >> Shida and Mary. >> >> >> >> Begin forwarded message: >> >>> *From: *Internet-Drafts@ietf.org >>> > > >>> *Date: *March 10, 2009 2:30:01 AM JST >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D >>> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * >>> *Reply-To: *internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line >>> > Internet-Drafts > >>> directories. >>> >>> >>> Title >>> : Delivery of Request-URI Targets to User Agents >>> Author(s) >>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert >>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt >>> Pages >>> : 16 >>> Date >>> : 2009-3-9 >>> >>> When a Session Initiation Protocol (SIP) proxy receives a request >>> targeted at a URI identifying a user or resource it is >>> > responsible > >>> for, the proxy translates the URI to a registered or configured >>> contact URI of an agent representing that user or resource. >>> In >>> > the > >>> process, the original URI is removed from the request. >>> Numerous use >>> cases have arisen which require this information to be >>> > delivered to > >>> the user agent. This document describes these use cases and >>> defines >>> an extension to the History-Info header field which allows it >>> > to be > >>> used to support those cases. >>> >>> A URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d >>> e >>> livery-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> Content-Type: text/plain
Content-ID: >> <2009-3-9102756.I-D@ietf.org =20 >> >

>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current >> > sip > >> Use sipping@ietf.org for new >> developments on the application of sip >> >> >> =09 From john.elwell@siemens.com Thu Mar 12 06:43:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CD73A6901 for ; Thu, 12 Mar 2009 06:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfK5WvmESgWj for ; Thu, 12 Mar 2009 06:43:48 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2602E3A6806 for ; Thu, 12 Mar 2009 06:43:48 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGE00596BI1V3@siemenscomms.co.uk> for sip@ietf.org; Thu, 12 Mar 2009 13:44:25 +0000 (GMT) Date: Thu, 12 Mar 2009 13:44:23 +0000 From: "Elwell, John" In-reply-to: <9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> To: Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001A27C69@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjEo9cACSfdpORRgqN7inoq6qTugABBxGA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:43:49 -0000 (Old messages stripped to prevent blocking) Hans Erik, =20 The way I interpreted the 01 draft, you would not get the freephone number anyway. If that is a requirement, then I accept my suggestion won't suffice. =20 John ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 12 March 2009 12:57 To: Elwell, John Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 But that does not solve the freephone service use case. Freephone represents a use case where the R-URI is replaced with an AoR of user B - not with the contact of user B.=20 =09 A calls Bfreephonenumber routed the B (AOR) routed to B's contact. =09 The target-uri draft is interested in obtaining: Bfreephonenumber as that is what A used to reach B. =09 So what we like to see that B UA receives is something like H-I: Bfreephone; "istarget",\ B,\ contact-B =09 So you want to get Bfreephonenumber and not B. =09 In certain situations you are also interested in B, I guess that PBX's would interested in that to deliver to the correct user. We could distinguish them like: H-I: Bfreephone; "istarget",\ B,"aor"\ contact-B =09 BR, /Hans Erik van Elburg =09 From mary.barnes@nortel.com Thu Mar 12 06:51:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57B33A677D for ; Thu, 12 Mar 2009 06:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSlJz2HxOD4D for ; Thu, 12 Mar 2009 06:51:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E11823A68CD for ; Thu, 12 Mar 2009 06:51:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2CDq3028966; Thu, 12 Mar 2009 13:52:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 08:54:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sAABMLoA References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Ian Elz" Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:51:36 -0000 Ian, Okay, so I think I might understand now - you want to use the "none" to override the Privacy header that would be (in current 4244/4244bis) applied to the whole message as it traverses across the n/w from the UAC to the UAS. Is that correct? That then though changes the meaning of the Privacy header, as I understand it - i.e., the "none" I thought had to do with specifying that an intermediary MUST NOT change the value of the Privacy header. But, I guess you are saying we specify a slightly different usage in 4244bis such that when we add it to an hi-entry, it specifies that that hi-entry MUST NOT be dropped by an intermediary. That might work, although, we would need verbage about the "risks" of doing so. Thanks, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, March 12, 2009 8:43 AM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org; Audet, Francois (SC100:3055) Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, (Written after reading your discussion with Hans Erik.) First an apology for not making it clear in my original email that a value of "none" in a Privacy header parameter in a History-Info entry was only applicable to the uri contained in the hi-targeted-to-uri. I only suggested using the value "none" as this is a value defined for the Privacy header which explicitly indicates that privacy is not required. Any other value with the meaning of explicitly indicating that there is no privacy required for the specific uri could be used. With regard to your second paragraph below I understand that the SIP and PSTN models do not align. You are correct in your assumption that this problem is not unique for History-Info. The problem also arises with the Referred-By header.=20 I have raised this for History-Info at this time as your new draft presents an opportunity to correct this problem for the H-I case. The general SIP privacy issue arises as when the Privacy header was defined the concept of carrying third party identities in the SIP messages was not defined. This came later with the REFER Request and the associated Referred-By header and the History-Info header.=20 We should take what opportunities arise to discuss and correct this if there is a will to make these changes. Ian Elz Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 11 March 2009 16:53 To: Ian Elz; Francois Audet Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, This is an interesting question. I need to think about it some more, but I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain. My initial thought is that we can't overrule the overall Privacy header. The thing is that the Privacy header doesn't preclude gathering the information and using within a domain AND if it were to not include an hi-entry when the request leaves the domain for which the proxy is responsible, the recipient can add the hi-entry for the current request-uri before it adds the new hi-entry. =20 Your PSTN example doesn't strictly map obviously to a SIP model and I would think you might consider the PSTN hop to be within the same domain for which the proxy (or gw, I guess) is responsible OR consider this a walled garden whereby the Privacy header doesn't apply. Which brings me to a more general question as to how you all deal with other headers when you do your mapping to the PSTN when there is a Privacy header? It would seem this problem isn't unique to History-Info, although I know little about the details of PSTN I/W. Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, March 11, 2009 4:54 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 04 March 2009 15:15 To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From christer.holmberg@ericsson.com Thu Mar 12 06:49:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022833A6888 for ; Thu, 12 Mar 2009 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=-1.716, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvSFzdhkqIyU for ; Thu, 12 Mar 2009 06:49:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 350F83A6826 for ; Thu, 12 Mar 2009 06:49:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 15F7821934; Thu, 12 Mar 2009 14:50:18 +0100 (CET) X-AuditID: c1b4fb3c-ab806bb000001b43-a7-49b91317ad19 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C699D21E0A; Thu, 12 Mar 2009 14:50:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 14:50:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A319.66BD4A8A" Date: Thu, 12 Mar 2009 14:49:44 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001A27C50@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjEo9cACSfdpORRgqN7inoq6qTugABBxGAAACgoIA= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com><49B82FB4.4030002@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com><49B84C55.5070107@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com><9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27C50@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Hans Erik van Elburg" X-OriginalArrivalTime: 12 Mar 2009 13:50:13.0288 (UTC) FILETIME=[779A4A80:01C9A319] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 12 Mar 2009 06:55:56 -0700 Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:49:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A319.66BD4A8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 IF we would remove that requierment, and ONLY care about the case when the R-URI is replaced with the CONTACT, I don't think we need to do anything. I believe P-Called-Party-ID already solves that. =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: 12. maaliskuuta 2009 15:31 To: Hans Erik van Elburg Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Hans Erik, =20 The way I interpreted the 01 draft, you would not get the freephone number anyway. If that is a requirement, then I accept my suggestion won't suffice. =20 John ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 12 March 2009 12:57 To: Elwell, John Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 But that does not solve the freephone service use case. Freephone represents a use case where the R-URI is replaced with an AoR of user B - not with the contact of user B.=20 =09 A calls Bfreephonenumber routed the B (AOR) routed to B's contact. =09 The target-uri draft is interested in obtaining: Bfreephonenumber as that is what A used to reach B. =09 So what we like to see that B UA receives is something like H-I: Bfreephone; "istarget",\ B,\ contact-B =09 So you want to get Bfreephonenumber and not B. =09 In certain situations you are also interested in B, I guess that PBX's would interested in that to deliver to the correct user. We could distinguish them like: H-I: Bfreephone; "istarget",\ B,"aor"\ contact-B =09 BR, /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John wrote: =09 If 'istarget' is used only to identify the value that was overwritten in the Request-URI by a contact URI, an alternative approach would be to flag the contact URI H-I entry as 'iscontact'. Then the UAS would just need to look for the most recent H-I entry that is not marked 'iscontact'. =09 John =09 =09 ________________________________ =09 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 12 March 2009 08:35 To: Mary Barnes Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: =09 I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 Yes, because you are using the 3261 use of target and the 4244bis introduced definition of retarget. I thought it was clear that we need other words as those definitions don't match the target-uri drafts use of the terms. Also they do not suffice to provide a solution for the use cases in the target-uri draft. =09 The 3261 text you refer to is exactly about the case where the home proxy overwrites the Request-URI with a new target. This target is teh registered contact address. And hence this would be what target-uri calls a hop or a route. This case and this is where it gets confusing is not a "retarget" in the target-uri draft use of the term. =09 The target-uri draft states: =09 "To avoid confusion, we refer to a SIP URI that is an address for a user or resource as a "target" and a SIP URI that is a hop for reaching that user as a =09 "hop". =09 =09 Apparently that does not suffice to avoid confusion. =09 As for the tagging, speaking about the solution before agreeing on the terminology and the problem it should solve is meaningless. =09 /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes wrote: =09 =09 Responses below [MB]. =09 =09 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] =09 Sent: Wednesday, March 11, 2009 6:42 PM To: Barnes, Mary (RICH2:AR00) Cc: Shida Schubert; sip@ietf.org Subject: Re: Terminology (was RE: [Sip] Fwd: I-D =09 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 I was talking about the concept. =09 The use cases only describe cases where the target-uri (lets call that current target from now) has been lost when an initial request for a dialog or standalone request arrives at the UAS. =09 [MB] And I think this is where the terminology confusion starts - I don't think of the "lost" target-uri as being the "current" target. In my mind, the "current" target is reflected by the last hi-entry and the request-uri in the incoming request at the UAS. If the entity that sent the request was the entity that added the last hi-entry, then the uri in that hi-entry is the same as the request-URI in the SIP request that arrives at the UAS. I refer to the "lost" uri as the one that was "retargeted" - that's the one the UAS wants to pull from the hi-entries in the incoming request. That hi-entry was not the one that was just added by the entity that built the request just received by the UAS. That hi-entry is tagged with whatever name we are going to tag it with BEFORE the request is forwarded (using the term forward per section 16.6 of RFC 3261). That tag is added once the target set of potential candidates for the new request uri are determined in section 16.5 of 3261 (with "target set" being a 3261 term), just before the request is forwarded in section 16.6 to one of those targets. A new hi-entry (which will be the last hi-entry in the request received by the UAS) is added in section 16.6 of 3261 as the request is forwarded. At this point in time, the lost information is in the previous hi-entry when the outgoing request is sent. [/MB] =09 =09 What has been lost is the current target of the request: =09 [MB] Right - at which point in my mind, it's no longer the current target ;) Maybe we call it "lost". [/MB] =09 =09 =09 Current target =09 The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. =09 =09 [MB] I don't think this definition fits what you want - i.e., if there is no retargeting, then none of the hi-entries are tagged - i.e., you won't have your concept of current. The way it works is that if no hi-entries are tagged, then you know that there was no retargeting, thus you know the request-uri has not been lost. [/MB] =09 =09 This defintion only makes sense when the following definitions are used: =09 Name: =09 A name is a moniker for an entity which refers to it in a way which =09 reveals nothing about where it is in a network. In SIP, tel URI =09 which doesn't represent the location of the entity is a name. =09 =09 Address: =09 An address is an identifier for an entity which describes it by its =09 location on the network. In SIP, the SIP URI itself is a form of =09 address because the host part of the URI, the only mandatory part of =09 the URI besides the scheme itself, indicates the location of a SIP =09 server that can be used to handle the request. =09 Route: =09 Finally, a route is a sequence of SIP entities (including the UA itself!) which are =09 traversed in order to forward a request to an address or name. =09 Retarget (other term might be needed, as this is highly confusing): =09 A Request-URI rewrite operation that changes the target identity of the request. =09 Reroute (other term might be needed): =09 A Request-URI rewrite operation that does not change the current target of the request, but determines the route/next hop taken to reach the target-identity. =09 /Hans Erik =09 Mary Barnes wrote: > So, by "target-uri concept" are you referring to the solution in the > current target-uri draft or the application usage as such in the > target-uri document (which is what I was referring to)? > > Yes, the problem is that SIP doesn't differentiate the various > mechanisms by which a request-URI may be changed, which is what some > of the updated text in 4244bis is trying to do and why we need precise =09 > terms. I think we all agree that. > > I honestly don't care what we call the tag, as long as we're clear > about the functionality. > > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, March 11, 2009 4:40 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > The target-uri concept when defined properly is entirely application > agnostic. > > When one uses History-Info or another header as a vehicle for this > information then it still can be considered application agnostic as > any application can use this information as it likes. > > From SIP perspective all the Request-URI rewrites look the same, that =09 > is what brought us discussing this in the first place. > > /Hans Erik > > Mary Barnes wrote: > >> And, I think the big issue with the terminology is that 4244bis is >> application agnostic, so it is tagging what happens to the URIs >> (why/how the specific URI was overwritten). Whereas, specific >> applications can derive information, such as what "is" the real >> "target" for the request, from the History-Info header. So, IMHO, >> it's a matter of the target-uri document specifying that the last >> entry tagged by whatever name we come up with "is" the real "target" >> for the request. I believe it's up to the applications to describe >> how they make use of the History-Info and not for the History-Info to =09 >> describe how applications can use it. History-Info purely reflects >> what happened from a SIP Protocol perspective and should not imply >> any >> > > >> application semantics. Indeed the intent of section 5 of 4244 was to >> inform the applications how they should decribe their usage of the >> header. >> >> Mary. >> Note: I changed the subject to hopefully make this topic easier to >> keep track of. >> >> =09 --------------------------------------------------------------------- >> - >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Wednesday, March 11, 2009 3:59 AM >> *To:* Shida Schubert >> *Cc:* sip@ietf.org List; Barnes, Mary (RICH2:AR00) >> *Subject:* Re: [Sip] Fwd: I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >> >> One of the problems that made the discussion quite tedious is the >> complete inversed meaning of the terms "retarget" and "reroute" >> between 4244bis and target-uri factions have. >> >> Conclusion was that the terminology need to be properly defined and >> some attempt was made to start such activity. >> >> On 3. I have strong concerns when we start tagging the URI as to how >> they come about "retarget"/"mapped conficuration" etc. It is better >> to >> > > >> embellish them with a tag that just represents there meaning for >> example "istarget" or "hop". For the following reasons: >> 1. It is much more intuitive for the user of this information, its >> meaning can basically be guessed. >> 2. Such meaning also probably survives application in other problem >> spaces that we had not foreseen when introducing the concept. >> >> The solution that is described now in the target-URI delivery draft >> is not yet complete, it does not solve the freephone use case for >> example and in its current form it will deliver exactly the same >> target-URI as that which would be delivered by the P-Called-Party-ID =09 >> header. Contrary to what the draft says. So some work is needed still. >> >> /Hans Erik van Elburg >> >> >> On Wed, Mar 11, 2009 at 7:13 AM, Shida Schubert > > wrote: >> >> >> We have submitted the updated target-uri draft based on the >> > comments > >> submitted to the list and comments received at IETF73. >> >> I have taken over as editor as Jonathan didn't have the cycles to =09 >> update the draft, with Francois, Christer and Hans Erick as >> additional >> co-authors and great deal of help from Mary. >> >> The following summarizes the changes made to the target-uri >> > document > >> 1. Added use-case for toll-free number back >> 2. Added definition of "retarget" operation. >> 3. Removed a reference to URN >> 4. Added a text discussing the difference to P-Called-Party-Id >> 5. Changed parameter name from "target" to "istarget" >> >> Note, that the target-uri document still contains the normative >> text for the >> History-Info header. >> >> In addition, Mary (with Francois as co-author) has submitted a >> rfc4244bis, with the following changes: >> 1. Incorporated the normative aspects of the target-uri document >> into the existing normative text in RFC 4244 - the functionality >> > is > >> virtually identical (as is some of the text) as the HI based >> > solution > >> described in the target-uri document. It's important that the >> solution >> be integrated into RFC 4244 as it MUST work and be based on the >> normative >> aspects of RFC 4244. >> 2. Added the use cases from target-uri the the summary >> in the overview of rfc4244bis. >> 3. Added an additional requirement to capture the "target-uri" >> information. >> 4. Fixed an error in the RFC 4244 ABNF and added "retarget" >> > parameter. > >> 5. Added a more simplified example. >> >> >> We had some very long offline exchanges as to the best way >> forward >> > and > >> remaining work for both documents. >> >> Some of the issues identified are: >> >> ::Issues:: >> 1. Should we remove the normative text from target-uri and >> > progress > >> 4244bis along with the target-uri document to meet the >> chartered >> SIP WG milestone? >> >> >> 2. Name of the parameter. >> At the last meeting, parameter "target" was said >> > inappropriate > >> because voicemail-uri spec already defines a parameter >> > called > >> "target" which also can be found in hi-entry, thus >> > potentially > >> causing confusion. >> >> Currently the target-uri draft uses "istarget" and 4244bis >> > uses > >> "retarget" but we could never come to >> a consensus on what name is appropriate. Other suggestions >> > have > >> included the following: >> "target-identity" (someone didn't like that "identity" is >> also a SIP header) >> "reg-uri" (can be paired with "mapped-uri" for item 3 >> > below) > >> "aor" >> "jibberish" >> etc. >> >> One reason this is so difficult relates to the problem >> statement in target-uri in that >> RFC 3261 doesn't differentiate the mechanism by which the >> > new > >> (target) Request-URI is selected. Another issue is that >> some of the terminology in >> RFC 3261 is overloaded - e.g., "forwarding" refers both to a >> Proxy >> which does not have responsibility for the domain of the >> request-URI >> in the incoming request, thus the proxy just "forwards" the >> request to >> the next hop AND "forwarding" is used to describe the >> process whereby >> the outgoing request is built and "forwarded" to the next >> hop at which >> point the proxy does not know how the new request-uri was >> selected. >> RFC 4244 has attempted to clarify the terms and attempts to >> use "forward" >> in the context of the former situation and "retarget" for >> the case whereby >> a proxy is responsible for the domain and thus can use a >> number of >> mechanism to select the new target for the request - e.g., a >> REGISTRAR, >> configured data, etc. >> >> 3. Related to the last point in item 2 above, it has been >> proposed that >> we differentiate the hi-entries even more by defining >> separate parameters >> for registered and configured/mapped contacts. >> Currently when the R-URI is translated to a URI which is >> either derived >> from location service lookup(registered by UA) or from >> > mapping > >> table, there is no differentiation as to how the URI was >> derived once it is >> added to the list of potential targets. >> >> The general consensus of the authors of the two documents was >> that it may >> be useful for some services to have the hi-entries tagged >> with the >> more specific information. >> >> And, of course, this gets us into another naming contest. In >> the end, the naming >> is not so important as long as the term isn't too overloaded >> and it is defined >> precisely in the document(s). >> >> We would appreciate WG feedback on these issues and any other >> comments on >> the two documents prior to IETF-74. >> >> Regards, >> Shida and Mary. >> >> >> >> Begin forwarded message: >> >>> *From: *Internet-Drafts@ietf.org >>> > > >>> *Date: *March 10, 2009 2:30:01 AM JST >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D >>> =09 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt * >>> *Reply-To: *internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line >>> > Internet-Drafts > >>> directories. >>> >>> >>> Title >>> : Delivery of Request-URI Targets to User Agents >>> Author(s) >>> : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert >>> Filename : draft-rosenberg-sip-target-uri-delivery-01.txt >>> Pages >>> : 16 >>> Date >>> : 2009-3-9 >>> >>> When a Session Initiation Protocol (SIP) proxy receives a request >>> targeted at a URI identifying a user or resource it is >>> > responsible > >>> for, the proxy translates the URI to a registered or configured >>> contact URI of an agent representing that user or resource. >>> In >>> > the > >>> process, the original URI is removed from the request. >>> Numerous use >>> cases have arisen which require this information to be >>> > delivered to > >>> the user agent. This document describes these use cases and >>> defines >>> an extension to the History-Info header field which allows it >>> > to be > >>> used to support those cases. >>> >>> A URL for this Internet-Draft is: >>> >>> =09 http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-d >>> e >>> livery-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> Content-Type: text/plain
Content-ID: >> <2009-3-9102756.I-D@ietf.org =20 =09 > =09 >> >

>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> =09 https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current >> > sip > >> Use sipping@ietf.org for new >> developments on the application of sip >> >> >> =09 =09 =09 =09 ------_=_NextPart_001_01C9A319.66BD4A8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
IF we would = remove that=20 requierment, and ONLY care about the case when the R-URI is = replaced with=20 the CONTACT, I don't think we need to do anything. I believe = P-Called-Party-ID=20 already solves that.
 
Regards,
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, = John
Sent:=20 12. maaliskuuta 2009 15:31
To: Hans Erik van = Elburg
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Terminology (was RE: Fwd:=20 = I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Hans Erik,
 
The way I interpreted the 01 draft, you would not get = the=20 freephone number anyway. If that is a requirement, then I accept my = suggestion=20 won't suffice.
 
John

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: 12 March 2009=20 12:57
To: Elwell, John
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Terminology (was RE: Fwd:=20 = I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

But that does not solve the freephone service use case.=20 Freephone represents a use case where the R-URI is replaced with an = AoR of=20 user B - not with the contact of user B.

A calls = Bfreephonenumber=20 routed the B (AOR) routed to B's contact.

The target-uri = draft is=20 interested in obtaining: Bfreephonenumber as that is what A used to = reach=20 B.

So what we like to see that B UA receives is something=20 like
    H-I:  Bfreephone;=20 "istarget",\
       =20 B,\
        contact-B

So you = want to=20 get Bfreephonenumber and not B.

In certain situations you are = also=20 interested in B, I guess that  PBX's would interested in that = to=20 deliver to the correct user. We could distinguish them=20 like:
    H-I:  Bfreephone;=20 "istarget",\
       =20 B,"aor"\
        = contact-B

BR,/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 12:08 PM, Elwell, = John <john.elwell@siemens.com>=20 wrote:
If=20 'istarget' is used only to identify the value that was overwritten = in
the Request-URI by a contact URI, an alternative approach = would be=20 to
flag the contact URI H-I entry as 'iscontact'. Then the UAS = would=20 just
need to look for the most recent H-I entry that is not=20 = marked
'iscontact'.

John


___________________________= _____

 =20      From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] = On
Behalf=20 Of Hans Erik van Elburg
       Sent: 12 = March 2009=20 08:35
       To: Mary Barnes
  =  =20    Cc: sip@ietf.org
 =20      Subject: Re: [Sip] Terminology (was RE:=20 = Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


       Yes, because = you are=20 using the 3261 use of target and the
4244bis introduced = definition of=20 retarget. I thought it was clear that
we need other words as = those=20 definitions don't match the target-uri
drafts use of the terms. = Also=20 they do not suffice to provide a solution
for the use cases in = the=20 target-uri draft.

       The 3261 text = you=20 refer to is exactly about the case where the
home proxy = overwrites the=20 Request-URI with a new target. This target is
teh registered = contact=20 address. And hence this would be what target-uri
calls a hop or = a=20 route. This case and this is where it gets confusing is
not a=20 "retarget" in the target-uri draft use of the term.

  =  =20    The target-uri draft states:

    =  =20     "To avoid confusion, we
      =  =20   refer to a SIP URI that is an address for a user or = resource
as=20 a
          "target" and a SIP URI = that is a=20 hop for reaching that user
as a

      =  =20   "hop".


       Apparently = that does=20 not suffice to avoid confusion.

      =  As for=20 the tagging, speaking about the solution before agreeing
on the = terminology and the problem it should solve is = meaningless.

 =20      /Hans Erik van Elburg



  =  =20    On Thu, Mar 12, 2009 at 2:33 AM, Mary = Barnes
<mary.barnes@nortel.com>=20 wrote:


              =  Responses below [MB].


        =  =20      -----Original Message-----
    =  =20          From: Hans Erik van = Elburg
[mailto:ietf.hanserik@gmail.com]
<= BR> =20              Sent: Wednesday, = March 11,=20 2009 6:42 PM
              =  To:=20 Barnes, Mary (RICH2:AR00)
          =  =20    Cc: Shida Schubert; sip@ietf.org
    =    =20        Subject: Re: Terminology (was RE: [Sip] = Fwd:=20 I-D
             =20 =  ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


&n= bsp;=20              I was talking = about the=20 concept.

              =  The=20 use cases only describe  cases where the target-uri
(lets = call=20 that
              =  current=20 target from now) has been lost when an initial
request for = a
 =20              dialog or = standalone=20 request arrives at the UAS.

        =  =20      [MB] And I think this is where the terminology = confusion
starts - I
          =  =20    don't think of the "lost" target-uri as being=20 the
"current" target. In
          =  =20    my mind, the "current" target is reflected by the=20 last
hi-entry and the
          =  =20    request-uri in the incoming request at the UAS. If=20 the
entity that sent
          =  =20    the request was the entity that added the last=20 hi-entry,
then the uri in
          =  =20    that hi-entry is the same as the request-URI in the=20 SIP
request that
            =  =20  arrives at the UAS. I refer to the "lost" uri as the = one
that=20 was
              =  "retargeted"=20 - that's the one the UAS wants to pull from
the = hi-entries
 =20              in the incoming = request.=20 That hi-entry was not the one
that was just
    =  =20          added by the entity that built = the=20 request just received
by the UAS.
      =    =20      That hi-entry is tagged with whatever name we = are=20 going
to tag it with
          =  =20    BEFORE the request is forwarded (using the term=20 forward
per section 16.6
          =  =20    of RFC 3261).  That tag is added once the target = set=20 of
potential
            =  =20  candidates for the new request uri are determined = in
section 16.5=20 of
               3261 = (with=20 "target set" being a 3261 term), just before
the request = is
 =20              forwarded in = section 16.6=20 to one of those targets.  A
new hi-entry
    =  =20          (which will be the last hi-entry = in the=20 request received
by the UAS) is
        =  =20      added in section 16.6 of 3261 as the request=20 is
forwarded.  At this
        =  =20      point in time, the lost information is in the=20 previous
hi-entry when the
        =    =20    outgoing request is sent. [/MB]


  =  =20            What has been lost is the = current=20 target of the request:

          =  =20    [MB] Right - at which point in my mind, it's no = longer
the=20 current
              =  target=20 ;) Maybe we call it "lost". [/MB]



    =  =20               Current=20 target

              =  =20  The current target of an initial request for a dialog
or=20 standalone
              =  =20  request is the name or address to which the request = is
targeted,=20 i.e.
               =20  either the initial target inserted in the Request-URI
by = the UAC=20 that
               =20  originates the request, or when a retarget occurred,
the=20 target
               =20  provided in that retarget operation.  Reroute=20 and
translation
            =  =20    operations never change the current = target.


 =20              [MB] I don't think = this=20 definition fits what you want -
i.e., if there
    =  =20          is no retargeting, then none of = the=20 hi-entries are
tagged - i.e., you
      =    =20      won't have your concept of current. The way it = works=20 is
that if no
            =  =20  hi-entries are tagged, then you know that there was=20 no
retargeting, thus
          =  =20    you know the request-uri has not been lost.=20 [/MB]


             =20  This defintion only makes sense when the = following
definitions=20 are used:

             =20  Name:

            =    =20  A name is a moniker for an entity which refers to it
in a = way=20 which

              =  =20  reveals nothing about where it is in a network. =  In
SIP, tel=20 URI

                =  which doesn't represent the location of the entity is
a=20 name.


             =20  Address:

            =  =20    An address is an identifier for an entity = which
describes=20 it by its

              =  =20  location on the network.  In SIP, the SIP URI = itself
is a=20 form of

              =  =20  address because the host part of the URI, the = only
mandatory part=20 of

               =20  the URI besides the scheme itself, indicates the
location = of a=20 SIP

                =  server that can be used to handle the request.

  =  =20            Route:

  =  =20              Finally, a route = is a=20   sequence of SIP entities
(including the UA
  =  =20            itself!) which = are

 =20               traversed in = order to=20 forward a request to an address
or name.

    =  =20          Retarget (other term might be = needed, as=20 this is highly
confusing):

        =  =20         A Request-URI rewrite operation that = changes=20 the
target identity of
          =  =20    the request.

        =    =20    Reroute (other term might be needed):

  =  =20               A Request-URI = rewrite=20 operation that does not change
the current
    =  =20          target of the request, but =    =20 determines the route/next
hop taken to
      =  =20        reach the = target-identity.

   =20            /Hans Erik

  =  =20            Mary Barnes = wrote:
 =20              > So, by = "target-uri=20 concept" are you referring to the
solution in the
  =  =20            > current target-uri = draft or=20 the application usage as
such in the
      =  =20        > target-uri document (which is what = I was=20 referring
to)?
            =  =20  >
              =  >=20 Yes, the problem is that SIP doesn't differentiate=20 the
various
              =  > mechanisms by which a request-URI may be = changed,
which is=20 what some
              =  >=20 of the updated text in 4244bis is trying to do and why
we need=20 precise

              =  >=20 terms. I think we all agree that.
        =  =20      >
          =  =20    > I honestly don't care what we call the tag, as = long=20 as
we're clear
            =  =20  > about the functionality.
        =  =20      >
          =  =20    > Mary.
          =  =20    >
            =  =20  > -----Original Message-----
      =  =20        > From: Hans Erik van = Elburg
[mailto:ietf.hanserik@gmail.com]
&= nbsp;=20              > Sent: = Wednesday,=20 March 11, 2009 4:40 PM
          =    =20  > To: Barnes, Mary (RICH2:AR00)
      =  =20        > Cc: Shida Schubert; sip@ietf.org
    =    =20        > Subject: Re: Terminology (was RE: = [Sip]=20 Fwd: I-D
              =  >=20 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
  =  =20            >
    =  =20          > The target-uri concept when = defined=20 properly is
entirely application
        =  =20      > agnostic.
        =  =20      >
          =  =20    > When one uses History-Info or another header as=20 a
vehicle for this
            =  =20  > information then it still can be = considered
application=20 agnostic as
              =  >=20 any application can use this information as it likes.
  =  =20            >
    =  =20          >  From SIP perspective = all the=20 Request-URI rewrites
look the same, that

    =  =20          > is what brought us = discussing this=20 in the first place.
            =  =20  >
              =  >=20 /Hans Erik
             =20  >
              =  >=20 Mary Barnes wrote:
            =  =20  >
             =20  >> And, I think the big issue with the terminology = is
that=20 4244bis is
             =20  >> application agnostic, so it is tagging what = happens
to=20 the URIs
             =20  >> (why/how the specific URI was overwritten).=20  Whereas,
specific
          =  =20    >> applications can derive information, such as = what
"is" the real
            =  =20  >> "target" for the request, from the = History-Info
header.=20   So, IMHO,
            =  =20  >> it's a matter of the target-uri document = specifying
that=20 the last
             =20  >> entry tagged by whatever name we come up with = "is"
the=20 real "target"
             =20  >> for the request.  I believe it's up to=20 the
applications to describe
        =  =20      >> how they make use of the History-Info = and not=20 for the
History-Info to

        =  =20      >> describe how applications can use it. =  History-Info
purely reflects
      =  =20        >> what happened from a SIP = Protocol=20 perspective and
should not imply
        =  =20      >> any
        =  =20      >>
          =  =20    >
            =  =20  >
             =20  >> application semantics. Indeed the intent of section = 5
of=20 4244 was to
             =20  >> inform the applications how they should decribe=20 their
usage of the
            =  =20  >> header.
          =    =20  >>
              =  >> Mary.
            =  =20  >> Note: I changed the subject to hopefully make = this
topic=20 easier to
             =20  >> keep track of.
        =    =20    >>
            =  =20 =  >>
-------------------------------------------------------= --------------
 =20              >> = -
 =20              >> = --
 =20              >> *From:* = Hans Erik=20 van Elburg
[mailto:ietf.hanserik@gmail.com]
&= nbsp;=20              >> *Sent:*=20 Wednesday, March 11, 2009 3:59 AM
        =  =20      >> *To:* Shida Schubert
    =  =20          >> *Cc:* sip@ietf.org List; Barnes, Mary=20 (RICH2:AR00)
             =20  >> *Subject:* Re: [Sip] Fwd: I-D
    =  =20          >>=20 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
  =  =20            >>
    =  =20          >> One of the problems = that made=20 the discussion quite
tedious is the
      =  =20        >> complete inversed meaning of = the terms=20 "retarget" and
"reroute"
          =  =20    >> between 4244bis and target-uri factions=20 have.
             =20  >>
              =  >> Conclusion was that the terminology need to = be
properly=20 defined and
             =20  >> some attempt was made to start such = activity.
 =20              >>
  =  =20            >> On 3. I have = strong=20 concerns when we start tagging
the URI as to how
  =  =20            >> they come about=20 "retarget"/"mapped conficuration"
etc. It is better
  =  =20            >> to
  =  =20            >>
    =  =20          >
      =  =20        >
        =  =20      >> embellish them with a tag that just=20 represents there
meaning for
        =  =20      >> example "istarget" or "hop". For the=20 following
reasons:
            =  =20  >> 1. It is much more intuitive for the user of=20 this
information, its
          =  =20    >> meaning can basically be guessed.
  =  =20            >> 2. Such meaning = also=20 probably survives application in
other problem
    =  =20          >> spaces that we had not = foreseen=20 when introducing the
concept.
        =  =20      >>
          =  =20    >> The solution that is  described now in = the=20 target-URI
delivery draft
          =  =20    >> is not yet complete, it does not solve the=20 freephone
use case for
          =  =20    >> example and in its current form it will=20 deliver
exactly the same
          =  =20    >> target-URI as that which would be delivered = by=20 the
P-Called-Party-ID

          =  =20    >> header. Contrary to what the draft says. So = some=20 work
is needed
            =  =20  still.
             =20  >>
              =  >> /Hans Erik van Elburg
      =    =20      >>
          =  =20    >>
            =  =20  >> On Wed, Mar 11, 2009 at 7:13 AM, Shida = Schubert
<shida@ntt-at.com
  =  =20            >> <mailto:shida@ntt-at.com>>=20 wrote:
             =20  >>
              =  >>
              =  >>     We have submitted the updated = target-uri=20 draft
based on the
            =  =20  >>
              =  > comments
            =  =20  >
             =20  >>     submitted to the list and comments = received=20 at
IETF73.
             =20  >>
              =  >>     I have taken over as editor as = Jonathan=20 didn't
have the cycles to

        =  =20      >>     update the draft, with=20 Francois, Christer and
Hans Erick as
      =  =20        >>     = additional
 =20              >>   =  =20 co-authors and great deal of help from Mary.
    =  =20          >>
      =  =20        >>     The following = summarizes=20 the changes made to the
target-uri
      =  =20        >>
        =  =20      > document
        =  =20      >
          =  =20    >>     1. Added use-case for = toll-free number=20 back
              =  >>=20     2. Added definition of "retarget" = operation.
 =20              >>   =   3.=20 Removed a reference to URN
          =  =20    >>     4. Added a text discussing the = difference to
P-Called-Party-Id
        =  =20      >>     5. Changed parameter = name from=20 "target" to
"istarget"
          =  =20    >>
            =  =20  >>     Note, that the target-uri document = still=20 contains
the normative
          =  =20    >>     text for the
    =  =20          >>     = History-Info=20 header.
             =20  >>
              =  >>     In addition, Mary (with Francois as=20 co-author)
has submitted a
        =    =20    >>     rfc4244bis, with the following = changes:
             =20  >>     1. Incorporated the normative aspects = of=20 the
target-uri document
          =  =20    >>     into the existing normative = text in=20 RFC 4244 -
the functionality
        =  =20      >>
          =  =20    > is
            =  =20  >
             =20  >>     virtually identical (as is some of = the text)=20 as
the HI based
            =  =20  >>
              =  > solution
            =  =20  >
             =20  >>     described in the target-uri document. =  It's
important that the
        =  =20      >>     solution
  =  =20            >>     be = integrated into RFC 4244 as it MUST work and
be based on = the
 =20              >>   =  =20 normative
             =20  >>     aspects of RFC 4244.
    =  =20          >>     2. =  Added=20 the use cases from target-uri the the
summary
    =  =20          >>     in the = overview=20 of rfc4244bis.
              =  >>     3. Added an additional requirement to = capture=20 the
"target-uri"
            =  =20  >>     information.
      =  =20        >>     4. Fixed an = error in the=20 RFC 4244 ABNF and added
"retarget"
      =  =20        >>
        =  =20      > parameter.
        =  =20      >
          =  =20    >>     5. Added a more simplified=20 example.
             =20  >>
              =  >>
              =  >>     We had some very long offline = exchanges as to=20 the
best way
            =  =20  >> forward
          =    =20  >>
              =  > and
              =  >
             =20  >>     remaining work for both = documents.
 =20              >>
  =  =20            >>     = Some of=20 the issues identified are:
          =  =20    >>
            =  =20  >>     ::Issues::
      =  =20        >>        1. = Should=20 we remove the normative text from
target-uri and
  =  =20            >>
    =  =20          > progress
    =  =20          >
      =  =20        >>         =  =20  4244bis along with the target-uri document
to meet = the
 =20              >>   =  =20 chartered
             =20  >>           SIP WG=20 milestone?
             =20  >>
              =  >>
              =  >>        2. Name of the=20 parameter.
             =20  >>           At the last = meeting,=20 parameter "target" was
said
        =  =20      >>
          =  =20    > inappropriate
        =  =20      >
          =  =20    >>           because=20 voicemail-uri spec already defines
a parameter
    =  =20          >>
      =  =20        > called
      =  =20        >
        =  =20      >>           = "target"=20 which also can be found in
hi-entry, thus
    =  =20          >>
      =  =20        > potentially
    =    =20        >
        =  =20      >>           = causing=20 confusion.
             =20  >>
              =  >>           Currently the = target-uri=20 draft uses
"istarget" and 4244bis
      =    =20      >>
          =  =20    > uses
          =    =20  >
             =20  >>           "retarget" =  but we=20 could never come to
            =  =20  >>           a consensus on = what name=20 is appropriate.
Other suggestions
      =    =20      >>
          =  =20    > have
          =    =20  >
             =20  >>           included the=20 following:
             =20  >>           = "target-identity"=20 (someone didn't like that
"identity" is
      =  =20        >>     also a SIP=20 header)
              =  >>=20           "reg-uri"  (can be paired = with=20 "mapped-uri"
for item 3
          =  =20    >>
            =  =20  > below)
            =  =20  >
             =20  >>           "aor"
  =  =20            >>     =  =20     "jibberish"
          =  =20    >>           = etc.
 =20              >>
  =  =20            >>     =  =20     One reason this is so difficult relates to
the=20 problem
              =  >>=20     statement in target-uri in that
    =  =20          >>       =  =20   RFC 3261 doesn't differentiate the
mechanism by which=20 the
             =20  >>
              =  > new
              =  >
             =20  >>           (target) = Request-URI is=20 selected.  Another
issue is that
      =  =20        >>     some of the = terminology=20 in
              =  >>=20           RFC 3261 is overloaded - e.g.,=20 "forwarding"
refers both to
        =  =20      a
            =  =20  >>     Proxy
        =  =20      >>           = which does=20 not have responsibility for the
domain of the
    =  =20          >>    =20 request-URI
             =20  >>           in the incoming = request,=20 thus the proxy
just "forwards" the
      =  =20        >>     request = to
 =20              >>   =  =20       the next hop AND "forwarding" is used = to
describe=20 the
              =  >>=20     process whereby
        =    =20    >>           the = outgoing=20 request is built and
"forwarded" to the next
    =  =20          >>     hop at=20 which
              =  >>=20           point the proxy does not know = how the=20 new
request-uri was
          =    =20  >>     selected.
      =  =20        >>         =   RFC=20 4244 has attempted to clarify the terms
and attempts = to
 =20              >>   =   use=20 "forward"
             =20  >>           in the context = of the=20 former situation and
"retarget" for
      =  =20        >>     the case=20 whereby
              =  >>=20           a proxy is responsible for the = domain=20 and
thus can use a
            =  =20  >>     number of
      =  =20        >>         =  =20 mechanism to select the new target for the
request - = e.g.,
 =20              a
    =  =20          >>    =20 REGISTRAR,
             =20  >>           configured data, = etc.
             =20  >>
              =  >>      3.  Related to the last = point in=20 item 2 above,
it has been
          =  =20    >>     proposed that
    =  =20          >>       =  =20   we differentiate the hi-entries even more
by = defining
 =20              >>   =  =20 separate parameters
            =  =20  >>          for registered = and=20 configured/mapped
contacts.
        =  =20      >>         =  Currently=20 when the R-URI is translated to a
URI which is
    =  =20          >>     either=20 derived
              =  >>=20          from location service = lookup(registered=20 by
UA) or from
            =  =20  >>
              =  > mapping
            =  =20  >
             =20  >>          table, there is = no=20 differentiation as to how
the URI was
      =  =20        >>     derived once it=20 is
              =  >>=20          added to the list of potential=20 targets.
             =20  >>
              =  >>          The general = consensus of=20 the authors of the
two documents
        =  =20      was
          =  =20    >>     that it may
    =  =20          >>       =  =20  be useful for some services to have the
hi-entries=20 tagged
              =  >>=20     with the
          =    =20  >>          more specific=20 information.
             =20  >>
              =  >>          And, of course, = this gets=20 us into another
naming contest. In
      =  =20        >>     the end, the=20 naming
              =  >>=20          is not so important as long as = the=20 term
isn't too overloaded
          =  =20    >>     and it is defined
  =  =20            >>     =  =20    precisely in the document(s).
      =  =20        >>
        =  =20      >>     We would appreciate WG = feedback=20 on these issues
and any other
        =  =20      >>     comments on
  =  =20            >>     = the two=20 documents prior to IETF-74.
          =  =20    >>
            =  =20  >>     Regards,
      =  =20        >>     Shida and=20 Mary.
             =20  >>
              =  >>
              =  >>
              =  >>     Begin forwarded message:
  =  =20            >>
    =  =20          >>>     = *From: *Internet-Drafts@ietf.org
=  =20             =  >>>
 =20              > <mailto:Internet-Drafts@ietf.org>=
 =20              >
  =  =20            >>>   =   *Date:=20 *March 10, 2009 2:30:01 AM JST
        =  =20      >>>     *To: *i-d-announce@ietf.org
<ma= ilto:i-d-announce@ietf.org>
&n= bsp;=20              >>> =    =20 *Subject: **I-D
            =  =20 =  >>>
ACTION:draft-rosenberg-sip-target-uri-delivery-01.t= xt=20 *
              =  >>>=20     *Reply-To: *internet-drafts@ietf.org
=  =20              >>> =    =20 <mailto:internet-drafts@ietf.org>=
 =20             =  >>>
 =20              >>> =    =20 A New Internet-Draft is available from the
on-line
  =  =20            >>>
  =  =20            > = Internet-Drafts
 =20              >
  =  =20            >>>   =  =20 directories.
             =20  >>>
            =  =20  >>>
            =  =20  >>>     Title
      =  =20        >>>     : Delivery = of=20 Request-URI Targets to User Agents
        =  =20      >>>     Author(s)
  =  =20            >>>   =   : J.=20 Rosenberg, H. van Elburg, C. Holmberg, F.
Audet, S.
  =  =20            Schubert
    =  =20          >>>     = Filename=20 :
draft-rosenberg-sip-target-uri-delivery-01.txt
  =  =20            >>>   =  =20 Pages
             =20  >>>     : 16
      =  =20        >>>     = Date
 =20              >>> =    =20 : 2009-3-9
             =20  >>>
            =  =20  >>>     When a Session Initiation = Protocol (SIP)=20 proxy
receives a
            =  =20  request
             =20  >>>       targeted at a URI = identifying a=20 user or
resource it is
          =  =20    >>>
          =  =20    > responsible
        =    =20    >
            =  =20  >>>       for, the proxy translates = the URI=20 to a
registered or
            =  =20  configured
            =  =20  >>>       contact URI of an agent=20 representing that user
or resource.
      =  =20        >>> In
      =  =20        >>>
      =  =20        > the
        =  =20      >
          =  =20    >>>       process, the = original URI=20 is removed from the
request.
        =  =20      >>>      Numerous=20 use
              =  >>>=20       cases have arisen which require = this
information=20 to be
             =20  >>>
            =  =20  > delivered to
          =  =20    >
            =  =20  >>>       the user agent.  This = document describes these
use cases and
      =  =20        >>>     = defines
 =20              >>> =    =20   an extension to the History-Info header field
which = allows=20 it
             =20  >>>
            =  =20  > to be
            =  =20  >
             =20  >>>       used to support those=20 cases.
             =20  >>>
            =  =20  >>>     A URL for this Internet-Draft=20 is:
             =20  >>>
            =  =20  >>>
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-t= arget-uri-d
 =20              >>> = e
 =20              >>>=20 livery-01.txt
             =20  >>>
            =  =20  >>>     Internet-Drafts are also = available by=20 anonymous
FTP at:
            =  =20  >>>     ftp://ftp.ietf.org/internet-drafts/
  =  =20            >>>
  =  =20            >>>   =   Below=20 is the data which will enable a MIME
compliant mail = reader
 =20              >>> =    =20 implementation to automatically retrieve the
ASCII version = of
 =20              the
  =  =20            >>>   =  =20 Internet-Draft.
            =  =20  >>>
            =  =20  >>     Content-Type:=20 text/plain<BR>Content-ID:
        =  =20      >>     &lt;2009-3-9102756.I-D@ie= tf.org
<mailto:lt%3B2009-3-9102756.I-= D@ietf.org>
             =20  >>     <mailto:2009-3-9102756.I-D@ietf.org>&gt;<BR><BR>
 =20              >>
  =  =20            >>>   =  =20 _______________________________________________
    =  =20          >>>     = I-D-Announce=20 mailing list
             =20  >>>     I-D-Announce@ietf.org
<ma= ilto:I-D-Announce@ietf.org>
&n= bsp;=20              >>>
https://www.ietf.org/mailman/listinfo/i-d-announce =20              >>> =    =20 Internet-Draft directories:
http://www.ietf.org/shadow.html
  =    =20          >>>     or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 =20             =  >>>
 =20              >>   =  =20 _______________________________________________
    =  =20          >>     Sip = mailing=20 list
https://www.ietf.org/mailman/listinfo/sip
 =20              >>   =  =20 This list is for NEW development of the core = SIP
Protocol
 =20              >>   =   Use=20 sip-implementors@cs.colu= mbia.edu
 =20              >>   =  =20 <mailto:sip-implementors@cs.colu= mbia.edu>=20 for
questions on
            =  =20  >> current
          =    =20  >>
              =  > sip
              =  >
             =20  >>     Use sipping@ietf.org = <mailto:sipping@ietf.org>
for=20 new
              =  >>=20     developments on the application of sip
  =  =20            >>
    =  =20          >>
      =  =20      =20 =  >>




------_=_NextPart_001_01C9A319.66BD4A8A-- From christer.holmberg@ericsson.com Thu Mar 12 07:06:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D603A6984 for ; Thu, 12 Mar 2009 07:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rE-qvjz9ITH for ; Thu, 12 Mar 2009 07:06:14 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 284B63A6806 for ; Thu, 12 Mar 2009 07:06:14 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5826120EB8; Thu, 12 Mar 2009 15:06:32 +0100 (CET) X-AuditID: c1b4fb3c-ad80abb000001b43-82-49b916e8adf9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1343720D58; Thu, 12 Mar 2009 15:06:32 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 15:06:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A31B.AF9F7A6C" Date: Thu, 12 Mar 2009 15:06:05 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001A27C50@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjEo9cACSfdpORRgqN7inoq6qTugABBxGAAAE170A= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com><49B82FB4.4030002@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com><49B84C55.5070107@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com><9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27C50@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Hans Erik van Elburg" X-OriginalArrivalTime: 12 Mar 2009 14:06:31.0631 (UTC) FILETIME=[BEBD95F0:01C9A31B] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:06:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A31B.AF9F7A6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 IF we would remove that requierment, and ONLY care about the case when the R-URI is replaced with the CONTACT, I don't think we need to do anything. I believe P-Called-Party-ID already solves that. =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: 12. maaliskuuta 2009 15:31 To: Hans Erik van Elburg Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Hans Erik, =20 The way I interpreted the 01 draft, you would not get the freephone number anyway. If that is a requirement, then I accept my suggestion won't suffice. =20 John ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 12 March 2009 12:57 To: Elwell, John Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 But that does not solve the freephone service use case. Freephone represents a use case where the R-URI is replaced with an AoR of user B - not with the contact of user B.=20 =09 A calls Bfreephonenumber routed the B (AOR) routed to B's contact. =09 The target-uri draft is interested in obtaining: Bfreephonenumber as that is what A used to reach B. =09 So what we like to see that B UA receives is something like H-I: Bfreephone; "istarget",\ B,\ contact-B =09 So you want to get Bfreephonenumber and not B. =09 In certain situations you are also interested in B, I guess that PBX's would interested in that to deliver to the correct user. We could distinguish them like: H-I: Bfreephone; "istarget",\ B,"aor"\ contact-B =09 BR, /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John wrote: =09 If 'istarget' is used only to identify the value that was overwritten in the Request-URI by a contact URI, an alternative approach would be to flag the contact URI H-I entry as 'iscontact'. Then the UAS would just need to look for the most recent H-I entry that is not marked 'iscontact'. =09 John =09 =09 ________________________________ =09 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 12 March 2009 08:35 To: Mary Barnes Cc: sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: =09 I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 Yes, because you are using the 3261 use of target and the 4244bis introduced definition of retarget. I thought it was clear that we need other words as those definitions don't match the target-uri drafts use of the terms. Also they do not suffice to provide a solution for the use cases in the target-uri draft. =09 The 3261 text you refer to is exactly about the case where the home proxy overwrites the Request-URI with a new target. This target is teh registered contact address. And hence this would be what target-uri calls a hop or a route. This case and this is where it gets confusing is not a "retarget" in the target-uri draft use of the term. =09 The target-uri draft states: =09 "To avoid confusion, we refer to a SIP URI that is an address for a user or resource as a "target" and a SIP URI that is a hop for reaching that user as a =09 "hop". =09 =09 Apparently that does not suffice to avoid confusion. =09 As for the tagging, speaking about the solution before agreeing on the terminology and the problem it should solve is meaningless. =09 /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes wrote: =09 =09 Responses below [MB]. =09 =09 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] =09 Sent: Wednesday, March 11, 2009 6:42 PM To: Barnes, Mary (RICH2:AR00) Cc: Shida Schubert; sip@ietf.org Subject: Re: Terminology (was RE: [Sip] Fwd: I-D =09 ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 I was talking about the concept. =09 The use cases only describe cases where the target-uri (lets call that current target from now) has been lost when an initial request for a dialog or standalone request arrives at the UAS. =09 [MB] And I think this is where the terminology confusion starts - I don't think of the "lost" target-uri as being the "current" target. In my mind, the "current" target is reflected by the last hi-entry and the request-uri in the incoming request at the UAS. If the entity that sent the request was the entity that added the last hi-entry, then the uri in that hi-entry is the same as the request-URI in the SIP request that arrives at the UAS. I refer to the "lost" uri as the one that was "retargeted" - that's the one the UAS wants to pull from the hi-entries in the incoming request. That hi-entry was not the one that was just added by the entity that built the request just received by the UAS. That hi-entry is tagged with whatever name we are going to tag it with BEFORE the request is forwarded (using the term forward per section 16.6 of RFC 3261). That tag is added once the target set of potential candidates for the new request uri are determined in section 16.5 of 3261 (with "target set" being a 3261 term), just before the request is forwarded in section 16.6 to one of those targets. A new hi-entry (which will be the last hi-entry in the request received by the UAS) is added in section 16.6 of 3261 as the request is forwarded. At this point in time, the lost information is in the previous hi-entry when the outgoing request is sent. [/MB] =09 =09 What has been lost is the current target of the request: =09 [MB] Right - at which point in my mind, it's no longer the current target ;) Maybe we call it "lost". [/MB] =09 =09 =09 Current target =09 The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. =09 =09 [MB] I don't think this definition fits what you want - i.e., if there is no retargeting, then none of the hi-entries are tagged - i.e., you won't have your concept of current. The way it works is that if no hi-entries are tagged, then you know that there was no retargeting, thus you know the request-uri has not been lost. [/MB] =09 =09 This defintion only makes sense when the following definitions are used: =09 Name: =09 A name is a moniker for an entity which refers to it in a way which =09 reveals nothing about where it is in a network. In SIP, tel URI =09 which doesn't represent the location of the entity is a name. =09 =09 Address: =09 An address is an identifier for an entity which describes it by its =09 location on the network. In SIP, the SIP URI itself is a form of =09 address because the host part of the URI, the only mandatory part of =09 the URI besides the scheme itself, indicates the location of a SIP =09 server that can be used to handle the request. =09 Route: =09 Finally, a route is a sequence of SIP entities (including the UA itself!) which are =09 traversed in order to forward a request to an address or name. =09 Retarget (other term might be needed, as this is highly confusing): =09 A Request-URI rewrite operation that changes the target identity of the request. =09 Reroute (other term might be needed): =09 A Request-URI rewrite operation that does not change the current target of the request, but determines the route/next hop taken to reach the target-identity. =09 /Hans Erik =09 =09 ------_=_NextPart_001_01C9A31B.AF9F7A6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
IF we would = remove that=20 requierment, and ONLY care about the case when the R-URI is = replaced with=20 the CONTACT, I don't think we need to do anything. I believe = P-Called-Party-ID=20 already solves that.
 
Regards,
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, = John
Sent:=20 12. maaliskuuta 2009 15:31
To: Hans Erik van = Elburg
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Terminology (was RE: Fwd:=20 = I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Hans Erik,
 
The way I interpreted the 01 draft, you would not get = the=20 freephone number anyway. If that is a requirement, then I accept my = suggestion=20 won't suffice.
 
John

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: 12 March 2009=20 12:57
To: Elwell, John
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Terminology (was RE: Fwd:=20 = I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

But that does not solve the freephone service use case.=20 Freephone represents a use case where the R-URI is replaced with an = AoR of=20 user B - not with the contact of user B.

A calls = Bfreephonenumber=20 routed the B (AOR) routed to B's contact.

The target-uri = draft is=20 interested in obtaining: Bfreephonenumber as that is what A used to = reach=20 B.

So what we like to see that B UA receives is something=20 like
    H-I:  Bfreephone;=20 "istarget",\
       =20 B,\
        contact-B

So you = want to=20 get Bfreephonenumber and not B.

In certain situations you are = also=20 interested in B, I guess that  PBX's would interested in that = to=20 deliver to the correct user. We could distinguish them=20 like:
    H-I:  Bfreephone;=20 "istarget",\
       =20 B,"aor"\
        = contact-B

BR,/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 12:08 PM, Elwell, = John <john.elwell@siemens.com>=20 wrote:
If=20 'istarget' is used only to identify the value that was overwritten = in
the Request-URI by a contact URI, an alternative approach = would be=20 to
flag the contact URI H-I entry as 'iscontact'. Then the UAS = would=20 just
need to look for the most recent H-I entry that is not=20 = marked
'iscontact'.

John


___________________________= _____

 =20      From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] = On
Behalf=20 Of Hans Erik van Elburg
       Sent: 12 = March 2009=20 08:35
       To: Mary Barnes
  =  =20    Cc: sip@ietf.org
 =20      Subject: Re: [Sip] Terminology (was RE:=20 = Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


       Yes, because = you are=20 using the 3261 use of target and the
4244bis introduced = definition of=20 retarget. I thought it was clear that
we need other words as = those=20 definitions don't match the target-uri
drafts use of the terms. = Also=20 they do not suffice to provide a solution
for the use cases in = the=20 target-uri draft.

       The 3261 text = you=20 refer to is exactly about the case where the
home proxy = overwrites the=20 Request-URI with a new target. This target is
teh registered = contact=20 address. And hence this would be what target-uri
calls a hop or = a=20 route. This case and this is where it gets confusing is
not a=20 "retarget" in the target-uri draft use of the term.

  =  =20    The target-uri draft states:

    =  =20     "To avoid confusion, we
      =  =20   refer to a SIP URI that is an address for a user or = resource
as=20 a
          "target" and a SIP URI = that is a=20 hop for reaching that user
as a

      =  =20   "hop".


       Apparently = that does=20 not suffice to avoid confusion.

      =  As for=20 the tagging, speaking about the solution before agreeing
on the = terminology and the problem it should solve is = meaningless.

 =20      /Hans Erik van Elburg



  =  =20    On Thu, Mar 12, 2009 at 2:33 AM, Mary = Barnes
<mary.barnes@nortel.com>=20 wrote:


              =  Responses below [MB].


        =  =20      -----Original Message-----
    =  =20          From: Hans Erik van = Elburg
[mailto:ietf.hanserik@gmail.com]
<= BR> =20              Sent: Wednesday, = March 11,=20 2009 6:42 PM
              =  To:=20 Barnes, Mary (RICH2:AR00)
          =  =20    Cc: Shida Schubert; sip@ietf.org
    =    =20        Subject: Re: Terminology (was RE: [Sip] = Fwd:=20 I-D
             =20 =  ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


&n= bsp;=20              I was talking = about the=20 concept.

              =  The=20 use cases only describe  cases where the target-uri
(lets = call=20 that
              =  current=20 target from now) has been lost when an initial
request for = a
 =20              dialog or = standalone=20 request arrives at the UAS.

        =  =20      [MB] And I think this is where the terminology = confusion
starts - I
          =  =20    don't think of the "lost" target-uri as being=20 the
"current" target. In
          =  =20    my mind, the "current" target is reflected by the=20 last
hi-entry and the
          =  =20    request-uri in the incoming request at the UAS. If=20 the
entity that sent
          =  =20    the request was the entity that added the last=20 hi-entry,
then the uri in
          =  =20    that hi-entry is the same as the request-URI in the=20 SIP
request that
            =  =20  arrives at the UAS. I refer to the "lost" uri as the = one
that=20 was
              =  "retargeted"=20 - that's the one the UAS wants to pull from
the = hi-entries
 =20              in the incoming = request.=20 That hi-entry was not the one
that was just
    =  =20          added by the entity that built = the=20 request just received
by the UAS.
      =    =20      That hi-entry is tagged with whatever name we = are=20 going
to tag it with
          =  =20    BEFORE the request is forwarded (using the term=20 forward
per section 16.6
          =  =20    of RFC 3261).  That tag is added once the target = set=20 of
potential
            =  =20  candidates for the new request uri are determined = in
section 16.5=20 of
               3261 = (with=20 "target set" being a 3261 term), just before
the request = is
 =20              forwarded in = section 16.6=20 to one of those targets.  A
new hi-entry
    =  =20          (which will be the last hi-entry = in the=20 request received
by the UAS) is
        =  =20      added in section 16.6 of 3261 as the request=20 is
forwarded.  At this
        =  =20      point in time, the lost information is in the=20 previous
hi-entry when the
        =    =20    outgoing request is sent. [/MB]


  =  =20            What has been lost is the = current=20 target of the request:

          =  =20    [MB] Right - at which point in my mind, it's no = longer
the=20 current
              =  target=20 ;) Maybe we call it "lost". [/MB]



    =  =20               Current=20 target

              =  =20  The current target of an initial request for a dialog
or=20 standalone
              =  =20  request is the name or address to which the request = is
targeted,=20 i.e.
               =20  either the initial target inserted in the Request-URI
by = the UAC=20 that
               =20  originates the request, or when a retarget occurred,
the=20 target
               =20  provided in that retarget operation.  Reroute=20 and
translation
            =  =20    operations never change the current = target.


 =20              [MB] I don't think = this=20 definition fits what you want -
i.e., if there
    =  =20          is no retargeting, then none of = the=20 hi-entries are
tagged - i.e., you
      =    =20      won't have your concept of current. The way it = works=20 is
that if no
            =  =20  hi-entries are tagged, then you know that there was=20 no
retargeting, thus
          =  =20    you know the request-uri has not been lost.=20 [/MB]


             =20  This defintion only makes sense when the = following
definitions=20 are used:

             =20  Name:

            =    =20  A name is a moniker for an entity which refers to it
in a = way=20 which

              =  =20  reveals nothing about where it is in a network. =  In
SIP, tel=20 URI

                =  which doesn't represent the location of the entity is
a=20 name.


             =20  Address:

            =  =20    An address is an identifier for an entity = which
describes=20 it by its

              =  =20  location on the network.  In SIP, the SIP URI = itself
is a=20 form of

              =  =20  address because the host part of the URI, the = only
mandatory part=20 of

               =20  the URI besides the scheme itself, indicates the
location = of a=20 SIP

                =  server that can be used to handle the request.

  =  =20            Route:

  =  =20              Finally, a route = is a=20   sequence of SIP entities
(including the UA
  =  =20            itself!) which = are

 =20               traversed in = order to=20 forward a request to an address
or name.

    =  =20          Retarget (other term might be = needed, as=20 this is highly
confusing):

        =  =20         A Request-URI rewrite operation that = changes=20 the
target identity of
          =  =20    the request.

        =    =20    Reroute (other term might be needed):

  =  =20               A Request-URI = rewrite=20 operation that does not change
the current
    =  =20          target of the request, but =    =20 determines the route/next
hop taken to
      =  =20        reach the = target-identity.

   =20            /Hans=20 = Erik

------_=_NextPart_001_01C9A31B.AF9F7A6C-- From drage@alcatel-lucent.com Thu Mar 12 07:07:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAE53A6B12 for ; Thu, 12 Mar 2009 07:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umS614fyFDeE for ; Thu, 12 Mar 2009 07:06:59 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id E8AA53A6806 for ; Thu, 12 Mar 2009 07:06:58 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2CE7Txo023603 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 12 Mar 2009 15:07:31 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 12 Mar 2009 15:07:29 +0100 From: "DRAGE, Keith (Keith)" To: SIP IETF Date: Thu, 12 Mar 2009 15:07:28 +0100 Thread-Topic: Long posts from long threads Thread-Index: AcmjGMFoqvfF1NPMQ16lCqAcsGQbhw== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674B1B61F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [Sip] Long posts from long threads X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:07:00 -0000 (As WG chair) There is a length limitation in bytes on the messages posted to the SIP exp= loder, which I for one am glad of given the amount of time I have to spend = keeping my inbox from overflowing. If your message exceeds that length, it is held for moderation until Dean o= r myself get round to spending the cycles to unblock it. Many times we have= better things to do with life. If you blindly reply to existing messages including all the content from th= e thread, then you will rapidly reach this limit.=20 Posting non-text mails (e.g. RTF or HTML) also consumes more space and ther= efore will more rapidly exceed this limit. You do not need to use the MS ou= tlook default of not sending text - please change these defaults to text/pl= ain when sending to IETF lists. regards Keith= From ietf.hanserik@gmail.com Thu Mar 12 07:54:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97173A6B08 for ; Thu, 12 Mar 2009 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa292IP-CoGe for ; Thu, 12 Mar 2009 07:54:16 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 8B26E3A6A53 for ; Thu, 12 Mar 2009 07:54:15 -0700 (PDT) Received: by ewy25 with SMTP id 25so383808ewy.37 for ; Thu, 12 Mar 2009 07:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EG1iTAFdtC+b+VTAJfKlUFyNHj0YHE03aQkCNh0Cvzs=; b=QFNpvf25wTf1WjP6hbJklhJqB08XXL501XkcY3tKRGDWAxeP9y+v/M0BvXnenzlR6U SZXt+hkTa0WwXRKxhm3yg1onshjVFNs4TcGA6jH3seZo5YlxcSZQhF/00BxfvWBoi92i d5pswQ5w/5rFxs4Hk3MSzrmF+bnIQ1HHlM2mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iufVFANrtTfdN1E82onnhzdEXKjRq6EeyJIIXeJfi343k8aFIyclUVuiE4Tarpxtkm nAlQnUtP9rJwId6yoCb54AnCFdkUHaYqOfw4pxlvjhN4pzmFB1PerobUFtE5syerPx80 TTIl0NU4jZ7cdHrrHnq2fVDIgmaisNYvtVlg8= MIME-Version: 1.0 Received: by 10.210.42.13 with SMTP id p13mr48537ebp.2.1236869692583; Thu, 12 Mar 2009 07:54:52 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com> Date: Thu, 12 Mar 2009 15:54:52 +0100 Message-ID: <9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> From: Hans Erik van Elburg To: Mary Barnes Content-Type: multipart/alternative; boundary=0015174bea24a8efb40464ed2a94 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:54:16 -0000 --0015174bea24a8efb40464ed2a94 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm fine with discussing implementation if everyone is meaning the same if they use the same words. As to the "retarget" term such does not seem to be the case. /Hans Erik van Elburg --0015174bea24a8efb40464ed2a94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm fine with discussing implementation if everyone is meaning the same= if they use the same words.

As=A0 to the "retarget" term = such does not seem to be the case.

/Hans Erik van Elbu= rg

--0015174bea24a8efb40464ed2a94-- From ian.elz@ericsson.com Thu Mar 12 08:10:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5C028C167 for ; Thu, 12 Mar 2009 08:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+P7Pn+f89O9 for ; Thu, 12 Mar 2009 08:10:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1186C28C0FC for ; Thu, 12 Mar 2009 08:10:11 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 562D420670; Thu, 12 Mar 2009 16:10:47 +0100 (CET) X-AuditID: c1b4fb3c-ae80cbb000001b43-16-49b925f7d1cf Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0C1B5204FE; Thu, 12 Mar 2009 16:10:47 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 16:10:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A324.B8069A80" Date: Thu, 12 Mar 2009 16:12:20 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-barnes-sip-rfc4244bis-00.txt thread-index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sAABMLoAAAAx1hA= References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Mary Barnes" X-OriginalArrivalTime: 12 Mar 2009 15:10:46.0803 (UTC) FILETIME=[B89A2630:01C9A324] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:10:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A324.B8069A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mary, I was only considering the specific domain case as included in paragraph 2 of section 3.3 in the draft: Thus, local policy MAY also be used to determine whether to include the History-Info header at all, whether to capture a specific Request-URI in the header, or whether it be included only in the Request as it is retargeted within a specific domain (PRIV-req-3). In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether any or a specific History-Info header(s) SHOULD be forwarded. And from Section 4.1=20 o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi- targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The use of the Privacy Header with a priv-value of "history" indicates whether a specific or all History-Info headers should not be forwarded. (There appears to be an inconsistency here as sections 3.3 and 4.1 appear to contradict. [Perhaps it just needs clarification that section 3.3 allows forwarding within the domain and 4.1 prohibits forwarding outside the domain?]) Assuming that the value 'history' means that presentation and forwarding should not occur. In this case the inclusion of the value 'history' in the Privacy header impacts all H-I entries. If one node includes the value 'history' in the Privacy header then there is no way for another node to specifically allow the uri included in the hi-targeted-to-uri to not be restricted. To allow forwarding of a specific H-I entry there needs to be another value which can be included in the Privacy header parameter of for the hi-targeted-to-uri. If the value "none" has specific meanings which will cause confusion then another value should be used. =20 More comments in-line Nit in A.3 In both the sequence and the text you indicate that the INVITE to UA-B will retransmit. This should not occur if a 100 Trying has been received from UA-B. This means that the retransmit timer cannot be used to determine if UA-B does not respond. There will be a separate timer specified for determining no answer after the 180 has been received. Ian Elz Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 12 March 2009 13:55 To: Ian Elz Cc: sip@ietf.org; Francois Audet Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, Okay, so I think I might understand now - you want to use the "none" to override the Privacy header that would be (in current 4244/4244bis) applied to the whole message as it traverses across the n/w from the UAC to the UAS. Is that correct?=20 =20 [ige] Yes - currently a Privacy header with value 'history' will prevent any H-I entries from being passed. If the Privacy header does not contain the value 'history' then individual H-I entries may have privacy associated. Those which do will not be forwarded but those with no privacy will be forwarded. That then though changes the meaning of the Privacy header, as I understand it - i.e., the "none" I thought had to do with specifying that an intermediary MUST NOT change the value of the Privacy header. But, I guess you are saying we specify a slightly different usage in 4244bis such that when we add it to an hi-entry, it specifies that that hi-entry MUST NOT be dropped by an intermediary. That might work, although, we would need verbage about the "risks" of doing so. =20 [ige] I would not be as strong as MUST NOT. There may be local policy which will override what is included. I would prefer the words NEED NOT be removed {Scott B will hate me for that.} or perhaps MAY be forwarded based upon local policy.=20 Thanks, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, March 12, 2009 8:43 AM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org; Audet, Francois (SC100:3055) Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, (Written after reading your discussion with Hans Erik.) First an apology for not making it clear in my original email that a value of "none" in a Privacy header parameter in a History-Info entry was only applicable to the uri contained in the hi-targeted-to-uri. I only suggested using the value "none" as this is a value defined for the Privacy header which explicitly indicates that privacy is not required. Any other value with the meaning of explicitly indicating that there is no privacy required for the specific uri could be used. With regard to your second paragraph below I understand that the SIP and PSTN models do not align. You are correct in your assumption that this problem is not unique for History-Info. The problem also arises with the Referred-By header.=20 I have raised this for History-Info at this time as your new draft presents an opportunity to correct this problem for the H-I case. The general SIP privacy issue arises as when the Privacy header was defined the concept of carrying third party identities in the SIP messages was not defined. This came later with the REFER Request and the associated Referred-By header and the History-Info header.=20 We should take what opportunities arise to discuss and correct this if there is a will to make these changes. Ian Elz Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 11 March 2009 16:53 To: Ian Elz; Francois Audet Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, This is an interesting question. I need to think about it some more, but I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain. My initial thought is that we can't overrule the overall Privacy header. The thing is that the Privacy header doesn't preclude gathering the information and using within a domain AND if it were to not include an hi-entry when the request leaves the domain for which the proxy is responsible, the recipient can add the hi-entry for the current request-uri before it adds the new hi-entry. =20 Your PSTN example doesn't strictly map obviously to a SIP model and I would think you might consider the PSTN hop to be within the same domain for which the proxy (or gw, I guess) is responsible OR consider this a walled garden whereby the Privacy header doesn't apply. Which brings me to a more general question as to how you all deal with other headers when you do your mapping to the PSTN when there is a Privacy header? It would seem this problem isn't unique to History-Info, although I know little about the details of PSTN I/W. Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, March 11, 2009 4:54 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 04 March 2009 15:15 To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C9A324.B8069A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt

Mary,

I = was only considering the specific domain case as included in paragraph 2 = of section 3.3 in the draft:

           &n= bsp;           &nb= sp;           &nbs= p;            = ;  Thus, local policy

   MAY also be used to determine whether to include the = History-Info

   header at all, whether to capture a specific = Request-URI in the

   header, or whether it be included only in the Request = as it is

   retargeted within a specific domain = (PRIV-req-3).  In the latter

   case, this is accomplished by adding a new priv-value, = history, to

   the Privacy header [RFC3323] indicating whether any or = a specific

   History-Info header(s) SHOULD be = forwarded.

And from Section 4.1

   o  Privacy: An optional parameter for = History-Info, reflected in the

      History-Info header field values by = including the Privacy Header

      [RFC3323] with a priv-value of = "history" escaped in the hi-

      targeted-to-uri or by adding the = Privacy header with a priv-value

      of "history" to the = Request.  The use of the Privacy Header with a

      priv-value of "history" = indicates whether a specific or all

      History-Info = headers should not be forwarded.

(There appears to be an inconsistency here as = sections 3.3 and 4.1 appear to contradict. [Perhaps it just = needs clarification that section 3.3 allows forwarding within the domain = and 4.1 prohibits forwarding = outside the domain?])

Assuming that the value 'history' means that = presentation and forwarding should not occur.

In = this case the inclusion of the value 'history' in the Privacy header impacts all = H-I entries. If one node includes the value 'history' in the Privacy = header then there is no way for another node to specifically = allow the uri included in the hi-targeted-to-uri to not be = restricted. To allow forwarding of a specific H-I = entry there needs to be another value = which can be included in = the Privacy header parameter of for = the = hi-targeted-to-uri.

If = the value "none" has specific meanings = which will cause confusion then another value should be = used. 

More comments in-line

Nit in A.3

In = both the sequence and the text you indicate that the INVITE to UA-B will retransmit. This should not = occur if a 100 Trying has been received from UA-B. This = means that the retransmit timer cannot be used to determine if = UA-B does not respond. There will be = a separate timer specified for determining no = answer after the 180 has been received.

Ian = Elz

Office: + 44 24 764 35256

ian.elz@ericsson.com

-----Original Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]=
Sent: 12 March 2009 13:55
To: Ian Elz
Cc: sip@ietf.org; Francois Audet
Subject: RE: I-D = Action:draft-barnes-sip-rfc4244bis-00.txt

Ian,

Okay, so I think I might understand now - you want to use the = "none" to

override the Privacy header that would be (in current = 4244/4244bis)

applied to the whole message as it traverses across the n/w from = the UAC

to = the UAS. Is that correct?

 

[ige] Yes - currently a Privacy = header with value 'history' will prevent any H-I entries from being = passed. If the Privacy header = does not contain the value 'history' then individual H-I = entries may have privacy associated. Those which = do will not be forwarded but those with no privacy will be = forwarded.

That then though changes the meaning of the

Privacy header, as I understand it - i.e., the "none" I = thought had to

do = with specifying that an intermediary MUST NOT change the value of = the

Privacy header. But, I guess you are saying we specify a = slightly

different usage in 4244bis such that when we add it to an hi-entry, = it

specifies that that hi-entry MUST NOT be dropped by an = intermediary.

That might work, although, we would need verbage about the = "risks" of

doing so.

 

[ige] I would not be as strong as MUST NOT. There may be local policy = which will override what is included. I would = prefer the words NEED NOT be = removed {Scott B will hate me for that.} or perhaps MAY be forwarded based upon local = policy.

Thanks,

Mary.

-----Original Message-----

From: Ian Elz [mailto:ian.elz@ericsson.com] =

Sent: Thursday, March 12, 2009 8:43 AM

To: Barnes, Mary (RICH2:AR00)

Cc: sip@ietf.org; Audet, Francois (SC100:3055)

Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt =

Mary,

(Written after reading your discussion with Hans = Erik.)

First an apology for not making it clear in my original email that = a

value of "none" in a Privacy header parameter in a = History-Info entry

was only applicable to the uri contained in the = hi-targeted-to-uri.

I = only suggested using the value "none" as this is a value = defined for

the Privacy header which explicitly indicates that privacy is = not

required. Any other value with the meaning of explicitly indicating = that

there is no privacy required for the specific uri could be = used.

With regard to your second paragraph below I understand that the = SIP and

PSTN models do not align. You are correct in your assumption that = this

problem is not unique for History-Info. The problem also arises = with the

Referred-By header.

I = have raised this for History-Info at this time as your new = draft

presents an opportunity to correct this problem for the H-I = case.

The general SIP privacy issue arises as when the Privacy header = was

defined the concept of carrying third party identities in the = SIP

messages was not defined. This came later with the REFER Request = and the

associated Referred-By header and the History-Info header. =

We = should take what opportunities arise to discuss and correct this = if

there is a will to make these changes.

Ian Elz

Office: + 44 24 764 35256

ian.elz@ericsson.com


-----Original Message-----

From: Mary Barnes [mailto:mary.barnes@nortel.com]=

Sent: 11 March 2009 16:53

To: Ian Elz; Francois Audet

Cc: sip@ietf.org

Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt =

Ian,

This is an interesting question. I need to think about it some = more, but

I = don't like the "none" idea as it really must be up to the = entity that

added the Privacy header to the request, as to whether it wants the = HI

entries that it adds to go outside a domain. My initial thought is = that

we = can't overrule the overall Privacy header. The thing is that = the

Privacy header doesn't preclude gathering the information and = using

within a domain AND if it were to not include an hi-entry when = the

request leaves the domain for which the proxy is responsible, = the

recipient can add the hi-entry for the current request-uri before = it

adds the new hi-entry. 

Your PSTN example doesn't strictly map obviously to a SIP model and = I

would think you might consider the PSTN hop to be within the same = domain

for which the proxy (or gw, I guess) is responsible OR consider = this a

walled garden whereby the Privacy header doesn't apply. Which = brings me

to = a more general question as to how you all deal with other = headers

when you do your mapping to the PSTN when there is a Privacy = header?  It

would seem this problem isn't unique to History-Info, although I = know

little about the details of PSTN I/W.

Regards,

Mary.

-----Original Message-----

From: Ian Elz [mailto:ian.elz@ericsson.com]

Sent: Wednesday, March 11, 2009 4:54 AM

To: Barnes, Mary (RICH2:AR00); Audet, Francois = (SC100:3055)

Cc: sip@ietf.org

Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt =

Mary, Francois,

Section 4.1 of the draft allows for the addition of the Privacy = header

parameter with a value of "history" to be included with = the

hi-targeted-to-uri.

Can this be extended to also allow the value = "none".

A = node adding a H-I entry is allowed to specify the privacy = value

"history" either in the Privacy header or as a header = parameter

associated with the hi-targeted-to-uri. If the former action is = taken by

one node this results in privacy for all history info header = entries

even if this is not required. There is no way for privacy of = an

individual H-I entry to be set to none if no Privacy is required = for the

uri.

This creates a specific problem when interworking with the PSTN = where

the privacy is associated with each E.164 number included in = the

protocol. If an INVITE is being mapped to ISUP and the H-I entries = are

being used to map to redirection numbers then a single Privacy = header

with the value "history" will result in all numbers being = restricted.

If = the Privacy header parameter could include the value "none" = then this

would explicitly indicate that the associated uri was allowed to = be

presented.

The ability to explicitly allow presentation of specific H-I = entries may

also be useful in pure sip implementations.

I = don't believe that this change would create any backward = compatibility

issues. The existing implementations will continue as deployed but = new

implementations could explicitly set no privacy for a specific = uri.

There are no security issues other than those already defined in = the

draft that an intervening node could modify an existing H-I entry. = The

Privacy header value of "none" should only be included by = the node in

the same manner as the existing inclusion of the = "history" value.

Ian Elz


-----Original Message-----

From: i-d-announce-bounces@ietf.org

[mailto:i-d-announce-bounces= @ietf.org] On Behalf Of

Internet-Drafts@ietf.org

Sent: 04 March 2009 15:15

To: i-d-announce@ietf.org

Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt =

A = New Internet-Draft is available from the on-line = Internet-Drafts

directories.

        Title           : = An Extension to the Session Initiation

Protocol (SIP) for Request History Information

        Author(s)       : M. = Barnes, F. Audet

        Filename        = : draft-barnes-sip-rfc4244bis-00.txt

        Pages           : = 49

        Date          &nbs= p; : 2009-03-04

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 call arrives at a specific = application

or = user.  This document defines a new optional SIP header, = History-Info,

for capturing the history information in = requests.

A = URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00= .txt

Internet-Drafts are also available by anonymous FTP = at:

ftp://ftp.ietf.org/internet-= drafts/

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

------_=_NextPart_001_01C9A324.B8069A80-- From AUDET@nortel.com Thu Mar 12 08:10:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB803A6AD5 for ; Thu, 12 Mar 2009 08:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.258 X-Spam-Level: X-Spam-Status: No, score=-5.258 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-ckuRwROoAs for ; Thu, 12 Mar 2009 08:10:44 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5D52D28C10F for ; Thu, 12 Mar 2009 08:10:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2CFBJJ12223; Thu, 12 Mar 2009 15:11:19 GMT Received: from 47.103.119.44 ([47.103.119.44]) by zrc2hxm0.corp.nortel.com ([47.103.119.44]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Mar 2009 15:11:13 +0000 References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com><49B82FB4.4030002@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com><49B84C55.5070107@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com><9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27C50@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <6444A4A1-9E4B-4841-81F8-594E7C2220B4@nortel.com> From: "Francois Audet" To: "Christer Holmberg" In-Reply-To: thread-topic: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt thread-index: AcmjJMi7mYmF5j+XSQqMNN6mFvg97w== Content-Type: multipart/alternative; boundary="Apple-Mail-8-865434190"; charset="iso-8859-1" MIME-Version: 1.0 (iPod Mail 5H11a) Date: Thu, 12 Mar 2009 08:11:10 -0700 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:10:51 -0000 --Apple-Mail-8-865434190 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Does p-called-header include URI parameters? On Mar 12, 2009, at 7:07, "Christer Holmberg" wrote: > > Hi, > > IF we would remove that requierment, and ONLY care about the case > when the R-URI is replaced with the CONTACT, I don't think we need > to do anything. I believe P-Called-Party-ID already solves that. > > Regards, > > Christer > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: 12. maaliskuuta 2009 15:31 > To: Hans Erik van Elburg > Cc: sip@ietf.org > Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft- > rosenberg-sip-target-uri-delivery-01.txt > > Hans Erik, > > The way I interpreted the 01 draft, you would not get the freephone > number anyway. If that is a requirement, then I accept my suggestion > won't suffice. > > John > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: 12 March 2009 12:57 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft- > rosenberg-sip-target-uri-delivery-01.txt > > But that does not solve the freephone service use case. Freephone > represents a use case where the R-URI is replaced with an AoR of > user B - not with the contact of user B. > > A calls Bfreephonenumber routed the B (AOR) routed to B's contact. > > The target-uri draft is interested in obtaining: Bfreephonenumber as > that is what A used to reach B. > > So what we like to see that B UA receives is something like > H-I: Bfreephone; "istarget",\ > B,\ > contact-B > > So you want to get Bfreephonenumber and not B. > > In certain situations you are also interested in B, I guess that > PBX's would interested in that to deliver to the correct user. We > could distinguish them like: > H-I: Bfreephone; "istarget",\ > B,"aor"\ > contact-B > > BR, > /Hans Erik van Elburg > > > On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John > wrote: > If 'istarget' is used only to identify the value that was > overwritten in > the Request-URI by a contact URI, an alternative approach would be to > flag the contact URI H-I entry as 'iscontact'. Then the UAS would just > need to look for the most recent H-I entry that is not marked > 'iscontact'. > > John > > > ________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: 12 March 2009 08:35 > To: Mary Barnes > Cc: sip@ietf.org > Subject: Re: [Sip] Terminology (was RE: Fwd: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > Yes, because you are using the 3261 use of target and the > 4244bis introduced definition of retarget. I thought it was > clear that > we need other words as those definitions don't match the target-uri > drafts use of the terms. Also they do not suffice to provide a > solution > for the use cases in the target-uri draft. > > The 3261 text you refer to is exactly about the case where the > home proxy overwrites the Request-URI with a new target. This target > is > teh registered contact address. And hence this would be what target- > uri > calls a hop or a route. This case and this is where it gets > confusing is > not a "retarget" in the target-uri draft use of the term. > > The target-uri draft states: > > "To avoid confusion, we > refer to a SIP URI that is an address for a user or resource > as a > "target" and a SIP URI that is a hop for reaching that user > as a > > "hop". > > > Apparently that does not suffice to avoid confusion. > > As for the tagging, speaking about the solution before agreeing > on the terminology and the problem it should solve is meaningless. > > /Hans Erik van Elburg > > > > On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes > wrote: > > > Responses below [MB]. > > > -----Original Message----- > From: Hans Erik van Elburg > [mailto:ietf.hanserik@gmail.com] > > Sent: Wednesday, March 11, 2009 6:42 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Shida Schubert; sip@ietf.org > Subject: Re: Terminology (was RE: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > I was talking about the concept. > > The use cases only describe cases where the target-uri > (lets call that > current target from now) has been lost when an initial > request for a > dialog or standalone request arrives at the UAS. > > [MB] And I think this is where the terminology > confusion > starts - I > don't think of the "lost" target-uri as being the > "current" target. In > my mind, the "current" target is reflected by the last > hi-entry and the > request-uri in the incoming request at the UAS. > If the > entity that sent > the request was the entity that added the last hi- > entry, > then the uri in > that hi-entry is the same as the request-URI in > the SIP > request that > arrives at the UAS. I refer to the "lost" uri as the > one > that was > "retargeted" - that's the one the UAS wants to pull > from > the hi-entries > in the incoming request. That hi-entry was not the one > that was just > added by the entity that built the request just > received > by the UAS. > That hi-entry is tagged with whatever name we are going > to tag it with > BEFORE the request is forwarded (using the term forward > per section 16.6 > of RFC 3261). That tag is added once the target > set of > potential > candidates for the new request uri are determined in > section 16.5 of > 3261 (with "target set" being a 3261 term), just before > the request is > forwarded in section 16.6 to one of those targets. A > new hi-entry > (which will be the last hi-entry in the request > received > by the UAS) is > added in section 16.6 of 3261 as the request is > forwarded. At this > point in time, the lost information is in the previous > hi-entry when the > outgoing request is sent. [/MB] > > > What has been lost is the current target of the > request: > > [MB] Right - at which point in my mind, it's no longer > the current > target ;) Maybe we call it "lost". [/MB] > > > > Current target > > The current target of an initial request for a dialog > or standalone > request is the name or address to which the request > is > targeted, i.e. > either the initial target inserted in the Request-URI > by the UAC that > originates the request, or when a retarget occurred, > the target > provided in that retarget operation. Reroute and > translation > operations never change the current target. > > > [MB] I don't think this definition fits what > you want - > i.e., if there > is no retargeting, then none of the hi-entries are > tagged - i.e., you > won't have your concept of current. The way it works is > that if no > hi-entries are tagged, then you know that there was no > retargeting, thus > you know the request-uri has not been lost. [/MB] > > > This defintion only makes sense when the following > definitions are used: > > Name: > > A name is a moniker for an entity which refers to it > in a way which > > reveals nothing about where it is in a network. In > SIP, tel URI > > which doesn't represent the location of the entity is > a name. > > > Address: > > An address is an identifier for an entity which > describes it by its > > location on the network. In SIP, the SIP URI itself > is a form of > > address because the host part of the URI, the only > mandatory part of > > the URI besides the scheme itself, indicates the > location of a SIP > > server that can be used to handle the request. > > Route: > > Finally, a route is a sequence of SIP entities > (including the UA > itself!) which are > > traversed in order to forward a request to an > address > or name. > > Retarget (other term might be needed, as this is highly > confusing): > > A Request-URI rewrite operation that changes the > target identity of > the request. > > Reroute (other term might be needed): > > A Request-URI rewrite operation that does not change > the current > target of the request, but determines the route/ > next > hop taken to > reach the target-identity. > > /Hans Erik > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-8-865434190 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Does p-called-header include URI parameters?


On Mar 12, 2009, at 7:07, "Christer Holmberg" <christer.holmberg@ericsson.com> wrote:

 
Hi,
 
IF we would remove that requierment, and ONLY care about the case when the R-URI is replaced with the CONTACT, I don't think we need to do anything. I believe P-Called-Party-ID already solves that.
 
Regards,
 
Christer

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John
Sent: 12. maaliskuuta 2009 15:31
To: Hans Erik van Elburg
Cc: sip@ietf.org
Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Hans Erik,
 
The way I interpreted the 01 draft, you would not get the freephone number anyway. If that is a requirement, then I accept my suggestion won't suffice.
 
John

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: 12 March 2009 12:57
To: Elwell, John
Cc: sip@ietf.org
Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

But that does not solve the freephone service use case. Freephone represents a use case where the R-URI is replaced with an AoR of user B - not with the contact of user B.

A calls Bfreephonenumber routed the B (AOR) routed to B's contact.

The target-uri draft is interested in obtaining: Bfreephonenumber as that is what A used to reach B.

So what we like to see that B UA receives is something like
    H-I:  Bfreephone; "istarget",\
        B,\
        contact-B

So you want to get Bfreephonenumber and not B.

In certain situations you are also interested in B, I guess that  PBX's would interested in that to deliver to the correct user. We could distinguish them like:
    H-I:  Bfreephone; "istarget",\
        B,"aor"\
        contact-B

BR,
/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John <john.elwell@siemens.com> wrote:
If 'istarget' is used only to identify the value that was overwritten in
the Request-URI by a contact URI, an alternative approach would be to
flag the contact URI H-I entry as 'iscontact'. Then the UAS would just
need to look for the most recent H-I entry that is not marked
'iscontact'.

John


________________________________

       From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
Behalf Of Hans Erik van Elburg
       Sent: 12 March 2009 08:35
       To: Mary Barnes
       Cc: sip@ietf.org
       Subject: Re: [Sip] Terminology (was RE: Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


       Yes, because you are using the 3261 use of target and the
4244bis introduced definition of retarget. I thought it was clear that
we need other words as those definitions don't match the target-uri
drafts use of the terms. Also they do not suffice to provide a solution
for the use cases in the target-uri draft.

       The 3261 text you refer to is exactly about the case where the
home proxy overwrites the Request-URI with a new target. This target is
teh registered contact address. And hence this would be what target-uri
calls a hop or a route. This case and this is where it gets confusing is
not a "retarget" in the target-uri draft use of the term.

       The target-uri draft states:

          "To avoid confusion, we
          refer to a SIP URI that is an address for a user or resource
as a
          "target" and a SIP URI that is a hop for reaching that user
as a

          "hop".


       Apparently that does not suffice to avoid confusion.

       As for the tagging, speaking about the solution before agreeing
on the terminology and the problem it should solve is meaningless.

       /Hans Erik van Elburg



       On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes
<mary.barnes@nortel.com> wrote:


               Responses below [MB].


               -----Original Message-----
               From: Hans Erik van Elburg
[mailto:ietf.hanserik@gmail.com]

               Sent: Wednesday, March 11, 2009 6:42 PM
               To: Barnes, Mary (RICH2:AR00)
               Cc: Shida Schubert; sip@ietf.org
               Subject: Re: Terminology (was RE: [Sip] Fwd: I-D
               ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


               I was talking about the concept.

               The use cases only describe  cases where the target-uri
(lets call that
               current target from now) has been lost when an initial
request for a
               dialog or standalone request arrives at the UAS.

               [MB] And I think this is where the terminology confusion
starts - I
               don't think of the "lost" target-uri as being the
"current" target. In
               my mind, the "current" target is reflected by the last
hi-entry and the
               request-uri in the incoming request at the UAS. If the
entity that sent
               the request was the entity that added the last hi-entry,
then the uri in
               that hi-entry is the same as the request-URI in the SIP
request that
               arrives at the UAS. I refer to the "lost" uri as the one
that was
               "retargeted" - that's the one the UAS wants to pull from
the hi-entries
               in the incoming request. That hi-entry was not the one
that was just
               added by the entity that built the request just received
by the UAS.
               That hi-entry is tagged with whatever name we are going
to tag it with
               BEFORE the request is forwarded (using the term forward
per section 16.6
               of RFC 3261).  That tag is added once the target set of
potential
               candidates for the new request uri are determined in
section 16.5 of
               3261 (with "target set" being a 3261 term), just before
the request is
               forwarded in section 16.6 to one of those targets.  A
new hi-entry
               (which will be the last hi-entry in the request received
by the UAS) is
               added in section 16.6 of 3261 as the request is
forwarded.  At this
               point in time, the lost information is in the previous
hi-entry when the
               outgoing request is sent. [/MB]


               What has been lost is the current target of the request:

               [MB] Right - at which point in my mind, it's no longer
the current
               target ;) Maybe we call it "lost". [/MB]



                    Current target

                 The current target of an initial request for a dialog
or standalone
                 request is the name or address to which the request is
targeted, i.e.
                 either the initial target inserted in the Request-URI
by the UAC that
                 originates the request, or when a retarget occurred,
the target
                 provided in that retarget operation.  Reroute and
translation
                 operations never change the current target.


               [MB] I don't think this definition fits what you want -
i.e., if there
               is no retargeting, then none of the hi-entries are
tagged - i.e., you
               won't have your concept of current. The way it works is
that if no
               hi-entries are tagged, then you know that there was no
retargeting, thus
               you know the request-uri has not been lost. [/MB]


               This defintion only makes sense when the following
definitions are used:

               Name:

                 A name is a moniker for an entity which refers to it
in a way which

                 reveals nothing about where it is in a network.  In
SIP, tel URI

                 which doesn't represent the location of the entity is
a name.


               Address:

                 An address is an identifier for an entity which
describes it by its

                 location on the network.  In SIP, the SIP URI itself
is a form of

                 address because the host part of the URI, the only
mandatory part of

                 the URI besides the scheme itself, indicates the
location of a SIP

                 server that can be used to handle the request.

               Route:

                 Finally, a route is a   sequence of SIP entities
(including the UA
               itself!) which are

                traversed in order to forward a request to an address
or name.

               Retarget (other term might be needed, as this is highly
confusing):

                  A Request-URI rewrite operation that changes the
target identity of
               the request.

               Reroute (other term might be needed):

                  A Request-URI rewrite operation that does not change
the current
               target of the request, but     determines the route/next
hop taken to
               reach the target-identity.

               /Hans Erik

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--Apple-Mail-8-865434190-- From mary.barnes@nortel.com Thu Mar 12 08:16:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80A293A6BC8 for ; Thu, 12 Mar 2009 08:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHSi4YEWIWV8 for ; Thu, 12 Mar 2009 08:16:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3C5D53A6A53 for ; Thu, 12 Mar 2009 08:16:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2CFHNJ15378; Thu, 12 Mar 2009 15:17:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A325.A162D4E3" Date: Thu, 12 Mar 2009 10:19:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjIoHiTXPo804cSK+8KHlenVmQYQAAo4Zg References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com> <49B82FB4.4030002@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:16:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A325.A162D4E3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When I use "retarget" I am using the definition that I put into 4244bis. So, if you could ignore the tag or change it to 'iscontact' or whatever, what would you change in that definition? Also, consider that if you were to change everyplace that I use "retarget"/"retargeted"/"retargeting" in 4244bis with 'iscontact' the text would not make sense. So, even if we change the name of the tag, we still need to understand the concept or define another term that means that the request-uri in the incoming request (which should be the same as the last hi-entry in the request) is being chnaged due to service lookup, configuration, blah, blah, blah and that to meet the requirements in the target-uri document, we want to tag this entry so that this request-uri is not "lost" - i.e., this is the one the services identified in the target-uri document care about.=20 =20 So, right now, here's what's in 4244bis: =20 The term "retarget" is used in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on a lookup in a location service and thus changing the target of the request. =20 We have previously discussed that we do need to expand the "based on a lookup in a location service" to include configuration, etc., so let's not debate that.=20 =20 But, what explicitly is the concern with that definition? =20 Mary.=20 =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, March 12, 2009 9:55 AM To: Barnes, Mary (RICH2:AR00) Cc: Elwell, John; sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I'm fine with discussing implementation if everyone is meaning the same if they use the same words. As to the "retarget" term such does not seem to be the case. /Hans Erik van Elburg ------_=_NextPart_001_01C9A325.A162D4E3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
When I=20 use "retarget" I am using the definition that I put into 4244bis.  = So, if=20 you could ignore the tag or change it to 'iscontact' or whatever, what = would you=20 change in that definition? Also, consider that if you were to change = everyplace=20 that I use "retarget"/"retargeted"/"retargeting" in 4244bis with = 'iscontact' the=20 text would not make sense. So, even if we change the name of the tag, we = still=20 need to understand the concept or define another term that means that = the=20 request-uri in the incoming request (which should be the same as the = last=20 hi-entry in the request) is being chnaged due to service lookup, = configuration,=20 blah, blah, blah and that to meet the requirements in the target-uri = document,=20 we want to tag this entry so that this request-uri is not "lost" - i.e., = this is=20 the one the services identified in the target-uri document care about.=20
 
So,=20 right now, here's what's in 4244bis:
 
   The term "retarget" is used in = this=20 document to refer to the process
   of a Proxy Server/User = Agent=20 Client (UAC) changing a Uniform Resource
   Identifier = (URI) in a=20 request based on a lookup in a location service
   and thus changing the target of = the=20 request.
 
We=20 have previously discussed that we do need to expand the "based on a = lookup in a=20 location service" to include configuration, etc., so let's not debate = that.=20
 
But,=20 what explicitly is the concern with that definition?
 
Mary.=20
 

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, March 12, = 2009 9:55=20 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Elwell, John;=20 sip@ietf.org
Subject: Re: [Sip] Terminology (was RE: Fwd:=20 I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

I'm fine with discussing implementation if everyone is = meaning the=20 same if they use the same words.

As  to the "retarget" term = such=20 does not seem to be the case.

/Hans Erik van=20 Elburg

------_=_NextPart_001_01C9A325.A162D4E3-- From mary.barnes@nortel.com Thu Mar 12 08:49:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85E53A6768 for ; Thu, 12 Mar 2009 08:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMjKdnx8Pxie for ; Thu, 12 Mar 2009 08:49:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A5DDE28C100 for ; Thu, 12 Mar 2009 08:49:55 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2CFoAM21287; Thu, 12 Mar 2009 15:50:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 10:53:00 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sAABMLoAAAAx1hAAA2O9MA== References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Ian Elz" Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:49:58 -0000 Ian, =20 I do see your point now - the text does need clarification. Detailed comments are below [MB]. =20 Thanks, Mary.=20 ________________________________ From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, March 12, 2009 10:12 AM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org; Audet, Francois (SC100:3055) Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, I was only considering the specific domain case as included in paragraph 2 of section 3.3 in the draft: Thus, local policy MAY also be used to determine whether to include the History-Info header at all, whether to capture a specific Request-URI in the header, or whether it be included only in the Request as it is retargeted within a specific domain (PRIV-req-3). In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether any or a specific History-Info header(s) SHOULD be forwarded.=20 [MB] Yes, this is a little fuzzy. It is trying to make a very general statement that we are adding this new "priv-value" to the Privacy header so that we can control whether the entries are sent outside the proxy. I think that sentence is okay if we remove the normative (SHOULD) and just add a note that the details of the use of the privacy header are provided in section 4.1., something like the following:=20 In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether or not any or a specific History-Info header(s) are forwarded outside a specific domain for which the proxy is responsible.=20 =20 The details as to the use of the new priv-value with the Privacy header are provided in section 4.1. [/MB] =20 o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi- targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The use of the Privacy Header with a priv-value of "history" indicates whether a specific or all History-Info headers should not be forwarded. (There appears to be an inconsistency here as sections 3.3 and 4.1 appear to contradict. [Perhaps it just needs clarification that section 3.3 allows forwarding within the domain and 4.1 prohibits forwarding outside the domain?])=20 [MB] Yes, this is also fuzzy. It should really read (and the SHOULD NOT ought to be caps): Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi- targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The latter case indicates that =20 none of the History-Info headers should be forwarded , whereas the use of the Privacy header escaped in the hi-targeted-to-uri means that a specific hi-entry SHOULD NOT be forwarded.=20 [/MB] Assuming that the value 'history' means that presentation and forwarding should not occur. In this case the inclusion of the value 'history' in the Privacy header impacts all H-I entries. If one node includes the value 'history' in the Privacy header then there is no way for another node to specifically allow the uri included in the hi-targeted-to-uri to not be restricted. To allow forwarding of a specific H-I entry there needs to be another value which can be included in the Privacy header parameter of for the hi-targeted-to-uri. [MB] Exactly - that's why I had suggested earlier that we perhaps RECOMMEND that the Privacy header only be used in the escaped form associated with a specific hi-entry. There is text elsewhere explaining that you do have potential loss of functionality when you use the Privacy header. Perhaps, we need a stronger warning. [/MB] If the value "none" has specific meanings which will cause confusion then another value should be used. =20 More comments in-line Nit in A.3 In both the sequence and the text you indicate that the INVITE to UA-B will retransmit. This should not occur if a 100 Trying has been received from UA-B. This means that the retransmit timer cannot be used to determine if UA-B does not respond. There will be a separate timer specified for determining no answer after the 180 has been received. [MB] You are correct - that flow is buggy and there are bugs in the flows and we will rework these and/or remove some of them.[/MB] Ian Elz Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 12 March 2009 13:55 To: Ian Elz Cc: sip@ietf.org; Francois Audet Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, Okay, so I think I might understand now - you want to use the "none" to override the Privacy header that would be (in current 4244/4244bis) applied to the whole message as it traverses across the n/w from the UAC to the UAS. Is that correct?=20 =20 [ige] Yes - currently a Privacy header with value 'history' will prevent any H-I entries from being passed. If the Privacy header does not contain the value 'history' then individual H-I entries may have privacy associated. Those which do will not be forwarded but those with no privacy will be forwarded. That then though changes the meaning of the Privacy header, as I understand it - i.e., the "none" I thought had to do with specifying that an intermediary MUST NOT change the value of the Privacy header. But, I guess you are saying we specify a slightly different usage in 4244bis such that when we add it to an hi-entry, it specifies that that hi-entry MUST NOT be dropped by an intermediary. That might work, although, we would need verbage about the "risks" of doing so. =20 [ige] I would not be as strong as MUST NOT. There may be local policy which will override what is included. I would prefer the words NEED NOT be removed {Scott B will hate me for that.} or perhaps MAY be forwarded based upon local policy.=20 Thanks, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, March 12, 2009 8:43 AM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org; Audet, Francois (SC100:3055) Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, (Written after reading your discussion with Hans Erik.) First an apology for not making it clear in my original email that a value of "none" in a Privacy header parameter in a History-Info entry was only applicable to the uri contained in the hi-targeted-to-uri. I only suggested using the value "none" as this is a value defined for the Privacy header which explicitly indicates that privacy is not required. Any other value with the meaning of explicitly indicating that there is no privacy required for the specific uri could be used. With regard to your second paragraph below I understand that the SIP and PSTN models do not align. You are correct in your assumption that this problem is not unique for History-Info. The problem also arises with the Referred-By header.=20 I have raised this for History-Info at this time as your new draft presents an opportunity to correct this problem for the H-I case. The general SIP privacy issue arises as when the Privacy header was defined the concept of carrying third party identities in the SIP messages was not defined. This came later with the REFER Request and the associated Referred-By header and the History-Info header.=20 We should take what opportunities arise to discuss and correct this if there is a will to make these changes. Ian Elz Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 11 March 2009 16:53 To: Ian Elz; Francois Audet Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, This is an interesting question. I need to think about it some more, but I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain. My initial thought is that we can't overrule the overall Privacy header. The thing is that the Privacy header doesn't preclude gathering the information and using within a domain AND if it were to not include an hi-entry when the request leaves the domain for which the proxy is responsible, the recipient can add the hi-entry for the current request-uri before it adds the new hi-entry. =20 Your PSTN example doesn't strictly map obviously to a SIP model and I would think you might consider the PSTN hop to be within the same domain for which the proxy (or gw, I guess) is responsible OR consider this a walled garden whereby the Privacy header doesn't apply. Which brings me to a more general question as to how you all deal with other headers when you do your mapping to the PSTN when there is a Privacy header? It would seem this problem isn't unique to History-Info, although I know little about the details of PSTN I/W. Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, March 11, 2009 4:54 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 04 March 2009 15:15 To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From mary.barnes@nortel.com Thu Mar 12 08:53:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745373A6AE6 for ; Thu, 12 Mar 2009 08:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf-1YKZDvmyZ for ; Thu, 12 Mar 2009 08:53:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EA6F13A6973 for ; Thu, 12 Mar 2009 08:53:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2CFsPJ29805; Thu, 12 Mar 2009 15:54:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 10:56:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD4B1B7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjIoHiTXPo804cSK+8KHlenVmQYQAAo4ZgAAF5sxA= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com><49B82FB4.4030002@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com><49B84C55.5070107@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com><9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com><9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Mary Barnes" , "Hans Erik van Elburg" Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:53:55 -0000 And, just to clarify the phrase=20 "...changing a Uniform Resource Identifier (URI) in a request..." should perhaps be worded more specifically as: " ...changing the Request-URI in a SIP request..." ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Thursday, March 12, 2009 10:20 AM To: Hans Erik van Elburg Cc: sip@ietf.org; Elwell, John Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt When I use "retarget" I am using the definition that I put into 4244bis. So, if you could ignore the tag or change it to 'iscontact' or whatever, what would you change in that definition? Also, consider that if you were to change everyplace that I use "retarget"/"retargeted"/"retargeting" in 4244bis with 'iscontact' the text would not make sense. So, even if we change the name of the tag, we still need to understand the concept or define another term that means that the request-uri in the incoming request (which should be the same as the last hi-entry in the request) is being chnaged due to service lookup, configuration, blah, blah, blah and that to meet the requirements in the target-uri document, we want to tag this entry so that this request-uri is not "lost" - i.e., this is the one the services identified in the target-uri document care about.=20 =20 So, right now, here's what's in 4244bis: =20 The term "retarget" is used in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on a lookup in a location service and thus changing the target of the request. =20 We have previously discussed that we do need to expand the "based on a lookup in a location service" to include configuration, etc., so let's not debate that.=20 =20 But, what explicitly is the concern with that definition? =20 Mary.=20 =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, March 12, 2009 9:55 AM To: Barnes, Mary (RICH2:AR00) Cc: Elwell, John; sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I'm fine with discussing implementation if everyone is meaning the same if they use the same words. As to the "retarget" term such does not seem to be the case. /Hans Erik van Elburg From ietf.hanserik@gmail.com Thu Mar 12 09:16:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504C13A6AD2 for ; Thu, 12 Mar 2009 09:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=1.352, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vENY1k3Wbyml for ; Thu, 12 Mar 2009 09:16:27 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 924833A69E3 for ; Thu, 12 Mar 2009 09:16:26 -0700 (PDT) Received: by ewy25 with SMTP id 25so806267ewy.37 for ; Thu, 12 Mar 2009 09:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jGA4MuYA3++sORJuDU6n+wCNTvHoC2W4LOe3kouUqdk=; b=HnDu+PxZ6tXYq6zTu/6SnWXeiAvZUoKTkd4oJkntLnhTXBhdyD1WBEYBag3xa3rT0M NSwyg3LndCMedLBd7+tBq84daRX92Mb5n7bKZmJUSwgYek7qzays2MGzhmg7TcS0yhLV KQboyrPDUeQtbLqD4x3xXOzUdjtFktL6zJ3y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pNMinuOzSeHHgjDtJgkZryq6nEvG2Qxjx4ilQbzOGQrbp0J7jRVblO6xiqNRp9BnQV y07dbsCNUtdw6O+QXAEIfOS/vRYg+qAEw2h2pbjOTRdsdoOhD3j1EfuprMADxq3dN/nl ejPumSAZSiKZzbpIjV1llwKbtaFSoSdAaUlmo= MIME-Version: 1.0 Received: by 10.210.11.13 with SMTP id 13mr5475346ebk.36.1236874622894; Thu, 12 Mar 2009 09:17:02 -0700 (PDT) In-Reply-To: <6444A4A1-9E4B-4841-81F8-594E7C2220B4@nortel.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903120556t73208627v39b3c6221098cc44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27C50@GBNTHT12009MSX.gb002.siemens.net> <6444A4A1-9E4B-4841-81F8-594E7C2220B4@nortel.com> Date: Thu, 12 Mar 2009 17:17:02 +0100 Message-ID: <9ae56b1e0903120917u3472f27bxc1366a9192473783@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet Content-Type: multipart/alternative; boundary=0015174bde448785340464ee50d5 Cc: sip@ietf.org, "Elwell, John" , Christer Holmberg Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 16:16:29 -0000 --0015174bde448785340464ee50d5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes. RFC3455, section 4.2.2.2. /Hans Erik van Elburg On Thu, Mar 12, 2009 at 4:11 PM, Francois Audet wrote: > Does p-called-header include URI parameters? > > > On Mar 12, 2009, at 7:07, "Christer Holmberg" < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > IF we would remove that requierment, and ONLY care about the case when the > R-URI is replaced with the CONTACT, I don't think we need to do anything. I > believe P-Called-Party-ID already solves that. > > Regards, > > Christer > > ------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] > *On Behalf Of *Elwell, John > *Sent:* 12. maaliskuuta 2009 15:31 > *To:* Hans Erik van Elburg > *Cc:* sip@ietf.org > *Subject:* Re: [Sip] Terminology (was RE: Fwd: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > Hans Erik, > > The way I interpreted the 01 draft, you would not get the freephone number > anyway. If that is a requirement, then I accept my suggestion won't suffice > . > > John > > ------------------------------ > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > *Sent:* 12 March 2009 12:57 > *To:* Elwell, John > *Cc:* sip@ietf.org > *Subject:* Re: [Sip] Terminology (was RE: Fwd: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > But that does not solve the freephone service use case. Freephone > represents a use case where the R-URI is replaced with an AoR of user B - > not with the contact of user B. > > A calls Bfreephonenumber routed the B (AOR) routed to B's contact. > > The target-uri draft is interested in obtaining: Bfreephonenumber as that > is what A used to reach B. > > So what we like to see that B UA receives is something like > H-I: Bfreephone; "istarget",\ > B,\ > contact-B > > So you want to get Bfreephonenumber and not B. > > In certain situations you are also interested in B, I guess that PBX's > would interested in that to deliver to the correct user. We could > distinguish them like: > H-I: Bfreephone; "istarget",\ > B,"aor"\ > contact-B > > BR, > /Hans Erik van Elburg > > > On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John < > john.elwell@siemens.com> wrote: > >> If 'istarget' is used only to identify the value that was overwritten in >> the Request-URI by a contact URI, an alternative approach would be to >> flag the contact URI H-I entry as 'iscontact'. Then the UAS would just >> need to look for the most recent H-I entry that is not marked >> 'iscontact'. >> >> John >> >> >> ________________________________ >> >> From: sip-bounces@ietf.org [mailto: >> sip-bounces@ietf.org] On >> Behalf Of Hans Erik van Elburg >> Sent: 12 March 2009 08:35 >> To: Mary Barnes >> Cc: sip@ietf.org >> Subject: Re: [Sip] Terminology (was RE: Fwd: >> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >> >> >> Yes, because you are using the 3261 use of target and the >> 4244bis introduced definition of retarget. I thought it was clear that >> we need other words as those definitions don't match the target-uri >> drafts use of the terms. Also they do not suffice to provide a solution >> for the use cases in the target-uri draft. >> >> The 3261 text you refer to is exactly about the case where the >> home proxy overwrites the Request-URI with a new target. This target is >> teh registered contact address. And hence this would be what target-uri >> calls a hop or a route. This case and this is where it gets confusing is >> not a "retarget" in the target-uri draft use of the term. >> >> The target-uri draft states: >> >> "To avoid confusion, we >> refer to a SIP URI that is an address for a user or resource >> as a >> "target" and a SIP URI that is a hop for reaching that user >> as a >> >> "hop". >> >> >> Apparently that does not suffice to avoid confusion. >> >> As for the tagging, speaking about the solution before agreeing >> on the terminology and the problem it should solve is meaningless. >> >> /Hans Erik van Elburg >> >> >> >> On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes >> < mary.barnes@nortel.com> wrote: >> >> >> Responses below [MB]. >> >> >> -----Original Message----- >> From: Hans Erik van Elburg >> [mailto: ietf.hanserik@gmail.com] >> >> Sent: Wednesday, March 11, 2009 6:42 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Shida Schubert; sip@ietf.org >> Subject: Re: Terminology (was RE: [Sip] Fwd: I-D >> ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >> >> >> I was talking about the concept. >> >> The use cases only describe cases where the target-uri >> (lets call that >> current target from now) has been lost when an initial >> request for a >> dialog or standalone request arrives at the UAS. >> >> [MB] And I think this is where the terminology confusion >> starts - I >> don't think of the "lost" target-uri as being the >> "current" target. In >> my mind, the "current" target is reflected by the last >> hi-entry and the >> request-uri in the incoming request at the UAS. If the >> entity that sent >> the request was the entity that added the last hi-entry, >> then the uri in >> that hi-entry is the same as the request-URI in the SIP >> request that >> arrives at the UAS. I refer to the "lost" uri as the one >> that was >> "retargeted" - that's the one the UAS wants to pull from >> the hi-entries >> in the incoming request. That hi-entry was not the one >> that was just >> added by the entity that built the request just received >> by the UAS. >> That hi-entry is tagged with whatever name we are going >> to tag it with >> BEFORE the request is forwarded (using the term forward >> per section 16.6 >> of RFC 3261). That tag is added once the target set of >> potential >> candidates for the new request uri are determined in >> section 16.5 of >> 3261 (with "target set" being a 3261 term), just before >> the request is >> forwarded in section 16.6 to one of those targets. A >> new hi-entry >> (which will be the last hi-entry in the request received >> by the UAS) is >> added in section 16.6 of 3261 as the request is >> forwarded. At this >> point in time, the lost information is in the previous >> hi-entry when the >> outgoing request is sent. [/MB] >> >> >> What has been lost is the current target of the request: >> >> [MB] Right - at which point in my mind, it's no longer >> the current >> target ;) Maybe we call it "lost". [/MB] >> >> >> >> Current target >> >> The current target of an initial request for a dialog >> or standalone >> request is the name or address to which the request is >> targeted, i.e. >> either the initial target inserted in the Request-URI >> by the UAC that >> originates the request, or when a retarget occurred, >> the target >> provided in that retarget operation. Reroute and >> translation >> operations never change the current target. >> >> >> [MB] I don't think this definition fits what you want - >> i.e., if there >> is no retargeting, then none of the hi-entries are >> tagged - i.e., you >> won't have your concept of current. The way it works is >> that if no >> hi-entries are tagged, then you know that there was no >> retargeting, thus >> you know the request-uri has not been lost. [/MB] >> >> >> This defintion only makes sense when the following >> definitions are used: >> >> Name: >> >> A name is a moniker for an entity which refers to it >> in a way which >> >> reveals nothing about where it is in a network. In >> SIP, tel URI >> >> which doesn't represent the location of the entity is >> a name. >> >> >> Address: >> >> An address is an identifier for an entity which >> describes it by its >> >> location on the network. In SIP, the SIP URI itself >> is a form of >> >> address because the host part of the URI, the only >> mandatory part of >> >> the URI besides the scheme itself, indicates the >> location of a SIP >> >> server that can be used to handle the request. >> >> Route: >> >> Finally, a route is a sequence of SIP entities >> (including the UA >> itself!) which are >> >> traversed in order to forward a request to an address >> or name. >> >> Retarget (other term might be needed, as this is highly >> confusing): >> >> A Request-URI rewrite operation that changes the >> target identity of >> the request. >> >> Reroute (other term might be needed): >> >> A Request-URI rewrite operation that does not change >> the current >> target of the request, but determines the route/next >> hop taken to >> reach the target-identity. >> >> /Hans Erik >> >> _______________________________________________ > Sip mailing list > https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > --0015174bde448785340464ee50d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes. RFC3455, section 4.2.2.2.

/Hans Erik van Elbu= rg


On Thu, Mar 12, 2009 at 4:11 PM, Francoi= s Audet <audet@nor= tel.com> wrote:
Does p-called-header include URI parameters?<= br>

On Mar 12, 2009, at= 7:07, "Christer Holmberg" <christer.holmberg@ericsson.com> wr= ote:

=A0
Hi,
=A0
IF we would remove that=20 requierment, and=A0ONLY care about the case when the R-URI is replaced with= =20 the CONTACT, I don't think we need to do anything. I believe P-Called-P= arty-ID=20 already solves that.
=A0
Regards,
=A0
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bou= nces@ietf.org] On Behalf Of Elwell, John
Sent:=20 12. maaliskuuta 2009 15:31
To: Hans Erik van Elburg
Cc:=20 sip@ietf.org
Subject: Re: [Sip= ] Terminology (was RE: Fwd:=20 I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

Hans Erik,
=A0
The way I interpreted the 01 draft, you would not get the=20 freephone number anyway. If that is a requirement, then I accept my sugge= stion=20 won't suffice.
=A0
John

From: Hans Erik van Elburg=20 [mailto:ie= tf.hanserik@gmail.com]
Sent: 12 March 2009=20 12:57
To: Elwell, John
Cc:=20 sip@ietf.org
Subject: Re: [S= ip] Terminology (was RE: Fwd:=20 I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

=
But that does not solve the freephone service use case.=20 =20 Freephone represents a use case where the R-URI is replaced with an AoR= of=20 user B - not with the contact of user B.

A calls Bfreephonenumb= er=20 routed the B (AOR) routed to B's contact.

The target-uri dra= ft is=20 interested in obtaining: Bfreephonenumber as that is what A used to rea= ch=20 B.

So what we like to see that B UA receives is something=20 like
=A0=A0=A0 H-I:=A0 Bfreephone;=20 "istarget",\
=A0=A0=A0 =A0=A0=A0=20 B,\
=A0=A0=A0 =A0=A0=A0 contact-B

So you want to=20 get Bfreephonenumber and not B.

In certain situations you are al= so=20 interested in B, I guess that=A0 PBX's would interested in that to= =20 deliver to the correct user. We could distinguish them=20 like:
=A0=A0=A0 H-I:=A0 Bfreephone;=20 "istarget",\
=A0=A0=A0 =A0=A0=A0=20 B,"aor"\
=A0=A0=A0 =A0=A0=A0 contact-B

BR,
/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 12:08 PM, Elwell, Jo= hn <john.elwell@siemens.com>=20 wrote:
If=20 'istarget' is used only to identify the value that was overwr= itten=20 in
the Request-URI by a contact URI, an alternative approach would= be=20 to
flag the contact URI H-I entry as 'iscontact'. Then the= UAS would=20 just
need to look for the most recent H-I entry that is not=20 marked
'iscontact'.

John


_______________= _________________

=A0=20 =A0 =A0 =A0From: sip-bou= nces@ietf.org [mailto:sip-= bounces@ietf.org] On
Behalf=20 Of Hans Erik van Elburg
=A0 =A0 =A0 =A0Sent: 12 March 2009=20 08:35
=A0 =A0 =A0 =A0To: Mary Barnes
=A0 =A0=20 =A0 =A0Cc: sip@ietf.org
=A0=20 =A0 =A0 =A0Subject: Re: [Sip] Terminology (was RE:=20 Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


=A0 =A0 =A0 =A0Yes, because you are=20 using the 3261 use of target and the
4244bis introduced definition= of=20 retarget. I thought it was clear that
we need other words as those= =20 definitions don't match the target-uri
drafts use of the terms= . Also=20 they do not suffice to provide a solution
for the use cases in the= =20 target-uri draft.

=A0 =A0 =A0 =A0The 3261 text you=20 refer to is exactly about the case where the
home proxy overwrites= the=20 Request-URI with a new target. This target is
teh registered conta= ct=20 address. And hence this would be what target-uri
calls a hop or a= =20 route. This case and this is where it gets confusing is
not a=20 "retarget" in the target-uri draft use of the term.

= =A0 =A0=20 =A0 =A0The target-uri draft states:

=A0 =A0 =A0=20 =A0 =A0 "To avoid confusion, we
=A0 =A0 =A0 =A0=20 =A0 refer to a SIP URI that is an address for a user or resource
a= s=20 a
=A0 =A0 =A0 =A0 =A0 "target" and a SIP URI that is a= =20 hop for reaching that user
as a

=A0 =A0 =A0 =A0=20 =A0 "hop".


=A0 =A0 =A0 =A0Apparently that does= =20 not suffice to avoid confusion.

=A0 =A0 =A0 =A0As for=20 the tagging, speaking about the solution before agreeing
on the=20 terminology and the problem it should solve is meaningless.

= =A0=20 =A0 =A0 =A0/Hans Erik van Elburg



=A0 =A0=20 =A0 =A0On Thu, Mar 12, 2009 at 2:33 AM, Mary Barnes
<mary.barnes@nortel.com>=20 wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0Responses below [MB].


=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0-----Original Message-----
=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0From: Hans Erik van Elburg
[mailto:ietf.hanserik@gmail.com]

= =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sent: Wednesday, March 11,=20 2009 6:42 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To:=20 Barnes, Mary (RICH2:AR00)
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0Cc: Shida Schubert; sip@ietf.org<= /a>
=A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0Subject: Re: Terminology (was RE: [Sip] Fwd:=20 I-D
=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


= =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0I was talking about the=20 concept.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The=20 use cases only describe =A0cases where the target-uri
(lets call= =20 that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0current=20 target from now) has been lost when an initial
request for a
= =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0dialog or standalone=20 request arrives at the UAS.

=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0[MB] And I think this is where the terminology=20 confusion
starts - I
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0don't think of the "lost" target-uri as being=20 the
"current" target. In
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0my mind, the "current" target is reflected by the=20 last
hi-entry and the
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0request-uri in the incoming request at the UAS. If=20 the
entity that sent
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0the request was the entity that added the last=20 hi-entry,
then the uri in
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0that hi-entry is the same as the request-URI in the=20 SIP
request that
=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0arrives at the UAS. I refer to the "lost" uri as the one=
that=20 was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"retargeted"=20 - that's the one the UAS wants to pull from
the hi-entries
= =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0in the incoming request.=20 That hi-entry was not the one
that was just
=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0added by the entity that built the=20 request just received
by the UAS.
=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0That hi-entry is tagged with whatever name we are=20 going
to tag it with
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0BEFORE the request is forwarded (using the term=20 forward
per section 16.6
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0of RFC 3261). =A0That tag is added once the target set=20 of
potential
=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0candidates for the new request uri are determined in
section 16= .5=20 of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03261 (with=20 "target set" being a 3261 term), just before
the request= is
=A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0forwarded in section 16.6=20 to one of those targets. =A0A
new hi-entry
=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0(which will be the last hi-entry in the=20 request received
by the UAS) is
=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0added in section 16.6 of 3261 as the request=20 is
forwarded. =A0At this
=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0point in time, the lost information is in the=20 previous
hi-entry when the
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0outgoing request is sent. [/MB]


=A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0What has been lost is the current=20 target of the request:

=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0[MB] Right - at which point in my mind, it's no longer
= the=20 current
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target=20 ;) Maybe we call it "lost". [/MB]



=A0 =A0 = =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Current=20 target

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0The current target of an initial request for a dialog
or=20 standalone
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0request is the name or address to which the request is
targeted= ,=20 i.e.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0either the initial target inserted in the Request-URI
by the UA= C=20 that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0originates the request, or when a retarget occurred,
the=20 target
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0provided in that retarget operation. =A0Reroute=20 and
translation
=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0operations never change the current target.


=A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] I don't think this=20 definition fits what you want -
i.e., if there
=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0is no retargeting, then none of the=20 hi-entries are
tagged - i.e., you
=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0won't have your concept of current. The way it works= =20 is
that if no
=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0hi-entries are tagged, then you know that there was=20 no
retargeting, thus
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0you know the request-uri has not been lost.=20 [/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0This defintion only makes sense when the following
definitions= =20 are used:

=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0Name:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0A name is a moniker for an entity which refers to it
in a way= =20 which

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0reveals nothing about where it is in a network. =A0In
SIP, tel= =20 URI

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0which doesn't represent the location of the entity is
a=20 name.


=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0Address:

=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0An address is an identifier for an entity which
describes= =20 it by its

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0location on the network. =A0In SIP, the SIP URI itself
is a=20 form of

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0address because the host part of the URI, the only
mandatory pa= rt=20 of

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0the URI besides the scheme itself, indicates the
location of a= =20 SIP

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0server that can be used to handle the request.

=A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0Route:

=A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0Finally, a route is a=20 =A0 sequence of SIP entities
(including the UA
=A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0itself!) which are

=A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 traversed in order to=20 forward a request to an address
or name.

=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0Retarget (other term might be needed, as=20 this is highly
confusing):

=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 A Request-URI rewrite operation that changes=20 the
target identity of
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0the request.

=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0Reroute (other term might be needed):

=A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A Request-URI rewrite=20 operation that does not change
the current
=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0target of the request, but =A0 =A0=20 determines the route/next
hop taken to
=A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0reach the target-identity.

=A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0/Hans=20 Erik

_______________________________________________
= Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
<= /div>Use sip-implementors@cs.columbia.edu for questions on current s= ip
Use sipping@iet= f.org for new developments on the application of sip

--0015174bde448785340464ee50d5-- From drage@alcatel-lucent.com Thu Mar 12 09:40:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B803A6BF0 for ; Thu, 12 Mar 2009 09:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQo5SWgc6k4A for ; Thu, 12 Mar 2009 09:40:50 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id D61FB3A6931 for ; Thu, 12 Mar 2009 09:40:49 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2CGfNpM013866 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Mar 2009 17:41:23 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 12 Mar 2009 17:41:23 +0100 From: "DRAGE, Keith (Keith)" To: Mary Barnes , Dean Willis , Shida Schubert Date: Thu, 12 Mar 2009 17:41:22 +0100 Thread-Topic: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiE+DnTOrRhEI3TZuBywdic+rY4wAUfXywADLP8pA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674B5454E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <4CE1C789-127F-4495-A1C6-65EB3E2E9E54@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1CCA66E4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CCA66E4@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "sip@ietf.org" Subject: Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 16:40:51 -0000 Which is where I was coming from on my offline email to you, i.e. that we s= hould start recording our position of any changes required to RFC 3261 in a= n appendix. That way we know what changes we need to make to RFC 3261 when = we get to make them, even if they are only for alignment of terminology. We= can decide later whether the appendix gets published with the update to ei= ther RFC 4244 or target-URI or some combined document. Keith=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Mary Barnes > Sent: Wednesday, March 11, 2009 4:27 PM > To: Dean Willis; Shida Schubert > Cc: sip@ietf.org > Subject: Re: [Sip] Fwd: I-D=20 > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >=20 > I don't think it should cause so much concern as I think it=20 > just requires clarifying text and we just need to agree to=20 > more precise > terms: e.g., qualifying the use of "forward" with either=20 > "next hop forwarding" or "request forwarding" for this=20 > particular case. As long as we can be precise in 4244bis,=20 > then that should suffice for now, but whenever 3261 is=20 > updated or bised, then I think the clarifications should be included. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, March 11, 2009 1:38 AM > To: Shida Schubert > Cc: sip@ietf.org List; Barnes, Mary (RICH2:AR00) > Subject: Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >=20 >=20 > On Mar 11, 2009, at 1:13 AM, Shida Schubert wrote: >=20 > > > > One reason this is so difficult relates to the=20 > problem statement >=20 > > in target-uri in that > > RFC 3261 doesn't differentiate the mechanism by which the new > > (target) Request-URI is selected. Another issue is=20 > that some of >=20 > > the terminology in > > RFC 3261 is overloaded - e.g., "forwarding" refers both to a=20 > > Proxy > > which does not have responsibility for the domain of the=20 > > request-URI > > in the incoming request, thus the proxy just "forwards" the=20 > > request to > > the next hop AND "forwarding" is used to describe the process=20 > > whereby > > the outgoing request is built and "forwarded" to the=20 > next hop at >=20 > > which > > point the proxy does not know how the new request-uri was=20 > > selected. > > RFC 4244 has attempted to clarify the terms and=20 > attempts to use=20 > > "forward" > > in the context of the former situation and "retarget" for the=20 > > case whereby > > a proxy is responsible for the domain and thus can=20 > use a number=20 > > of > > mechanism to select the new target for the request - e.g., a=20 > > REGISTRAR, > > configured data, etc. > > >=20 > Thanks, Shida. >=20 > I personally would not be averse to an Essential Correction that > corrects the terminology in RFC 3261, but I suspect that will=20 > make many > heads spin around elsewhere in the WG. >=20 > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > = From ian.elz@ericsson.com Thu Mar 12 09:50:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347EF3A6BD8 for ; Thu, 12 Mar 2009 09:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auua36onhh2M for ; Thu, 12 Mar 2009 09:50:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BB8E13A6940 for ; Thu, 12 Mar 2009 09:50:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9FB8822317; Thu, 12 Mar 2009 17:51:13 +0100 (CET) X-AuditID: c1b4fb3c-ac007bb000001b43-d5-49b93d809b47 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E24BF20647; Thu, 12 Mar 2009 17:51:12 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 17:51:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 17:52:45 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-barnes-sip-rfc4244bis-00.txt thread-index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sAABMLoAAAAx1hAAA2O9MAACv+6w References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Mary Barnes" X-OriginalArrivalTime: 12 Mar 2009 16:51:11.0569 (UTC) FILETIME=[BFA47C10:01C9A332] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 16:50:40 -0000 Mary, Thanks. RFC4244 was always considered a little fuzzy in some areas but the intent was generally understood. We may be able to use this opportunity to clarify some additional parts. I will read through the full draft with this purpose to see what may need clarification. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 12 March 2009 15:53 To: Ian Elz Cc: sip@ietf.org; Francois Audet Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, =20 I do see your point now - the text does need clarification. Detailed comments are below [MB]. =20 Thanks, Mary.=20 ________________________________ From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, March 12, 2009 10:12 AM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org; Audet, Francois (SC100:3055) Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, I was only considering the specific domain case as included in paragraph 2 of section 3.3 in the draft: Thus, local policy MAY also be used to determine whether to include the History-Info header at all, whether to capture a specific Request-URI in the header, or whether it be included only in the Request as it is retargeted within a specific domain (PRIV-req-3). In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether any or a specific History-Info header(s) SHOULD be forwarded.=20 [MB] Yes, this is a little fuzzy. It is trying to make a very general statement that we are adding this new "priv-value" to the Privacy header so that we can control whether the entries are sent outside the proxy. I think that sentence is okay if we remove the normative (SHOULD) and just add a note that the details of the use of the privacy header are provided in section 4.1., something like the following:=20 In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether or not any or a specific History-Info header(s) are forwarded outside a specific domain for which the proxy is responsible.=20 =20 The details as to the use of the new priv-value with the Privacy header are provided in section 4.1. [/MB] =20 o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi- targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The use of the Privacy Header with a priv-value of "history" indicates whether a specific or all History-Info headers should not be forwarded. (There appears to be an inconsistency here as sections 3.3 and 4.1 appear to contradict. [Perhaps it just needs clarification that section 3.3 allows forwarding within the domain and 4.1 prohibits forwarding outside the domain?])=20 [MB] Yes, this is also fuzzy. It should really read (and the SHOULD NOT ought to be caps): Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] with a priv-value of "history" escaped in the hi- targeted-to-uri or by adding the Privacy header with a priv-value of "history" to the Request. The latter case indicates that =20 none of the History-Info headers should be forwarded , whereas the use of the Privacy header escaped in the hi-targeted-to-uri means that a specific hi-entry SHOULD NOT be forwarded.=20 [/MB] Assuming that the value 'history' means that presentation and forwarding should not occur. In this case the inclusion of the value 'history' in the Privacy header impacts all H-I entries. If one node includes the value 'history' in the Privacy header then there is no way for another node to specifically allow the uri included in the hi-targeted-to-uri to not be restricted. To allow forwarding of a specific H-I entry there needs to be another value which can be included in the Privacy header parameter of for the hi-targeted-to-uri. [MB] Exactly - that's why I had suggested earlier that we perhaps RECOMMEND that the Privacy header only be used in the escaped form associated with a specific hi-entry. There is text elsewhere explaining that you do have potential loss of functionality when you use the Privacy header. Perhaps, we need a stronger warning. [/MB] If the value "none" has specific meanings which will cause confusion then another value should be used. =20 More comments in-line Nit in A.3 In both the sequence and the text you indicate that the INVITE to UA-B will retransmit. This should not occur if a 100 Trying has been received from UA-B. This means that the retransmit timer cannot be used to determine if UA-B does not respond. There will be a separate timer specified for determining no answer after the 180 has been received. [MB] You are correct - that flow is buggy and there are bugs in the flows and we will rework these and/or remove some of them.[/MB] Ian Elz Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 12 March 2009 13:55 To: Ian Elz Cc: sip@ietf.org; Francois Audet Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, Okay, so I think I might understand now - you want to use the "none" to override the Privacy header that would be (in current 4244/4244bis) applied to the whole message as it traverses across the n/w from the UAC to the UAS. Is that correct?=20 =20 [ige] Yes - currently a Privacy header with value 'history' will prevent any H-I entries from being passed. If the Privacy header does not contain the value 'history' then individual H-I entries may have privacy associated. Those which do will not be forwarded but those with no privacy will be forwarded. That then though changes the meaning of the Privacy header, as I understand it - i.e., the "none" I thought had to do with specifying that an intermediary MUST NOT change the value of the Privacy header. But, I guess you are saying we specify a slightly different usage in 4244bis such that when we add it to an hi-entry, it specifies that that hi-entry MUST NOT be dropped by an intermediary. That might work, although, we would need verbage about the "risks" of doing so. =20 [ige] I would not be as strong as MUST NOT. There may be local policy which will override what is included. I would prefer the words NEED NOT be removed {Scott B will hate me for that.} or perhaps MAY be forwarded based upon local policy.=20 Thanks, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, March 12, 2009 8:43 AM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org; Audet, Francois (SC100:3055) Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, (Written after reading your discussion with Hans Erik.) First an apology for not making it clear in my original email that a value of "none" in a Privacy header parameter in a History-Info entry was only applicable to the uri contained in the hi-targeted-to-uri. I only suggested using the value "none" as this is a value defined for the Privacy header which explicitly indicates that privacy is not required. Any other value with the meaning of explicitly indicating that there is no privacy required for the specific uri could be used. With regard to your second paragraph below I understand that the SIP and PSTN models do not align. You are correct in your assumption that this problem is not unique for History-Info. The problem also arises with the Referred-By header.=20 I have raised this for History-Info at this time as your new draft presents an opportunity to correct this problem for the H-I case. The general SIP privacy issue arises as when the Privacy header was defined the concept of carrying third party identities in the SIP messages was not defined. This came later with the REFER Request and the associated Referred-By header and the History-Info header.=20 We should take what opportunities arise to discuss and correct this if there is a will to make these changes. Ian Elz Office: + 44 24 764 35256 ian.elz@ericsson.com -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 11 March 2009 16:53 To: Ian Elz; Francois Audet Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Ian, This is an interesting question. I need to think about it some more, but I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain. My initial thought is that we can't overrule the overall Privacy header. The thing is that the Privacy header doesn't preclude gathering the information and using within a domain AND if it were to not include an hi-entry when the request leaves the domain for which the proxy is responsible, the recipient can add the hi-entry for the current request-uri before it adds the new hi-entry. =20 Your PSTN example doesn't strictly map obviously to a SIP model and I would think you might consider the PSTN hop to be within the same domain for which the proxy (or gw, I guess) is responsible OR consider this a walled garden whereby the Privacy header doesn't apply. Which brings me to a more general question as to how you all deal with other headers when you do your mapping to the PSTN when there is a Privacy header? It would seem this problem isn't unique to History-Info, although I know little about the details of PSTN I/W. Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, March 11, 2009 4:54 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: sip@ietf.org Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 04 March 2009 15:15 To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From victor.pascual.avila@gmail.com Thu Mar 12 09:58:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012BE3A69BD for ; Thu, 12 Mar 2009 09:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA1BgiMMcxmN for ; Thu, 12 Mar 2009 09:58:40 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 3CBE33A6BC8 for ; Thu, 12 Mar 2009 09:58:40 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 25so378146eya.31 for ; Thu, 12 Mar 2009 09:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J+TWJU2JBr0e0dCNDnuQcVYhMTxuAF3JQU6DUBu7PUE=; b=rc4KAS4rXyc0rHtCa/bW2Kb2rgFvI9jTQ/N87d+AcMqLSlDSkAIUYqVA5ZdSLFWDiY V6VN6tqAmJS3kk2Bxfk1jPlWdiqgCsOQqfB6Pc53bVjxSg4bRbx9lixeOY1/ZKz/IOPQ 2vWMvxWYojTjS1w+EFrcfPWa00wH5NbGrfWTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XpWLxIX1HnweyIy08hh52Z7Hh3mcca0MbPFkJoA9p6afMef7Q59CASTJr6ymu8vqqF 8tj+5kbAsoCXRijxqxOkvdpgNku/LmZXCbbJDuPqOxABdpifZ5rQg3dV+smaUuizf3PR 9exxECsPLNpmcMnl2ArWKJvU6ZjvRnxhys8nU= MIME-Version: 1.0 Received: by 10.210.131.6 with SMTP id e6mr5480744ebd.64.1236877156501; Thu, 12 Mar 2009 09:59:16 -0700 (PDT) In-Reply-To: <2ec0d47f2557274d61ca48882a379aa1.squirrel@www.ohlmeier.com> References: <49AE593F.6080807@iptel.org> <49B2F7F2.6030804@ohlmeier.org> <49B5006D.8050702@iptel.org> <49B63B9F.9000101@iptel.org> <49B77BEB.4000501@iptel.org> <2ec0d47f2557274d61ca48882a379aa1.squirrel@www.ohlmeier.com> Date: Thu, 12 Mar 2009 17:59:16 +0100 Message-ID: <618e24240903120959t7199623en2e265686311c090a@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Nils Ohlmeier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 16:58:46 -0000 On Wed, Mar 11, 2009 at 2:49 PM, Nils Ohlmeier wrote: > Sure to create a Contact binding via an authenticated REGISTER is one > possible solution. > But I think this only works because you rely on the fact that REGISTERs > are not being retargeted like INVITEs. Which then in the end means you > simply can forget about authenticating all other requests, as long as the > Contact or IP/port was successfully authenticated via the "one hop" > REGISTER method (refer-to: IMS). > The advantage of this solution is clearly that it can be easily deployed > by hopefully most of the service providers today. > > But I believe the proper technical solution would be that the server > authenticates itself in the challenge, plus adding protected informations > to the challenge which allows the receiver of the challenge to verify tha= t > this challenge was/is targeted to himself. > The dis-advantage is clearly that this would be only possible with > extensions of the existing protocols. But we would/might gain other > benefits by such a solution as well. I did not follow the discussion on draft-dotson-sip-mutual-auth. Has this work been discontinued? http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt Cheers, --=20 Victor Pascual =C3=81vila From fluffy@cisco.com Thu Mar 12 10:10:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEDE3A6BF4; Thu, 12 Mar 2009 10:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeceBwbO1OVH; Thu, 12 Mar 2009 10:10:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 85C673A6AD2; Thu, 12 Mar 2009 10:10:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,351,1233532800"; d="scan'208,217";a="154873811" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 12 Mar 2009 17:11:26 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2CHBQhq003869; Thu, 12 Mar 2009 10:11:26 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2CHBOWJ011878; Thu, 12 Mar 2009 17:11:25 GMT Message-Id: <80246DD0-F70E-43A1-859B-CE6231AACFEE@cisco.com> From: Cullen Jennings To: SIP List , sipping Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: multipart/alternative; boundary=Apple-Mail-1-872646857 Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 Date: Thu, 12 Mar 2009 11:11:24 -0600 References: X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5845; t=1236877886; x=1237741886; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20Internet=20Society=20Panel=20on=20IPv6 =20Deployment=20during=20IETF=2074 |Sender:=20; bh=T3GONqKSRsJ5whXoDmmkLskNlLhk0cLtN8w4T1P0PmY=; b=WNlJ5WQqkK0M6yqxV+7d8UiD0zMQTn25WmFdT2wdI1RJD330qxFJqwTe8P RsYEp50M067Qt7wg/vLwUonFbFAjDDo8bHEYDnfOKc75Laq0Bjw3aNFqBtVh 74AqcLZN4n; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Sip] Fwd: Internet Society Panel on IPv6 Deployment during IETF 74 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 17:10:50 -0000 --Apple-Mail-1-872646857 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit If you have opinions about IPv6, or NAT, you might be interested in the following. Begin forwarded message: > From: Russ Housley > Date: March 12, 2009 10:55:26 AM MDT (CA) > To: all74@ietf.org > Cc: iab@iab.org, iesg@ietf.org > Subject: Internet Society Panel on IPv6 Deployment during IETF 74 > Reply-To: Russ Housley > > IETF 74 Attendees: > > I am writing to make sure that you are aware of the Internet Society > (ISOC) briefing panel focused on the real world experiences > associated with deploying IPv6. While not part of the IETF agenda, > the panel session will be coincident with the IETF 74 meeting in San > Francisco. > > "The Seven Stages of IPv6" will review the opportunities of IPv6 > from the perspective of network citizens in the seven stages of > dealing > with massive change. Leslie Daigle, ISOC Chief Internet Technology > Officer, will moderate the panel. The panel session will be held at > the Hilton San Francisco on Tuesday, March 24th at 11:30am - 12:45pm > PDT. > > Lunch will be provided; however, seating is limited and pre- > registration is required before > Wednesday, March 18th at 5:00pm PDT. Registration is free. The > panel session is open > to interested IETF participants, ISOC members, and journalists. > > Register online at: > http://www.isoc.org/isoc/conferences/registration/20090324.shtml --Apple-Mail-1-872646857 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

If you = have opinions about IPv6, or NAT, you might be interested in = the following. 

Begin forwarded = message:

From: Russ Housley <housley@vigilsec.com>
Date: = March 12, 2009 10:55:26 AM MDT (CA)
Subject: = Internet Society Panel on IPv6 Deployment during IETF = 74
Reply-To: Russ Housley <housley@vigilsec.com>

IETF 74 Attendees:

I am writing to make sure = that you are aware of the Internet Society (ISOC) briefing panel = focused on the real world experiences associated with deploying = IPv6.  While not part of the IETF agenda, the panel session will be = coincident with the IETF 74 meeting in San Francisco.

"The Seven = Stages of IPv6" will review the opportunities of IPv6 from the = perspective of network citizens in the seven stages of dealing
with = massive change.  Leslie Daigle, ISOC Chief Internet Technology = Officer, will moderate the panel.  The panel session will be = held at the Hilton San Francisco on Tuesday, March 24th = at 11:30am - 12:45pm PDT.

Lunch will be provided; however, = seating is limited and pre-registration is required before
Wednesday, = March 18th at 5:00pm PDT.  Registration is free.  The panel = session is open
to interested IETF participants, ISOC members, and = journalists.

Register online at:
http://www.isoc.org/isoc/conferences/registration/20090324.shtml

= --Apple-Mail-1-872646857-- From mary.barnes@nortel.com Thu Mar 12 11:08:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B698F3A6831 for ; Thu, 12 Mar 2009 11:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.291 X-Spam-Level: X-Spam-Status: No, score=-5.291 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+UccH+AL7kd for ; Thu, 12 Mar 2009 11:08:53 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 839E13A67E1 for ; Thu, 12 Mar 2009 11:08:53 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2CI9RG01037; Thu, 12 Mar 2009 18:09:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A33D.A783AE75" Date: Thu, 12 Mar 2009 13:10:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> In-Reply-To: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3 - two tags (was RE: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEI7gxw6pHGgNQySU7Oghm7q2AwBKxBIw References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> From: "Mary Barnes" To: "Hans Erik van Elburg" , Subject: [Sip] Issue 3 - two tags (was RE: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:08:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A33D.A783AE75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think there is another solution proposal that we should pursue for issue 3 identified in the email summary sent by Shida earlier this week - I've snipped all the text except for that issue and issue 2 in the summary below. I do think the discussion has confounded the two issues and I think it ought to be clarified that if we agree to the two tags per issue 3, that the options for the terminology MUST change. And, perhaps this is why the other discussion threads aren't progressing well. =20 So, Hans Erick, I would like clarification on as to your view on the solution: =20 In general, ISTM that one of the issues we're having in this terminology thread is that you are considering the solution to be that the hi-entries are tagged as they=20 are added to the request. And, just for clarification from my perspective, that is NOT the solution in either 4244bis or target-uri.=20 =20 I don't view it as a problem necessarily if you'd like to pursue an alternate solution, we just need to be clear that's what you're advocating. In that case, I would agree the "retarget" is not an appropriate tag for the entries, as you don't know at the point in time that you add an hi-entry that it will be retargeted. In the case of this approach to the solution, you do have to alter the mechanism for determining the hi-entry that your services would want to use. You would need to skip the most recent/last hi-entry (as that would contain the same as the Request-URI in the incoming request), since it would be tagged if you use this solution approach. Thus, you'd have to take the next hi-entry that you find that has the desired "tag". I will posit that we could accomplish this solution without any changes to 4244 by just registering new SIP URI parameter(s). And, that's not to say we shouldn't do a 4244bis as there are other issues to address in that document, but that allows the target-uri to describe a solution that makes use of 4244bis "as is". =20 So, feedback on this specific point (from Hans Erik and others) would be appreciated.=20 =20 Mary. =20 =20 =20 ________________________________ From: Shida Schubert [mailto:shida@ntt-at.com]=20 Sent: Wednesday, March 11, 2009 1:13 AM To: sip@ietf.org List Cc: Barnes, Mary (RICH2:AR00) Subject: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=20 We have submitted the updated target-uri draft based on the comments=20 submitted to the list and comments received at IETF73.=20 I have taken over as editor as Jonathan didn't have the cycles to=20 update the draft, with Francois, Christer and Hans Erick as additional=20 co-authors and great deal of help from Mary. =20 =20 The following summarizes the changes made to the target-uri document 1. Added use-case for toll-free number back 2. Added definition of "retarget" operation.=20 3. Removed a reference to URN 4. Added a text discussing the difference to P-Called-Party-Id 5. Changed parameter name from "target" to "istarget" =20 Note, that the target-uri document still contains the normative text for the History-Info header. =20 In addition, Mary (with Francois as co-author) has submitted a rfc4244bis, with the following changes: 1. Incorporated the normative aspects of the target-uri document into the existing normative text in RFC 4244 - the functionality is=20 virtually identical (as is some of the text) as the HI based solution=20 described in the target-uri document. It's important that the solution be integrated into RFC 4244 as it MUST work and be based on the normative aspects of RFC 4244. 2. Added the use cases from target-uri the the summary in the overview of rfc4244bis. 3. Added an additional requirement to capture the "target-uri" information. 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. 5. Added a more simplified example. =20 =20 We had some very long offline exchanges as to the best way forward and remaining work for both documents. =20 Some of the issues identified are: ::Issues:: 1. Should we remove the normative text from target-uri and progress 4244bis along with the target-uri document to meet the chartered SIP WG milestone?=20 =20 =20 2. Name of the parameter.=20 At the last meeting, parameter "target" was said inappropriate=20 because voicemail-uri spec already defines a parameter called=20 "target" which also can be found in hi-entry, thus potentially=20 causing confusion. =20 Currently the target-uri draft uses "istarget" and 4244bis uses "retarget" but we could never come to=20 a consensus on what name is appropriate. Other suggestions have included the following: "target-identity" (someone didn't like that "identity" is also a SIP header) "reg-uri" (can be paired with "mapped-uri" for item 3 below) "aor" "jibberish"=20 etc. =20 One reason this is so difficult relates to the problem statement in target-uri in that RFC 3261 doesn't differentiate the mechanism by which the new (target) Request-URI is selected. Another issue is that some of the terminology in RFC 3261 is overloaded - e.g., "forwarding" refers both to a Proxy which does not have responsibility for the domain of the request-URI in the incoming request, thus the proxy just "forwards" the request to the next hop AND "forwarding" is used to describe the process whereby the outgoing request is built and "forwarded" to the next hop at which point the proxy does not know how the new request-uri was selected. RFC 4244 has attempted to clarify the terms and attempts to use "forward"=20 in the context of the former situation and "retarget" for the case whereby a proxy is responsible for the domain and thus can use a number of mechanism to select the new target for the request - e.g., a REGISTRAR,=20 configured data, etc. =20 3. Related to the last point in item 2 above, it has been proposed that we differentiate the hi-entries even more by defining separate parameters for registered and configured/mapped contacts.=20 Currently when the R-URI is translated to a URI which is either derived=20 from location service lookup(registered by UA) or from mapping=20 table, there is no differentiation as to how the URI was derived once it is added to the list of potential targets. =20 The general consensus of the authors of the two documents was that it may=20 be useful for some services to have the hi-entries tagged with the more specific information.=20 =20 And, of course, this gets us into another naming contest. In the end, the naming is not so important as long as the term isn't too overloaded and it is defined precisely in the document(s). =20 We would appreciate WG feedback on these issues and any other comments on the two documents prior to IETF-74. =20 Regards, Shida and Mary. Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 10, 2009 2:30:01 AM JST To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =09 =09 Title : Delivery of Request-URI Targets to User Agents Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert Filename : draft-rosenberg-sip-target-uri-delivery-01.txt Pages : 16 Date : 2009-3-9 =09 When a Session Initiation Protocol (SIP) proxy receives a request targeted at a URI identifying a user or resource it is responsible for, the proxy translates the URI to a registered or configured contact URI of an agent representing that user or resource. In the process, the original URI is removed from the request. Numerous use cases have arisen which require this information to be delivered to the user agent. This document describes these use cases and defines an extension to the History-Info header field which allows it to be used to support those cases. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-deliv ery-01.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 Content-Type: text/plain
Content-ID: <2009-3-9102756.I-D@ietf.org>

=20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------_=_NextPart_001_01C9A33D.A783AE75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 think there is another solution proposal that we should pursue for issue = 3=20 identified in the email summary sent by Shida earlier this week - I've = snipped=20 all the text except for that issue and issue 2 in the summary = below.  I do=20 think the discussion has confounded the two issues and I think it ought = to be=20 clarified that if we agree to the two tags per issue 3, that the options = for the=20 terminology MUST change. And, perhaps this is why the other discussion = threads=20 aren't progressing well.
 
So,=20 Hans Erick, I would like clarification on as to your view on the=20 solution:
 
In=20 general, ISTM that one of the issues we're having in this terminology = thread is=20 that you are considering the solution to be that the hi-entries are = tagged as=20 they
are=20 added to the request.  And, just for clarification from my = perspective,=20 that is NOT the solution in either 4244bis or target-uri. =
 
I=20 don't view it as a problem necessarily if you'd like to pursue an = alternate=20 solution, we just need to be clear that's what you're advocating. In = that case,=20 I would agree the "retarget" is not an appropriate tag for the entries, = as you=20 don't know at the point in time that you add an hi-entry that it will be = retargeted. In the case of this approach to the solution, you do have to = alter=20 the mechanism for determining the hi-entry that your services would want = to use.=20 You would need to skip the most recent/last hi-entry (as that = would contain=20 the same as the Request-URI in the incoming request), since it would be = tagged=20 if you use this solution approach. Thus, you'd have to take the next = hi-entry=20 that you find that has the desired "tag".  I will posit that we = could=20 accomplish this solution without any changes to 4244 by just registering = new SIP URI parameter(s).   And,  that's not to = say we=20 shouldn't do a 4244bis as there are other issues to address in that = document,=20 but that allows the target-uri to describe a solution that makes use of = 4244bis=20 "as is".
 
So,=20 feedback on this specific point (from Hans Erik and others) would be=20 appreciated.
 
Mary.
 
 
 

From: Shida Schubert = [mailto:shida@ntt-at.com]=20
Sent: Wednesday, March 11, 2009 1:13 AM
To: = sip@ietf.org=20 List
Cc: Barnes, Mary (RICH2:AR00)
Subject: Fwd: I-D = ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =


We have submitted the updated target-uri draft based on the=20 comments 
submitted to the list and comments received at IETF73. 

I have taken over as editor as Jonathan didn't have the cycles=20 to 
update the draft, with Francois, Christer and Hans Erick as=20 additional 
co-authors and great deal of help from Mary.  
 
The following summarizes the changes made to the target-uri = document
1. Added use-case for toll-free number back
2. Added definition of "retarget" operation. 
3. Removed a reference to URN
4. Added a text discussing the difference to = P-Called-Party-Id
5. Changed parameter name from "target" to "istarget"
 
Note, that the target-uri document still contains the normative = text for=20 the
History-Info header.
 
In addition, Mary (with Francois as co-author) has submitted = a
rfc4244bis, with the following changes:
1. Incorporated the normative aspects of the target-uri = document
into the existing normative text in RFC 4244 - the functionality=20 is 
virtually identical (as is some of the text) as the HI based=20 solution 
described in the target-uri document.  It's important that the = solution
be integrated into RFC 4244 as it MUST work and be based on the=20 normative
aspects of RFC 4244.
2.  Added the use cases from target-uri the the summary
in the overview of rfc4244bis.
3. Added an additional requirement to capture the "target-uri"=20 information.
4. Fixed an error in the RFC 4244 ABNF and added "retarget"=20 parameter.
5. Added a more simplified example.
 
 
We had some very long offline exchanges as to the best way forward=20 and
remaining work for both documents.
 
Some of the issues identified are:

::Issues::
   1. Should we remove the normative text from target-uri = and=20 progress
       4244bis along with the target-uri = document to=20 meet the chartered
      SIP WG milestone? 
 
 
   2. Name of the parameter. 
      At the last meeting, parameter "target" = was said=20 inappropriate 
      because voicemail-uri spec already = defines a=20 parameter called 
      "target" which also can be found in = hi-entry,=20 thus potentially 
      causing confusion.
     
      Currently the target-uri draft uses = "istarget"=20 and 4244bis uses
      "retarget"  but we could never come=20 to 
      a consensus on what name is appropriate.=20  Other suggestions have
      included the following:
      "target-identity" (someone didn't like = that=20 "identity" is also a SIP header)
      "reg-uri"  (can be paired with = "mapped-uri"=20 for item 3 below)
      "aor"
      "jibberish" 
      etc.
 
      One reason this is so difficult relates = to the=20 problem statement in target-uri in that
      RFC 3261 doesn't differentiate the = mechanism by=20 which the new
      (target) Request-URI is selected. =  Another=20 issue is that some of the terminology in
      RFC 3261 is overloaded - e.g., = "forwarding"=20 refers both to a Proxy
      which does not have responsibility for = the domain=20 of the request-URI
      in the incoming request, thus the proxy = just=20 "forwards" the request to
      the next hop AND "forwarding" is used to = describe=20 the process whereby
      the outgoing request is built and = "forwarded" to=20 the next hop at which
      point the proxy does not know how the new = request-uri was selected.
      RFC 4244 has attempted to clarify the = terms and=20 attempts to use "forward" 
      in the context of the former situation = and=20 "retarget" for the case whereby
      a proxy is responsible for the domain and = thus=20 can use a number of 
      mechanism to select the new target for = the=20 request - e.g., a REGISTRAR, 
      configured data, etc.  

 3.  Related to the last point in item 2 above, it has = been=20 proposed that
      we differentiate the hi-entries even more = by=20 defining separate parameters
     for registered and configured/mapped=20 contacts. 
     Currently when the R-URI is translated to a URI = which=20 is either derived 
     from location service lookup(registered by UA) = or from=20 mapping 
     table, there is no differentiation as to how = the URI=20 was derived once it is
     added to the list of potential targets.
     
     The general consensus of the authors of the two = documents was that it may 
     be useful for some services to have the = hi-entries=20 tagged with the
     more specific information. 
 
     And, of course, this gets us into another = naming=20 contest. In the end, the naming
     is not so important as long as the term isn't = too=20 overloaded and it is defined
     precisely in the document(s).
 
We would appreciate WG feedback on these issues and any other = comments=20 on
the two documents prior to IETF-74.
 
Regards,
Shida and Mary.


 ------_=_NextPart_001_01C9A33D.A783AE75-- From mary.barnes@nortel.com Thu Mar 12 11:13:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94DC3A6C15 for ; Thu, 12 Mar 2009 11:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKx+t36povqM for ; Thu, 12 Mar 2009 11:13:03 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 476A13A6C0E for ; Thu, 12 Mar 2009 11:12:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2CIDCG02631; Thu, 12 Mar 2009 18:13:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 13:15:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD4B6F1@zrc2hxm0.corp.nortel.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674B5454E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiE+DnTOrRhEI3TZuBywdic+rY4wAUfXywADLP8pAAA1Z0cA== References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><4CE1C789-127F-4495-A1C6-65EB3E2E9E54@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1CCA66E4@zrc2hxm0.corp.nortel.com> <28B7C3AA2A7ABA4A841F11217ABE78D674B5454E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Mary Barnes" To: "DRAGE, Keith (Keith)" , "Dean Willis" , "Shida Schubert" Cc: sip@ietf.org Subject: Re: [Sip] Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:13:04 -0000 Yes, we can plan on doing so in the revisions, once we actually agree to where we're going with both docs in terms of supporting the target-uri solution requirements. Mary.=20 -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Thursday, March 12, 2009 11:41 AM To: Barnes, Mary (RICH2:AR00); Dean Willis; Shida Schubert Cc: sip@ietf.org Subject: RE: [Sip] Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Which is where I was coming from on my offline email to you, i.e. that we should start recording our position of any changes required to RFC 3261 in an appendix. That way we know what changes we need to make to RFC 3261 when we get to make them, even if they are only for alignment of terminology. We can decide later whether the appendix gets published with the update to either RFC 4244 or target-URI or some combined document. Keith=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > Mary Barnes > Sent: Wednesday, March 11, 2009 4:27 PM > To: Dean Willis; Shida Schubert > Cc: sip@ietf.org > Subject: Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >=20 > I don't think it should cause so much concern as I think it just=20 > requires clarifying text and we just need to agree to more precise > terms: e.g., qualifying the use of "forward" with either "next hop=20 > forwarding" or "request forwarding" for this particular case. As long=20 > as we can be precise in 4244bis, then that should suffice for now, but > whenever 3261 is updated or bised, then I think the clarifications=20 > should be included. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, March 11, 2009 1:38 AM > To: Shida Schubert > Cc: sip@ietf.org List; Barnes, Mary (RICH2:AR00) > Subject: Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >=20 >=20 > On Mar 11, 2009, at 1:13 AM, Shida Schubert wrote: >=20 > > > > One reason this is so difficult relates to the > problem statement >=20 > > in target-uri in that > > RFC 3261 doesn't differentiate the mechanism by which the new > > (target) Request-URI is selected. Another issue is > that some of >=20 > > the terminology in > > RFC 3261 is overloaded - e.g., "forwarding" refers both to a=20 > > Proxy > > which does not have responsibility for the domain of the=20 > > request-URI > > in the incoming request, thus the proxy just "forwards" the=20 > > request to > > the next hop AND "forwarding" is used to describe the process=20 > > whereby > > the outgoing request is built and "forwarded" to the > next hop at >=20 > > which > > point the proxy does not know how the new request-uri was=20 > > selected. > > RFC 4244 has attempted to clarify the terms and > attempts to use > > "forward" > > in the context of the former situation and "retarget" for the=20 > > case whereby > > a proxy is responsible for the domain and thus can > use a number > > of > > mechanism to select the new target for the request - e.g., a=20 > > REGISTRAR, > > configured data, etc. > > >=20 > Thanks, Shida. >=20 > I personally would not be averse to an Essential Correction that=20 > corrects the terminology in RFC 3261, but I suspect that will make=20 > many heads spin around elsewhere in the WG. >=20 > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 From mary.barnes@nortel.com Thu Mar 12 11:16:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9231428C227 for ; Thu, 12 Mar 2009 11:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.278 X-Spam-Level: X-Spam-Status: No, score=-5.278 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nDNRCUKsBYe for ; Thu, 12 Mar 2009 11:16:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 168303A6C0C for ; Thu, 12 Mar 2009 11:16:43 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2CIGwZ00666; Thu, 12 Mar 2009 18:16:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 13:19:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD4B715@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Snipped/text version- Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmiEI7gxw6pHGgNQySU7Oghm7q2AwBKxBIwAADXqmA= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Hans Erik van Elburg" , Subject: [Sip] Snipped/text version- Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:16:44 -0000 Sorry Keith ... I forgot to snip and transform to text.=20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Thursday, March 12, 2009 1:10 PM To: Hans Erik van Elburg; sip@ietf.org Subject: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I think there is another solution proposal that we should pursue for issue 3 identified in the email summary sent by Shida earlier this week - I've snipped all the text except for that issue and issue 2 in the summary below. I do think the discussion has confounded the two issues and I think it ought to be clarified that if we agree to the two tags per issue 3, that the options for the terminology MUST change. And, perhaps this is why the other discussion threads aren't progressing well. =20 So, Hans Erick, I would like clarification on as to your view on the solution: =20 In general, ISTM that one of the issues we're having in this terminology thread is that you are considering the solution to be that the hi-entries are tagged as they=20 are added to the request. And, just for clarification from my perspective, that is NOT the solution in either 4244bis or target-uri.=20 =20 I don't view it as a problem necessarily if you'd like to pursue an alternate solution, we just need to be clear that's what you're advocating. In that case, I would agree the "retarget" is not an appropriate tag for the entries, as you don't know at the point in time that you add an hi-entry that it will be retargeted. In the case of this approach to the solution, you do have to alter the mechanism for determining the hi-entry that your services would want to use. You would need to skip the most recent/last hi-entry (as that would contain the same as the Request-URI in the incoming request), since it would be tagged if you use this solution approach. Thus, you'd have to take the next hi-entry that you find that has the desired "tag". I will posit that we could accomplish this solution without any changes to 4244 by just registering new SIP URI parameter(s). And, that's not to say we shouldn't do a 4244bis as there are other issues to address in that document, but that allows the target-uri to describe a solution that makes use of 4244bis "as is". =20 So, feedback on this specific point (from Hans Erik and others) would be appreciated.=20 =20 Mary. =20 =20 =20 ________________________________ From: Shida Schubert [mailto:shida@ntt-at.com]=20 Sent: Wednesday, March 11, 2009 1:13 AM To: sip@ietf.org List Cc: Barnes, Mary (RICH2:AR00) Subject: Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=20 We have submitted the updated target-uri draft based on the comments=20 submitted to the list and comments received at IETF73.=20 ....snipped... 2. Name of the parameter.=20 At the last meeting, parameter "target" was said inappropriate=20 because voicemail-uri spec already defines a parameter called=20 "target" which also can be found in hi-entry, thus potentially=20 causing confusion. =20 Currently the target-uri draft uses "istarget" and 4244bis uses "retarget" but we could never come to=20 a consensus on what name is appropriate. Other suggestions have included the following: "target-identity" (someone didn't like that "identity" is also a SIP header) "reg-uri" (can be paired with "mapped-uri" for item 3 below) "aor" "jibberish"=20 etc. =20 One reason this is so difficult relates to the problem statement in target-uri in that RFC 3261 doesn't differentiate the mechanism by which the new (target) Request-URI is selected. Another issue is that some of the terminology in RFC 3261 is overloaded - e.g., "forwarding" refers both to a Proxy which does not have responsibility for the domain of the request-URI in the incoming request, thus the proxy just "forwards" the request to the next hop AND "forwarding" is used to describe the process whereby the outgoing request is built and "forwarded" to the next hop at which point the proxy does not know how the new request-uri was selected. RFC 4244 has attempted to clarify the terms and attempts to use "forward"=20 in the context of the former situation and "retarget" for the case whereby a proxy is responsible for the domain and thus can use a number of mechanism to select the new target for the request - e.g., a REGISTRAR,=20 configured data, etc. =20 3. Related to the last point in item 2 above, it has been proposed that we differentiate the hi-entries even more by defining separate parameters for registered and configured/mapped contacts.=20 Currently when the R-URI is translated to a URI which is either derived=20 from location service lookup(registered by UA) or from mapping=20 table, there is no differentiation as to how the URI was derived once it is added to the list of potential targets. =20 The general consensus of the authors of the two documents was that it may=20 be useful for some services to have the hi-entries tagged with the more specific information.=20 =20 And, of course, this gets us into another naming contest. In the end, the naming is not so important as long as the term isn't too overloaded and it is defined precisely in the document(s). =20 We would appreciate WG feedback on these issues and any other comments on the two documents prior to IETF-74. =20 Regards, Shida and Mary. Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 10, 2009 2:30:01 AM JST To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt=20 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =09 =09 Title : Delivery of Request-URI Targets to User Agents Author(s) : J. Rosenberg, H. van Elburg, C. Holmberg, F. Audet, S. Schubert Filename : draft-rosenberg-sip-target-uri-delivery-01.txt Pages : 16 Date : 2009-3-9 =09 When a Session Initiation Protocol (SIP) proxy receives a request targeted at a URI identifying a user or resource it is responsible for, the proxy translates the URI to a registered or configured contact URI of an agent representing that user or resource. In the process, the original URI is removed from the request. Numerous use cases have arisen which require this information to be delivered to the user agent. This document describes these use cases and defines an extension to the History-Info header field which allows it to be used to support those cases. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target-uri-deliv ery-01.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 Content-Type: text/plain
Content-ID: <2009-3-9102756.I-D@ietf.org>

=20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From christer.holmberg@ericsson.com Thu Mar 12 11:18:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A82428C231 for ; Thu, 12 Mar 2009 11:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtmme6JglpTB for ; Thu, 12 Mar 2009 11:18:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 06DA828C279 for ; Thu, 12 Mar 2009 11:17:47 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 55A742027E; Thu, 12 Mar 2009 19:18:23 +0100 (CET) X-AuditID: c1b4fb3e-ac89bbb0000023da-ed-49b951efdfa0 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1A3F621172; Thu, 12 Mar 2009 19:18:23 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 19:18:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A33E.E9E13BBA" Date: Thu, 12 Mar 2009 19:18:16 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjIoHiTXPo804cSK+8KHlenVmQYQAAo4ZgAAZFpsA= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com><49B82FB4.4030002@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com><49B84C55.5070107@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com><9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com><9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Hans Erik van Elburg" X-OriginalArrivalTime: 12 Mar 2009 18:18:22.0819 (UTC) FILETIME=[EDB5E330:01C9A33E] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:18:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A33E.E9E13BBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mary, =20 A couple of question: =20 1. Does the 4244bis definition of "retarget" cover the freephone case, when the R-URI is replaced with the AoR of B - not with the contact of B - no matter whether it's done based on location service, configuration or whatever? =20 2. Related to the first question, when you say "...and thus chaning the target of the request", what is the defintion of "target"? =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, March 12, 2009 5:20 PM To: Hans Erik van Elburg Cc: sip@ietf.org; Elwell, John Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt When I use "retarget" I am using the definition that I put into 4244bis. So, if you could ignore the tag or change it to 'iscontact' or whatever, what would you change in that definition? Also, consider that if you were to change everyplace that I use "retarget"/"retargeted"/"retargeting" in 4244bis with 'iscontact' the text would not make sense. So, even if we change the name of the tag, we still need to understand the concept or define another term that means that the request-uri in the incoming request (which should be the same as the last hi-entry in the request) is being chnaged due to service lookup, configuration, blah, blah, blah and that to meet the requirements in the target-uri document, we want to tag this entry so that this request-uri is not "lost" - i.e., this is the one the services identified in the target-uri document care about.=20 =20 So, right now, here's what's in 4244bis: =20 The term "retarget" is used in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on a lookup in a location service and thus changing the target of the request. =20 We have previously discussed that we do need to expand the "based on a lookup in a location service" to include configuration, etc., so let's not debate that.=20 =20 But, what explicitly is the concern with that definition? =20 Mary.=20 =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, March 12, 2009 9:55 AM To: Barnes, Mary (RICH2:AR00) Cc: Elwell, John; sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I'm fine with discussing implementation if everyone is meaning the same if they use the same words. As to the "retarget" term such does not seem to be the case. /Hans Erik van Elburg ------_=_NextPart_001_01C9A33E.E9E13BBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mary,
 
A couple of question:
 
1. Does the 4244bis definition of "retarget" = cover the=20 freephone case, when the R-URI is replaced with the AoR of B - not with = the=20 contact of B - no matter whether it's done based on location service,=20 configuration or whatever?
 
2. Related to the first question, when you say = "...and thus=20 chaning the target of the request", what is the defintion of=20 "target"?
 
Regards,
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent:=20 Thursday, March 12, 2009 5:20 PM
To: Hans Erik van=20 Elburg
Cc: sip@ietf.org; Elwell, John
Subject: Re: = [Sip]=20 Terminology (was RE:=20 Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
When I=20 use "retarget" I am using the definition that I put into 4244bis.  = So, if=20 you could ignore the tag or change it to 'iscontact' or whatever, what = would you=20 change in that definition? Also, consider that if you were to change = everyplace=20 that I use "retarget"/"retargeted"/"retargeting" in 4244bis with = 'iscontact' the=20 text would not make sense. So, even if we change the name of the tag, we = still=20 need to understand the concept or define another term that means that = the=20 request-uri in the incoming request (which should be the same as the = last=20 hi-entry in the request) is being chnaged due to service lookup, = configuration,=20 blah, blah, blah and that to meet the requirements in the target-uri = document,=20 we want to tag this entry so that this request-uri is not "lost" - i.e., = this is=20 the one the services identified in the target-uri document care about.=20
 
So,=20 right now, here's what's in 4244bis:
 
   The term "retarget" is used in = this=20 document to refer to the process
   of a Proxy Server/User = Agent=20 Client (UAC) changing a Uniform Resource
   Identifier = (URI) in a=20 request based on a lookup in a location service
   and thus changing the target of = the=20 request.
 
We=20 have previously discussed that we do need to expand the "based on a = lookup in a=20 location service" to include configuration, etc., so let's not debate = that.=20
 
But,=20 what explicitly is the concern with that definition?
 
Mary.=20
 

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, March 12, = 2009 9:55=20 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Elwell, John;=20 sip@ietf.org
Subject: Re: [Sip] Terminology (was RE: Fwd:=20 I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

I'm fine with discussing implementation if everyone is = meaning the=20 same if they use the same words.

As  to the "retarget" term = such=20 does not seem to be the case.

/Hans Erik van=20 Elburg

------_=_NextPart_001_01C9A33E.E9E13BBA-- From mary.barnes@nortel.com Thu Mar 12 11:33:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB7B3A68E3 for ; Thu, 12 Mar 2009 11:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fROi+SzNH5Vx for ; Thu, 12 Mar 2009 11:33:43 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8ECB73A6881 for ; Thu, 12 Mar 2009 11:33:43 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2CIYIH10685; Thu, 12 Mar 2009 18:34:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 13:36:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD4B7BB@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjIoHiTXPo804cSK+8KHlenVmQYQAAo4ZgAAZFpsAAALjboA== References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com><49B82FB4.4030002@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com><49B84C55.5070107@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com><9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com><9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , "Hans Erik van Elburg" Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:33:45 -0000 Responses below [MB]. ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, March 12, 2009 1:18 PM To: Barnes, Mary (RICH2:AR00); Hans Erik van Elburg Cc: sip@ietf.org; Elwell, John Subject: RE: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Hi Mary, =20 A couple of question: =20 1. Does the 4244bis definition of "retarget" cover the freephone case, when the R-URI is replaced with the AoR of B - not with the contact of B - no matter whether it's done based on location service, configuration or whatever? [MB] That was the intention, however, the current text needs to be made more general (i.e., I was using location service to mean more than registration based contacts - another thing that's not quite so clear in 3261). [/MB] =20 2. Related to the first question, when you say "...and thus chaning the target of the request", what is the defintion of "target"? [MB] The definition of target matches that used in section 16.5 of 3261. A target is an entry in the target list, which is populated using information from a location service, configuration, etc. I can clarify that as well and as you previously suggested make a more comprehensive glossary in the more conventional format - e.g., "Target: definition text, blah, blah, blah...] So, I believe it is the same use of target as in the target-uri draft. [/MB] =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, March 12, 2009 5:20 PM To: Hans Erik van Elburg Cc: sip@ietf.org; Elwell, John Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt When I use "retarget" I am using the definition that I put into 4244bis. So, if you could ignore the tag or change it to 'iscontact' or whatever, what would you change in that definition? Also, consider that if you were to change everyplace that I use "retarget"/"retargeted"/"retargeting" in 4244bis with 'iscontact' the text would not make sense. So, even if we change the name of the tag, we still need to understand the concept or define another term that means that the request-uri in the incoming request (which should be the same as the last hi-entry in the request) is being chnaged due to service lookup, configuration, blah, blah, blah and that to meet the requirements in the target-uri document, we want to tag this entry so that this request-uri is not "lost" - i.e., this is the one the services identified in the target-uri document care about.=20 =20 So, right now, here's what's in 4244bis: =20 The term "retarget" is used in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on a lookup in a location service and thus changing the target of the request. =20 We have previously discussed that we do need to expand the "based on a lookup in a location service" to include configuration, etc., so let's not debate that.=20 =20 But, what explicitly is the concern with that definition? =20 Mary.=20 =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, March 12, 2009 9:55 AM To: Barnes, Mary (RICH2:AR00) Cc: Elwell, John; sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I'm fine with discussing implementation if everyone is meaning the same if they use the same words. As to the "retarget" term such does not seem to be the case. /Hans Erik van Elburg From lists@ohlmeier.org Thu Mar 12 11:38:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C9C3A6881 for ; Thu, 12 Mar 2009 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+Zpn-vOCkJf for ; Thu, 12 Mar 2009 11:38:37 -0700 (PDT) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id B0F5B3A67F3 for ; Thu, 12 Mar 2009 11:38:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id C0D287F97; Thu, 12 Mar 2009 19:39:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hffrHrKcP1qt; Thu, 12 Mar 2009 19:39:13 +0100 (CET) Received: from www.ohlmeier.com (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 41B157F82; Thu, 12 Mar 2009 19:39:13 +0100 (CET) Received: from 192.100.130.229 (SquirrelMail authenticated user lando) by www.ohlmeier.com with HTTP; Thu, 12 Mar 2009 19:39:13 +0100 (CET) Message-ID: <391edc72be6bc16fcc1ff6f3b0e1951c.squirrel@www.ohlmeier.com> In-Reply-To: <618e24240903120959t7199623en2e265686311c090a@mail.gmail.com> References: <49AE593F.6080807@iptel.org> <49B2F7F2.6030804@ohlmeier.org> <49B5006D.8050702@iptel.org> <49B63B9F.9000101@iptel.org> <49B77BEB.4000501@iptel.org> <2ec0d47f2557274d61ca48882a379aa1.squirrel@www.ohlmeier.com> <618e24240903120959t7199623en2e265686311c090a@mail.gmail.com> Date: Thu, 12 Mar 2009 19:39:13 +0100 (CET) From: "Nils Ohlmeier" To: Victor Pascual =?iso-8859-15?Q?=C1vila?= User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Nils Ohlmeier , "sip@ietf.org" Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:38:38 -0000 > On Wed, Mar 11, 2009 at 2:49 PM, Nils Ohlmeier wrote: >> Sure to create a Contact binding via an authenticated REGISTER is one >> possible solution. >> But I think this only works because you rely on the fact that REGISTERs >> are not being retargeted like INVITEs. Which then in the end means you >> simply can forget about authenticating all other requests, as long as >> the >> Contact or IP/port was successfully authenticated via the "one hop" >> REGISTER method (refer-to: IMS). >> The advantage of this solution is clearly that it can be easily deployed >> by hopefully most of the service providers today. >> >> But I believe the proper technical solution would be that the server >> authenticates itself in the challenge, plus adding protected >> informations >> to the challenge which allows the receiver of the challenge to verify >> that >> this challenge was/is targeted to himself. >> The dis-advantage is clearly that this would be only possible with >> extensions of the existing protocols. But we would/might gain other >> benefits by such a solution as well. > > I did not follow the discussion on draft-dotson-sip-mutual-auth. Has > this work been discontinued? > > http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt I can not answer your question. But this draft does not solve the discussed attack, because the server is authenticated after the victim sends its credentials to the attacker alerady. To have a chance to solve the attack scenario the server/challenger would have to prove its identity together with the challenge to prevent that the victim sends out its credentials to the attacker at all. Regards Nils Ohlmeier From lists@ohlmeier.org Thu Mar 12 11:49:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929AE3A698C for ; Thu, 12 Mar 2009 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv6E6dHL5y33 for ; Thu, 12 Mar 2009 11:49:26 -0700 (PDT) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 7D6553A6962 for ; Thu, 12 Mar 2009 11:49:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id AEDF17F97; Thu, 12 Mar 2009 19:50:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxJ9TgMqOdUi; Thu, 12 Mar 2009 19:50:02 +0100 (CET) Received: from www.ohlmeier.com (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 6EFDE7F82; Thu, 12 Mar 2009 19:50:02 +0100 (CET) Received: from 192.100.130.229 (SquirrelMail authenticated user lando) by www.ohlmeier.com with HTTP; Thu, 12 Mar 2009 19:50:02 +0100 (CET) Message-ID: <828cd554936c9f74cee1a9351f03aaed.squirrel@www.ohlmeier.com> Date: Thu, 12 Mar 2009 19:50:02 +0100 (CET) From: "Nils Ohlmeier" To: "sip@ietf.org" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: s.hoggan@cablelabs.com, steve.dotson@cox.com Subject: [Sip] Question regarding draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:49:27 -0000 Hello, after reading the mutual auth draft: http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt I have an open question: what should the client do if the server send authentication informations in a Proxy-Authentication-Info header back in a let say 200 response, but when the client computes response it comes to a different result (e.g. because man in the middle changed something in the messages)? In chapter 5 of your draft you are simply referring to RFC3261 for more details regarding the implementation of the UAC. But I failed to find any information about the UAC handling of this header in 3261. Even RFC2617 gives no hints, at least I did not found any, what a client should do when the server authentication fails. So it is probably not your fault, but still an interesting question I think. Especially because the client has already send its credentials when the check of the server authentication fails. Best regards Nils Ohlmeier From dean.willis@softarmor.com Thu Mar 12 12:27:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725C63A6B3A for ; Thu, 12 Mar 2009 12:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7THoJegNqJI for ; Thu, 12 Mar 2009 12:27:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E82153A690E for ; Thu, 12 Mar 2009 12:27:28 -0700 (PDT) Received: from [192.168.2.104] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2CJRwGP011164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Mar 2009 14:28:00 -0500 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 14:27:53 -0500 References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com><49B82FB4.4030002@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com><49B84C55.5070107@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com><9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com><9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: sip@ietf.org, "Elwell, John" , Mary Barnes Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 19:27:30 -0000 On Mar 12, 2009, at 1:18 PM, Christer Holmberg wrote: > A couple of question: > > 1. Does the 4244bis definition of "retarget" cover the freephone > case, when the R-URI is replaced with the AoR of B - not with the > contact of B - no matter whether it's done based on location > service, configuration or whatever? By the way, I believe that the way I use the words, this is a "reroute" and not a "retarget". In the freephone case, I would still expect the destination to have an awareness that it is the target of freephone calls and have credentials for the freephone number such that it could appropriately authenticate its responses if we had a means to do so. > > 2. Related to the first question, when you say "...and thus chaning > the target of the request", what is the defintion of "target"? > My definition is that a "retarget" changes the expected identity of the expected responder, introducing the possibility of an "unanticipated respondent" scenario. This is, AFAIK, very different from the 4244 terminology, which I've always held to be not particularly useful. -- Dean From sumanth@cablelabs.com Thu Mar 12 13:24:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FAB3A6936 for ; Thu, 12 Mar 2009 13:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az+OOEUlaVTJ for ; Thu, 12 Mar 2009 13:24:02 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id EF5B53A68CD for ; Thu, 12 Mar 2009 13:24:01 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n2CKOcN7001609; Thu, 12 Mar 2009 14:24:38 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 12 Mar 2009 14:24:38 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 14:24:38 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601A1AB2B@srvxchg3.cablelabs.com> In-Reply-To: <828cd554936c9f74cee1a9351f03aaed.squirrel@www.ohlmeier.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding draft-dotson-sip-mutual-auth-03 Thread-Index: AcmjRFlGTE0A8XCwRay5FQHA6ZYHrQACLCKA References: <828cd554936c9f74cee1a9351f03aaed.squirrel@www.ohlmeier.com> From: "Sumanth Channabasappa" To: "Nils Ohlmeier" , X-Approved: ondar Cc: Stuart Hoggan , steve.dotson@cox.com Subject: Re: [Sip] Question regarding draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 20:24:03 -0000 Nils, In the case you describe, the UAC cannot trust the response. So it can take actions similar to when it does not receive a valid response: e.g., it can reasonably retry, log the error, and/or any other appropriate behavior specified by the architecture.=20 RFC3261 supports the Authentication-Info header (used in registration) and not the Proxy-Authentication-Info header; which is why this I-D was authored in the first place. The reference was to ensure that the behavior is kept consistent, and available irrespective of registration and non-registration messages.=20 In any case, please refer to the following small thread (3 emails) for the feedback I received during offline discussions at the last IETF: http://www.ietf.org/mail-archive/web/sip/current/msg25882.html =09 - S -----Original Message----- From: Nils Ohlmeier [mailto:lists@ohlmeier.org]=20 Sent: Thursday, March 12, 2009 12:50 PM To: sip@ietf.org Cc: steve.dotson@cox.com; Stuart Hoggan; Sumanth Channabasappa Subject: Question regarding draft-dotson-sip-mutual-auth-03 Hello, after reading the mutual auth draft: http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt I have an open question: what should the client do if the server send authentication informations in a Proxy-Authentication-Info header back in a let say 200 response, but when the client computes response it comes to a different result (e.g. because man in the middle changed something in the messages)? In chapter 5 of your draft you are simply referring to RFC3261 for more details regarding the implementation of the UAC. But I failed to find any information about the UAC handling of this header in 3261. Even RFC2617 gives no hints, at least I did not found any, what a client should do when the server authentication fails. So it is probably not your fault, but still an interesting question I think. Especially because the client has already send its credentials when the check of the server authentication fails. Best regards Nils Ohlmeier From ietf.hanserik@gmail.com Thu Mar 12 14:25:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E169F3A6BA6 for ; Thu, 12 Mar 2009 14:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=1.183, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlX61nNNq3mA for ; Thu, 12 Mar 2009 14:25:22 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 75BF43A6774 for ; Thu, 12 Mar 2009 14:25:19 -0700 (PDT) Received: by ewy25 with SMTP id 25so2088288ewy.37 for ; Thu, 12 Mar 2009 14:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iYftM+houjIkazMNH8nggSPHw8PF76FYvA8cBPZRdug=; b=InleiSSLlQwCaYBPyrl0UZjgVxpF4POOIakvi20WTo3zrC3OVURs2C1AW2LHTGO4Hx wyTnvA+6sfI4puU3nRUrbs4zPkjcpXzVwgYMEMjcocfTRm4gK4NoLxbW0uaEmo8VZSiB /fzg/eAcEX8Zy3/5Pgu3yKudNpVRXHYzTOdX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Wlx/5viLZHP1OFbbEFmWqhyrz5zuOFiqI9FJoaUMDjzrufgrNmn4JTmgD+n4vDBsew rayG0jky7XMCW9Fv20VbcJfRYXEIVOGWKsfdkeGPCbPa5ZxKb/37wvXkm63rru6geBWX 8ikSxh16omB7+Pl3+nSaMSMWKd/pa+/dIOy1U= MIME-Version: 1.0 Received: by 10.211.196.13 with SMTP id y13mr284337ebp.79.1236893156387; Thu, 12 Mar 2009 14:25:56 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> Date: Thu, 12 Mar 2009 22:25:56 +0100 Message-ID: <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> From: Hans Erik van Elburg To: Mary Barnes Content-Type: multipart/alternative; boundary=0015174c0cec362eb10464f2a1cd Cc: Hans Erik van Elburg , sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 21:25:31 -0000 --0015174c0cec362eb10464f2a1cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Inline... /Hans Erik van Elburg On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes wrote: > I think there is another solution proposal that we should pursue for > issue 3 identified in the email summary sent by Shida earlier this week - > I've snipped all the text except for that issue and issue 2 in the summary > below. I do think the discussion has confounded the two issues and I think > it ought to be clarified that if we agree to the two tags per issue 3, that > the options for the terminology MUST change. And, perhaps this is why the > other discussion threads aren't progressing well. > Agree. > > So, Hans Erick, I would like clarification on as to your view on the > solution: > > In general, ISTM that one of the issues we're having in this terminology > thread is that you are considering the solution to be that the hi-entries > are tagged as they > are added to the request. And, just for clarification from my perspective, > that is NOT the solution in either 4244bis or target-uri. > > The principle should be that the node that has the information about what type of rewrite is performed should add the tag. (This is done by the current target-uri draft allthough the solution is not complete.) For the freephone service, that would be the freephone service. For the AOR that is the home proxy. Assume that the freephone service receives an INVITE request that either 1. received request contains History-Info header that contains the freephone number (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI. (I think that was how History-Info works right.) 2. received request contains History-Info header that does not contain the freephone number as last entry, THEN when rewriting the Request-URI it has add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI. 3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI. After forwarding this request it arrives at the home proxy: 1. received request contains History-Info header that contains the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. (I think that was how History-Info works right.) 2. received request contains History-Info header that does not contain the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has add an entry with the AOR and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. 3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the AOR as in the Request-URI and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact.. > I don't view it as a problem necessarily if you'd like to pursue an > alternate solution, we just need to be clear that's what you're advocating. > In that case, I would agree the "retarget" is not an appropriate tag for the > entries, as you don't know at the point in time that you add an hi-entry > that it will be retargeted. In the case of this approach to the solution, > you do have to alter the mechanism for determining the hi-entry that your > services would want to use. You would need to skip the most recent/last > hi-entry (as that would contain the same as the Request-URI in the incoming > request), since it would be tagged if you use this solution approach. > Yes, but only if the previous proxy added it. As History-Info is optional one never knows really. > Thus, you'd have to take the next hi-entry that you find that has the > desired "tag". I will posit that we could accomplish this solution without > any changes to 4244 by just registering new SIP URI parameter(s). And, > that's not to say we shouldn't do a 4244bis as there are other issues to > address in that document, but that allows the target-uri to describe a > solution that makes use of 4244bis "as is". > > Are you proposing to decouple the target-uri and the 4244bis discussion? > So, feedback on this specific point (from Hans Erik and others) would be > appreciated. > > > Mary. > > --0015174c0cec362eb10464f2a1cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...

/Hans Erik van Elburg


On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes <mary.barnes@nortel.com> wrote:
I think ther= e is another solution proposal that we should pursue for issue 3 identified in the email summary sent by Shida earlier this week - I've snipped all the text except for that issue and issue 2 in the summary below.=A0 I do think the discussion has confounded the two issues and I think it ought to be clarified that if we agree to the two tags per issue 3, that the options for the terminology MUST change. And, perhaps this is why the other discussion threads aren't progressing well.

Agree.
=A0
=A0
So, Hans Erick, I would like clarification on as to your view on the solution:
=A0
In general, ISTM that one of the issues we're having in this terminology thread is that you are considering the solution to be that the hi-entries are tagged as they
are added to the request.=A0 And, just for clarification from my perspective, that is NOT the solution in either 4244bis or target-uri.
=A0=
The principle should be that the node that has the information about what type of rewrite is performed should add the tag. (This is done b= y the current target-uri draft allthough the solution is not complete.)

For the freephone service, that would be the freephone service. For the AOR= that is the home proxy.

Assume that the freephone service receives an INVITE=A0 request that either=A0
1. received request contains History-Info header that contains the freephone number (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI. (I think that was how History-Info works right.)
2. received request contains History-Info header that does not contain the freephone number as last entry, THEN when rewriting the Request-URI it has add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI.
3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI.

After forwarding this request it arrives at the home proxy:
1. received request contains History-Info header that contains the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. (I think that was how History-Info works right.)
2. received request contains History-Info header that does not contain the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has add an entry with the AOR and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact.
3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the AOR as in the Request-URI and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact..
=A0
I don't = view it as a problem necessarily if you'd like to pursue an alternate solution, we just need to be clear that's what you're advocating. I= n that case, I would agree the "retarget" is not an appropriate tag= for the entries, as you don't know at the point in time that you add an hi-entry that it will be retargeted. In the case of this approach to the solution, you do have to alter the mechanism for determining the hi-entry that your services would want to use. You would need to skip the most recent/last hi-entry (as that would=A0contain the same as the Request-URI in the incoming request), since it would be tagged if you use this solution approach.

= Yes, but only if the previous proxy added it. As History-Info is optional o= ne never knows really.
=A0
Thus, yo= u'd have to take the next hi-entry that you find that has the desired "tag".=A0 I will posit that we= could accomplish this solution without any changes to 4244 by just registering new=A0SIP URI parameter(s).=A0=A0=A0And, =A0that's not to s= ay we shouldn't do a 4244bis as there are other issues to address in that document, but that allows the target-uri to describe a solution that makes use of 4244bis "as is".
=A0
Are you proposing to decouple the target= -uri and the 4244bis discussion?
=A0
So, feedback on this specific point (from Hans Erik and others) would be appreciated.


Mary.=



--0015174c0cec362eb10464f2a1cd-- From christer.holmberg@ericsson.com Thu Mar 12 14:56:39 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6581B3A6ABB for ; Thu, 12 Mar 2009 14:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9azhFJ3Vv3ey for ; Thu, 12 Mar 2009 14:56:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1E5293A6AAB for ; Thu, 12 Mar 2009 14:56:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6FC1620458; Thu, 12 Mar 2009 22:57:14 +0100 (CET) X-AuditID: c1b4fb3c-ac007bb000001b43-20-49b9853ae07b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 451D120802; Thu, 12 Mar 2009 22:57:14 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 22:57:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 22:51:22 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CD4B7BB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjIoHiTXPo804cSK+8KHlenVmQYQAAo4ZgAAZFpsAAALjboAAGoaLQ References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903110158m1e6fb07o66110501e8581971@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CCA681D@zrc2hxm0.corp.nortel.com><49B82FB4.4030002@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF97F5@zrc2hxm0.corp.nortel.com><49B84C55.5070107@gmail.com><1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com><9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com><9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1CD4B7BB@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Hans Erik van Elburg" X-OriginalArrivalTime: 12 Mar 2009 21:57:13.0897 (UTC) FILETIME=[80716190:01C9A35D] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 21:56:39 -0000 Hi Mary,=20 >A couple of question: >=20 >1. Does the 4244bis definition of "retarget" cover the freephone case, >when the R-URI is replaced with the AoR of B - not with the contact of B >- no matter whether it's done based on location service, configuration >or whatever? >[MB] That was the intention, however, the current text needs to be made >more general (i.e., I was using location service to mean more than >registration based contacts - another thing that's not quite so clear in >3261). [/MB] [CH] We can fix the text. I just wanted to make sure that you agree on the principle. =20 >2. Related to the first question, when you say "...and thus chaning the >target of the request", what is the defintion of "target"? >[MB] The definition of target matches that used in section 16.5 of 3261. >A target is an entry in the target list, which is populated using >information from a location service, configuration, etc. I can clarify >that as well and as you previously suggested make a more comprehensive >glossary in the more conventional format - e.g., "Target: definition >text, blah, blah, blah...] So, I believe it is the same use of target as >in the target-uri draft. [/MB] [CH] Ok. Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, March 12, 2009 5:20 PM To: Hans Erik van Elburg Cc: sip@ietf.org; Elwell, John Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt When I use "retarget" I am using the definition that I put into 4244bis. So, if you could ignore the tag or change it to 'iscontact' or whatever, what would you change in that definition? Also, consider that if you were to change everyplace that I use "retarget"/"retargeted"/"retargeting" in 4244bis with 'iscontact' the text would not make sense. So, even if we change the name of the tag, we still need to understand the concept or define another term that means that the request-uri in the incoming request (which should be the same as the last hi-entry in the request) is being chnaged due to service lookup, configuration, blah, blah, blah and that to meet the requirements in the target-uri document, we want to tag this entry so that this request-uri is not "lost" - i.e., this is the one the services identified in the target-uri document care about.=20 =20 So, right now, here's what's in 4244bis: =20 The term "retarget" is used in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on a lookup in a location service and thus changing the target of the request. =20 We have previously discussed that we do need to expand the "based on a lookup in a location service" to include configuration, etc., so let's not debate that.=20 =20 But, what explicitly is the concern with that definition? =20 Mary.=20 =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, March 12, 2009 9:55 AM To: Barnes, Mary (RICH2:AR00) Cc: Elwell, John; sip@ietf.org Subject: Re: [Sip] Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I'm fine with discussing implementation if everyone is meaning the same if they use the same words. As to the "retarget" term such does not seem to be the case. /Hans Erik van Elburg From victor.pascual.avila@gmail.com Thu Mar 12 15:20:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA3628C0FC for ; Thu, 12 Mar 2009 15:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmZSiQplWIb9 for ; Thu, 12 Mar 2009 15:20:30 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id D81F428C0E3 for ; Thu, 12 Mar 2009 15:20:29 -0700 (PDT) Received: by ewy25 with SMTP id 25so2135622ewy.37 for ; Thu, 12 Mar 2009 15:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Vb/ZvTM10pnwl5oYB3wbG73stVo0dbb6wEDmqAoeS0k=; b=YM454xsi3LDvs/DqqdWoo73p55ePOKv4U79Rq0R5SfItNlsD7j/3N7Z/yxm9qKj4gG KM4ByPmkNC/Qefav0m/XVa39ikBgrzcWyWEl1CAmshYCbrz5soVu/Jx48TtAGivLGVnN jw4HQ51iv7fetLXVH1BuuzqpStTGbF3aLtZ3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VIC/bJxgqrc9gTcFrgRoxaacvV2dVsWX/9LaEU+A9/MMTMUs4eIx4zt1yy1ioqFfQy zQ6mlyjv1mY3JKfHpMxp1CmEQf6vf7VTM8NVq7yIT9lUSKG94FbuKH32QQWRHQnAvoOc MynOXQt4uz19zA7APPpAJpleK8eifEgLgnlY8= MIME-Version: 1.0 Received: by 10.210.139.15 with SMTP id m15mr166820ebd.84.1236896467010; Thu, 12 Mar 2009 15:21:07 -0700 (PDT) In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601A1AB2B@srvxchg3.cablelabs.com> References: <828cd554936c9f74cee1a9351f03aaed.squirrel@www.ohlmeier.com> <9AAEDF491EF7CA48AB587781B8F5D7C601A1AB2B@srvxchg3.cablelabs.com> Date: Thu, 12 Mar 2009 23:21:06 +0100 Message-ID: <618e24240903121521k2f62031bscb88d2ae5580063a@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Sumanth Channabasappa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Nils Ohlmeier , sip@ietf.org, Stuart Hoggan , steve.dotson@cox.com Subject: Re: [Sip] Question regarding draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 22:20:31 -0000 On Thu, Mar 12, 2009 at 9:24 PM, Sumanth Channabasappa wrote: (snip) > In any case, please refer to the following small thread (3 emails) for > the feedback I received during offline discussions at the last IETF: > > http://www.ietf.org/mail-archive/web/sip/current/msg25882.html >From [1]: "the UA trusts its connection with the next-hop and does not need to authenticate any elements beyond the next-hop" [1] http://www.ietf.org/mail-archive/web/sip/current/msg25890.html Could you please develop this assumption? Thanks, --=20 Victor Pascual =C3=81vila From ietf.hanserik@gmail.com Fri Mar 13 03:18:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70A13A6B68 for ; Fri, 13 Mar 2009 03:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81UOhSfNQXHh for ; Fri, 13 Mar 2009 03:18:14 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id F306D3A6B3A for ; Fri, 13 Mar 2009 03:18:04 -0700 (PDT) Received: by ewy25 with SMTP id 25so2472568ewy.37 for ; Fri, 13 Mar 2009 03:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=l5ZxtgXmTNfzek1f4r7/UeOTl+bcTvs9PER8MtsZNWg=; b=ewLED5PHv3tjeQ/yWl0dbArM0Qn1BGK2A1d/VxKDP/Sdn4Z+sv9nbuEuAQykbVdNwY K5E4Ubsn2PbR7pvB8zC2kuNaXfjqg7uHjEAGgtjhdo0R5hen09bv7iWty6kR2I51HyNZ hCXomNM85sJ5z7KKPZHzwO3/7nr1wsQiMvDmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UO5tx1fH/y4ddqfMurPuYj7QovRVPvEBDXg+YhvBvYJJbqiITtiryi2cwIkoWlfVZ2 ZS8uAwqdWyoscOAMkPtKYCOtuOh7wOkEV9L5JK4+OOq8fZ1zqzDWeeeOzYwNgrwI9cW+ oN/rgrNDvAJXbyceUMOgkcAdI2meq80VhtQG8= MIME-Version: 1.0 Received: by 10.210.54.15 with SMTP id c15mr755514eba.25.1236939522320; Fri, 13 Mar 2009 03:18:42 -0700 (PDT) In-Reply-To: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> Date: Fri, 13 Mar 2009 11:18:42 +0100 Message-ID: <9ae56b1e0903130318x7f0c8dc3rb9bd593a83ddbdbd@mail.gmail.com> From: Hans Erik van Elburg To: Dean Willis Content-Type: multipart/alternative; boundary=0015174beb3ad629910464fd6c61 Cc: sip@ietf.org, "Elwell, John" , Mary Barnes , Christer Holmberg Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 10:18:20 -0000 --0015174beb3ad629910464fd6c61 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dean, Yes this was exactly how we used/defined the terms at the time we where discussing the ua-loose-route vs Target-header solutions. I still think that this way they are most intuitive and closest to how you would use the terms in natural language. /Hans Erik van Elburg On Thu, Mar 12, 2009 at 8:27 PM, Dean Willis wrote: > > On Mar 12, 2009, at 1:18 PM, Christer Holmberg wrote: > > A couple of question: >> >> 1. Does the 4244bis definition of "retarget" cover the freephone case, >> when the R-URI is replaced with the AoR of B - not with the contact of B - >> no matter whether it's done based on location service, configuration or >> whatever? >> > > By the way, I believe that the way I use the words, this is a "reroute" and > not a "retarget". In the freephone case, I would still expect the > destination to have an awareness that it is the target of freephone calls > and have credentials for the freephone number such that it could > appropriately authenticate its responses if we had a means to do so. > > >> 2. Related to the first question, when you say "...and thus chaning the >> target of the request", what is the defintion of "target"? >> >> > > My definition is that a "retarget" changes the expected identity of the > expected responder, introducing the possibility of an "unanticipated > respondent" scenario. > > This is, AFAIK, very different from the 4244 terminology, which I've always > held to be not particularly useful. > > -- > Dean > > --0015174beb3ad629910464fd6c61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dean,

Yes this was exactly how we used/defined the terms at the t= ime we where discussing the ua-loose-route vs Target-header solutions.
<= br>I still think that this way they are most intuitive and closest to how y= ou would use the terms in natural language.

/Hans Erik van Elburg

On Thu, Mar 12, 2009 at 8:27 PM, Dean Willis= <dean.wi= llis@softarmor.com> wrote:

On Mar 12, 2009, at 1:18 PM, Christer Holmberg wrote:

A couple of question:

1. Does the 4244bis definition of "retarget" cover the freephone = case, when the R-URI is replaced with the AoR of B - not with the contact o= f B - no matter whether it's done based on location service, configurat= ion or whatever?

By the way, I believe that the way I use the words, this is a "reroute= " and not a "retarget". In the freephone case, I would still= expect the destination to have an awareness that it is the target of freep= hone calls and have credentials for the freephone number such that it could= appropriately authenticate its responses if we had a means to do so.



2. Related to the first question, when you say "...and thus chaning th= e target of the request", what is the defintion of "target"?=



My definition is that a "retarget" changes the expected identity = of the expected responder, introducing the possibility of an "unantici= pated respondent" scenario.

This is, AFAIK, very different from the 4244 terminology, which I've al= ways held to be not particularly useful.

--
Dean


--0015174beb3ad629910464fd6c61-- From christer.holmberg@ericsson.com Fri Mar 13 04:42:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C403A6A11 for ; Fri, 13 Mar 2009 04:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2YRPJ078TqO for ; Fri, 13 Mar 2009 04:41:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1E0083A683D for ; Fri, 13 Mar 2009 04:41:51 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 44B0F203F9; Fri, 13 Mar 2009 12:42:28 +0100 (CET) X-AuditID: c1b4fb3c-aa804bb000001b43-17-49ba46a4c3df Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 14A3E204CD; Fri, 13 Mar 2009 12:42:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 12:42:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A3D0.AE6DA45C" Date: Fri, 13 Mar 2009 12:41:42 +0100 Message-ID: In-Reply-To: <9ae56b1e0903130318x7f0c8dc3rb9bd593a83ddbdbd@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjxRhZ819f4W9wQ5iV2x9RFuWOtAACyv+A References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> <9ae56b1e0903130318x7f0c8dc3rb9bd593a83ddbdbd@mail.gmail.com> From: "Christer Holmberg" To: "Hans Erik van Elburg" , "Dean Willis" X-OriginalArrivalTime: 13 Mar 2009 11:42:27.0954 (UTC) FILETIME=[C91EE520:01C9A3D0] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "Elwell, John" , Mary Barnes Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 11:42:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A3D0.AE6DA45C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I think we should use those definitions as base. That way I think we would be able to progress faster. =20 Because, I think we really need to agree on the definitions FIRST. There is no idea on discussing detailed wording in 4244bis if we don't have a common understanding of what we mean. =20 Regards, =20 Christer =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 13. maaliskuuta 2009 12:19 To: Dean Willis Cc: Christer Holmberg; Mary Barnes; sip@ietf.org; Elwell, John Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Hi Dean, =09 Yes this was exactly how we used/defined the terms at the time we where discussing the ua-loose-route vs Target-header solutions. =09 I still think that this way they are most intuitive and closest to how you would use the terms in natural language.=20 =09 /Hans Erik van Elburg =09 =09 On Thu, Mar 12, 2009 at 8:27 PM, Dean Willis wrote: =09 On Mar 12, 2009, at 1:18 PM, Christer Holmberg wrote: =09 =09 A couple of question: =09 1. Does the 4244bis definition of "retarget" cover the freephone case, when the R-URI is replaced with the AoR of B - not with the contact of B - no matter whether it's done based on location service, configuration or whatever? =09 By the way, I believe that the way I use the words, this is a "reroute" and not a "retarget". In the freephone case, I would still expect the destination to have an awareness that it is the target of freephone calls and have credentials for the freephone number such that it could appropriately authenticate its responses if we had a means to do so.=20 2. Related to the first question, when you say "...and thus chaning the target of the request", what is the defintion of "target"? =09 =09 My definition is that a "retarget" changes the expected identity of the expected responder, introducing the possibility of an "unanticipated respondent" scenario. =09 This is, AFAIK, very different from the 4244 terminology, which I've always held to be not particularly useful. =09 -- Dean =09 =09 ------_=_NextPart_001_01C9A3D0.AE6DA45C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I think we should use those definitions as = base. That=20 way I think we would be able to progress faster.
 
Because, I think we really need to agree on = the=20 definitions FIRST. There is no idea on discussing detailed wording in = 4244bis if=20 we don't have a common understanding of what we = mean.
 
Regards,
 
Christer
 

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: 13. maaliskuuta 2009 = 12:19
To: Dean Willis
Cc: Christer Holmberg; Mary = Barnes;=20 sip@ietf.org; Elwell, John
Subject: Re: [Sip] Terminology = (was RE:=20 = Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
Hi Dean,

Yes this was exactly how we used/defined = the terms=20 at the time we where discussing the ua-loose-route vs Target-header=20 solutions.

I still think that this way they are most intuitive = and=20 closest to how you would use the terms in natural language.
/Hans Erik van Elburg

On Thu, Mar 12, 2009 at 8:27 PM, Dean Willis = <dean.willis@softarmor.com&g= t;=20 wrote:

On Mar 12, 2009, at 1:18 PM, Christer Holmberg=20 wrote:

A=20 couple of question:

1. Does the 4244bis definition of = "retarget"=20 cover the freephone case, when the R-URI is replaced with the AoR = of B -=20 not with the contact of B - no matter whether it's done based on = location=20 service, configuration or whatever?

By = the way, I=20 believe that the way I use the words, this is a "reroute" and not a=20 "retarget". In the freephone case, I would still expect the = destination to=20 have an awareness that it is the target of freephone calls and have=20 credentials for the freephone number such that it could = appropriately=20 authenticate its responses if we had a means to do so.



2.=20 Related to the first question, when you say "...and thus chaning = the=20 target of the request", what is the defintion of=20 "target"?



My definition is that a=20 "retarget" changes the expected identity of the expected responder,=20 introducing the possibility of an "unanticipated respondent"=20 scenario.

This is, AFAIK, very different from the 4244 = terminology,=20 which I've always held to be not particularly = useful.

--
Dean



Begin forwarded = message:
From: Internet-Drafts@ietf.org
Date: March 10, = 2009 2:30:01 AM=20 JST
To: i-d-announce@ietf.org
Subject: I-D=20 = ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt 
Reply-To: internet-drafts@ietf.org

A New Internet-Draft is available from the on-line=20 Internet-Drafts 
directories.


Title : Delivery of Request-URI Targets to = User=20 Agents
Author(s) : J. Rosenberg, H. van Elburg, C. = Holmberg,=20 F. Audet, S. Schubert
Filename :=20 draft-rosenberg-sip-target-uri-delivery-01.txt
Pages : 16
Date : 2009-3-9

When a Session Initiation = Protocol (SIP)=20 proxy receives a request
  targeted at a URI identifying = a user=20 or resource it is responsible
  for, the proxy translates = the URI=20 to a registered or configured
  contact URI of an agent=20 representing that user or resource.  In = the
  process, the=20 original URI is removed from the request.  Numerous=20 use
  cases have arisen which require this information to = be=20 delivered to
  the user agent.  This document = describes=20 these use cases and defines
  an extension to the = History-Info=20 header field which allows it to be
  used to support = those=20 cases.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-si= p-target-uri-delivery-01.txt

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

Below=20 is the data which will enable a MIME compliant mail = reader
implementation=20 to automatically retrieve the ASCII version of=20 the
Internet-Draft.
Content-Type:=20 text/plain<BR>Content-ID: &lt;2009-3-9102756.I-D@ietf.org&gt;<BR><BR>
_______________________________________________
I-D-Announce = mailing=20 list
I-D-Announce@ietf.org
https://www.i= etf.org/mailman/listinfo/i-d-announce
Internet-Draft=20 directories: http://www.ietf.org/shadow.html<= /A>
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
------_=_NextPart_001_01C9A3D0.AE6DA45C-- From ranjit@motorola.com Fri Mar 13 04:52:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B466B28C0DE; Fri, 13 Mar 2009 04:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXjlcKqduAE8; Fri, 13 Mar 2009 04:52:30 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 74D1F3A6951; Fri, 13 Mar 2009 04:52:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1236945185!29169909!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16880 invoked from network); 13 Mar 2009 11:53:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with AES256-SHA encrypted SMTP; 13 Mar 2009 11:53:05 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n2DBr5Y8009110; Fri, 13 Mar 2009 04:53:05 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id n2DBr48H016048; Fri, 13 Mar 2009 06:53:04 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id n2DBr36l016040; Fri, 13 Mar 2009 06:53:04 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A3D2.438C6B88" Date: Fri, 13 Mar 2009 19:52:57 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B06001CA1@ZMY16EXM66.ds.mot.com> In-Reply-To: <9fcc84cf0903130438w4d7e6f6fh2ff542317315d122@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Pls clarify on session timer thread-index: Acmj0FOjbH3ZujofS6ujQSS0HydrwgAAd7QQ References: <9fcc84cf0903130438w4d7e6f6fh2ff542317315d122@mail.gmail.com> From: "Avasarala Ranjit-A20990" To: "Prakash Ganesan" , , X-CFilter-Loop: Reflected Subject: Re: [Sip] [Sipping] Pls clarify on session timer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 11:52:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A3D2.438C6B88 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Prakash =20 The Server sends a 420 when it doesn't support "timer" option-tag. so its working fine when you remove it from your request. =20 As per section 7.1 of RFC 4028, the UAC SHALL include a Require header with option-tag as "time" in the initial INVITE when it wants the server to support session timer - but this does not necessarily mean that UAC wants the server to perform refresh - but only wants the server to support the session timer. =20 but if the UAC includes a Proxy-Require header with value as "timer", in the initial INVITE then the server MUST support "session-timer" in order to process the request. =20 But again as per RFC Require and Proxy-Require headers are not recommended to be used - but a UAC needs to include "Session-Expires" header field to indicate to the server to apply Session Timer. Regards=20 Ranjit=20 =20 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Prakash Ganesan Sent: Friday, March 13, 2009 5:08 PM To: sip@ietf.org; sipping@ietf.org Subject: [Sipping] Pls clarify on session timer Hi All, I am facing a problem with the session timer. =20 The refesh re-invite contains header field Require: timer and my server is rejecting the request with 420 bad extension. When I remove the header field Reqire: timer, it is working fine.=20 I am bit confused with the section 7.1 Generating an Initial Session Refresh Request, in RFC 4028 it is referring to the first SIP invite or the first session refresher (re-Invite) --=20 Cheers Prakash ------_=_NextPart_001_01C9A3D2.438C6B88 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Prakash
 
The Server sends a 420 when it doesn't support = "timer"=20 option-tag. so its working fine when you remove it from your=20 request.
 
As per section 7.1 of RFC 4028, the UAC SHALL = include a=20 Require header with option-tag as "time" in the initial INVITE when it = wants the=20 server to support session timer - but this does not necessarily mean = that UAC=20 wants the server to perform refresh - but only wants the server to = support the=20 session timer.
 
but if=20 the UAC includes a Proxy-Require header with value as "timer", in the = initial=20 INVITE then the server MUST support "session-timer" in order to process = the=20 request.
 
But=20 again as per RFC Require and Proxy-Require headers are not recommended = to be=20 used - but a UAC needs to include "Session-Expires" header field to = indicate to=20 the server to apply Session Timer.

Regards
Ranjit=20
 

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of Prakash=20 Ganesan
Sent: Friday, March 13, 2009 5:08 PM
To:=20 sip@ietf.org; sipping@ietf.org
Subject: [Sipping] Pls clarify = on=20 session timer

Hi All,
I am facing a problem with the = session=20 timer.
 
The refesh re-invite contains = header field=20 Require: timer and my server is rejecting the request with 420 bad = extension.=20 When I remove the header field Reqire: timer, it is working fine. =
I am bit confused with the = section 7.1=20 Generating an Initial Session Refresh Request, in RFC = 4028 it=20 is referring to the first SIP invite or the first session refresher=20 (re-Invite)


-- =
Cheers
Prakash
------_=_NextPart_001_01C9A3D2.438C6B88-- From lists@ohlmeier.org Fri Mar 13 05:15:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532C928C0F9 for ; Fri, 13 Mar 2009 05:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLs0lZ-YaiBD for ; Fri, 13 Mar 2009 05:14:54 -0700 (PDT) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id E3DFF3A6BBD for ; Fri, 13 Mar 2009 05:14:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 9EC757F97; Fri, 13 Mar 2009 13:15:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9aYSE-PKyBF; Fri, 13 Mar 2009 13:15:28 +0100 (CET) Received: from www.ohlmeier.com (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 2E2257F82; Fri, 13 Mar 2009 13:15:28 +0100 (CET) Received: from 192.100.130.229 (SquirrelMail authenticated user lando) by www.ohlmeier.com with HTTP; Fri, 13 Mar 2009 13:15:28 +0100 (CET) Message-ID: <9c44079715e12f55de7c79d1735ca570.squirrel@www.ohlmeier.com> In-Reply-To: <618e24240903121521k2f62031bscb88d2ae5580063a@mail.gmail.com> References: <828cd554936c9f74cee1a9351f03aaed.squirrel@www.ohlmeier.com> <9AAEDF491EF7CA48AB587781B8F5D7C601A1AB2B@srvxchg3.cablelabs.com> <618e24240903121521k2f62031bscb88d2ae5580063a@mail.gmail.com> Date: Fri, 13 Mar 2009 13:15:28 +0100 (CET) From: "Nils Ohlmeier" To: Victor Pascual =?iso-8859-15?Q?=C1vila?= User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Nils Ohlmeier , sip@ietf.org, Stuart Hoggan , steve.dotson@cox.com Subject: Re: [Sip] Question regarding draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 12:15:02 -0000 > On Thu, Mar 12, 2009 at 9:24 PM, Sumanth Channabasappa > wrote: > (snip) >> In any case, please refer to the following small thread (3 emails) for >> the feedback I received during offline discussions at the last IETF: >> >> http://www.ietf.org/mail-archive/web/sip/current/msg25882.html > >>From [1]: "the UA trusts its connection with the next-hop and does not > need to authenticate any elements beyond the next-hop" > > [1] http://www.ietf.org/mail-archive/web/sip/current/msg25890.html > > Could you please develop this assumption? I also do not understand this sentense. It sounds like the IP connection to the next hop is so trustworthy that we could use clear text passwords instead of digest auth?! But I think that such conditions would only be given when we use TLS or IPSec, in which case digest mutual auth makes no real sense any more. Regards Nils From lists@ohlmeier.org Fri Mar 13 05:37:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD273A6B0C for ; Fri, 13 Mar 2009 05:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-2.062, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFZaGAYkbHic for ; Fri, 13 Mar 2009 05:36:53 -0700 (PDT) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id D035328C0E4 for ; Fri, 13 Mar 2009 05:36:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id F381A7F97; Fri, 13 Mar 2009 13:37:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVhBtU76+4l4; Fri, 13 Mar 2009 13:37:29 +0100 (CET) Received: from www.ohlmeier.com (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id 6FF987F82; Fri, 13 Mar 2009 13:37:29 +0100 (CET) Received: from 192.100.130.229 (SquirrelMail authenticated user lando) by www.ohlmeier.com with HTTP; Fri, 13 Mar 2009 13:37:29 +0100 (CET) Message-ID: In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601A1AB2B@srvxchg3.cablelabs.com> References: <828cd554936c9f74cee1a9351f03aaed.squirrel@www.ohlmeier.com> <9AAEDF491EF7CA48AB587781B8F5D7C601A1AB2B@srvxchg3.cablelabs.com> Date: Fri, 13 Mar 2009 13:37:29 +0100 (CET) From: "Nils Ohlmeier" To: "Sumanth Channabasappa" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Nils Ohlmeier , sip@ietf.org, Stuart Hoggan , steve.dotson@cox.com Subject: Re: [Sip] Question regarding draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 12:37:00 -0000 Hi Sumanth, > In the case you describe, the UAC cannot trust the response. So it can > take actions similar to when it does not receive a valid response: e.g., > it can reasonably retry, log the error, and/or any other appropriate > behavior specified by the architecture. Ok, but the point is that in most of the cases it will be too late already. Maybe an example is helpfull: I try to register via proxy.hotel.com to my registrar at example.com. Note: I'm using the open WLAN of hotel of cours. Now proxy.hotel.com challenges my initial REGISTER request, which my UA replies to with the password which I got at the receiption. Now this second REGISTER request is forwarded to example.com and replied with a 200 OK. When my UA receives the 200 OK it checks the Proxy-Authentication-Info header and detects an error (maybe because a man-in-the-midlle modified something). Upppss! What should the UA do here? Display me a warning "It looks like you successfully registered to example.com. Unfortunately something went wrong. But your credentials where send already to example.com... Maybe now someone else is registered with your account to example.com?!" > RFC3261 supports the Authentication-Info header (used in registration) > and not the Proxy-Authentication-Info header; which is why this I-D was > authored in the first place. The reference was to ensure that the > behavior is kept consistent, and available irrespective of registration > and non-registration messages. I understand that your draft is only adding the Proxy-Authentication-Info header. On the other hand I doubt that the whole mutual digest auth like it is described in 2617 and 3261 is usuable for SIP at all. > In any case, please refer to the following small thread (3 emails) for > the feedback I received during offline discussions at the last IETF: > > http://www.ietf.org/mail-archive/web/sip/current/msg25882.html >From that small thread I can only ask the same question as Victor did already: what is meant by this trusted connection to the next hop? And another issue in your draft in my opinion is what you describe in second paragraph of section 10: If someone is going to use mutual digest authentication it can not be optional! As recent "demonstrations" on HTTPS and SMTP with TLS have shown security "upgrades" of an IP connection are not optional. If you know that your server (the hotel proxy in the example above) supports mutual auth, you should configure your UA to require mutual auth. If the mutual auth is not there or failed, something is really wrong in the network and you should definately not proceed with whatever you wanted to do. If you insist on the Proxy-Authorization-Info header being optional is will be of no use at all. Because in all positiv working scenario it will be present and working. But in all scenarios with broken, tapped or whatever networks the header will be missing and your UA should send any message with credentials in first place. Best regards Nils Ohlmeier > > - S > > -----Original Message----- > From: Nils Ohlmeier [mailto:lists@ohlmeier.org] > Sent: Thursday, March 12, 2009 12:50 PM > To: sip@ietf.org > Cc: steve.dotson@cox.com; Stuart Hoggan; Sumanth Channabasappa > Subject: Question regarding draft-dotson-sip-mutual-auth-03 > > Hello, > > after reading the mutual auth draft: > > http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt > > I have an open question: > what should the client do if the server send authentication informations > in a Proxy-Authentication-Info header back in a let say 200 response, > but > when the client computes response it comes to a different result (e.g. > because man in the middle changed something in the messages)? > > In chapter 5 of your draft you are simply referring to RFC3261 for more > details regarding the implementation of the UAC. But I failed to find > any > information about the UAC handling of this header in 3261. Even RFC2617 > gives no hints, at least I did not found any, what a client should do > when > the server authentication fails. > So it is probably not your fault, but still an interesting question I > think. Especially because the client has already send its credentials > when > the check of the server authentication fails. > > Best regards > Nils Ohlmeier > > From john.elwell@siemens.com Fri Mar 13 07:24:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9043F3A6A5C for ; Fri, 13 Mar 2009 07:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kRrftgerLKr for ; Fri, 13 Mar 2009 07:23:58 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 630343A6991 for ; Fri, 13 Mar 2009 07:23:57 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGG0016N80OR4@siemenscomms.co.uk> for sip@ietf.org; Fri, 13 Mar 2009 14:24:34 +0000 (GMT) Date: Fri, 13 Mar 2009 14:24:30 +0000 From: "Elwell, John" In-reply-to: <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> To: Hans Erik van Elburg , Mary Barnes Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjXdDsF7jfvNX1TD62pUpoH3J7kgAiPERw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> Cc: Hans Erik van Elburg , sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:24:04 -0000 Hans Erik, Following your detailed description, it seems that the UAS serving a freephone number could receive one of the following (assuming H-I is supported by all relevant nodes): 1) H-I containing: - the freephone number (tagged); - the AoR (tagged); - the contact URI (not tagged). Or 2) H-I containing:=20 - the freephone number (tagged); - the contact URI (not tagged). The latter would occur when the same proxy translates the freephone number (via the AoR) to the contact directly. So how does this help the UAS to figure out the freephone number? It seems the UAS would have to search back through the tagged entries looking for one that matches a freephone number it recognises? Does the tagging really add much value? John ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 12 March 2009 21:26 To: Mary Barnes Cc: Hans Erik van Elburg; sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Inline... =09 /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes wrote: =09 I think there is another solution proposal that we should pursue for issue 3 identified in the email summary sent by Shida earlier this week - I've snipped all the text except for that issue and issue 2 in the summary below. I do think the discussion has confounded the two issues and I think it ought to be clarified that if we agree to the two tags per issue 3, that the options for the terminology MUST change. And, perhaps this is why the other discussion threads aren't progressing well. Agree. =20 =20 So, Hans Erick, I would like clarification on as to your view on the solution: =20 In general, ISTM that one of the issues we're having in this terminology thread is that you are considering the solution to be that the hi-entries are tagged as they=20 are added to the request. And, just for clarification from my perspective, that is NOT the solution in either 4244bis or target-uri.=20 =20 The principle should be that the node that has the information about what type of rewrite is performed should add the tag. (This is done by the current target-uri draft allthough the solution is not complete.) =09 For the freephone service, that would be the freephone service. For the AOR that is the home proxy. =09 Assume that the freephone service receives an INVITE request that either =20 1. received request contains History-Info header that contains the freephone number (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI. (I think that was how History-Info works right.) 2. received request contains History-Info header that does not contain the freephone number as last entry, THEN when rewriting the Request-URI it has add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI. 3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI. =09 After forwarding this request it arrives at the home proxy: 1. received request contains History-Info header that contains the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. (I think that was how History-Info works right.) 2. received request contains History-Info header that does not contain the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has add an entry with the AOR and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. 3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the AOR as in the Request-URI and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact.. =20 I don't view it as a problem necessarily if you'd like to pursue an alternate solution, we just need to be clear that's what you're advocating. In that case, I would agree the "retarget" is not an appropriate tag for the entries, as you don't know at the point in time that you add an hi-entry that it will be retargeted. In the case of this approach to the solution, you do have to alter the mechanism for determining the hi-entry that your services would want to use. You would need to skip the most recent/last hi-entry (as that would contain the same as the Request-URI in the incoming request), since it would be tagged if you use this solution approach. Yes, but only if the previous proxy added it. As History-Info is optional one never knows really. =20 =09 Thus, you'd have to take the next hi-entry that you find that has the desired "tag". I will posit that we could accomplish this solution without any changes to 4244 by just registering new SIP URI parameter(s). And, that's not to say we shouldn't do a 4244bis as there are other issues to address in that document, but that allows the target-uri to describe a solution that makes use of 4244bis "as is". =09 =20 Are you proposing to decouple the target-uri and the 4244bis discussion? =20 So, feedback on this specific point (from Hans Erik and others) would be appreciated.=20 =09 =09 =09 Mary. From mary.barnes@nortel.com Fri Mar 13 07:27:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46833A6A3D for ; Fri, 13 Mar 2009 07:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpQtI69uOh0D for ; Fri, 13 Mar 2009 07:27:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9EC2C3A683D for ; Fri, 13 Mar 2009 07:27:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2DERg404320; Fri, 13 Mar 2009 14:27:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 09:30:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD7F3FF@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjxRhZ819f4W9wQ5iV2x9RFuWOtAACyv+AAAXQ7aA= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> <9ae56b1e0903130318x7f0c8dc3rb9bd593a83ddbdbd@mail.gmail.com> From: "Mary Barnes" To: "Christer Holmberg" , "Hans Erik van Elburg" , "Dean Willis" Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:27:35 -0000 That's fine - we just need to be careful with the wording in 4244 so that the existing normative functionality isn't so impacted. I'll look at the detailed impact of the changes as retarget is quite prevalent in that document. It could be that we can leave it in the early sections (and define it to be the same as the term we agree) and just keep it out of the normative sections - right now, it is only used in a few places other than describing the new parameter in the normative sections. =20 Mary. ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, March 13, 2009 6:42 AM To: Hans Erik van Elburg; Dean Willis Cc: Barnes, Mary (RICH2:AR00); sip@ietf.org; Elwell, John Subject: RE: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Hi, =20 I think we should use those definitions as base. That way I think we would be able to progress faster. =20 Because, I think we really need to agree on the definitions FIRST. There is no idea on discussing detailed wording in 4244bis if we don't have a common understanding of what we mean. =20 Regards, =20 Christer =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 13. maaliskuuta 2009 12:19 To: Dean Willis Cc: Christer Holmberg; Mary Barnes; sip@ietf.org; Elwell, John Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Hi Dean, =09 Yes this was exactly how we used/defined the terms at the time we where discussing the ua-loose-route vs Target-header solutions. =09 I still think that this way they are most intuitive and closest to how you would use the terms in natural language.=20 =09 /Hans Erik van Elburg =09 =09 On Thu, Mar 12, 2009 at 8:27 PM, Dean Willis wrote: =09 On Mar 12, 2009, at 1:18 PM, Christer Holmberg wrote: =09 =09 A couple of question: =09 1. Does the 4244bis definition of "retarget" cover the freephone case, when the R-URI is replaced with the AoR of B - not with the contact of B - no matter whether it's done based on location service, configuration or whatever? =09 By the way, I believe that the way I use the words, this is a "reroute" and not a "retarget". In the freephone case, I would still expect the destination to have an awareness that it is the target of freephone calls and have credentials for the freephone number such that it could appropriately authenticate its responses if we had a means to do so.=20 2. Related to the first question, when you say "...and thus chaning the target of the request", what is the defintion of "target"? =09 =09 My definition is that a "retarget" changes the expected identity of the expected responder, introducing the possibility of an "unanticipated respondent" scenario. =09 This is, AFAIK, very different from the 4244 terminology, which I've always held to be not particularly useful. =09 -- Dean =09 =09 From ietf.hanserik@gmail.com Fri Mar 13 07:32:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64FD3A6A94 for ; Fri, 13 Mar 2009 07:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOBrJBAvi4Ol for ; Fri, 13 Mar 2009 07:32:39 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id ABED73A684A for ; Fri, 13 Mar 2009 07:32:38 -0700 (PDT) Received: by ewy25 with SMTP id 25so2571816ewy.37 for ; Fri, 13 Mar 2009 07:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nrXDMj0uDif0UiD44jYeWKEiTRJan5iLK9VPOkUFIhw=; b=XMUm6yde3ML30L9hTDs1yOAKiBeFBV3DJNnoAzK3b5fdZ/fOQrqy6V8DXn53T6pIH6 bYrSXdOh1OlhsmYpwiCRpslUMLc5JbfgKhTZ/jiqoD7vdjVZyuXo6UBlerjfmPErVxa4 qeMiToOKrYzS/25nX4Dd8IB0rm8JNX5hNdmmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dMVJmhbqDUkyFdPQPue0DLY1eq+wz+BXHpY7EMECEFoM9IRMUZyn+3Q2d7Irn9tN0V OYizypca+yhdLkd5oodv50RaRJIE7P+P+iXnSy4PAVpU6MkavzFJriUJGlTBt/ELf0jv pNXENeKTFcpakqMnjLsPApBNAHIFixxTZ2kmw= MIME-Version: 1.0 Received: by 10.210.17.14 with SMTP id 14mr824810ebq.49.1236954796520; Fri, 13 Mar 2009 07:33:16 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 13 Mar 2009 15:33:16 +0100 Message-ID: <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174be6ea3ff725046500fba1 Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:32:45 -0000 --0015174be6ea3ff725046500fba1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi John, Well that is simple one would use different tags for different type of entries, like in the example I already gave: H-I: Bfreephone; "istarget",\ B,"aor"\ contact-B Where the UAS interested in the initial target with which it was addressed it would obtain the "istarget" tagged entry. Where the UAS interested in the AOR that was used to address it would obtain the "aor" tagged entry. In simpler cases it could be that one entry holds the "aor" as well as the "istarget" tag. Of course the algorithm needs some work to make it complete. /Hans Erik van Elburg On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John wrote: > Hans Erik, > > Following your detailed description, it seems that the UAS serving a > freephone number could receive one of the following (assuming H-I is > supported by all relevant nodes): > > 1) H-I containing: > - the freephone number (tagged); > - the AoR (tagged); > - the contact URI (not tagged). > > Or > > 2) H-I containing: > - the freephone number (tagged); > - the contact URI (not tagged). > > The latter would occur when the same proxy translates the freephone > number (via the AoR) to the contact directly. > > So how does this help the UAS to figure out the freephone number? It > seems the UAS would have to search back through the tagged entries > looking for one that matches a freephone number it recognises? Does the > tagging really add much value? > > John > > > ________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: 12 March 2009 21:26 > To: Mary Barnes > Cc: Hans Erik van Elburg; sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > Inline... > > /Hans Erik van Elburg > > > > On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes > wrote: > > > I think there is another solution proposal that we > should pursue for issue 3 identified in the email summary sent by Shida > earlier this week - I've snipped all the text except for that issue and > issue 2 in the summary below. I do think the discussion has confounded > the two issues and I think it ought to be clarified that if we agree to > the two tags per issue 3, that the options for the terminology MUST > change. And, perhaps this is why the other discussion threads aren't > progressing well. > > > Agree. > > > > So, Hans Erick, I would like clarification on as to your > view on the solution: > > In general, ISTM that one of the issues we're having in > this terminology thread is that you are considering the solution to be > that the hi-entries are tagged as they > are added to the request. And, just for clarification > from my perspective, that is NOT the solution in either 4244bis or > target-uri. > > > The principle should be that the node that has the information > about what type of rewrite is performed should add the tag. (This is > done by the current target-uri draft allthough the solution is not > complete.) > > For the freephone service, that would be the freephone service. > For the AOR that is the home proxy. > > Assume that the freephone service receives an INVITE request > that either > 1. received request contains History-Info header that contains > the freephone number (as in R-URI) as last entry, THEN when rewriting > the Request-URI it has to tag that existing received entry AND add the > new entry with the new value of the Request-URI. (I think that was how > History-Info works right.) > 2. received request contains History-Info header that does not > contain the freephone number as last entry, THEN when rewriting the > Request-URI it has add an entry with the freephone number and tag that > entry AND add the new entry with the new value of the Request-URI. > 3. received request does not contain a History-Info header, THEN > when rewriting the Request-URI it has to add an entry with the freephone > number and tag that entry AND add the new entry with the new value of > the Request-URI. > > After forwarding this request it arrives at the home proxy: > 1. received request contains History-Info header that contains > the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI > it has to tag that existing received entry AND add the new entry with > the new value of the Request-URI i.e. the registered contact. (I think > that was how History-Info works right.) > 2. received request contains History-Info header that does not > contain the AOR (as in R-URI) as last entry, THEN when rewriting the > Request-URI it has add an entry with the AOR and tag that entry AND add > the new entry with the new value of the Request-URI i.e. the registered > contact. > 3. received request does not contain a History-Info header, THEN > when rewriting the Request-URI it has to add an entry with the AOR as in > the Request-URI and tag that entry AND add the new entry with the new > value of the Request-URI i.e. the registered contact.. > > > I don't view it as a problem necessarily if you'd like > to pursue an alternate solution, we just need to be clear that's what > you're advocating. In that case, I would agree the "retarget" is not an > appropriate tag for the entries, as you don't know at the point in time > that you add an hi-entry that it will be retargeted. In the case of this > approach to the solution, you do have to alter the mechanism for > determining the hi-entry that your services would want to use. You would > need to skip the most recent/last hi-entry (as that would contain the > same as the Request-URI in the incoming request), since it would be > tagged if you use this solution approach. > > > Yes, but only if the previous proxy added it. As History-Info is > optional one never knows really. > > > > Thus, you'd have to take the next hi-entry that you find > that has the desired "tag". I will posit that we could accomplish this > solution without any changes to 4244 by just registering new SIP URI > parameter(s). And, that's not to say we shouldn't do a 4244bis as > there are other issues to address in that document, but that allows the > target-uri to describe a solution that makes use of 4244bis "as is". > > > > Are you proposing to decouple the target-uri and the 4244bis > discussion? > > > So, feedback on this specific point (from Hans Erik and > others) would be appreciated. > > > > Mary. > > > > > --0015174be6ea3ff725046500fba1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John,

Well that is simple one would use different tags for differ= ent type of entries, like in the example I already gave:

=A0=A0 H-I:= =A0 Bfreephone; "istarget",\
=A0=A0=A0 =A0=A0=A0 B,"aor"\
=A0=A0=A0 =A0=A0=A0 contact-B

Where the UAS interested in the initia= l target with which it was addressed it would obtain the "istarget&quo= t; tagged entry.
Where the UAS interested in the AOR=A0 that was used to= address it would obtain the "aor" tagged entry.
=A0
In simpler cases it could be that one entry holds the "aor"= ; as well as the "istarget" tag.

Of course the algorithm n= eeds some work to make it complete.

/Hans Erik van Elburg


On Fri, Mar 13, 2009 at 3:24 PM, Elwell,= John <john= .elwell@siemens.com> wrote:
Hans Erik,

Following your detailed description, it seems that the UAS serving a
freephone number could receive one of the following (assuming H-I is
supported by all relevant nodes):

1) H-I containing:
- the freephone number (tagged);
- the AoR (tagged);
- the contact URI (not tagged).

Or

2) H-I containing:
- the freephone number (tagged);
- the contact URI (not tagged).

The latter would occur when the same proxy translates the freephone
number (via the AoR) to the contact directly.

So how does this help the UAS to figure out the freephone number? It
seems the UAS would have to search back through the tagged entries
looking for one that matches a freephone number it recognises? Does the
tagging really add much value?

John


________________________________

=A0 =A0 =A0 =A0From: sip-bounces@i= etf.org [mailto:sip-bounces@iet= f.org] On
Behalf Of Hans Erik van Elburg
=A0 =A0 =A0 =A0Sent: 12 March 2009 21:26
=A0 =A0 =A0 =A0To: Mary Barnes
=A0 =A0 =A0 =A0Cc: Hans Erik van Elburg; s= ip@ietf.org
=A0 =A0 =A0 =A0Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


=A0 =A0 =A0 =A0Inline...

=A0 =A0 =A0 =A0/Hans Erik van Elburg



=A0 =A0 =A0 =A0On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes
<mary.barnes@nortel.com>= ; wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I think there is another solution proposal = that we
should pursue for issue 3 identified in the email summary sent by Shida
earlier this week - I've snipped all the text except for that issue and=
issue 2 in the summary below. =A0I do think the discussion has confounded the two issues and I think it ought to be clarified that if we agree to
the two tags per issue 3, that the options for the terminology MUST
change. And, perhaps this is why the other discussion threads aren't progressing well.


=A0 =A0 =A0 =A0Agree.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So, Hans Erick, I would like clarification = on as to your
view on the solution:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In general, ISTM that one of the issues we&= #39;re having in
this terminology thread is that you are considering the solution to be
that the hi-entries are tagged as they
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are added to the request. =A0And, just for = clarification
from my perspective, that is NOT the solution in either 4244bis or
target-uri.


=A0 =A0 =A0 =A0The principle should be that the node that has the informat= ion
about what type of rewrite is performed should add the tag. (This is
done by the current target-uri draft allthough the solution is not
complete.)

=A0 =A0 =A0 =A0For the freephone service, that would be the freephone serv= ice.
For the AOR that is the home proxy.

=A0 =A0 =A0 =A0Assume that the freephone service receives an INVITE =A0req= uest
that either
=A0 =A0 =A0 =A01. received request contains History-Info header that conta= ins
the freephone number (as in R-URI) as last entry, THEN when rewriting
the Request-URI it has to tag that existing received entry AND add the
new entry with the new value of the Request-URI. (I think that was how
History-Info works right.)
=A0 =A0 =A0 =A02. received request contains History-Info header that does = not
contain the freephone number as last entry, THEN when rewriting the
Request-URI it has add an entry with the freephone number and tag that
entry AND add the new entry with the new value of the Request-URI.
=A0 =A0 =A0 =A03. received request does not contain a History-Info header,= THEN
when rewriting the Request-URI it has to add an entry with the freephone number and tag that entry AND add the new entry with the new value of
the Request-URI.

=A0 =A0 =A0 =A0After forwarding this request it arrives at the home proxy:=
=A0 =A0 =A0 =A01. received request contains History-Info header that conta= ins
the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with
the new value of the Request-URI i.e. the registered contact. (I think
that was how History-Info works right.)
=A0 =A0 =A0 =A02. received request contains History-Info header that does = not
contain the AOR (as in R-URI) as last entry, THEN when rewriting the
Request-URI it has add an entry with the AOR and tag that entry AND add
the new entry with the new value of the Request-URI i.e. the registered
contact.
=A0 =A0 =A0 =A03. received request does not contain a History-Info header,= THEN
when rewriting the Request-URI it has to add an entry with the AOR as in the Request-URI and tag that entry AND add the new entry with the new
value of the Request-URI i.e. the registered contact..


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I don't view it as a problem necessaril= y if you'd like
to pursue an alternate solution, we just need to be clear that's what you're advocating. In that case, I would agree the "retarget"= is not an
appropriate tag for the entries, as you don't know at the point in time=
that you add an hi-entry that it will be retargeted. In the case of this approach to the solution, you do have to alter the mechanism for
determining the hi-entry that your services would want to use. You would need to skip the most recent/last hi-entry (as that would contain the
same as the Request-URI in the incoming request), since it would be
tagged if you use this solution approach.


=A0 =A0 =A0 =A0Yes, but only if the previous proxy added it. As History-In= fo is
optional one never knows really.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thus, you'd have to take the next hi-en= try that you find
that has the desired "tag". =A0I will posit that we could accompl= ish this
solution without any changes to 4244 by just registering new SIP URI
parameter(s). =A0 And, =A0that's not to say we shouldn't do a 4244b= is as
there are other issues to address in that document, but that allows the
target-uri to describe a solution that makes use of 4244bis "as is&quo= t;.



=A0 =A0 =A0 =A0Are you proposing to decouple the target-uri and the 4244bi= s
discussion?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So, feedback on this specific point (from H= ans Erik and
others) would be appreciated.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mary.





--0015174be6ea3ff725046500fba1-- From mary.barnes@nortel.com Fri Mar 13 07:36:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06863A684E for ; Fri, 13 Mar 2009 07:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql6fVr2LJznh for ; Fri, 13 Mar 2009 07:36:19 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 76B4C3A680E for ; Fri, 13 Mar 2009 07:36:19 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2DEaZ407864; Fri, 13 Mar 2009 14:36:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 09:39:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CD7F457@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 3 - two tags (was RE: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjWSQz40gPTJThQ5am+UYceIaTqgAjzTdg References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: Hans Erik van Elburg , sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:36:25 -0000 So, it appears we are both talking about the solutions that are currently described in 4244bis and target-uri (they are the same and one in 4244bis is more complete than the one in target-uri for obvious reasons). I view this solution to be tagging the entries with the "action" (whatever we call it) that resulted in the uri reflected in the hi-entry in the incoming request being overwritten by a "new" Request-URI in the outgoing request. Whereas, I had been concerned that the solution you had in mind was one whereby we were tagging the "new" Request-URI with the action that resulted in the "new" request URI. So your response clears my confusion, so we'll ignore the alternative suggestion (as that would only apply to that latter view of the solution - i.e., the one suggested below). =20 Thanks, Mary.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, March 12, 2009 4:26 PM To: Barnes, Mary (RICH2:AR00) Cc: Hans Erik van Elburg; sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Inline... /Hans Erik van Elburg On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes wrote: > I think there is another solution proposal that we should pursue for issue 3 identified in the email=20 > summary sent by Shida earlier this week - I've snipped all the text except for that issue and issue 2 in the=20 > summary below. I do think the discussion has confounded the two issues and I think it ought to be clarified=20 > that if we agree to the two tags per issue 3, that the options for the terminology MUST change. And, perhaps=20 > this is why the other discussion threads aren't progressing well. Agree. =20 =20 > So, Hans Erick, I would like clarification on as to your view on the solution: =20 > In general, ISTM that one of the issues we're having in this terminology thread is that you are considering the=20 > solution to be that the hi-entries are tagged as they=20 > are added to the request. And, just for clarification from my perspective, that is NOT the solution in either > 4244bis or target-uri.=20 =20 The principle should be that the node that has the information about what type of rewrite is performed should add the tag. (This is done by the current target-uri draft allthough the solution is not complete.) For the freephone service, that would be the freephone service. For the AOR that is the home proxy. Assume that the freephone service receives an INVITE request that either =20 1. received request contains History-Info header that contains the freephone number (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI. (I think that was how History-Info works right.) 2. received request contains History-Info header that does not contain the freephone number as last entry, THEN when rewriting the Request-URI it has add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI. 3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI. After forwarding this request it arrives at the home proxy: 1. received request contains History-Info header that contains the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. (I think that was how History-Info works right.) 2. received request contains History-Info header that does not contain the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has add an entry with the AOR and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. 3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the AOR as in the Request-URI and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact.. =20 > I don't view it as a problem necessarily if you'd like to pursue an alternate solution, we just need to be clear=20 > that's what you're advocating. In that case, I would agree the "retarget" is not an appropriate tag for the entries, > as you don't know at the point in time that you add an hi-entry that it will be retargeted. In the case of this=20 > approach to the solution, you do have to alter the mechanism for determining the hi-entry that your services would=20 > want to use. You would need to skip the most recent/last hi-entry (as that would contain the same as the Request-URI > in the incoming request), since it would be tagged if you use this solution approach. Yes, but only if the previous proxy added it. As History-Info is optional one never knows really. =20 > Thus, you'd have to take the next hi-entry that you find that has the desired "tag". I will posit that we could=20 > accomplish this solution without any changes to 4244 by just registering new SIP URI parameter(s). And, that's not > to say we shouldn't do a 4244bis as there are other issues to address in that document, but that allows the target-uri > to describe a solution that makes use of 4244bis "as is". =09 =20 Are you proposing to decouple the target-uri and the 4244bis discussion? =20 > So, feedback on this specific point (from Hans Erik and others) would be appreciated.=20 =09 =09 =09 Mary. From john.elwell@siemens.com Fri Mar 13 07:39:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374023A6855 for ; Fri, 13 Mar 2009 07:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFZ1mRkjl2An for ; Fri, 13 Mar 2009 07:39:21 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B28FA3A684A for ; Fri, 13 Mar 2009 07:39:20 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGG0024U8QJNG@siemenscomms.co.uk> for sip@ietf.org; Fri, 13 Mar 2009 14:39:59 +0000 (GMT) Date: Fri, 13 Mar 2009 14:39:48 +0000 From: "Elwell, John" In-reply-to: <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> To: Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: Acmj6KZoJUQToImZSbOC98zn8iE5gQAAHDtA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:39:27 -0000 Hans Erik, But how does a proxy know what to use? How does it know whether the received Request-URI, which it uses to query the LS, is a target or an AoR? Does it need to scan back up the H-I chain to see whether there is already an 'istarget' present, and if so use 'aor' instead of 'istarget'? John ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 13 March 2009 14:33 To: Elwell, John Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Hi John, =09 Well that is simple one would use different tags for different type of entries, like in the example I already gave: =09 H-I: Bfreephone; "istarget",\ B,"aor"\ contact-B =09 Where the UAS interested in the initial target with which it was addressed it would obtain the "istarget" tagged entry. Where the UAS interested in the AOR that was used to address it would obtain the "aor" tagged entry. =20 In simpler cases it could be that one entry holds the "aor" as well as the "istarget" tag. =09 Of course the algorithm needs some work to make it complete. =09 /Hans Erik van Elburg =09 =09 =09 On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John wrote: =09 Hans Erik, =09 Following your detailed description, it seems that the UAS serving a freephone number could receive one of the following (assuming H-I is supported by all relevant nodes): =09 1) H-I containing: - the freephone number (tagged); - the AoR (tagged); - the contact URI (not tagged). =09 Or =09 2) H-I containing: - the freephone number (tagged); - the contact URI (not tagged). =09 The latter would occur when the same proxy translates the freephone number (via the AoR) to the contact directly. =09 So how does this help the UAS to figure out the freephone number? It seems the UAS would have to search back through the tagged entries looking for one that matches a freephone number it recognises? Does the tagging really add much value? =09 John =09 =09 ________________________________ =09 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 12 March 2009 21:26 To: Mary Barnes Cc: Hans Erik van Elburg; sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 Inline... =09 /Hans Erik van Elburg =09 =09 =09 On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes wrote: =09 =09 I think there is another solution proposal that we should pursue for issue 3 identified in the email summary sent by Shida earlier this week - I've snipped all the text except for that issue and issue 2 in the summary below. I do think the discussion has confounded the two issues and I think it ought to be clarified that if we agree to the two tags per issue 3, that the options for the terminology MUST change. And, perhaps this is why the other discussion threads aren't progressing well. =09 =09 Agree. =09 =09 =09 So, Hans Erick, I would like clarification on as to your view on the solution: =09 In general, ISTM that one of the issues we're having in this terminology thread is that you are considering the solution to be that the hi-entries are tagged as they are added to the request. And, just for clarification from my perspective, that is NOT the solution in either 4244bis or target-uri. =09 =09 The principle should be that the node that has the information about what type of rewrite is performed should add the tag. (This is done by the current target-uri draft allthough the solution is not complete.) =09 For the freephone service, that would be the freephone service. For the AOR that is the home proxy. =09 Assume that the freephone service receives an INVITE request that either 1. received request contains History-Info header that contains the freephone number (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI. (I think that was how History-Info works right.) 2. received request contains History-Info header that does not contain the freephone number as last entry, THEN when rewriting the Request-URI it has add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI. 3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the freephone number and tag that entry AND add the new entry with the new value of the Request-URI. =09 After forwarding this request it arrives at the home proxy: 1. received request contains History-Info header that contains the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has to tag that existing received entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. (I think that was how History-Info works right.) 2. received request contains History-Info header that does not contain the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI it has add an entry with the AOR and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact. 3. received request does not contain a History-Info header, THEN when rewriting the Request-URI it has to add an entry with the AOR as in the Request-URI and tag that entry AND add the new entry with the new value of the Request-URI i.e. the registered contact.. =09 =09 I don't view it as a problem necessarily if you'd like to pursue an alternate solution, we just need to be clear that's what you're advocating. In that case, I would agree the "retarget" is not an appropriate tag for the entries, as you don't know at the point in time that you add an hi-entry that it will be retargeted. In the case of this approach to the solution, you do have to alter the mechanism for determining the hi-entry that your services would want to use. You would need to skip the most recent/last hi-entry (as that would contain the same as the Request-URI in the incoming request), since it would be tagged if you use this solution approach. =09 =09 Yes, but only if the previous proxy added it. As History-Info is optional one never knows really. =09 =09 =09 Thus, you'd have to take the next hi-entry that you find that has the desired "tag". I will posit that we could accomplish this solution without any changes to 4244 by just registering new SIP URI parameter(s). And, that's not to say we shouldn't do a 4244bis as there are other issues to address in that document, but that allows the target-uri to describe a solution that makes use of 4244bis "as is". =09 =09 =09 Are you proposing to decouple the target-uri and the 4244bis discussion? =09 =09 So, feedback on this specific point (from Hans Erik and others) would be appreciated. =09 =09 =09 Mary. =09 =09 =09 =09 =09 From ietf.hanserik@gmail.com Fri Mar 13 07:51:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9D83A680E for ; Fri, 13 Mar 2009 07:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai6Oiy7eiwcg for ; Fri, 13 Mar 2009 07:51:22 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 0AC2F3A69AA for ; Fri, 13 Mar 2009 07:51:21 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 25so637813eya.31 for ; Fri, 13 Mar 2009 07:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cc2Ft9dJNnDMuy9kpDSsd1logwB1kkg9JenDsynwy/M=; b=IlSJwvCghXG+Jnv6ucPYUxFdq51WGXEyAxeUBo3jgjcx+vHjlzdNg7B3n55p9aJTi9 gM56W6xtXUnzSyZshBboBm/C4KmhsUxKaZcwdTk6mOQ7p8mvmL3k4PdskZnugTqHiyZT 51lW0BA8lBf1j+ZVcuXqEnyswMC3CaEZd5wKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cnej23430z03bOCEvV2cPFOhSrkNbUhNqnqP52aGXCF0gxAXHNXe7wegvp1A0BP6uv tWgjnQyBYXdxAacqDNHuu/1TxMZiXYq2NWkBqkie/RGl6ISGeXCbNK7kiR/TXkXSLhjY cjoAYloJEGouOVxI5iXA+pC72RjQkX6Z04z1c= MIME-Version: 1.0 Received: by 10.210.89.4 with SMTP id m4mr986584ebb.65.1236955919727; Fri, 13 Mar 2009 07:51:59 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 13 Mar 2009 15:51:59 +0100 Message-ID: <9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174bde8432cd740465013eae Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:51:28 -0000 --0015174bde8432cd740465013eae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It knows when it rewrites the Request-URI due to a location lookup --> tag "aor". It knows (is configured to) when it rewrites the Request-URI with a value that leads the request to target with a different identity then the one that has been replaced --> tag new entry "istarget". It knows when it rewrites the Request-URI with a value and this leads to the first History-Info entry being recorded --> tag "istarget". /Hans Erik van Elburg On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John wrote: > Hans Erik, > > But how does a proxy know what to use? How does it know whether the > received Request-URI, which it uses to query the LS, is a target or an > AoR? Does it need to scan back up the H-I chain to see whether there is > already an 'istarget' present, and if so use 'aor' instead of > 'istarget'? > > John > > > ________________________________ > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: 13 March 2009 14:33 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > Hi John, > > Well that is simple one would use different tags for different > type of entries, like in the example I already gave: > > H-I: Bfreephone; "istarget",\ > B,"aor"\ > contact-B > > Where the UAS interested in the initial target with which it was > addressed it would obtain the "istarget" tagged entry. > Where the UAS interested in the AOR that was used to address it > would obtain the "aor" tagged entry. > > In simpler cases it could be that one entry holds the "aor" as > well as the "istarget" tag. > > Of course the algorithm needs some work to make it complete. > > /Hans Erik van Elburg > > > > On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John > wrote: > > > Hans Erik, > > Following your detailed description, it seems that the > UAS serving a > freephone number could receive one of the following > (assuming H-I is > supported by all relevant nodes): > > 1) H-I containing: > - the freephone number (tagged); > - the AoR (tagged); > - the contact URI (not tagged). > > Or > > 2) H-I containing: > - the freephone number (tagged); > - the contact URI (not tagged). > > The latter would occur when the same proxy translates > the freephone > number (via the AoR) to the contact directly. > > So how does this help the UAS to figure out the > freephone number? It > seems the UAS would have to search back through the > tagged entries > looking for one that matches a freephone number it > recognises? Does the > tagging really add much value? > > John > > > ________________________________ > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: 12 March 2009 21:26 > To: Mary Barnes > Cc: Hans Erik van Elburg; sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > Inline... > > /Hans Erik van Elburg > > > > On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes > wrote: > > > I think there is another solution > proposal that we > should pursue for issue 3 identified in the email > summary sent by Shida > earlier this week - I've snipped all the text except for > that issue and > issue 2 in the summary below. I do think the discussion > has confounded > the two issues and I think it ought to be clarified that > if we agree to > the two tags per issue 3, that the options for the > terminology MUST > change. And, perhaps this is why the other discussion > threads aren't > progressing well. > > > Agree. > > > > So, Hans Erick, I would like > clarification on as to your > view on the solution: > > In general, ISTM that one of the issues > we're having in > this terminology thread is that you are considering the > solution to be > that the hi-entries are tagged as they > are added to the request. And, just for > clarification > from my perspective, that is NOT the solution in either > 4244bis or > target-uri. > > > The principle should be that the node that has > the information > about what type of rewrite is performed should add the > tag. (This is > done by the current target-uri draft allthough the > solution is not > complete.) > > For the freephone service, that would be the > freephone service. > For the AOR that is the home proxy. > > Assume that the freephone service receives an > INVITE request > that either > 1. received request contains History-Info header > that contains > the freephone number (as in R-URI) as last entry, THEN > when rewriting > the Request-URI it has to tag that existing received > entry AND add the > new entry with the new value of the Request-URI. (I > think that was how > History-Info works right.) > 2. received request contains History-Info header > that does not > contain the freephone number as last entry, THEN when > rewriting the > Request-URI it has add an entry with the freephone > number and tag that > entry AND add the new entry with the new value of the > Request-URI. > 3. received request does not contain a > History-Info header, THEN > when rewriting the Request-URI it has to add an entry > with the freephone > number and tag that entry AND add the new entry with the > new value of > the Request-URI. > > After forwarding this request it arrives at the > home proxy: > 1. received request contains History-Info header > that contains > the AOR (as in R-URI) as last entry, THEN when rewriting > the Request-URI > it has to tag that existing received entry AND add the > new entry with > the new value of the Request-URI i.e. the registered > contact. (I think > that was how History-Info works right.) > 2. received request contains History-Info header > that does not > contain the AOR (as in R-URI) as last entry, THEN when > rewriting the > Request-URI it has add an entry with the AOR and tag > that entry AND add > the new entry with the new value of the Request-URI i.e. > the registered > contact. > 3. received request does not contain a > History-Info header, THEN > when rewriting the Request-URI it has to add an entry > with the AOR as in > the Request-URI and tag that entry AND add the new entry > with the new > value of the Request-URI i.e. the registered contact.. > > > I don't view it as a problem necessarily > if you'd like > to pursue an alternate solution, we just need to be > clear that's what > you're advocating. In that case, I would agree the > "retarget" is not an > appropriate tag for the entries, as you don't know at > the point in time > that you add an hi-entry that it will be retargeted. In > the case of this > approach to the solution, you do have to alter the > mechanism for > determining the hi-entry that your services would want > to use. You would > need to skip the most recent/last hi-entry (as that > would contain the > same as the Request-URI in the incoming request), since > it would be > tagged if you use this solution approach. > > > Yes, but only if the previous proxy added it. As > History-Info is > optional one never knows really. > > > > Thus, you'd have to take the next > hi-entry that you find > that has the desired "tag". I will posit that we could > accomplish this > solution without any changes to 4244 by just registering > new SIP URI > parameter(s). And, that's not to say we shouldn't do > a 4244bis as > there are other issues to address in that document, but > that allows the > target-uri to describe a solution that makes use of > 4244bis "as is". > > > > Are you proposing to decouple the target-uri and > the 4244bis > discussion? > > > So, feedback on this specific point (from > Hans Erik and > others) would be appreciated. > > > > Mary. > > > > > > > > --0015174bde8432cd740465013eae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It knows when it rewrites the Request-URI due to a location lookup --> t= ag "aor".
It knows (is configured to) when it rewrites the Req= uest-URI with a value that leads the request to target with a different ide= ntity then the one that has been replaced --> tag new entry "istarg= et".
It knows when it rewrites the Request-URI with a value and this leads to th= e first History-Info entry being recorded --> tag "istarget".<= br>
/Hans Erik van Elburg


On Fri, Mar 13, 2009 at 3:39 PM, Elwell,= John <john= .elwell@siemens.com> wrote:
=A0Hans Erik,

But how does a proxy know what to use? How does it know whether the
received Request-URI, which it uses to query the LS, is a target or an
AoR? Does it need to scan back up the H-I chain to see whether there is
already an 'istarget' present, and if so use 'aor' instead = of
'istarget'?

John


________________________________

=A0 =A0 =A0 =A0From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
=A0 =A0 =A0 =A0Sent: 13 March 2009 14:33
=A0 =A0 =A0 =A0To: Elwell, John
=A0 =A0 =A0 =A0Cc: sip@ietf.org
=A0 =A0 =A0 =A0Subject: Re: [Sip] Issue = 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


=A0 =A0 =A0 =A0Hi John,

=A0 =A0 =A0 =A0Well that is simple one would use different tags for differ= ent
type of entries, like in the example I already gave:

=A0 =A0 =A0 =A0 =A0 H-I: =A0Bfreephone; "istarget",\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B,"aor"\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact-B

=A0 =A0 =A0 =A0Where the UAS interested in the initial target with which i= t was
addressed it would obtain the "istarget" tagged entry.
=A0 =A0 =A0 =A0Where the UAS interested in the AOR =A0that was used to add= ress it
would obtain the "aor" tagged entry.

=A0 =A0 =A0 =A0In simpler cases it could be that one entry holds the "= ;aor" as
well as the "istarget" tag.

=A0 =A0 =A0 =A0Of course the algorithm needs some work to make it complete= .

=A0 =A0 =A0 =A0/Hans Erik van Elburg



=A0 =A0 =A0 =A0On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John
<john.elwell@siemens.com&= gt; wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hans Erik,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Following your detailed description, it see= ms that the
UAS serving a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0freephone number could receive one of the f= ollowing
(assuming H-I is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0supported by all relevant nodes):

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01) H-I containing:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the freephone number (tagged);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the AoR (tagged);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the contact URI (not tagged).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Or

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02) H-I containing:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the freephone number (tagged);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the contact URI (not tagged).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The latter would occur when the same proxy = translates
the freephone
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0number (via the AoR) to the contact directl= y.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So how does this help the UAS to figure out= the
freephone number? It
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0seems the UAS would have to search back thr= ough the
tagged entries
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0looking for one that matches a freephone nu= mber it
recognises? Does the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tagging really add much value?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0________________________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: sip-bounces@ietf.org
[mailto:sip-bounces@ietf.org] O= n
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Behalf Of Hans Erik van Elburg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: 12 March 2009 21:26
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cc: Hans Erik van Elburg; sip@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: Re: [Sip] Issue 3 - t= wo tags (was RE:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I-DACTION:draft-rosenberg-sip-target-uri-de= livery-01.txt



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Inline...

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /Hans Erik van Elburg



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Thu, Mar 12, 2009 at 7:10 P= M, Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mary.barnes@nortel.com> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I think there = is another solution
proposal that we
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should pursue for issue 3 identified in the= email
summary sent by Shida
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0earlier this week - I've snipped all th= e text except for
that issue and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0issue 2 in the summary below. =A0I do think= the discussion
has confounded
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the two issues and I think it ought to be c= larified that
if we agree to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the two tags per issue 3, that the options = for the
terminology MUST
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change. And, perhaps this is why the other = discussion
threads aren't
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0progressing well.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Agree.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 So, Hans Erick= , I would like
clarification on as to your
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0view on the solution:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 In general, IS= TM that one of the issues
we're having in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this terminology thread is that you are con= sidering the
solution to be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that the hi-entries are tagged as they
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 are added to t= he request. =A0And, just for
clarification
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0from my perspective, that is NOT the soluti= on in either
4244bis or
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target-uri.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The principle should be that t= he node that has
the information
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0about what type of rewrite is performed sho= uld add the
tag. (This is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0done by the current target-uri draft alltho= ugh the
solution is not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0complete.)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 For the freephone service, tha= t would be the
freephone service.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0For the AOR that is the home proxy.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Assume that the freephone serv= ice receives an
INVITE =A0request
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that either
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1. received request contains H= istory-Info header
that contains
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the freephone number (as in R-URI) as last = entry, THEN
when rewriting
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI it has to tag that existing= received
entry AND add the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0new entry with the new value of the Request= -URI. (I
think that was how
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0History-Info works right.)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2. received request contains H= istory-Info header
that does not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contain the freephone number as last entry,= THEN when
rewriting the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request-URI it has add an entry with the fr= eephone
number and tag that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0entry AND add the new entry with the new va= lue of the
Request-URI.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3. received request does not c= ontain a
History-Info header, THEN
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when rewriting the Request-URI it has to ad= d an entry
with the freephone
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0number and tag that entry AND add the new e= ntry with the
new value of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 After forwarding this request = it arrives at the
home proxy:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1. received request contains H= istory-Info header
that contains
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the AOR (as in R-URI) as last entry, THEN w= hen rewriting
the Request-URI
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it has to tag that existing received entry = AND add the
new entry with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the new value of the Request-URI i.e. the r= egistered
contact. (I think
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that was how History-Info works right.)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2. received request contains H= istory-Info header
that does not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contain the AOR (as in R-URI) as last entry= , THEN when
rewriting the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request-URI it has add an entry with the AO= R and tag
that entry AND add
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the new entry with the new value of the Req= uest-URI i.e.
the registered
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3. received request does not c= ontain a
History-Info header, THEN
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when rewriting the Request-URI it has to ad= d an entry
with the AOR as in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI and tag that entry AND add = the new entry
with the new
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value of the Request-URI i.e. the registere= d contact..


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I don't vi= ew it as a problem necessarily
if you'd like
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to pursue an alternate solution, we just ne= ed to be
clear that's what
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0you're advocating. In that case, I woul= d agree the
"retarget" is not an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0appropriate tag for the entries, as you don= 't know at
the point in time
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that you add an hi-entry that it will be re= targeted. In
the case of this
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0approach to the solution, you do have to al= ter the
mechanism for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0determining the hi-entry that your services= would want
to use. You would
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0need to skip the most recent/last hi-entry = (as that
would contain the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0same as the Request-URI in the incoming req= uest), since
it would be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tagged if you use this solution approach.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yes, but only if the previous = proxy added it. As
History-Info is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0optional one never knows really.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thus, you'= d have to take the next
hi-entry that you find
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that has the desired "tag". =A0I = will posit that we could
accomplish this
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0solution without any changes to 4244 by jus= t registering
new SIP URI
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parameter(s). =A0 And, =A0that's not to= say we shouldn't do
a 4244bis as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0there are other issues to address in that d= ocument, but
that allows the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target-uri to describe a solution that make= s use of
4244bis "as is".



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Are you proposing to decouple = the target-uri and
the 4244bis
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0discussion?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 So, feedback o= n this specific point (from
Hans Erik and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0others) would be appreciated.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mary.








--0015174bde8432cd740465013eae-- From john.elwell@siemens.com Fri Mar 13 09:34:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFE33A6954 for ; Fri, 13 Mar 2009 09:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL2yxLndaByU for ; Fri, 13 Mar 2009 09:34:07 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 53AD43A68F5 for ; Fri, 13 Mar 2009 09:34:07 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGG008CKDW6YH@siemenscomms.co.uk> for sip@ietf.org; Fri, 13 Mar 2009 16:31:19 +0000 (GMT) Date: Fri, 13 Mar 2009 16:31:14 +0000 From: "Elwell, John" In-reply-to: <9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> To: Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: Acmj60R6rW+3hNjERSWW1c0T71DU/AADPnIA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:34:09 -0000 =20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 13 March 2009 14:52 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE:=20 > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >=20 > It knows when it rewrites the Request-URI due to a location=20 > lookup --> tag "aor". > It knows (is configured to) when it rewrites the Request-URI=20 > with a value that leads the request to target with a=20 > different identity then the one that has been replaced -->=20 > tag new entry "istarget". > It knows when it rewrites the Request-URI with a value and=20 > this leads to the first History-Info entry being recorded -->=20 > tag "istarget". [JRE] It does not know that this is the first target, because upstream nodes may have retargeted without inserting H-I. In any case, the To header field URI is the first target, so we don't need that anyway. I can accept that a proxy might know, having done a LS look-up, whether the new URI is a registered contact or some other URI, and on that basis it could choose whether or not to insert a single tag. I thought that was the basis on which we agreed to go ahead with this updated to RFC 4424, rather than following the loose route draft. It is not clear to me that a proxy would have enough information to make a 3-way choice. John >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John=20 > wrote: >=20 >=20 > Hans Erik, > =09 > But how does a proxy know what to use? How does it know=20 > whether the > received Request-URI, which it uses to query the LS, is=20 > a target or an > AoR? Does it need to scan back up the H-I chain to see=20 > whether there is > already an 'istarget' present, and if so use 'aor' instead of > 'istarget'? > =09 > John > =09 >=20 >=20 > ________________________________ > =09 > From: Hans Erik van Elburg=20 > [mailto:ietf.hanserik@gmail.com] > =09 > Sent: 13 March 2009 14:33 > To: Elwell, John > Cc: sip@ietf.org > =09 > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > =09 > =09 > Hi John, > =09 > Well that is simple one would use different tags=20 > for different > type of entries, like in the example I already gave: > =09 > H-I: Bfreephone; "istarget",\ > B,"aor"\ > contact-B > =09 > Where the UAS interested in the initial target=20 > with which it was > addressed it would obtain the "istarget" tagged entry. > Where the UAS interested in the AOR that was=20 > used to address it > would obtain the "aor" tagged entry. > =09 > In simpler cases it could be that one entry=20 > holds the "aor" as > well as the "istarget" tag. > =09 > Of course the algorithm needs some work to make=20 > it complete. > =09 > /Hans Erik van Elburg > =09 > =09 > =09 > On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John > wrote: > =09 > =09 > Hans Erik, > =09 > Following your detailed description, it=20 > seems that the > UAS serving a > freephone number could receive one of=20 > the following > (assuming H-I is > supported by all relevant nodes): > =09 > 1) H-I containing: > - the freephone number (tagged); > - the AoR (tagged); > - the contact URI (not tagged). > =09 > Or > =09 > 2) H-I containing: > - the freephone number (tagged); > - the contact URI (not tagged). > =09 > The latter would occur when the same=20 > proxy translates > the freephone > number (via the AoR) to the contact directly. > =09 > So how does this help the UAS to figure out the > freephone number? It > seems the UAS would have to search back=20 > through the > tagged entries > looking for one that matches a freephone=20 > number it > recognises? Does the > tagging really add much value? > =09 > John > =09 > =09 > ________________________________ > =09 > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: 12 March 2009 21:26 > To: Mary Barnes > Cc: Hans Erik van Elburg; sip@ietf.org > Subject: Re: [Sip] Issue 3 - two=20 > tags (was RE: > =20 > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > =09 > =09 > =09 > Inline... > =09 > /Hans Erik van Elburg > =09 > =09 > =09 > On Thu, Mar 12, 2009 at 7:10 PM,=20 > Mary Barnes > wrote: > =09 > =09 > I think there is another solution > proposal that we > should pursue for issue 3 identified in the email > summary sent by Shida > earlier this week - I've snipped all the=20 > text except for > that issue and > issue 2 in the summary below. I do=20 > think the discussion > has confounded > the two issues and I think it ought to=20 > be clarified that > if we agree to > the two tags per issue 3, that the=20 > options for the > terminology MUST > change. And, perhaps this is why the=20 > other discussion > threads aren't > progressing well. > =09 > =09 > Agree. > =09 > =09 > =09 > So, Hans Erick, I would like > clarification on as to your > view on the solution: > =09 > In general, ISTM that one=20 > of the issues > we're having in > this terminology thread is that you are=20 > considering the > solution to be > that the hi-entries are tagged as they > are added to the request.=20 > And, just for > clarification > from my perspective, that is NOT the=20 > solution in either > 4244bis or > target-uri. > =09 > =09 > The principle should be that the=20 > node that has > the information > about what type of rewrite is performed=20 > should add the > tag. (This is > done by the current target-uri draft=20 > allthough the > solution is not > complete.) > =09 > For the freephone service, that=20 > would be the > freephone service. > For the AOR that is the home proxy. > =09 > Assume that the freephone service=20 > receives an > INVITE request > that either > 1. received request contains=20 > History-Info header > that contains > the freephone number (as in R-URI) as=20 > last entry, THEN > when rewriting > the Request-URI it has to tag that=20 > existing received > entry AND add the > new entry with the new value of the=20 > Request-URI. (I > think that was how > History-Info works right.) > 2. received request contains=20 > History-Info header > that does not > contain the freephone number as last=20 > entry, THEN when > rewriting the > Request-URI it has add an entry with the=20 > freephone > number and tag that > entry AND add the new entry with the new=20 > value of the > Request-URI. > 3. received request does not contain a > History-Info header, THEN > when rewriting the Request-URI it has to=20 > add an entry > with the freephone > number and tag that entry AND add the=20 > new entry with the > new value of > the Request-URI. > =09 > After forwarding this request it=20 > arrives at the > home proxy: > 1. received request contains=20 > History-Info header > that contains > the AOR (as in R-URI) as last entry,=20 > THEN when rewriting > the Request-URI > it has to tag that existing received=20 > entry AND add the > new entry with > the new value of the Request-URI i.e.=20 > the registered > contact. (I think > that was how History-Info works right.) > 2. received request contains=20 > History-Info header > that does not > contain the AOR (as in R-URI) as last=20 > entry, THEN when > rewriting the > Request-URI it has add an entry with the=20 > AOR and tag > that entry AND add > the new entry with the new value of the=20 > Request-URI i.e. > the registered > contact. > 3. received request does not contain a > History-Info header, THEN > when rewriting the Request-URI it has to=20 > add an entry > with the AOR as in > the Request-URI and tag that entry AND=20 > add the new entry > with the new > value of the Request-URI i.e. the=20 > registered contact.. > =09 > =09 > I don't view it as a=20 > problem necessarily > if you'd like > to pursue an alternate solution, we just=20 > need to be > clear that's what > you're advocating. In that case, I would=20 > agree the > "retarget" is not an > appropriate tag for the entries, as you=20 > don't know at > the point in time > that you add an hi-entry that it will be=20 > retargeted. In > the case of this > approach to the solution, you do have to=20 > alter the > mechanism for > determining the hi-entry that your=20 > services would want > to use. You would > need to skip the most recent/last=20 > hi-entry (as that > would contain the > same as the Request-URI in the incoming=20 > request), since > it would be > tagged if you use this solution approach. > =09 > =09 > Yes, but only if the previous=20 > proxy added it. As > History-Info is > optional one never knows really. > =09 > =09 > =09 > Thus, you'd have to take the next > hi-entry that you find > that has the desired "tag". I will=20 > posit that we could > accomplish this > solution without any changes to 4244 by=20 > just registering > new SIP URI > parameter(s). And, that's not to say=20 > we shouldn't do > a 4244bis as > there are other issues to address in=20 > that document, but > that allows the > target-uri to describe a solution that=20 > makes use of > 4244bis "as is". > =09 > =09 > =09 > Are you proposing to decouple the=20 > target-uri and > the 4244bis > discussion? > =09 > =09 > So, feedback on this=20 > specific point (from > Hans Erik and > others) would be appreciated. > =09 > =09 > =09 > Mary. > =09 > =09 > =09 > =09 > =09 > =09 > =09 > =09 >=20 >=20 >=20 From ietf.hanserik@gmail.com Fri Mar 13 09:58:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0005E28C20E for ; Fri, 13 Mar 2009 09:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLb+G0l+XqNc for ; Fri, 13 Mar 2009 09:58:35 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 4143128C113 for ; Fri, 13 Mar 2009 09:58:34 -0700 (PDT) Received: by ewy25 with SMTP id 25so2633076ewy.37 for ; Fri, 13 Mar 2009 09:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1oMaw82eAzvzktdLQTmuzLjd931EzWlzJkfw20+ZTxk=; b=eBBRZ6NT8VIwjHsozsB0KPckx/uOAXtADMMm5y0prhhXNf1ZfRgXCcRwAkNsKfXTfe vq8EAr1ry8zQ7JTc9lMdd0loKQRX5pzS7NlCkvK7JKVZm3jRrmsmGtryl+rYEILQ6AZ1 +2Mqc8VRnRVsVqRfDaEUdIGjC89e1wpVCv/rk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZqDcdbZ4rx9svGkir4DJhupWLFlSZt2ho7KCUOjVWxXnNROoprKDaq9kYekl1PkO7V Puz6Y8bfWdZTjl4iISIT+KVv44yqPP/36zIVRSpygh0lsb3Y+fbV87wGYx+aEM1D3LlX yeVFpGUvT+DXhY69czDWKI1+crCWSo2j/q3Mw= MIME-Version: 1.0 Received: by 10.210.66.1 with SMTP id o1mr937318eba.16.1236963552331; Fri, 13 Mar 2009 09:59:12 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 13 Mar 2009 17:59:12 +0100 Message-ID: <9ae56b1e0903130959h5a142c55v335600dc93041fe6@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174c3f902308e9046503053b Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:58:37 -0000 --0015174c3f902308e9046503053b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 3-way choice? A proxy that has retargeting logic knows when it is doing so. A proxy that has rerouting logic to registered contact knows when it is doing so. No 3-way magic there. And yes the History-Info is optional so you never know if all nodes in the chain do there bit. But that is fact of life. As long as you can ensure that in your domain it is supported you will receive correct information. /Hans Erik van Elburg On Fri, Mar 13, 2009 at 5:31 PM, Elwell, John wrote: > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 13 March 2009 14:52 > > To: Elwell, John > > Cc: sip@ietf.org > > Subject: Re: [Sip] Issue 3 - two tags (was RE: > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > It knows when it rewrites the Request-URI due to a location > > lookup --> tag "aor". > > It knows (is configured to) when it rewrites the Request-URI > > with a value that leads the request to target with a > > different identity then the one that has been replaced --> > > tag new entry "istarget". > > It knows when it rewrites the Request-URI with a value and > > this leads to the first History-Info entry being recorded --> > > tag "istarget". > [JRE] It does not know that this is the first target, because upstream > nodes may have retargeted without inserting H-I. In any case, the To > header field URI is the first target, so we don't need that anyway. > > I can accept that a proxy might know, having done a LS look-up, whether > the new URI is a registered contact or some other URI, and on that basis > it could choose whether or not to insert a single tag. I thought that > was the basis on which we agreed to go ahead with this updated to RFC > 4424, rather than following the loose route draft. It is not clear to me > that a proxy would have enough information to make a 3-way choice. > > John > > > > > > /Hans Erik van Elburg > > > > > > > > On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John > > wrote: > > > > > > Hans Erik, > > > > But how does a proxy know what to use? How does it know > > whether the > > received Request-URI, which it uses to query the LS, is > > a target or an > > AoR? Does it need to scan back up the H-I chain to see > > whether there is > > already an 'istarget' present, and if so use 'aor' instead of > > 'istarget'? > > > > John > > > > > > > > ________________________________ > > > > From: Hans Erik van Elburg > > [mailto:ietf.hanserik@gmail.com] > > > > Sent: 13 March 2009 14:33 > > To: Elwell, John > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] Issue 3 - two tags (was RE: > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > Hi John, > > > > Well that is simple one would use different tags > > for different > > type of entries, like in the example I already gave: > > > > H-I: Bfreephone; "istarget",\ > > B,"aor"\ > > contact-B > > > > Where the UAS interested in the initial target > > with which it was > > addressed it would obtain the "istarget" tagged entry. > > Where the UAS interested in the AOR that was > > used to address it > > would obtain the "aor" tagged entry. > > > > In simpler cases it could be that one entry > > holds the "aor" as > > well as the "istarget" tag. > > > > Of course the algorithm needs some work to make > > it complete. > > > > /Hans Erik van Elburg > > > > > > > > On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John > > wrote: > > > > > > Hans Erik, > > > > Following your detailed description, it > > seems that the > > UAS serving a > > freephone number could receive one of > > the following > > (assuming H-I is > > supported by all relevant nodes): > > > > 1) H-I containing: > > - the freephone number (tagged); > > - the AoR (tagged); > > - the contact URI (not tagged). > > > > Or > > > > 2) H-I containing: > > - the freephone number (tagged); > > - the contact URI (not tagged). > > > > The latter would occur when the same > > proxy translates > > the freephone > > number (via the AoR) to the contact directly. > > > > So how does this help the UAS to figure out the > > freephone number? It > > seems the UAS would have to search back > > through the > > tagged entries > > looking for one that matches a freephone > > number it > > recognises? Does the > > tagging really add much value? > > > > John > > > > > > ________________________________ > > > > From: sip-bounces@ietf.org > > [mailto:sip-bounces@ietf.org] On > > Behalf Of Hans Erik van Elburg > > Sent: 12 March 2009 21:26 > > To: Mary Barnes > > Cc: Hans Erik van Elburg; sip@ietf.org > > Subject: Re: [Sip] Issue 3 - two > > tags (was RE: > > > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > > > Inline... > > > > /Hans Erik van Elburg > > > > > > > > On Thu, Mar 12, 2009 at 7:10 PM, > > Mary Barnes > > wrote: > > > > > > I think there is another solution > > proposal that we > > should pursue for issue 3 identified in the email > > summary sent by Shida > > earlier this week - I've snipped all the > > text except for > > that issue and > > issue 2 in the summary below. I do > > think the discussion > > has confounded > > the two issues and I think it ought to > > be clarified that > > if we agree to > > the two tags per issue 3, that the > > options for the > > terminology MUST > > change. And, perhaps this is why the > > other discussion > > threads aren't > > progressing well. > > > > > > Agree. > > > > > > > > So, Hans Erick, I would like > > clarification on as to your > > view on the solution: > > > > In general, ISTM that one > > of the issues > > we're having in > > this terminology thread is that you are > > considering the > > solution to be > > that the hi-entries are tagged as they > > are added to the request. > > And, just for > > clarification > > from my perspective, that is NOT the > > solution in either > > 4244bis or > > target-uri. > > > > > > The principle should be that the > > node that has > > the information > > about what type of rewrite is performed > > should add the > > tag. (This is > > done by the current target-uri draft > > allthough the > > solution is not > > complete.) > > > > For the freephone service, that > > would be the > > freephone service. > > For the AOR that is the home proxy. > > > > Assume that the freephone service > > receives an > > INVITE request > > that either > > 1. received request contains > > History-Info header > > that contains > > the freephone number (as in R-URI) as > > last entry, THEN > > when rewriting > > the Request-URI it has to tag that > > existing received > > entry AND add the > > new entry with the new value of the > > Request-URI. (I > > think that was how > > History-Info works right.) > > 2. received request contains > > History-Info header > > that does not > > contain the freephone number as last > > entry, THEN when > > rewriting the > > Request-URI it has add an entry with the > > freephone > > number and tag that > > entry AND add the new entry with the new > > value of the > > Request-URI. > > 3. received request does not contain a > > History-Info header, THEN > > when rewriting the Request-URI it has to > > add an entry > > with the freephone > > number and tag that entry AND add the > > new entry with the > > new value of > > the Request-URI. > > > > After forwarding this request it > > arrives at the > > home proxy: > > 1. received request contains > > History-Info header > > that contains > > the AOR (as in R-URI) as last entry, > > THEN when rewriting > > the Request-URI > > it has to tag that existing received > > entry AND add the > > new entry with > > the new value of the Request-URI i.e. > > the registered > > contact. (I think > > that was how History-Info works right.) > > 2. received request contains > > History-Info header > > that does not > > contain the AOR (as in R-URI) as last > > entry, THEN when > > rewriting the > > Request-URI it has add an entry with the > > AOR and tag > > that entry AND add > > the new entry with the new value of the > > Request-URI i.e. > > the registered > > contact. > > 3. received request does not contain a > > History-Info header, THEN > > when rewriting the Request-URI it has to > > add an entry > > with the AOR as in > > the Request-URI and tag that entry AND > > add the new entry > > with the new > > value of the Request-URI i.e. the > > registered contact.. > > > > > > I don't view it as a > > problem necessarily > > if you'd like > > to pursue an alternate solution, we just > > need to be > > clear that's what > > you're advocating. In that case, I would > > agree the > > "retarget" is not an > > appropriate tag for the entries, as you > > don't know at > > the point in time > > that you add an hi-entry that it will be > > retargeted. In > > the case of this > > approach to the solution, you do have to > > alter the > > mechanism for > > determining the hi-entry that your > > services would want > > to use. You would > > need to skip the most recent/last > > hi-entry (as that > > would contain the > > same as the Request-URI in the incoming > > request), since > > it would be > > tagged if you use this solution approach. > > > > > > Yes, but only if the previous > > proxy added it. As > > History-Info is > > optional one never knows really. > > > > > > > > Thus, you'd have to take the next > > hi-entry that you find > > that has the desired "tag". I will > > posit that we could > > accomplish this > > solution without any changes to 4244 by > > just registering > > new SIP URI > > parameter(s). And, that's not to say > > we shouldn't do > > a 4244bis as > > there are other issues to address in > > that document, but > > that allows the > > target-uri to describe a solution that > > makes use of > > 4244bis "as is". > > > > > > > > Are you proposing to decouple the > > target-uri and > > the 4244bis > > discussion? > > > > > > So, feedback on this > > specific point (from > > Hans Erik and > > others) would be appreciated. > > > > > > > > Mary. > > > > > > > > > > > > > > > > > > > > > > > --0015174c3f902308e9046503053b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 3-way choice?

A proxy that has retargeting logic knows when it is do= ing so.
A proxy that has rerouting logic to registered contact knows whe= n it is doing so.

No 3-way magic there.

And yes the History-I= nfo is optional so you never know if all nodes in the chain do there bit. B= ut that is fact of life. As long as you can ensure that in your domain it i= s supported you will receive=A0 correct information.

/Hans Erik van Elburg


On Fri, Mar 13, 2009 at 5:31 PM, Elwell,= John <john= .elwell@siemens.com> wrote:


> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: 13 March 2009 14:52
> To: Elwell, John
> Cc: sip@ietf.org
> Subject: Re: [Sip] Issue 3 - two tags (was RE:
> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
> It knows when it rewrites the Request-URI due = to a location
> lookup --> tag "aor".
> It knows (is configured to) when it rewrites the Request-URI
> with a value that leads the request to target with a
> different identity then the one that has been replaced -->
> tag new entry "istarget".
> It knows when it rewrites the Request-URI with a value and
> this leads to the first History-Info entry being recorded -->
> tag "istarget".
[JRE] It does not know that this is the first target, because upstrea= m
nodes may have retargeted without inserting H-I. In any case, the To
header field URI is the first target, so we don't need that anyway.

I can accept that a proxy might know, having done a LS look-up, whether
the new URI is a registered contact or some other URI, and on that basis it could choose whether or not to insert a single tag. I thought that
was the basis on which we agreed to go ahead with this updated to RFC
4424, rather than following the loose route draft. It is not clear to me that a proxy would have enough information to make a 3-way choice.

John


>
> /Hans Erik van Elburg
>
>
>
> On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John
> <john.elwell@siemens.com= > wrote:
>
>
> =A0 =A0 =A0 =A0Hans Erik,
>
> =A0 =A0 =A0 But how does a proxy know what to use? How does it know > whether the
> =A0 =A0 =A0 received Request-URI, which it uses to query the LS, is > a target or an
> =A0 =A0 =A0 AoR? Does it need to scan back up the H-I chain to see
> whether there is
> =A0 =A0 =A0 already an 'istarget' present, and if so use '= aor' instead of
> =A0 =A0 =A0 'istarget'?
>
> =A0 =A0 =A0 John
>
>
>
> =A0 =A0 =A0 ________________________________
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0From: Hans Erik van Elburg
> [mailto:ietf.hanserik@gmail= .com]
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Sent: 13 March 2009 14:33
> =A0 =A0 =A0 =A0 =A0 =A0 =A0To: Elwell, John
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Cc: sip@iet= f.org
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject: Re: [Sip] Issue 3 - two tags (was = RE:
> =A0 =A0 =A0 I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi John,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Well that is simple one would use different= tags
> for different
> =A0 =A0 =A0 type of entries, like in the example I already gave:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 H-I: =A0Bfreephone; "istarget&quo= t;,\
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B,"aor"\
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact-B
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Where the UAS interested in the initial tar= get
> with which it was
> =A0 =A0 =A0 addressed it would obtain the "istarget" tagged = entry.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Where the UAS interested in the AOR =A0that= was
> used to address it
> =A0 =A0 =A0 would obtain the "aor" tagged entry.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0In simpler cases it could be that one entry=
> holds the "aor" as
> =A0 =A0 =A0 well as the "istarget" tag.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Of course the algorithm needs some work to = make
> it complete.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0/Hans Erik van Elburg
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0On Fri, Mar 13, 2009 at 3:24 PM, Elwell, Jo= hn
> =A0 =A0 =A0 <john.elwell= @siemens.com> wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hans Erik,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Following your detailed des= cription, it
> seems that the
> =A0 =A0 =A0 UAS serving a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0freephone number could rece= ive one of
> the following
> =A0 =A0 =A0 (assuming H-I is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0supported by all relevant n= odes):
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01) H-I containing:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the freephone number (tag= ged);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the AoR (tagged);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the contact URI (not tagg= ed).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Or
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02) H-I containing:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the freephone number (tag= ged);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the contact URI (not tagg= ed).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The latter would occur when= the same
> proxy translates
> =A0 =A0 =A0 the freephone
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0number (via the AoR) to the= contact directly.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So how does this help the U= AS to figure out the
> =A0 =A0 =A0 freephone number? It
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0seems the UAS would have to= search back
> through the
> =A0 =A0 =A0 tagged entries
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0looking for one that matche= s a freephone
> number it
> =A0 =A0 =A0 recognises? Does the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tagging really add much val= ue?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________= _____
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: sip-bounces@ietf.org
> =A0 =A0 =A0 [mailto:sip-bounce= s@ietf.org] On
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Behalf Of Hans Erik van Elb= urg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: 12 March= 2009 21:26
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: Mary Barne= s
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cc: Hans Erik = van Elburg; sip@ietf.org
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: Re: [= Sip] Issue 3 - two
> tags (was RE:
>
> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Inline...
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /Hans Erik van= Elburg
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Thu, Mar 12= , 2009 at 7:10 PM,
> Mary Barnes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mary.barnes@nortel.com> wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 I think there is another solution
> =A0 =A0 =A0 proposal that we
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should pursue for issue 3 i= dentified in the email
> =A0 =A0 =A0 summary sent by Shida
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0earlier this week - I'v= e snipped all the
> text except for
> =A0 =A0 =A0 that issue and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0issue 2 in the summary belo= w. =A0I do
> think the discussion
> =A0 =A0 =A0 has confounded
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the two issues and I think = it ought to
> be clarified that
> =A0 =A0 =A0 if we agree to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the two tags per issue 3, t= hat the
> options for the
> =A0 =A0 =A0 terminology MUST
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change. And, perhaps this i= s why the
> other discussion
> =A0 =A0 =A0 threads aren't
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0progressing well.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Agree.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 So, Hans Erick, I would like
> =A0 =A0 =A0 clarification on as to your
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0view on the solution:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 In general, ISTM that one
> of the issues
> =A0 =A0 =A0 we're having in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this terminology thread is = that you are
> considering the
> =A0 =A0 =A0 solution to be
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that the hi-entries are tag= ged as they
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 are added to the request.
> =A0And, just for
> =A0 =A0 =A0 clarification
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0from my perspective, that i= s NOT the
> solution in either
> =A0 =A0 =A0 4244bis or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target-uri.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The principle = should be that the
> node that has
> =A0 =A0 =A0 the information
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0about what type of rewrite = is performed
> should add the
> =A0 =A0 =A0 tag. (This is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0done by the current target-= uri draft
> allthough the
> =A0 =A0 =A0 solution is not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0complete.)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 For the freeph= one service, that
> would be the
> =A0 =A0 =A0 freephone service.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0For the AOR that is the hom= e proxy.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Assume that th= e freephone service
> receives an
> =A0 =A0 =A0 INVITE =A0request
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that either
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1. received re= quest contains
> History-Info header
> =A0 =A0 =A0 that contains
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the freephone number (as in= R-URI) as
> last entry, THEN
> =A0 =A0 =A0 when rewriting
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI it has to t= ag that
> existing received
> =A0 =A0 =A0 entry AND add the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0new entry with the new valu= e of the
> Request-URI. (I
> =A0 =A0 =A0 think that was how
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0History-Info works right.)<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2. received re= quest contains
> History-Info header
> =A0 =A0 =A0 that does not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contain the freephone numbe= r as last
> entry, THEN when
> =A0 =A0 =A0 rewriting the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request-URI it has add an e= ntry with the
> freephone
> =A0 =A0 =A0 number and tag that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0entry AND add the new entry= with the new
> value of the
> =A0 =A0 =A0 Request-URI.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3. received re= quest does not contain a
> =A0 =A0 =A0 History-Info header, THEN
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when rewriting the Request-= URI it has to
> add an entry
> =A0 =A0 =A0 with the freephone
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0number and tag that entry A= ND add the
> new entry with the
> =A0 =A0 =A0 new value of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 After forwardi= ng this request it
> arrives at the
> =A0 =A0 =A0 home proxy:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1. received re= quest contains
> History-Info header
> =A0 =A0 =A0 that contains
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the AOR (as in R-URI) as la= st entry,
> THEN when rewriting
> =A0 =A0 =A0 the Request-URI
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it has to tag that existing= received
> entry AND add the
> =A0 =A0 =A0 new entry with
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the new value of the Reques= t-URI i.e.
> the registered
> =A0 =A0 =A0 contact. (I think
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that was how History-Info w= orks right.)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2. received re= quest contains
> History-Info header
> =A0 =A0 =A0 that does not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contain the AOR (as in R-UR= I) as last
> entry, THEN when
> =A0 =A0 =A0 rewriting the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request-URI it has add an e= ntry with the
> AOR and tag
> =A0 =A0 =A0 that entry AND add
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the new entry with the new = value of the
> Request-URI i.e.
> =A0 =A0 =A0 the registered
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3. received re= quest does not contain a
> =A0 =A0 =A0 History-Info header, THEN
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when rewriting the Request-= URI it has to
> add an entry
> =A0 =A0 =A0 with the AOR as in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI and tag tha= t entry AND
> add the new entry
> =A0 =A0 =A0 with the new
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value of the Request-URI i.= e. the
> registered contact..
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 I don't view it as a
> problem necessarily
> =A0 =A0 =A0 if you'd like
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to pursue an alternate solu= tion, we just
> need to be
> =A0 =A0 =A0 clear that's what
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0you're advocating. In t= hat case, I would
> agree the
> =A0 =A0 =A0 "retarget" is not an
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0appropriate tag for the ent= ries, as you
> don't know at
> =A0 =A0 =A0 the point in time
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that you add an hi-entry th= at it will be
> retargeted. In
> =A0 =A0 =A0 the case of this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0approach to the solution, y= ou do have to
> alter the
> =A0 =A0 =A0 mechanism for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0determining the hi-entry th= at your
> services would want
> =A0 =A0 =A0 to use. You would
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0need to skip the most recen= t/last
> hi-entry (as that
> =A0 =A0 =A0 would contain the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0same as the Request-URI in = the incoming
> request), since
> =A0 =A0 =A0 it would be
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tagged if you use this solu= tion approach.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yes, but only = if the previous
> proxy added it. As
> =A0 =A0 =A0 History-Info is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0optional one never knows re= ally.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Thus, you'd have to take the next
> =A0 =A0 =A0 hi-entry that you find
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that has the desired "= tag". =A0I will
> posit that we could
> =A0 =A0 =A0 accomplish this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0solution without any change= s to 4244 by
> just registering
> =A0 =A0 =A0 new SIP URI
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parameter(s). =A0 And, =A0t= hat's not to say
> we shouldn't do
> =A0 =A0 =A0 a 4244bis as
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0there are other issues to a= ddress in
> that document, but
> =A0 =A0 =A0 that allows the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target-uri to describe a so= lution that
> makes use of
> =A0 =A0 =A0 4244bis "as is".
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Are you propos= ing to decouple the
> target-uri and
> =A0 =A0 =A0 the 4244bis
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0discussion?
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 So, feedback on this
> specific point (from
> =A0 =A0 =A0 Hans Erik and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0others) would be appreciate= d.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Mary.
>
>
>
>
>
>
>
>
>
>
>

--0015174c3f902308e9046503053b-- From sumanth@cablelabs.com Fri Mar 13 10:07:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF11028C233 for ; Fri, 13 Mar 2009 10:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.637 X-Spam-Level: * X-Spam-Status: No, score=1.637 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpB8iqU2h58G for ; Fri, 13 Mar 2009 10:07:35 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 61D5628C22C for ; Fri, 13 Mar 2009 10:07:35 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n2DH8Dke022215; Fri, 13 Mar 2009 11:08:13 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 13 Mar 2009 11:08:13 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 11:08:11 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601A1ABE3@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding draft-dotson-sip-mutual-auth-03 Thread-Index: Acmj2HtPXRb7JYqlSd2zr5a+3I03cwAH2nBA References: <828cd554936c9f74cee1a9351f03aaed.squirrel@www.ohlmeier.com> <9AAEDF491EF7CA48AB587781B8F5D7C601A1AB2B@srvxchg3.cablelabs.com> From: "Sumanth Channabasappa" To: "Nils Ohlmeier" X-Approved: ondar Cc: sip@ietf.org, Stuart Hoggan , steve.dotson@cox.com Subject: Re: [Sip] Question regarding draft-dotson-sip-mutual-auth-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 17:07:37 -0000 Nils, Ok, but the point is that in most of the cases it will be too late already. Maybe an example is helpfull: I try to register via proxy.hotel.com to my registrar at example.com. Note: I'm using the open WLAN of hotel of cours. Now proxy.hotel.com challenges my initial REGISTER request, which my UA replies to with the password which I got at the receiption. Now this second REGISTER request is forwarded to example.com and replied with a 200 OK. When my UA receives the 200 OK it checks the Proxy-Authentication-Info header and detects an error (maybe because a man-in-the-midlle modified something). Upppss! What should the UA do here? Display me a warning "It looks like you successfully registered to example.com. Unfortunately something went wrong. But your credentials where send already to example.com... Maybe now someone else is registered with your account to example.com?!" [S] In the registration example you provide, the SIP UA will need to verify the Authentication-Info header (per RFC 3261), which is specific to the UA-to-registrar interactions. However, the example can be easily generalized for UA-to-Proxy interactions, where the Proxy-Authentication-Info header is used. When the response (say 200 OK) cannot be authenticated, then the UA probably cannot ascertain as to what happened; for example, the proxy could have been an imposter who generated a phony response (i.e., it never reached the intended proxy) or there was a M-i-M who modified a valid response (i.e., it did reach the intended proxy). What the UA can ascertain is that something is wrong! This is similar to the case where it does not receive a response, i.e., the UA does not know if the other end did receive it and the response was lost (in your registration example, the device will be registered without the UA knowing about it), or the other end did not ever receive it (and registration request never made it through).=20 By rejecting an unauthenticated response, the UA can potentially minimize some of the threats (e.g., a hijack of the UA by a phony proxy). Further, actions such as a retry may help. For example, if the proxy sees a retry after it sent a response, then it can ascertain that something went wrong (e.g., the packet was dropped) and clear up associated resources. [Obvious caution: Too many retries can lead to dictionary attacks.] [Of course, if the MiM did not manipulate the parts of the response that are authenticated by the Proxy-Authentication-Info header, then the threat never surfaces. This is a drawback/limitation.] I understand that your draft is only adding the Proxy-Authentication-Info header. On the other hand I doubt that the whole mutual digest auth like it is described in 2617 and 3261 is usuable for SIP at all. [S] Well, digest is being used by quite a few implementations :)! And in the presence of multiple proxies, digest is an option to authenticate (or authorize) end-to-end. Thus, even when TLS is established with the next-hop, it can be a useful tool. Is it a replacement for SIPS? Perhaps not! But what are the other options?=20 > In any case, please refer to the following small thread (3 emails) for > the feedback I received during offline discussions at the last IETF: > > http://www.ietf.org/mail-archive/web/sip/current/msg25882.html >From that small thread I can only ask the same question as Victor did already: what is meant by this trusted connection to the next hop? [S] The feedback I received (as I understood) was that once you establish mutually-authenticated-TLS with the next-hop, you trust any communication over that link (even to registrars and proxies outside of the next-hop). This also meant that the Authentication-Info header (for registration) is redundant (in RFC3261). And another issue in your draft in my opinion is what you describe in second paragraph of section 10: If someone is going to use mutual digest authentication it can not be optional! As recent "demonstrations" on HTTPS and SMTP with TLS have shown security "upgrades" of an IP connection are not optional. If you know that your server (the hotel proxy in the example above) supports mutual auth, you should configure your UA to require mutual auth. If the mutual auth is not there or failed, something is really wrong in the network and you should definately not proceed with whatever you wanted to do. [S] The reason it is optional is primarily due to WG feedback that it may not be required in all cases. For example, if you use SIPS or your access network is always integrity-protected (e.g., Cable access with DOCSIS BPI+). As Section 10 tries to say, use of this header is not a replacement for TLS. It is only useful in architectures where digest is used (with or without TLS) and you prefer mutual authentication to minimize some threats. I say minimize since some threats still exist (e.g., a transparent MiM who is an active or passive participant). - S From dworley@nortel.com Fri Mar 13 10:52:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B083A6A3D for ; Fri, 13 Mar 2009 10:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBieR1MWgHZe for ; Fri, 13 Mar 2009 10:52:53 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E5BCC3A6927 for ; Fri, 13 Mar 2009 10:52:52 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2DHr9418201 for ; Fri, 13 Mar 2009 17:53:09 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 13:53:28 -0400 From: "Dale Worley" To: SIP Content-Type: text/plain Organization: Nortel Networks Date: Fri, 13 Mar 2009 13:53:27 -0400 Message-Id: <1236966807.4021.34.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2009 17:53:28.0684 (UTC) FILETIME=[9D8CBAC0:01C9A404] Subject: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 17:52:53 -0000 I don't know if this has been mentioned, but I skimmed draft-ietf-sip-199-06 and couldn't find it: One thing that I've always felt was a weakness of the "199" proposal was that it was not possible to associate the early dialog of the 199 with the particular media streams of that early dialog, which makes it difficult for a UAC to use a 199 response to free media-processing resources. However, if the UAS that creates an early media stream sends a 1xx (e.g., 183) *reliably*, then the UAC is certain to be able to associate the to-tag of the 1xx (which is the same as the to-tag of the 199) with the early media source address/port. Why isn't this fact put in the draft? I suppose it isn't a *requirement* for 199, but it seems like a very strong suggestion for UAS behavior to enable the UAC to take advantage of 199. Dale From mary.barnes@nortel.com Fri Mar 13 11:41:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8559728C124 for ; Fri, 13 Mar 2009 11:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdOigutxZTJu for ; Fri, 13 Mar 2009 11:41:05 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DEA2F3A65A5 for ; Fri, 13 Mar 2009 11:41:04 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2DIfI402296; Fri, 13 Mar 2009 18:41:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 13:43:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: Acmj60R6rW+3hNjERSWW1c0T71DU/AADPnIAAASi5lA= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com><9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> From: "Mary Barnes" To: "Elwell, John" , "Hans Erik van Elburg" Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 18:41:06 -0000 =20 Hi John, Thanks for all your feedback thus far on this topic. I have a couple comments below [MB]. Mary. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, March 13, 2009 11:31 AM To: Hans Erik van Elburg Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: 13 March 2009 14:52 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE:=20 > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >=20 > It knows when it rewrites the Request-URI due to a location lookup --> > tag "aor". > It knows (is configured to) when it rewrites the Request-URI with a=20 > value that leads the request to target with a different identity then=20 > the one that has been replaced --> tag new entry "istarget". > It knows when it rewrites the Request-URI with a value and this leads=20 > to the first History-Info entry being recorded --> tag "istarget". [JRE] It does not know that this is the first target, because upstream nodes may have retargeted without inserting H-I. In any case, the To header field URI is the first target, so we don't need that anyway. [MB] John is correct. There is no rule about tagging the first History-Info entry. It may be tagged if the next node changes the request-URI via a service lookup or some other manner such as configuration.[/MB] I can accept that a proxy might know, having done a LS look-up, whether the new URI is a registered contact or some other URI, and on that basis it could choose whether or not to insert a single tag. I thought that was the basis on which we agreed to go ahead with this updated to RFC 4424, rather than following the loose route draft. It is not clear to me that a proxy would have enough information to make a 3-way choice. [MB] My understanding is that there are just two ways in which the request-URI changes if you are using loose routing. It's either changed due to a lookup in a location server, whose information was populated by the UA during registration, OR it is changed due to configuration data (either system, user, etc.). In both cases, obviously, the proxy that is doing this is responsible for the domain of the request-URI in the incoming request. If it were not the case, then all the proxy can do is forward the outgoing request to the next hop. So, I think that may be where the concept of a 3rd choice comes in. But, as far as tagging, we (as I understand it) at least were discussing the potential of two tags only - i.e., further differentiating the cases that are currently all captured by the "retarget" as defined in 4244bis, which is the same mechanism that is specified in the target-uri document EXCEPT that document was only capturing the service lookups, which we believe is incorrect. [/MB] John >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John=20 > wrote: >=20 >=20 > Hans Erik, > =09 > But how does a proxy know what to use? How does it know whether the > received Request-URI, which it uses to query the LS, is a target or=20 > an > AoR? Does it need to scan back up the H-I chain to see whether there=20 > is > already an 'istarget' present, and if so use 'aor' instead of > 'istarget'? > =09 > John > =09 >=20 >=20 > ________________________________ > =09 > From: Hans Erik van Elburg > [mailto:ietf.hanserik@gmail.com] > =09 > Sent: 13 March 2009 14:33 > To: Elwell, John > Cc: sip@ietf.org > =09 > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > =09 > =09 > Hi John, > =09 > Well that is simple one would use different tags for different > type of entries, like in the example I already gave: > =09 > H-I: Bfreephone; "istarget",\ > B,"aor"\ > contact-B > =09 > Where the UAS interested in the initial target with which it=20 > was > addressed it would obtain the "istarget" tagged entry. > Where the UAS interested in the AOR that was used to address=20 > it > would obtain the "aor" tagged entry. > =09 > In simpler cases it could be that one entry holds the "aor" as > well as the "istarget" tag. > =09 > Of course the algorithm needs some work to make it complete. > =09 > /Hans Erik van Elburg > =09 > =09 > =09 > On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John > wrote: > =09 > =09 > Hans Erik, > =09 > Following your detailed description, it seems that the > UAS serving a > freephone number could receive one of the following > (assuming H-I is > supported by all relevant nodes): > =09 > 1) H-I containing: > - the freephone number (tagged); > - the AoR (tagged); > - the contact URI (not tagged). > =09 > Or > =09 > 2) H-I containing: > - the freephone number (tagged); > - the contact URI (not tagged). > =09 > The latter would occur when the same proxy translates > the freephone > number (via the AoR) to the contact directly. > =09 > So how does this help the UAS to figure out the > freephone number? It > seems the UAS would have to search back through the > tagged entries > looking for one that matches a freephone number it > recognises? Does the > tagging really add much value? > =09 > John > =09 > =09 > ________________________________ > =09 > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: 12 March 2009 21:26 > To: Mary Barnes > Cc: Hans Erik van Elburg; sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > =20 > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > =09 > =09 > =09 > Inline... > =09 > /Hans Erik van Elburg > =09 > =09 > =09 > On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes > wrote: > =09 > =09 > I think there is another solution > proposal that we > should pursue for issue 3 identified in the email > summary sent by Shida > earlier this week - I've snipped all the text except=20 > for > that issue and > issue 2 in the summary below. I do think the=20 > discussion > has confounded > the two issues and I think it ought to be clarified=20 > that > if we agree to > the two tags per issue 3, that the options for the > terminology MUST > change. And, perhaps this is why the other discussion > threads aren't > progressing well. > =09 > =09 > Agree. > =09 > =09 > =09 > So, Hans Erick, I would like > clarification on as to your > view on the solution: > =09 > In general, ISTM that one of the issues > we're having in > this terminology thread is that you are considering=20 > the > solution to be > that the hi-entries are tagged as they > are added to the request.=20 > And, just for > clarification > from my perspective, that is NOT the solution in=20 > either > 4244bis or > target-uri. > =09 > =09 > The principle should be that the node that has > the information > about what type of rewrite is performed should add the > tag. (This is > done by the current target-uri draft allthough the > solution is not > complete.) > =09 > For the freephone service, that would be the > freephone service. > For the AOR that is the home proxy. > =09 > Assume that the freephone service receives an > INVITE request > that either > 1. received request contains History-Info=20 > header > that contains > the freephone number (as in R-URI) as last entry, THEN > when rewriting > the Request-URI it has to tag that existing received > entry AND add the > new entry with the new value of the Request-URI. (I > think that was how > History-Info works right.) > 2. received request contains History-Info=20 > header > that does not > contain the freephone number as last entry, THEN when > rewriting the > Request-URI it has add an entry with the freephone > number and tag that > entry AND add the new entry with the new value of the > Request-URI. > 3. received request does not contain a > History-Info header, THEN > when rewriting the Request-URI it has to add an entry > with the freephone > number and tag that entry AND add the new entry with=20 > the > new value of > the Request-URI. > =09 > After forwarding this request it arrives at the > home proxy: > 1. received request contains History-Info=20 > header > that contains > the AOR (as in R-URI) as last entry, THEN when=20 > rewriting > the Request-URI > it has to tag that existing received entry AND add the > new entry with > the new value of the Request-URI i.e.=20 > the registered > contact. (I think > that was how History-Info works right.) > 2. received request contains History-Info=20 > header > that does not > contain the AOR (as in R-URI) as last entry, THEN when > rewriting the > Request-URI it has add an entry with the AOR and tag > that entry AND add > the new entry with the new value of the Request-URI=20 > i.e. > the registered > contact. > 3. received request does not contain a > History-Info header, THEN > when rewriting the Request-URI it has to add an entry > with the AOR as in > the Request-URI and tag that entry AND add the new=20 > entry > with the new > value of the Request-URI i.e. the registered contact.. > =09 > =09 > I don't view it as a problem=20 > necessarily > if you'd like > to pursue an alternate solution, we just need to be > clear that's what > you're advocating. In that case, I would agree the > "retarget" is not an > appropriate tag for the entries, as you don't know at > the point in time > that you add an hi-entry that it will be retargeted.=20 > In > the case of this > approach to the solution, you do have to alter the > mechanism for > determining the hi-entry that your services would want > to use. You would > need to skip the most recent/last hi-entry (as that > would contain the > same as the Request-URI in the incoming request), > since > it would be > tagged if you use this solution approach. > =09 > =09 > Yes, but only if the previous proxy added it.=20 > As > History-Info is > optional one never knows really. > =09 > =09 > =09 > Thus, you'd have to take the next > hi-entry that you find > that has the desired "tag". I will posit that we > could > accomplish this > solution without any changes to 4244 by just=20 > registering > new SIP URI > parameter(s). And, that's not to say=20 > we shouldn't do > a 4244bis as > there are other issues to address in that document,=20 > but > that allows the > target-uri to describe a solution that makes use of > 4244bis "as is". > =09 > =09 > =09 > Are you proposing to decouple the target-uri=20 > and > the 4244bis > discussion? > =09 > =09 > So, feedback on this specific point=20 > (from > Hans Erik and > others) would be appreciated. > =09 > =09 > =09 > Mary. > =09 > =09 > =09 > =09 > =09 > =09 > =09 > =09 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From ietf.hanserik@gmail.com Fri Mar 13 14:16:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7CAB3A6A94 for ; Fri, 13 Mar 2009 14:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2unVornvdE2P for ; Fri, 13 Mar 2009 14:16:41 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id B3F8B3A680A for ; Fri, 13 Mar 2009 14:16:40 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so712230nfh.39 for ; Fri, 13 Mar 2009 14:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=v+vJUH20fLatRwQbVYQJCQTlg3tHQvsw2gL7g5/lfzA=; b=bAmdKB+T5kPnbPx+GuJGKUn/vfd5cXWrBR1Zi0excsna8vlUndg8FSujb1HlwOsUPU qpo6EEOJ6u0PL1UBz9O7EO5/Qliji3gFVCTIkBLXatUU/8kpyHunlTgGg6ZsPv62m3/R E3P20vZu1z03ehxe1fTuGFd47c0a+CZaVz1n4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KUCyTYxSh5XeoJNAs0bQmNYPK/Q56AwmWNrNzJJWtFDNHOOpTAOYw5xvw9Z1yIBdFX bWesPmESP4BweuPSLBtMt44rj/qgPIoaOufWxAdto7HzHinuvYuzkgzADKY+nwDZAZKM XxZWAGxeeL1CXOfQC9Swngf9b0uecgjToE3OY= MIME-Version: 1.0 Received: by 10.210.10.11 with SMTP id 11mr1095465ebj.35.1236979038479; Fri, 13 Mar 2009 14:17:18 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com> Date: Fri, 13 Mar 2009 22:17:18 +0100 Message-ID: <9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com> From: Hans Erik van Elburg To: Mary Barnes Content-Type: multipart/alternative; boundary=0015174be0782ee6cc046506a070 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 21:16:44 -0000 --0015174be0782ee6cc046506a070 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I guess you mean that you agree with John that such rule can not be reliably construed. I dont think I have seen convincing proof that such is the case. Are you also saying that we may only consider loose routing being used? Further for "configured mappings" for which we never saw a proper definition. But assuming that this is a proxy that can be configured to do a Request-URI rewrite based on some configured setting. In that case there are two variants of such mapping: 1. A mapping that changes the identity of the target to be reached. (This is what call forwarding or diversion does normally.) 2. A mapping that only changes the next hop route taken towards the target identity that has not been changed. For the UAS it only matters that the home domain does the tagging consistently and correctly if it wants to rely on such information. Otherwise we would have to start adding information about the domain that added a specific hi-entry, if one wants to be sure who added the particular hi-entry. /Hans Erik van Elburg On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes wrote: > Hi John, > > Thanks for all your feedback thus far on this topic. I have a couple > comments below [MB]. > > Mary. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Friday, March 13, 2009 11:31 AM > To: Hans Erik van Elburg > Cc: sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 13 March 2009 14:52 > > To: Elwell, John > > Cc: sip@ietf.org > > Subject: Re: [Sip] Issue 3 - two tags (was RE: > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > It knows when it rewrites the Request-URI due to a location lookup --> > > > tag "aor". > > It knows (is configured to) when it rewrites the Request-URI with a > > value that leads the request to target with a different identity then > > the one that has been replaced --> tag new entry "istarget". > > It knows when it rewrites the Request-URI with a value and this leads > > to the first History-Info entry being recorded --> tag "istarget". > [JRE] It does not know that this is the first target, because upstream > nodes may have retargeted without inserting H-I. In any case, the To > header field URI is the first target, so we don't need that anyway. > [MB] John is correct. There is no rule about tagging the first > History-Info entry. It may be tagged if the next node changes the > request-URI via a service lookup or some other manner such as > configuration.[/MB] > > I can accept that a proxy might know, having done a LS look-up, whether > the new URI is a registered contact or some other URI, and on that basis > it could choose whether or not to insert a single tag. I thought that > was the basis on which we agreed to go ahead with this updated to RFC > 4424, rather than following the loose route draft. It is not clear to me > that a proxy would have enough information to make a 3-way choice. > [MB] My understanding is that there are just two ways in which the > request-URI changes if you are using loose routing. It's either changed > due to a lookup in a location server, whose information was populated by > the UA during registration, OR it is changed due to configuration data > (either system, user, etc.). In both cases, obviously, the proxy that is > doing this is responsible for the domain of the request-URI in the > incoming request. If it were not the case, then all the proxy can do is > forward the outgoing request to the next hop. So, I think that may be > where the concept of a 3rd choice comes in. But, as far as tagging, we > (as I understand it) at least were discussing the potential of two tags > only - i.e., further differentiating the cases that are currently all > captured by the "retarget" as defined in 4244bis, which is the same > mechanism that is specified in the target-uri document EXCEPT that > document was only capturing the service lookups, which we believe is > incorrect. [/MB] > > John > > > > > > /Hans Erik van Elburg > > > > > > > > On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John > > wrote: > > > > > > Hans Erik, > > > > But how does a proxy know what to use? How does it know whether > the > > received Request-URI, which it uses to query the LS, is a target > or > > an > > AoR? Does it need to scan back up the H-I chain to see whether > there > > is > > already an 'istarget' present, and if so use 'aor' instead of > > 'istarget'? > > > > John > > > > > > > > ________________________________ > > > > From: Hans Erik van Elburg > > [mailto:ietf.hanserik@gmail.com] > > > > Sent: 13 March 2009 14:33 > > To: Elwell, John > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] Issue 3 - two tags (was RE: > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > Hi John, > > > > Well that is simple one would use different tags for > different > > type of entries, like in the example I already gave: > > > > H-I: Bfreephone; "istarget",\ > > B,"aor"\ > > contact-B > > > > Where the UAS interested in the initial target with which > it > > was > > addressed it would obtain the "istarget" tagged entry. > > Where the UAS interested in the AOR that was used to > address > > it > > would obtain the "aor" tagged entry. > > > > In simpler cases it could be that one entry holds the > "aor" as > > well as the "istarget" tag. > > > > Of course the algorithm needs some work to make it > complete. > > > > /Hans Erik van Elburg > > > > > > > > On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John > > wrote: > > > > > > Hans Erik, > > > > Following your detailed description, it seems > that the > > UAS serving a > > freephone number could receive one of the > following > > (assuming H-I is > > supported by all relevant nodes): > > > > 1) H-I containing: > > - the freephone number (tagged); > > - the AoR (tagged); > > - the contact URI (not tagged). > > > > Or > > > > 2) H-I containing: > > - the freephone number (tagged); > > - the contact URI (not tagged). > > > > The latter would occur when the same proxy > translates > > the freephone > > number (via the AoR) to the contact directly. > > > > So how does this help the UAS to figure out the > > freephone number? It > > seems the UAS would have to search back through > the > > tagged entries > > looking for one that matches a freephone number > it > > recognises? Does the > > tagging really add much value? > > > > John > > > > > > ________________________________ > > > > From: sip-bounces@ietf.org > > [mailto:sip-bounces@ietf.org] On > > Behalf Of Hans Erik van Elburg > > Sent: 12 March 2009 21:26 > > To: Mary Barnes > > Cc: Hans Erik van Elburg; sip@ietf.org > > Subject: Re: [Sip] Issue 3 - two tags (was > RE: > > > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > > > Inline... > > > > /Hans Erik van Elburg > > > > > > > > On Thu, Mar 12, 2009 at 7:10 PM, Mary > Barnes > > wrote: > > > > > > I think there is another solution > > proposal that we > > should pursue for issue 3 identified in the email > > summary sent by Shida > > earlier this week - I've snipped all the text > except > > for > > that issue and > > issue 2 in the summary below. I do think the > > discussion > > has confounded > > the two issues and I think it ought to be > clarified > > that > > if we agree to > > the two tags per issue 3, that the options for > the > > terminology MUST > > change. And, perhaps this is why the other > discussion > > threads aren't > > progressing well. > > > > > > Agree. > > > > > > > > So, Hans Erick, I would like > > clarification on as to your > > view on the solution: > > > > In general, ISTM that one of the > issues > > we're having in > > this terminology thread is that you are > considering > > the > > solution to be > > that the hi-entries are tagged as they > > are added to the request. > > And, just for > > clarification > > from my perspective, that is NOT the solution in > > either > > 4244bis or > > target-uri. > > > > > > The principle should be that the node that > has > > the information > > about what type of rewrite is performed should > add the > > tag. (This is > > done by the current target-uri draft allthough > the > > solution is not > > complete.) > > > > For the freephone service, that would be > the > > freephone service. > > For the AOR that is the home proxy. > > > > Assume that the freephone service receives > an > > INVITE request > > that either > > 1. received request contains History-Info > > header > > that contains > > the freephone number (as in R-URI) as last entry, > THEN > > when rewriting > > the Request-URI it has to tag that existing > received > > entry AND add the > > new entry with the new value of the Request-URI. > (I > > think that was how > > History-Info works right.) > > 2. received request contains History-Info > > header > > that does not > > contain the freephone number as last entry, THEN > when > > rewriting the > > Request-URI it has add an entry with the > freephone > > number and tag that > > entry AND add the new entry with the new value of > the > > Request-URI. > > 3. received request does not contain a > > History-Info header, THEN > > when rewriting the Request-URI it has to add an > entry > > with the freephone > > number and tag that entry AND add the new entry > with > > the > > new value of > > the Request-URI. > > > > After forwarding this request it arrives > at the > > home proxy: > > 1. received request contains History-Info > > header > > that contains > > the AOR (as in R-URI) as last entry, THEN when > > rewriting > > the Request-URI > > it has to tag that existing received entry AND > add the > > new entry with > > the new value of the Request-URI i.e. > > the registered > > contact. (I think > > that was how History-Info works right.) > > 2. received request contains History-Info > > header > > that does not > > contain the AOR (as in R-URI) as last entry, THEN > when > > rewriting the > > Request-URI it has add an entry with the AOR and > tag > > that entry AND add > > the new entry with the new value of the > Request-URI > > i.e. > > the registered > > contact. > > 3. received request does not contain a > > History-Info header, THEN > > when rewriting the Request-URI it has to add an > entry > > with the AOR as in > > the Request-URI and tag that entry AND add the > new > > entry > > with the new > > value of the Request-URI i.e. the registered > contact.. > > > > > > I don't view it as a problem > > necessarily > > if you'd like > > to pursue an alternate solution, we just need to > be > > clear that's what > > you're advocating. In that case, I would agree > the > > "retarget" is not an > > appropriate tag for the entries, as you don't > know at > > the point in time > > that you add an hi-entry that it will be > retargeted. > > In > > the case of this > > approach to the solution, you do have to alter > the > > mechanism for > > determining the hi-entry that your services would > want > > to use. You would > > need to skip the most recent/last hi-entry (as > that > > would contain the > > same as the Request-URI in the incoming request), > > > since > > it would be > > tagged if you use this solution approach. > > > > > > Yes, but only if the previous proxy added > it. > > As > > History-Info is > > optional one never knows really. > > > > > > > > Thus, you'd have to take the next > > hi-entry that you find > > that has the desired "tag". I will posit that we > > > could > > accomplish this > > solution without any changes to 4244 by just > > registering > > new SIP URI > > parameter(s). And, that's not to say > > we shouldn't do > > a 4244bis as > > there are other issues to address in that > document, > > but > > that allows the > > target-uri to describe a solution that makes use > of > > 4244bis "as is". > > > > > > > > Are you proposing to decouple the > target-uri > > and > > the 4244bis > > discussion? > > > > > > So, feedback on this specific > point > > (from > > Hans Erik and > > others) would be appreciated. > > > > > > > > Mary. > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > --0015174be0782ee6cc046506a070 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess you mean that you agree with John that such rule can not be reliabl= y construed.
I dont think I have seen convincing proof that such is the = case.

Are you also saying that we may only consider loose routing be= ing used?

Further for "configured mappings" for which we never saw a pr= oper definition. But assuming that this is a proxy that can be configured t= o do a Request-URI=A0 rewrite based on some configured setting.

In t= hat case there are two variants of such mapping:
1. A mapping that changes the identity of the target to be reached. (This i= s what call forwarding or diversion does normally.)
2. A mapping that on= ly changes=A0 the next hop route taken towards the target identity that has= not been changed.

For the UAS it only matters that the home domain does the tagging consi= stently and correctly if it wants to rely on such information.

Other= wise we would have to start adding information about the domain that added = a specific hi-entry, if one wants to be sure who added the particular hi-en= try.

/Hans Erik van Elburg


On Fri, Mar 13, 2009 at 7:43 PM, Mary Ba= rnes <mary.b= arnes@nortel.com> wrote:
Hi John,

Thanks for all your feedback thus far on this topic. I have a couple
comments below [MB].

Mary.

-----Original Message-----
From: sip-bounces@ietf.org [mai= lto:sip-bounces@ietf.org] On Be= half Of
Elwell, John
Sent: Friday, March 13, 2009 11:31 AM
To: Hans Erik van Elburg
Cc: sip@ietf.org
Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt




> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: 13 March 2009 14:52
> To: Elwell, John
> Cc: sip@ietf.org
> Subject: Re: [Sip] Issue 3 - two tags (was RE:
> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
> It knows when it rewrites the Request-URI due to a location lookup --&= gt;

> tag "aor".
> It knows (is configured to) when it rewrites the Request-URI with a > value that leads the request to target with a different identity then<= br> > the one that has been replaced --> tag new entry "istarget&quo= t;.
> It knows when it rewrites the Request-URI with a value and this leads<= br> > to the first History-Info entry being recorded --> tag "istarg= et".
[JRE] It does not know that this is the first target, because upstream
nodes may have retargeted without inserting H-I. In any case, the To
header field URI is the first target, so we don't need that anyway.
[MB] John is correct. There is no rule about tagging the first<= br> History-Info entry. It may be tagged if the next node changes the
request-URI via a service lookup or some other manner such as
configuration.[/MB]

I can accept that a proxy might know, having done a LS look-up, whether
the new URI is a registered contact or some other URI, and on that basis it could choose whether or not to insert a single tag. I thought that
was the basis on which we agreed to go ahead with this updated to RFC
4424, rather than following the loose route draft. It is not clear to me that a proxy would have enough information to make a 3-way choice.
[MB] My understanding is that there are just two ways in which the request-URI changes if you are using loose routing. It's either changed=
due to a lookup in a location server, whose information was populated by the UA during registration, OR it is changed due to configuration data
(either system, user, etc.). In both cases, obviously, the proxy that is doing this is responsible for the domain of the request-URI in the
incoming request. If it were not the case, then all the proxy can do is
forward the outgoing request to the next hop. So, I think that may be
where the concept of a 3rd choice comes in. But, as far as tagging, we
(as I understand it) at least were discussing the potential of two tags
only - i.e., further differentiating the cases that are currently all
captured by the "retarget" as defined in 4244bis, which is the sa= me
mechanism that is specified in the target-uri document EXCEPT that
document was only capturing the service lookups, which we believe is
incorrect. [/MB]

John


>
> /Hans Erik van Elburg
>
>
>
> On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John
> <john.elwell@siemens.com= > wrote:
>
>
> =A0 =A0 =A0 =A0Hans Erik,
>
> =A0 =A0 =A0 But how does a proxy know what to use? How does it know wh= ether
the
> =A0 =A0 =A0 received Request-URI, which it uses to query the LS, is a = target
or
> an
> =A0 =A0 =A0 AoR? Does it need to scan back up the H-I chain to see whe= ther
there
> is
> =A0 =A0 =A0 already an 'istarget' present, and if so use '= aor' instead of
> =A0 =A0 =A0 'istarget'?
>
> =A0 =A0 =A0 John
>
>
>
> =A0 =A0 =A0 ________________________________
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0From: Hans Erik van Elburg
> [mailto:ietf.hanserik@gmail= .com]
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Sent: 13 March 2009 14:33
> =A0 =A0 =A0 =A0 =A0 =A0 =A0To: Elwell, John
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Cc: sip@iet= f.org
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject: Re: [Sip] Issue 3 - two tags (was = RE:
> =A0 =A0 =A0 I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt >
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi John,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Well that is simple one would use different= tags for
different
> =A0 =A0 =A0 type of entries, like in the example I already gave:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 H-I: =A0Bfreephone; "istarget&quo= t;,\
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B,"aor"\
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact-B
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Where the UAS interested in the initial tar= get with which
it
> was
> =A0 =A0 =A0 addressed it would obtain the "istarget" tagged = entry.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Where the UAS interested in the AOR =A0that= was used to
address
> it
> =A0 =A0 =A0 would obtain the "aor" tagged entry.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0In simpler cases it could be that one entry= holds the
"aor" as
> =A0 =A0 =A0 well as the "istarget" tag.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Of course the algorithm needs some work to = make it
complete.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0/Hans Erik van Elburg
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0On Fri, Mar 13, 2009 at 3:24 PM, Elwell, Jo= hn
> =A0 =A0 =A0 <john.elwell= @siemens.com> wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hans Erik,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Following your detailed des= cription, it seems
that the
> =A0 =A0 =A0 UAS serving a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0freephone number could rece= ive one of the
following
> =A0 =A0 =A0 (assuming H-I is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0supported by all relevant n= odes):
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01) H-I containing:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the freephone number (tag= ged);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the AoR (tagged);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the contact URI (not tagg= ed).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Or
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02) H-I containing:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the freephone number (tag= ged);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- the contact URI (not tagg= ed).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The latter would occur when= the same proxy
translates
> =A0 =A0 =A0 the freephone
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0number (via the AoR) to the= contact directly.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So how does this help the U= AS to figure out the
> =A0 =A0 =A0 freephone number? It
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0seems the UAS would have to= search back through
the
> =A0 =A0 =A0 tagged entries
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0looking for one that matche= s a freephone number
it
> =A0 =A0 =A0 recognises? Does the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tagging really add much val= ue?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________= _____
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: sip-bounces@ietf.org
> =A0 =A0 =A0 [mailto:sip-bounce= s@ietf.org] On
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Behalf Of Hans Erik van Elb= urg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: 12 March= 2009 21:26
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: Mary Barne= s
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cc: Hans Erik = van Elburg; sip@ietf.org
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: Re: [= Sip] Issue 3 - two tags (was
RE:
>
> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Inline...
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /Hans Erik van= Elburg
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Thu, Mar 12= , 2009 at 7:10 PM, Mary
Barnes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mary.barnes@nortel.com> wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 I think there is another solution
> =A0 =A0 =A0 proposal that we
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should pursue for issue 3 i= dentified in the email
> =A0 =A0 =A0 summary sent by Shida
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0earlier this week - I'v= e snipped all the text
except
> for
> =A0 =A0 =A0 that issue and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0issue 2 in the summary belo= w. =A0I do think the
> discussion
> =A0 =A0 =A0 has confounded
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the two issues and I think = it ought to be
clarified
> that
> =A0 =A0 =A0 if we agree to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the two tags per issue 3, t= hat the options for
the
> =A0 =A0 =A0 terminology MUST
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change. And, perhaps this i= s why the other
discussion
> =A0 =A0 =A0 threads aren't
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0progressing well.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Agree.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 So, Hans Erick, I would like
> =A0 =A0 =A0 clarification on as to your
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0view on the solution:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 In general, ISTM that one of the
issues
> =A0 =A0 =A0 we're having in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this terminology thread is = that you are
considering
> the
> =A0 =A0 =A0 solution to be
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that the hi-entries are tag= ged as they
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 are added to the request.
> =A0And, just for
> =A0 =A0 =A0 clarification
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0from my perspective, that i= s NOT the solution in
> either
> =A0 =A0 =A0 4244bis or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target-uri.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The principle = should be that the node that
has
> =A0 =A0 =A0 the information
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0about what type of rewrite = is performed should
add the
> =A0 =A0 =A0 tag. (This is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0done by the current target-= uri draft allthough
the
> =A0 =A0 =A0 solution is not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0complete.)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 For the freeph= one service, that would be
the
> =A0 =A0 =A0 freephone service.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0For the AOR that is the hom= e proxy.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Assume that th= e freephone service receives
an
> =A0 =A0 =A0 INVITE =A0request
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that either
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1. received re= quest contains History-Info
> header
> =A0 =A0 =A0 that contains
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the freephone number (as in= R-URI) as last entry,
THEN
> =A0 =A0 =A0 when rewriting
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI it has to t= ag that existing
received
> =A0 =A0 =A0 entry AND add the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0new entry with the new valu= e of the Request-URI.
(I
> =A0 =A0 =A0 think that was how
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0History-Info works right.)<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2. received re= quest contains History-Info
> header
> =A0 =A0 =A0 that does not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contain the freephone numbe= r as last entry, THEN
when
> =A0 =A0 =A0 rewriting the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request-URI it has add an e= ntry with the
freephone
> =A0 =A0 =A0 number and tag that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0entry AND add the new entry= with the new value of
the
> =A0 =A0 =A0 Request-URI.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3. received re= quest does not contain a
> =A0 =A0 =A0 History-Info header, THEN
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when rewriting the Request-= URI it has to add an
entry
> =A0 =A0 =A0 with the freephone
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0number and tag that entry A= ND add the new entry
with
> the
> =A0 =A0 =A0 new value of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 After forwardi= ng this request it arrives
at the
> =A0 =A0 =A0 home proxy:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1. received re= quest contains History-Info
> header
> =A0 =A0 =A0 that contains
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the AOR (as in R-URI) as la= st entry, THEN when
> rewriting
> =A0 =A0 =A0 the Request-URI
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it has to tag that existing= received entry AND
add the
> =A0 =A0 =A0 new entry with
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the new value of the Reques= t-URI i.e.
> the registered
> =A0 =A0 =A0 contact. (I think
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that was how History-Info w= orks right.)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2. received re= quest contains History-Info
> header
> =A0 =A0 =A0 that does not
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contain the AOR (as in R-UR= I) as last entry, THEN
when
> =A0 =A0 =A0 rewriting the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request-URI it has add an e= ntry with the AOR and
tag
> =A0 =A0 =A0 that entry AND add
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the new entry with the new = value of the
Request-URI
> i.e.
> =A0 =A0 =A0 the registered
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3. received re= quest does not contain a
> =A0 =A0 =A0 History-Info header, THEN
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when rewriting the Request-= URI it has to add an
entry
> =A0 =A0 =A0 with the AOR as in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the Request-URI and tag tha= t entry AND add the
new
> entry
> =A0 =A0 =A0 with the new
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value of the Request-URI i.= e. the registered
contact..
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 I don't view it as a problem
> necessarily
> =A0 =A0 =A0 if you'd like
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to pursue an alternate solu= tion, we just need to
be
> =A0 =A0 =A0 clear that's what
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0you're advocating. In t= hat case, I would agree
the
> =A0 =A0 =A0 "retarget" is not an
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0appropriate tag for the ent= ries, as you don't
know at
> =A0 =A0 =A0 the point in time
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that you add an hi-entry th= at it will be
retargeted.
> In
> =A0 =A0 =A0 the case of this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0approach to the solution, y= ou do have to alter
the
> =A0 =A0 =A0 mechanism for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0determining the hi-entry th= at your services would
want
> =A0 =A0 =A0 to use. You would
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0need to skip the most recen= t/last hi-entry (as
that
> =A0 =A0 =A0 would contain the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0same as the Request-URI in = the incoming request),

> since
> =A0 =A0 =A0 it would be
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tagged if you use this solu= tion approach.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yes, but only = if the previous proxy added
it.
> As
> =A0 =A0 =A0 History-Info is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0optional one never knows re= ally.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Thus, you'd have to take the next
> =A0 =A0 =A0 hi-entry that you find
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that has the desired "= tag". =A0I will posit that we

> could
> =A0 =A0 =A0 accomplish this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0solution without any change= s to 4244 by just
> registering
> =A0 =A0 =A0 new SIP URI
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parameter(s). =A0 And, =A0t= hat's not to say
> we shouldn't do
> =A0 =A0 =A0 a 4244bis as
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0there are other issues to a= ddress in that
document,
> but
> =A0 =A0 =A0 that allows the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0target-uri to describe a so= lution that makes use
of
> =A0 =A0 =A0 4244bis "as is".
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Are you propos= ing to decouple the
target-uri
> and
> =A0 =A0 =A0 the 4244bis
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0discussion?
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 So, feedback on this specific
point
> (from
> =A0 =A0 =A0 Hans Erik and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0others) would be appreciate= d.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Mary.
>
>
>
>
>
>
>
>
>
>
>
_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors@cs.col= umbia.edu for questions on current sip Use
sipping@ietf.org for new developmen= ts on the application of sip

--0015174be0782ee6cc046506a070-- From mary.barnes@nortel.com Fri Mar 13 14:50:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2712528C196 for ; Fri, 13 Mar 2009 14:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZLXpK7nyJgp for ; Fri, 13 Mar 2009 14:50:29 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6F97A28C172 for ; Fri, 13 Mar 2009 14:50:29 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2DLoi429396; Fri, 13 Mar 2009 21:50:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 16:53:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmkIR3d3ywyAZbORXaUGnJopMcfsAAAINvA References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1CD4B6D1@zrc2hxm0.corp.nortel.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com> <9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 21:50:31 -0000 Responses below [MB]. ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, March 13, 2009 4:17 PM To: Barnes, Mary (RICH2:AR00) Cc: Elwell, John; sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I guess you mean that you agree with John that such rule can not be reliably construed.=20 [MB] Which rule? I fully agree we can discern the 3 cases as I explained below. Per 16.5 (Determining Request Targets) in RFC 3261, these are unique and recognized situations. The reason I refer to loose routing is that it's my understanding it is far more commonly used and RFC 3261 doesn't even describe strict routing - it focuses on loose routing and strict routing support is for 2543 backwards compatibility as I understood. But, actually it makes no difference to History-Info processing. The important thing really, is that you MUST tag the old entry as you are doing the processing per 16.5 as that information is lost by the time you get around to adding the next History-Info header in section 16.6 ( Request Forwarding). I think one thing that might be being missed in this thread is that I have been very careful to rely explicitly on what is described in 16.5 - that a must read to understand what I am saying - again there is a lack of clarity in that section and we can suggest clarifications once we all can finally agree appropriate terms. If you'd like me to pull the explicit text that supports everything I've been saying, I can do so, but it's somewhat a waste of time. [/MB] =20 I dont think I have seen convincing proof that such is the case.=20 [MB] And, I'm not saying that you can't construct such a rule - indeed I am saying that you certainly should be able to per RFC 3261 section 16.5. Can you point out what text below that suggests I am saying that? [/MB]=20 Are you also saying that we may only consider loose routing being used?=20 [MB] Nope. [/MB]=20 Further for "configured mappings" for which we never saw a proper definition. But assuming that this is a proxy that can be configured to do a Request-URI rewrite based on some configured setting.=20 [MB] The concept of "configured mappings" is described in RFC 3261 - perhaps not with the level of granularity or specificity that some might desire, but it's there - it's initially described as an abstract location service (1st Paragraph section 16.5). And, then later it specifies that a proxy can determine "targets" (3261 term not mine) just about any ole way it wants, so I don't know that we need to define a new term for "configured mappings" per se - there is no limitation as to the mechanism one can use to determine the request-URI for the outgoing request (once it is determined that the Proxy is ALLOWED to overwrite the request-URI - the right domain, etc.), This is a fundamental SIP concept that many products use to give a (human) user flexibility in configuring where an incoming call might terminate. So, I see no issue at all is specifying two tags to capture this rewrite as it's already in section 16.5 that this is information that a Proxy should be able to derive. [/MB]=20 In that case there are two variants of such mapping: 1. A mapping that changes the identity of the target to be reached. (This is what call forwarding or diversion does normally.) 2. A mapping that only changes the next hop route taken towards the target identity that has not been changed. =20 For the UAS it only matters that the home domain does the tagging consistently and correctly if it wants to rely on such information.=20 [MB] I don't know that I agree it's the home domain - it's a proxy that has responsibility for the domain in the request-URI that is able to do the service lookup or using any other sort of mapping to determine the new URI for the request-URI in the outgoing request. I don't know that we want to restrict that to the "home" domain. If we restrict it to the home domain, then that implies that we are only tagging the entries that are determined based on service lookup in a Registrar (per RFC 3261's definition of a "home domain"). [/MB] Otherwise we would have to start adding information about the domain that added a specific hi-entry, if one wants to be sure who added the particular hi-entry.=20 [MB] I'm not sure why this would be needed and I wasn't espousing that it would - we know by definition that the domain that mucked with a URI is the domain associated with the URI that was overwritten/lost, etc. [/MB]=20 /Hans Erik van Elburg On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes wrote: Hi John, =09 Thanks for all your feedback thus far on this topic. I have a couple comments below [MB]. =09 Mary. =09 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of =09 Elwell, John Sent: Friday, March 13, 2009 11:31 AM To: Hans Erik van Elburg =09 Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 =09 =09 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: 13 March 2009 14:52 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > It knows when it rewrites the Request-URI due to a location lookup --> =09 > tag "aor". > It knows (is configured to) when it rewrites the Request-URI with a > value that leads the request to target with a different identity then > the one that has been replaced --> tag new entry "istarget". > It knows when it rewrites the Request-URI with a value and this leads > to the first History-Info entry being recorded --> tag "istarget". [JRE] It does not know that this is the first target, because upstream nodes may have retargeted without inserting H-I. In any case, the To header field URI is the first target, so we don't need that anyway. =09 [MB] John is correct. There is no rule about tagging the first History-Info entry. It may be tagged if the next node changes the request-URI via a service lookup or some other manner such as configuration.[/MB] =09 I can accept that a proxy might know, having done a LS look-up, whether the new URI is a registered contact or some other URI, and on that basis it could choose whether or not to insert a single tag. I thought that was the basis on which we agreed to go ahead with this updated to RFC 4424, rather than following the loose route draft. It is not clear to me that a proxy would have enough information to make a 3-way choice. =09 [MB] My understanding is that there are just two ways in which the request-URI changes if you are using loose routing. It's either changed due to a lookup in a location server, whose information was populated by the UA during registration, OR it is changed due to configuration data (either system, user, etc.). In both cases, obviously, the proxy that is doing this is responsible for the domain of the request-URI in the incoming request. If it were not the case, then all the proxy can do is forward the outgoing request to the next hop. So, I think that may be where the concept of a 3rd choice comes in. But, as far as tagging, we (as I understand it) at least were discussing the potential of two tags only - i.e., further differentiating the cases that are currently all captured by the "retarget" as defined in 4244bis, which is the same mechanism that is specified in the target-uri document EXCEPT that document was only capturing the service lookups, which we believe is incorrect. [/MB] =09 John =09 =09 > ---remainder of theread snipped by Mary. -------- From christer.holmberg@ericsson.com Fri Mar 13 15:26:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C75D3A6AF1 for ; Fri, 13 Mar 2009 15:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.725 X-Spam-Level: X-Spam-Status: No, score=-5.725 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJqePL1hAxvA for ; Fri, 13 Mar 2009 15:26:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EED983A6967 for ; Fri, 13 Mar 2009 15:26:34 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 76BA2201C6; Fri, 13 Mar 2009 23:27:12 +0100 (CET) X-AuditID: c1b4fb3e-af0a0bb0000023da-39-49baddc0e3ee Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4932E20094; Fri, 13 Mar 2009 23:27:12 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 23:27:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 23:25:23 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CD7F3FF@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: AcmjxRhZ819f4W9wQ5iV2x9RFuWOtAACyv+AAAXQ7aAAEKvp4A== References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <49B84C55.5070107@gmail.com> <1ECE0EB50388174790F9694F77522CCF1CCF9A06@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120134i76a6a92brb183205cd66e841f@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A27AF1@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CCF9DC8@zrc2hxm0.corp.nortel.com> <9ae56b1e0903120754m66c0b7c5y225ce0f9193dba28@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD4B01D@zrc2hxm0.corp.nortel.com> <9ae56b1e0903130318x7f0c8dc3rb9bd593a83ddbdbd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CD7F3FF@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Hans Erik van Elburg" , "Dean Willis" X-OriginalArrivalTime: 13 Mar 2009 22:27:12.0000 (UTC) FILETIME=[DA9BE000:01C9A42A] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 22:26:36 -0000 Hi, I think we shall try to agree on the definitions first - then we can decide where to put it. But, wherever we put it, I think there shall be a separate and clear definitions chapter. Other chapters then simply refers to that. Regards, Christer=20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Friday, March 13, 2009 4:31 PM To: Christer Holmberg; Hans Erik van Elburg; Dean Willis Cc: sip@ietf.org; Elwell, John Subject: RE: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt That's fine - we just need to be careful with the wording in 4244 so that the existing normative functionality isn't so impacted. I'll look at the detailed impact of the changes as retarget is quite prevalent in that document. It could be that we can leave it in the early sections (and define it to be the same as the term we agree) and just keep it out of the normative sections - right now, it is only used in a few places other than describing the new parameter in the normative sections. =20 Mary. ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, March 13, 2009 6:42 AM To: Hans Erik van Elburg; Dean Willis Cc: Barnes, Mary (RICH2:AR00); sip@ietf.org; Elwell, John Subject: RE: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Hi, =20 I think we should use those definitions as base. That way I think we would be able to progress faster. =20 Because, I think we really need to agree on the definitions FIRST. There is no idea on discussing detailed wording in 4244bis if we don't have a common understanding of what we mean. =20 Regards, =20 Christer =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: 13. maaliskuuta 2009 12:19 To: Dean Willis Cc: Christer Holmberg; Mary Barnes; sip@ietf.org; Elwell, John Subject: Re: [Sip] Terminology (was RE: Fwd:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 Hi Dean, =09 Yes this was exactly how we used/defined the terms at the time we where discussing the ua-loose-route vs Target-header solutions. =09 I still think that this way they are most intuitive and closest to how you would use the terms in natural language.=20 =09 /Hans Erik van Elburg =09 =09 On Thu, Mar 12, 2009 at 8:27 PM, Dean Willis wrote: =09 On Mar 12, 2009, at 1:18 PM, Christer Holmberg wrote: =09 =09 A couple of question: =09 1. Does the 4244bis definition of "retarget" cover the freephone case, when the R-URI is replaced with the AoR of B - not with the contact of B - no matter whether it's done based on location service, configuration or whatever? =09 By the way, I believe that the way I use the words, this is a "reroute" and not a "retarget". In the freephone case, I would still expect the destination to have an awareness that it is the target of freephone calls and have credentials for the freephone number such that it could appropriately authenticate its responses if we had a means to do so.=20 2. Related to the first question, when you say "...and thus chaning the target of the request", what is the defintion of "target"? =09 =09 My definition is that a "retarget" changes the expected identity of the expected responder, introducing the possibility of an "unanticipated respondent" scenario. =09 This is, AFAIK, very different from the 4244 terminology, which I've always held to be not particularly useful. =09 -- Dean =09 =09 From christer.holmberg@ericsson.com Fri Mar 13 15:45:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFF53A69EB for ; Fri, 13 Mar 2009 15:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.73 X-Spam-Level: X-Spam-Status: No, score=-5.73 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FScvZih84OqB for ; Fri, 13 Mar 2009 15:45:36 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EEDA83A67FC for ; Fri, 13 Mar 2009 15:45:35 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D5DE22066D; Fri, 13 Mar 2009 23:46:13 +0100 (CET) X-AuditID: c1b4fb3e-ae89fbb0000023da-18-49bae23571bc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B5CC920094; Fri, 13 Mar 2009 23:46:13 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 23:46:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2009 23:44:04 +0100 Message-ID: In-Reply-To: <1236966807.4021.34.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-199-06 Thread-Index: AcmkBLFr75kvEWhBTAqMyluMgWFq5gAJsZJw References: <1236966807.4021.34.camel@victoria-pingtel-com.us.nortel.com> From: "Christer Holmberg" To: "Dale Worley" , "SIP" X-OriginalArrivalTime: 13 Mar 2009 22:46:13.0438 (UTC) FILETIME=[82F57DE0:01C9A42D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 22:45:37 -0000 Hi Dale,=20 >I don't know if this has been mentioned, but I skimmed draft-ietf-sip-199-06 and couldn't find it: > >One thing that I've always felt was a weakness of the "199" proposal was that it was not possible to associate the early dialog of the 199 with the particular media streams of that early dialog, which=20 >makes it difficult for a UAC to use a 199 response to free media-processing resources. It is true that the 199 spec doesn't define mechanisms how to do the association. I think we a long time ago agreed that it is outside the scope of the document. But, as indicated in the draft, even if the UAC is not able to associate the dialog with a particular strem, when it receives 199 it can e.g. remove media resources (codecs etc) which have only been reserved for that particular dialgo.=20 >However, if the UAS that creates an early media stream sends a 1xx (e.g., 183) *reliably*, then the UAC is certain to be able to associate the to-tag of the 1xx (which is the same as the to-tag of the=20 >199) with the early media source address/port. > >Why isn't this fact put in the draft? I suppose it isn't a *requirement* for 199, but it seems like a very strong suggestion for UAS behavior to enable the UAC to take advantage of 199. Are you saying that if the UAS sends a reliable 18x with SDP, the UAC will then be able to use the SDP information to associate the media with the dialog? That works with the following assumptions: 1. The UAS uses symmetric media, ie it sends media from the same port/address where it wants to receive media (keep in mind that SDP only indicates where you want to receive media). 2. There are no NATs in the media path. Also, the draft doesn't say anything about whether to send 18x responses reliably or not. If the UAS wants to make sure the UAC gets the SDP, it should send the 18x reliably - no matter if he supports 199 or not. Regards, Christer From HKaplan@acmepacket.com Fri Mar 13 20:34:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5DE3A6AE3 for ; Fri, 13 Mar 2009 20:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnCGwrVVeQEx for ; Fri, 13 Mar 2009 20:34:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6A2B63A6A82 for ; Fri, 13 Mar 2009 20:34:39 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 13 Mar 2009 23:35:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 13 Mar 2009 23:35:17 -0400 From: Hadriel Kaplan To: "Elwell, John" , "sip@ietf.org" Date: Fri, 13 Mar 2009 23:35:15 -0400 Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-asserter-identity-01.txt Thread-Index: AcmgHAvp4O4wrLI1Qnyv3RMS6sFcgwACk1lwAE61iiAAvPG18A== Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D0019F7234@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0019F7234@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-asserter-identity-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 03:34:40 -0000 Hey John, Thanks for reviewing the draft! I was thinking that basically the asserter= should decide what it wants to sign, but I think you're right that a defau= lt list would be good.=20 -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Tuesday, March 10, 2009 5:29 AM >=20 > An interesting draft, perhaps useful in two ways: first in the way you > intend (as asserter ID in closed domains or federations of closed > domains), but secondly some aspects might be relevant for inclusion in > an eventual solution to the SIP-Identity problem, notably the means of > selecting particular body parts and SDP attributes to sign. >=20 > On that particular issue, I am not sure whether the asserter is in a > position to decide on a request-by-request basis which body parts and > SDP attributes to sign, since it cannot know what downstream entities > are likely to need to do to those fields, so we may need some guidance > (e.g., a default list of things to sign). From ietf.hanserik@gmail.com Sat Mar 14 00:54:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7523A6846 for ; Sat, 14 Mar 2009 00:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOIISJ06mJ0B for ; Sat, 14 Mar 2009 00:54:05 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 6819C3A67DA for ; Sat, 14 Mar 2009 00:54:03 -0700 (PDT) Received: by ewy25 with SMTP id 25so2828999ewy.37 for ; Sat, 14 Mar 2009 00:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=xf+JsjBJ0/mGhqqS6zv/hrHt8Hanuu9OL/cJ+NuzhWM=; b=HrSh6/4EtpP7VS+/Hvf8j1IoXXO+JPeoyntNh4HXD+KwnrrZ0GiHNgUAsKKH5PhXgQ 6NS1k9ibJMb6Wy8buj05IcwD2dNQPpK79UZxwpP6++9Ei2sGYlma3wq5KsQNILCb+c9X wACKg5qrBsvyQOJ1VPd8BDCbxLwhjXhVrvJdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uaIgKuK8uiyxl0Cf7TuwKVH32O5rccFLKJvqQw1GYHgGNrCu4xTamWYFgBfi08n9VG UoeRO+LhSgT2ITaT3gIbdfKhWw/12bl8dOHa4TfDj3ax1N/35D3QRZeN4BsRxkNhgM7V JbJOix4qh6hbDX/DPfEpp58D08Rk26Hr2JgbI= MIME-Version: 1.0 Received: by 10.210.35.17 with SMTP id i17mr1630661ebi.81.1237017282685; Sat, 14 Mar 2009 00:54:42 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com> References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com> <9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com> Date: Sat, 14 Mar 2009 08:54:42 +0100 Message-ID: <9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> From: Hans Erik van Elburg To: "sip@ietf.org List" Content-Type: multipart/alternative; boundary=0015174c17a8b72bea04650f87ec Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 07:54:07 -0000 --0015174c17a8b72bea04650f87ec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I just realised that there is an additional problem that makes it even harder to do any distinction. A UA may register as a contact an AOR of another user or resource. Effectively this causes the request to be forwarded to the other user by overwriting the Request-URI. So the fact that the Request-URI was overwritten due to a location lookup, doesn't tell you a bit about the nature of the rewrite. /Hans Erik van Elburg On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes wrote: > Responses below [MB]. > > ________________________________ > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Friday, March 13, 2009 4:17 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Elwell, John; sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > I guess you mean that you agree with John that such rule can not be > reliably construed. > [MB] Which rule? I fully agree we can discern the 3 cases as I > explained below. Per 16.5 (Determining Request Targets) in RFC 3261, > these are unique and recognized situations. The reason I refer to loose > routing is that it's my understanding it is far more commonly used and > RFC 3261 doesn't even describe strict routing - it focuses on loose > routing and strict routing support is for 2543 backwards compatibility > as I understood. But, actually it makes no difference to History-Info > processing. The important thing really, is that you MUST tag the old > entry as you are doing the processing per 16.5 as that information is > lost by the time you get around to adding the next History-Info header > in section 16.6 ( Request Forwarding). I think one thing that might be > being missed in this thread is that I have been very careful to rely > explicitly on what is described in 16.5 - that a must read to understand > what I am saying - again there is a lack of clarity in that section and > we can suggest clarifications once we all can finally agree appropriate > terms. If you'd like me to pull the explicit text that supports > everything I've been saying, I can do so, but it's somewhat a waste of > time. [/MB] > > I dont think I have seen convincing proof that such is the case. > [MB] And, I'm not saying that you can't construct such a rule - indeed I > am saying that you certainly should be able to per RFC 3261 section > 16.5. Can you point out what text below that suggests I am saying that? > [/MB] > > Are you also saying that we may only consider loose routing being used? > [MB] Nope. [/MB] > > Further for "configured mappings" for which we never saw a proper > definition. But assuming that this is a proxy that can be configured to > do a Request-URI rewrite based on some configured setting. > [MB] The concept of "configured mappings" is described in RFC 3261 - > perhaps not with the level of granularity or specificity that some might > desire, but it's there - it's initially described as an abstract > location service (1st Paragraph section 16.5). And, then later it > specifies that a proxy can determine "targets" (3261 term not mine) just > about any ole way it wants, so I don't know that we need to define a new > term for "configured mappings" per se - there is no limitation as to the > mechanism one can use to determine the request-URI for the outgoing > request (once it is determined that the Proxy is ALLOWED to overwrite > the request-URI - the right domain, etc.), This is a fundamental SIP > concept that many products use to give a (human) user flexibility in > configuring where an incoming call might terminate. So, I see no issue > at all is specifying two tags to capture this rewrite as it's already in > section 16.5 that this is information that a Proxy should be able to > derive. [/MB] > > In that case there are two variants of such mapping: > 1. A mapping that changes the identity of the target to be reached. > (This is what call forwarding or diversion does normally.) > 2. A mapping that only changes the next hop route taken towards the > target identity that has not been changed. > > For the UAS it only matters that the home domain does the tagging > consistently and correctly if it wants to rely on such information. > [MB] I don't know that I agree it's the home domain - it's a proxy that > has responsibility for the domain in the request-URI that is able to do > the service lookup or using any other sort of mapping to determine the > new URI for the request-URI in the outgoing request. I don't know that > we want to restrict that to the "home" domain. If we restrict it to the > home domain, then that implies that we are only tagging the entries that > are determined based on service lookup in a Registrar (per RFC 3261's > definition of a "home domain"). [/MB] > > Otherwise we would have to start adding information about the domain > that added a specific hi-entry, if one wants to be sure who added the > particular hi-entry. > [MB] I'm not sure why this would be needed and I wasn't espousing that > it would - we know by definition that the domain that mucked with a URI > is the domain associated with the URI that was overwritten/lost, etc. > [/MB] > > /Hans Erik van Elburg > > > > On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes > wrote: > > > Hi John, > > Thanks for all your feedback thus far on this topic. I have a > couple > comments below [MB]. > > Mary. > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Elwell, John > Sent: Friday, March 13, 2009 11:31 AM > To: Hans Erik van Elburg > > Cc: sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 13 March 2009 14:52 > > To: Elwell, John > > Cc: sip@ietf.org > > Subject: Re: [Sip] Issue 3 - two tags (was RE: > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > It knows when it rewrites the Request-URI due to a location > lookup --> > > > tag "aor". > > It knows (is configured to) when it rewrites the Request-URI > with a > > value that leads the request to target with a different > identity then > > the one that has been replaced --> tag new entry "istarget". > > It knows when it rewrites the Request-URI with a value and > this leads > > to the first History-Info entry being recorded --> tag > "istarget". > [JRE] It does not know that this is the first target, because > upstream > nodes may have retargeted without inserting H-I. In any case, > the To > header field URI is the first target, so we don't need that > anyway. > > [MB] John is correct. There is no rule about tagging the first > History-Info entry. It may be tagged if the next node changes > the > request-URI via a service lookup or some other manner such as > configuration.[/MB] > > > I can accept that a proxy might know, having done a LS look-up, > whether > the new URI is a registered contact or some other URI, and on > that basis > it could choose whether or not to insert a single tag. I thought > that > was the basis on which we agreed to go ahead with this updated > to RFC > 4424, rather than following the loose route draft. It is not > clear to me > that a proxy would have enough information to make a 3-way > choice. > > [MB] My understanding is that there are just two ways in which > the > request-URI changes if you are using loose routing. It's either > changed > due to a lookup in a location server, whose information was > populated by > the UA during registration, OR it is changed due to > configuration data > (either system, user, etc.). In both cases, obviously, the proxy > that is > doing this is responsible for the domain of the request-URI in > the > incoming request. If it were not the case, then all the proxy > can do is > forward the outgoing request to the next hop. So, I think that > may be > where the concept of a 3rd choice comes in. But, as far as > tagging, we > (as I understand it) at least were discussing the potential of > two tags > only - i.e., further differentiating the cases that are > currently all > captured by the "retarget" as defined in 4244bis, which is the > same > mechanism that is specified in the target-uri document EXCEPT > that > document was only capturing the service lookups, which we > believe is > incorrect. [/MB] > > > John > > > > > ---remainder of theread snipped by Mary. -------- > --0015174c17a8b72bea04650f87ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I just realised that there is an additional problem that makes it even hard= er to do any distinction.

A UA may register as a contact an AOR of a= nother user or resource. Effectively this causes the request to be forwarde= d to the other user by overwriting the Request-URI.

So the fact that the Request-URI was overwritten due to a location look= up, doesn't tell you a bit about the nature of the rewrite.

/Hans Erik van Elburg


On Fri, Mar 13, 2009 at 10:53 PM, Mary B= arnes <mary.= barnes@nortel.com> wrote:
Responses below [MB].

________________________________

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Friday, March 13, 2009 4:17 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Elwell, John; sip@ietf.org
Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


I guess you mean that you agree with John that such= rule can not be
reliably construed.
[MB] Which rule? =A0I fully agree we can discern the 3 cases as I
explained below. Per 16.5 (Determining Request Targets) in RFC 3261,
these are unique and recognized situations. The reason I refer to loose
routing is that it's my understanding it is far more commonly used and<= br> RFC 3261 doesn't even describe strict routing - it focuses on loose
routing and strict routing support is for 2543 backwards compatibility
as I understood. But, actually it makes no difference to History-Info
processing. =A0The important thing really, is that you MUST tag the old
entry as you are doing the processing per 16.5 as that information is
lost by the time you get around to adding the next History-Info header
in section 16.6 ( Request Forwarding). I think one thing that might be
being missed in this thread is that I have been very careful to rely
explicitly on what is described in 16.5 - that a must read to understand what I am saying - again there is a lack of clarity in that section and
we can suggest clarifications once we all can finally agree appropriate
terms. If you'd like me to pull the explicit text that supports
everything I've been saying, I can do so, but it's somewhat a waste= of
time. [/MB]

I dont think I have seen convincing proof that such is the case.
[MB] And, I'm not saying that you can't construct such a rule= - indeed I
am saying that you certainly should be able to per RFC 3261 section
16.5. =A0Can you point out what text below that suggests I am saying that?<= br> [/MB]

Are you also saying that we may only consider loose routing being used?
[MB] Nope. [/MB]

Further for "configured mappings" for which we never saw a proper=
definition. But assuming that this is a proxy that can be configured to
do a Request-URI =A0rewrite based on some configured setting.
[MB] The concept of "configured mappings" is described in R= FC 3261 -
perhaps not with the level of granularity or specificity that some might desire, but it's there - it's initially described as an abstract location service (1st Paragraph section 16.5). =A0And, then later it
specifies that a proxy can determine "targets" (3261 term not min= e) just
about any ole way it wants, so I don't know that we need to define a ne= w
term for "configured mappings" per se - there is no limitation as= to the
mechanism one can use to determine the request-URI for the outgoing
request (once it is determined that the Proxy is ALLOWED =A0to overwrite the request-URI - the right domain, etc.), =A0This is a fundamental SIP
concept that many products use to give a (human) user flexibility in
configuring where an incoming call might terminate. So, I see no issue
at all is specifying two tags to capture this rewrite as it's already i= n
section 16.5 that this is information that a Proxy should be able to
derive. [/MB]

In that case there are two variants of such mapping:
1. A mapping that changes the identity of the target to be reached.
(This is what call forwarding or diversion does normally.)
2. A mapping that only changes =A0the next hop route taken towards the
target identity that has not been changed.

For the UAS it only matters that the home domain does the tagging
consistently and correctly if it wants to rely on such information.
[MB] I don't know that I agree it's the home domain - it'= s a proxy that
has responsibility for the domain in the request-URI that is able to do
the service lookup or using any other sort of mapping to determine the
new URI for the request-URI in the outgoing request. =A0I don't know th= at
we want to restrict that to the "home" domain. If we restrict it = to the
home domain, then that implies that we are only tagging the entries that are determined based on service lookup in a Registrar (per RFC 3261's definition of a "home domain"). =A0[/MB]

Otherwise we would have to start adding information about the domain
that added a specific hi-entry, if one wants to be sure who added the
particular hi-entry.
[MB] I'm not sure why this would be needed and I wasn't espou= sing that
it would - we know by definition that the domain that mucked with a URI
is the domain associated with the URI that was overwritten/lost, etc.
[/MB]

/Hans Erik van Elburg



On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes <mary.barnes@nortel.com>
wrote:


=A0 =A0 =A0 =A0Hi John,

=A0 =A0 =A0 =A0Thanks for all your feedback thus far on this topic. I have= a
couple
=A0 =A0 =A0 =A0comments below [MB].

=A0 =A0 =A0 =A0Mary.


=A0 =A0 =A0 =A0-----Original Message-----
=A0 =A0 =A0 =A0From: sip-bounces@i= etf.org [mailto:sip-bounces@iet= f.org] On
Behalf Of

=A0 =A0 =A0 =A0Elwell, John
=A0 =A0 =A0 =A0Sent: Friday, March 13, 2009 11:31 AM
=A0 =A0 =A0 =A0To: Hans Erik van Elburg

=A0 =A0 =A0 =A0Cc: sip@ietf.org
=A0 =A0 =A0 =A0Subject: Re: [Sip] Issue 3 - two tags (was RE:
=A0 =A0 =A0 =A0I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt



=A0 =A0 =A0 =A0> -----Original Message-----
=A0 =A0 =A0 =A0> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
=A0 =A0 =A0 =A0> Sent: 13 March 2009 14:52
=A0 =A0 =A0 =A0> To: Elwell, John
=A0 =A0 =A0 =A0> Cc: sip@ietf.org =A0 =A0 =A0 =A0> Subject: Re: [Sip] Issue 3 - two tags (was RE:
=A0 =A0 =A0 =A0> I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.t= xt
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> It knows when it rewrites the Request-URI due to a loc= ation
lookup -->

=A0 =A0 =A0 =A0> tag "aor".
=A0 =A0 =A0 =A0> It knows (is configured to) when it rewrites the Reque= st-URI
with a
=A0 =A0 =A0 =A0> value that leads the request to target with a differen= t
identity then
=A0 =A0 =A0 =A0> the one that has been replaced --> tag new entry &q= uot;istarget".
=A0 =A0 =A0 =A0> It knows when it rewrites the Request-URI with a value= and
this leads
=A0 =A0 =A0 =A0> to the first History-Info entry being recorded --> = tag
"istarget".
=A0 =A0 =A0 =A0[JRE] It does not know that this is the first target, becau= se
upstream
=A0 =A0 =A0 =A0nodes may have retargeted without inserting H-I. In any cas= e,
the To
=A0 =A0 =A0 =A0header field URI is the first target, so we don't need = that
anyway.

=A0 =A0 =A0 =A0[MB] John is correct. There is no rule about tagging the fi= rst
=A0 =A0 =A0 =A0History-Info entry. It may be tagged if the next node chang= es
the
=A0 =A0 =A0 =A0request-URI via a service lookup or some other manner such = as
=A0 =A0 =A0 =A0configuration.[/MB]


=A0 =A0 =A0 =A0I can accept that a proxy might know, having done a LS look= -up,
whether
=A0 =A0 =A0 =A0the new URI is a registered contact or some other URI, and = on
that basis
=A0 =A0 =A0 =A0it could choose whether or not to insert a single tag. I th= ought
that
=A0 =A0 =A0 =A0was the basis on which we agreed to go ahead with this upda= ted
to RFC
=A0 =A0 =A0 =A04424, rather than following the loose route draft. It is no= t
clear to me
=A0 =A0 =A0 =A0that a proxy would have enough information to make a 3-way<= br> choice.

=A0 =A0 =A0 =A0[MB] My understanding is that there are just two ways in wh= ich
the
=A0 =A0 =A0 =A0request-URI changes if you are using loose routing. It'= s either
changed
=A0 =A0 =A0 =A0due to a lookup in a location server, whose information was=
populated by
=A0 =A0 =A0 =A0the UA during registration, OR it is changed due to
configuration data
=A0 =A0 =A0 =A0(either system, user, etc.). In both cases, obviously, the = proxy
that is
=A0 =A0 =A0 =A0doing this is responsible for the domain of the request-URI= in
the
=A0 =A0 =A0 =A0incoming request. If it were not the case, then all the pro= xy
can do is
=A0 =A0 =A0 =A0forward the outgoing request to the next hop. So, I think t= hat
may be
=A0 =A0 =A0 =A0where the concept of a 3rd choice comes in. But, as far as<= br> tagging, we
=A0 =A0 =A0 =A0(as I understand it) at least were discussing the potential= of
two tags
=A0 =A0 =A0 =A0only - i.e., further differentiating the cases that are
currently all
=A0 =A0 =A0 =A0captured by the "retarget" as defined in 4244bis,= which is the
same
=A0 =A0 =A0 =A0mechanism that is specified in the target-uri document EXCE= PT
that
=A0 =A0 =A0 =A0document was only capturing the service lookups, which we believe is
=A0 =A0 =A0 =A0incorrect. [/MB]


=A0 =A0 =A0 =A0John


=A0 =A0 =A0 =A0>
---remainder of theread snipped by Mary. --------

--0015174c17a8b72bea04650f87ec-- From jdrosen@cisco.com Sat Mar 14 05:26:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8429B3A67E5 for ; Sat, 14 Mar 2009 05:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URCiiIti3clF for ; Sat, 14 Mar 2009 05:26:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 88A8E3A6A48 for ; Sat, 14 Mar 2009 05:26:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,362,1233532800"; d="scan'208";a="155804148" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Mar 2009 12:26:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2ECQcgU026470; Sat, 14 Mar 2009 05:26:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2ECQcTW019678; Sat, 14 Mar 2009 12:26:38 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Mar 2009 05:26:38 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Mar 2009 05:26:37 -0700 Message-ID: <49BBA27C.4050805@cisco.com> Date: Sat, 14 Mar 2009 08:26:36 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Raphael Coeffic References: <49AE593F.6080807@iptel.org> In-Reply-To: <49AE593F.6080807@iptel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2009 12:26:38.0177 (UTC) FILETIME=[1F309510:01C9A4A0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3846; t=1237033598; x=1237897598; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20draft-state-sip-relay-attack-00 |Sender:=20; bh=HXnpwoqbyHEeyu1/DB3NcG0Zw9iotm0TG+INQJs01Ac=; b=MQHWzOJyMCUjco769p5Rh5iKQwTDxL4NVtddjXenj6F8mwYugwxznSowbj fzcY62jdNCD+YuTcx1Zj0HUz9felJqz0GFr8ngDilYRMtQL6Mu8GCPbQMo6W CHA9x2kVxb; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 12:26:02 -0000 Rafael and others, Thanks for putting this together. Considering for a moment figure 1, this attack is possible only if UAs accept incoming requests from any place, and not just their proxy. In practice, this is seldom allowed. Indeed, if it is allowed, there are worse attacks than this which can be launched (free phone calls, spam calling, etc.). Using the SIP recommended TLS between UA and proxy also mitigates that. So really figure 2 is the interesting one. However, this attack assumes that Alice has credentials on multiple systems. Again, in practice, this is extremely uncommon. Certainly none of the existing deployed enterprise or service provider consumer deployments are of this nature. As such, I dont think this attack is likely in practice. However, in theory it is possible. The essence of the attack is that the victim is providing credentials to an unauthenticated server (since the attacker is acting like a server, asking for credentials). In that way, as others have pointed out, it is similar to baiting attacks that have been previously documented. With SIP it is most easily remedied by a rule which says, 'don't pass credentials for domain X to a server that is not domain X'. Server identity can be verified by normal server-only auth between a client and its server, but even that is not needed. A client will know which domain its proxy is representing, and once connected, it only provides credentials for that domain. -Jonathan R. Raphael Coeffic wrote: > Hello, > > a new internet draft has been published concerning the relay attack on > digest authentication and SIP. The attack itself has been first > disclosed 2 years ago by the maydnes team from the french INRIA. Until > now, no document has been pushlished that documents the attack and > provides guidance to SIP operators or handset manufacturers. > > http://tools.ietf.org/html/draft-state-sip-relay-attack-00 > > The appropriate mitigations of problem resolutions are still not 100% > clear. We hope that this draft can help start a discussion on how to > best resolve this problem. > > > Regards, > > Raphael Coeffic. > (on behalf of all the authors of this draft) > > --------------------------------------------------------------------------------------------------- > > > Filename: draft-state-sip-relay-attack > Version: 00 > Staging URL: > http://www3.ietf.org/proceedings/staging/draft-state-sip-relay-attack-00.txt > > Title: SIP digest authentication relay attack > Creation_date: 2009-03-02 > WG ID: Indvidual Submission > Number_of_pages: 18 > Abstract: > The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism > for creating, modifying, and terminating sessions with one or more > participants. This document describes a vulnerability of SIP > combined with HTTP Digest Access Authentication [RFC2617] through > which an attacker can leverage the victim's credentials to send > authenticated requests on his behalf. This attack is different from > the man-in-the-middle (MITM) attack and does not require any > eavesdropping, DNS or IP spoofing. > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From jdrosen@cisco.com Sat Mar 14 06:37:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5303A67ED for ; Sat, 14 Mar 2009 06:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B+tscLnLWDB for ; Sat, 14 Mar 2009 06:37:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A21053A676A for ; Sat, 14 Mar 2009 06:37:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,362,1233532800"; d="scan'208";a="155812502" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 14 Mar 2009 13:38:31 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2EDcV9R018705 for ; Sat, 14 Mar 2009 06:38:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2EDcVcP017105 for ; Sat, 14 Mar 2009 13:38:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Mar 2009 06:38:30 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Mar 2009 06:38:30 -0700 Message-ID: <49BBB355.90808@cisco.com> Date: Sat, 14 Mar 2009 09:38:29 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2009 13:38:30.0830 (UTC) FILETIME=[29BB34E0:01C9A4AA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1386; t=1237037911; x=1237901911; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-zourzouvillys-sip-via-coo kie-02 |Sender:=20; bh=Vj7py1AjFMlDpXMrtjbSnWoCIPw79sJhqwsLPpiWKVE=; b=Sz5+6yuQ78XeXx2Z3r25n5WDbNN4ijDNmqpvc1m0N/AfAB+l4WNcDVMDEN 6rhPRQrJwBQR3gHDmwXxm8M0exUgAjN03V6LYevUmWDqaGo4dKWsETNODtU1 vx/T/OmCKAXMDGYAwSmRs6/GDCK79JJ0hSQAYshW8B4asJ2Q8z9tE=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Sip] comments on draft-zourzouvillys-sip-via-cookie-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 13:37:52 -0000 Theo, Thanks for writing this up. A few comments. Firstly, it seems that the easiest solution is just 'use tcp'. This is one of many reasons (and growing) why we need to be pushing implementations to tcp. Secondly, if you want to do this for UDP, you could instead use anonymous authentication. Then, the existing nonce takes on the role of a cookie. I suspect that anonymous authentication is not widely implemented, but neither is a new protocol. That said, I think the right answer still is 'use tcp'. Finally, the media portion of this attack, as you point out, is far more disruptive. That attack does not require spoofing even; just listing the IP address/port of the target in the SDP of the INVITE. We were calling this the 'voice hammer' attack, originally documented here: http://tools.ietf.org/html/draft-rosenberg-mmusic-rtp-denialofservice-00 and described in Section 18.5.1 of ICE. The via cookie mechanism you propose, SIP-over-TCP, or anonymous authentication, none of them fix this attack. AFAIK, ICE is the only remedy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From theo@crazygreek.co.uk Sat Mar 14 07:05:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07EB928C0E1 for ; Sat, 14 Mar 2009 07:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPyAnho-8Te0 for ; Sat, 14 Mar 2009 07:05:24 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with SMTP id 094693A6A08 for ; Sat, 14 Mar 2009 07:05:24 -0700 (PDT) Received: from source ([72.14.220.156]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSbu5yzihuNTS83wbZH89OSRdEOamcKzG@postini.com; Sat, 14 Mar 2009 07:06:04 PDT Received: by fg-out-1718.google.com with SMTP id l26so872379fgb.41 for ; Sat, 14 Mar 2009 07:06:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.83.1 with SMTP id g1mr1778078fgb.60.1237039563117; Sat, 14 Mar 2009 07:06:03 -0700 (PDT) In-Reply-To: <49BBB355.90808@cisco.com> References: <49BBB355.90808@cisco.com> Date: Sat, 14 Mar 2009 14:06:03 +0000 Message-ID: <167dfb9b0903140706o1b5fc4e4u7f4b085a2456bc97@mail.gmail.com> From: Theo Zourzouvillys To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF SIP List Subject: Re: [Sip] comments on draft-zourzouvillys-sip-via-cookie-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 14:05:26 -0000 Hi Jonathan, Thank you very much for your comments. On Sat, Mar 14, 2009 at 1:38 PM, Jonathan Rosenberg wrote: > Firstly, it seems that the easiest solution is just 'use tcp'. This is one > of many reasons (and growing) why we need to be pushing implementations to > tcp. absolutely, or even better, [D]TLS. problem is, in reality, UDP is not going away overnight. we're far more likely to get vendors to add a mechanism in that doesn't cost too much in terms of implementation than expect everyone stops using UDP. > Secondly, if you want to do this for UDP, you could instead use anonymous > authentication. Then, the existing nonce takes on the role of a cookie. I > suspect that anonymous authentication is not widely implemented, but neither > is a new protocol. That said, I think the right answer still is 'use tcp'. I did consider that. The problem then is that it requires end-to-end support, where as this is hop-by-hop, and as such means it doesn't have HERFP problems or require every endpoint to upgrade - only the hops that talk to public servers. Via cookies also work over multiple hops, where as anonymous would require a request-per-hop, each request getting one hop further. This could be very expensive in both network load and call setup time. > Finally, the media portion of this attack, as you point out, is far more > disruptive. That attack does not require spoofing even; just listing the IP > address/port of the target in the SDP of the INVITE. We were calling this > the 'voice hammer' attack, originally documented here: > > http://tools.ietf.org/html/draft-rosenberg-mmusic-rtp-denialofservice-00 excellent. i'd not come across that before. i'll have a read tonight. > and described in Section 18.5.1 of ICE. The via cookie mechanism you > propose, SIP-over-TCP, or anonymous authentication, none of them fix this > attack. indeed - i wanted to solve the signalling side before i moved onto the (albeit more serious) media problem > AFAIK, ICE is the only remedy. Yes, i came to the same conclusion; it's a shame that an ICE lite implementation wouldn't itself fix it. (could it? :-)) There is also the problem of targeting a dialog at the victim (think SUBSCRIBE with Contact of the victim), which is the 3rd issue. ~ Theo From mary.barnes@nortel.com Sat Mar 14 07:43:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492833A6A2A for ; Sat, 14 Mar 2009 07:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0liFxuYlh0wd for ; Sat, 14 Mar 2009 07:43:58 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 038B53A68A6 for ; Sat, 14 Mar 2009 07:43:57 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2EEiYH06374; Sat, 14 Mar 2009 14:44:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Mar 2009 09:47:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1CDCB4C4@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 3 - two tags (was RE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: Acmkei8qLAHgu2URQ8aFrPem9+QLcQAOLZ0g References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com><9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com> <9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" , Subject: Re: [Sip] Issue 3 - two tags (was RE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 14:43:59 -0000 Correct, you don't know anything about the URI that overwrites the request-URI. BUT, you know the type of URI that was overwritten (with respect to how it is used at the incoming Proxy). You know that the request URI that was overwritten was one of the types we've been discussing - i.e., a URI that can be used for a service Lookup in a Registrar, whether that URI is mapped, configured, etc. or whether that URI is just for a proxy hop - i.e., it's not a URI for which the proxy is responsible. And, you are using that tag against the URI that is being overwritten. =20 Mary.=20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: Saturday, March 14, 2009 2:55 AM To: sip@ietf.org List Subject: Re: [Sip] Issue 3 - two tags (was RE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I just realised that there is an additional problem that makes it even harder to do any distinction. A UA may register as a contact an AOR of another user or resource. Effectively this causes the request to be forwarded to the other user by overwriting the Request-URI. So the fact that the Request-URI was overwritten due to a location lookup, doesn't tell you a bit about the nature of the rewrite. /Hans Erik van Elburg On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes wrote: Responses below [MB]. =09 ________________________________ =09 From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] =09 Sent: Friday, March 13, 2009 4:17 PM =09 To: Barnes, Mary (RICH2:AR00) =09 Cc: Elwell, John; sip@ietf.org =09 Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 =09 I guess you mean that you agree with John that such rule can not be reliably construed. =09 [MB] Which rule? I fully agree we can discern the 3 cases as I explained below. Per 16.5 (Determining Request Targets) in RFC 3261, these are unique and recognized situations. The reason I refer to loose routing is that it's my understanding it is far more commonly used and RFC 3261 doesn't even describe strict routing - it focuses on loose routing and strict routing support is for 2543 backwards compatibility as I understood. But, actually it makes no difference to History-Info processing. The important thing really, is that you MUST tag the old entry as you are doing the processing per 16.5 as that information is lost by the time you get around to adding the next History-Info header in section 16.6 ( Request Forwarding). I think one thing that might be being missed in this thread is that I have been very careful to rely explicitly on what is described in 16.5 - that a must read to understand what I am saying - again there is a lack of clarity in that section and we can suggest clarifications once we all can finally agree appropriate terms. If you'd like me to pull the explicit text that supports everything I've been saying, I can do so, but it's somewhat a waste of time. [/MB] =09 I dont think I have seen convincing proof that such is the case. =09 [MB] And, I'm not saying that you can't construct such a rule - indeed I am saying that you certainly should be able to per RFC 3261 section 16.5. Can you point out what text below that suggests I am saying that? [/MB] =09 Are you also saying that we may only consider loose routing being used? =09 [MB] Nope. [/MB] =09 Further for "configured mappings" for which we never saw a proper definition. But assuming that this is a proxy that can be configured to do a Request-URI rewrite based on some configured setting. =09 [MB] The concept of "configured mappings" is described in RFC 3261 - perhaps not with the level of granularity or specificity that some might desire, but it's there - it's initially described as an abstract location service (1st Paragraph section 16.5). And, then later it specifies that a proxy can determine "targets" (3261 term not mine) just about any ole way it wants, so I don't know that we need to define a new term for "configured mappings" per se - there is no limitation as to the mechanism one can use to determine the request-URI for the outgoing request (once it is determined that the Proxy is ALLOWED to overwrite the request-URI - the right domain, etc.), This is a fundamental SIP concept that many products use to give a (human) user flexibility in configuring where an incoming call might terminate. So, I see no issue at all is specifying two tags to capture this rewrite as it's already in section 16.5 that this is information that a Proxy should be able to derive. [/MB] =09 In that case there are two variants of such mapping: 1. A mapping that changes the identity of the target to be reached. (This is what call forwarding or diversion does normally.) 2. A mapping that only changes the next hop route taken towards the target identity that has not been changed. =09 For the UAS it only matters that the home domain does the tagging consistently and correctly if it wants to rely on such information. =09 [MB] I don't know that I agree it's the home domain - it's a proxy that has responsibility for the domain in the request-URI that is able to do the service lookup or using any other sort of mapping to determine the new URI for the request-URI in the outgoing request. I don't know that we want to restrict that to the "home" domain. If we restrict it to the home domain, then that implies that we are only tagging the entries that are determined based on service lookup in a Registrar (per RFC 3261's definition of a "home domain"). [/MB] =09 Otherwise we would have to start adding information about the domain that added a specific hi-entry, if one wants to be sure who added the particular hi-entry. =09 [MB] I'm not sure why this would be needed and I wasn't espousing that it would - we know by definition that the domain that mucked with a URI is the domain associated with the URI that was overwritten/lost, etc. [/MB] =09 /Hans Erik van Elburg =09 =09 =09 ---remainder of theread snipped by Mary. -------- =09 From AUDET@nortel.com Sat Mar 14 08:10:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8F43A6801 for ; Sat, 14 Mar 2009 08:10:19 -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=-0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbNnHFSY2gy3 for ; Sat, 14 Mar 2009 08:10:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5C5503A683F for ; Sat, 14 Mar 2009 08:10:17 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2EFArH10140; Sat, 14 Mar 2009 15:10:54 GMT Received: from 47.103.119.44 ([47.103.119.44]) by zrc2hxm0.corp.nortel.com ([47.103.119.44]) with Microsoft Exchange Server HTTP-DAV ; Sat, 14 Mar 2009 15:10:52 +0000 References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com> <9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com> <9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com> <9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> Message-ID: <2FF31840-FEF5-4AEE-8603-2F5BEF5A9AD8@nortel.com> From: "Francois Audet" To: "Hans Erik van Elburg" In-Reply-To: <9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> thread-topic: [Sip] Issue 3 - two tags (was RE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt thread-index: AcmktxCdKJ8o6KPyQY2LxTKNRuofYA== Content-Type: multipart/alternative; boundary="Apple-Mail-1-1038211793"; charset="iso-8859-1" MIME-Version: 1.0 (iPod Mail 5H11a) Date: Sat, 14 Mar 2009 08:10:48 -0700 Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (was RE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 15:10:19 -0000 --Apple-Mail-1-1038211793 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yeah, I tought about that too. Not sure how to handle it. On Mar 14, 2009, at 0:55, "Hans Erik van Elburg" wrote: > I just realised that there is an additional problem that makes it > even harder to do any distinction. > > A UA may register as a contact an AOR of another user or resource. > Effectively this causes the request to be forwarded to the other > user by overwriting the Request-URI. > > So the fact that the Request-URI was overwritten due to a location > lookup, doesn't tell you a bit about the nature of the rewrite. > > /Hans Erik van Elburg > > > On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes > wrote: > Responses below [MB]. > > ________________________________ > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Friday, March 13, 2009 4:17 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Elwell, John; sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > I guess you mean that you agree with John that such rule can not be > reliably construed. > [MB] Which rule? I fully agree we can discern the 3 cases as I > explained below. Per 16.5 (Determining Request Targets) in RFC 3261, > these are unique and recognized situations. The reason I refer to > loose > routing is that it's my understanding it is far more commonly used and > RFC 3261 doesn't even describe strict routing - it focuses on loose > routing and strict routing support is for 2543 backwards compatibility > as I understood. But, actually it makes no difference to History-Info > processing. The important thing really, is that you MUST tag the old > entry as you are doing the processing per 16.5 as that information is > lost by the time you get around to adding the next History-Info header > in section 16.6 ( Request Forwarding). I think one thing that might be > being missed in this thread is that I have been very careful to rely > explicitly on what is described in 16.5 - that a must read to > understand > what I am saying - again there is a lack of clarity in that section > and > we can suggest clarifications once we all can finally agree > appropriate > terms. If you'd like me to pull the explicit text that supports > everything I've been saying, I can do so, but it's somewhat a waste of > time. [/MB] > > I dont think I have seen convincing proof that such is the case. > [MB] And, I'm not saying that you can't construct such a rule - > indeed I > am saying that you certainly should be able to per RFC 3261 section > 16.5. Can you point out what text below that suggests I am saying > that? > [/MB] > > Are you also saying that we may only consider loose routing being > used? > [MB] Nope. [/MB] > > Further for "configured mappings" for which we never saw a proper > definition. But assuming that this is a proxy that can be configured > to > do a Request-URI rewrite based on some configured setting. > [MB] The concept of "configured mappings" is described in RFC 3261 - > perhaps not with the level of granularity or specificity that some > might > desire, but it's there - it's initially described as an abstract > location service (1st Paragraph section 16.5). And, then later it > specifies that a proxy can determine "targets" (3261 term not mine) > just > about any ole way it wants, so I don't know that we need to define a > new > term for "configured mappings" per se - there is no limitation as to > the > mechanism one can use to determine the request-URI for the outgoing > request (once it is determined that the Proxy is ALLOWED to overwrite > the request-URI - the right domain, etc.), This is a fundamental SIP > concept that many products use to give a (human) user flexibility in > configuring where an incoming call might terminate. So, I see no issue > at all is specifying two tags to capture this rewrite as it's > already in > section 16.5 that this is information that a Proxy should be able to > derive. [/MB] > > In that case there are two variants of such mapping: > 1. A mapping that changes the identity of the target to be reached. > (This is what call forwarding or diversion does normally.) > 2. A mapping that only changes the next hop route taken towards the > target identity that has not been changed. > > For the UAS it only matters that the home domain does the tagging > consistently and correctly if it wants to rely on such information. > [MB] I don't know that I agree it's the home domain - it's a proxy > that > has responsibility for the domain in the request-URI that is able to > do > the service lookup or using any other sort of mapping to determine the > new URI for the request-URI in the outgoing request. I don't know > that > we want to restrict that to the "home" domain. If we restrict it to > the > home domain, then that implies that we are only tagging the entries > that > are determined based on service lookup in a Registrar (per RFC 3261's > definition of a "home domain"). [/MB] > > Otherwise we would have to start adding information about the domain > that added a specific hi-entry, if one wants to be sure who added the > particular hi-entry. > [MB] I'm not sure why this would be needed and I wasn't espousing that > it would - we know by definition that the domain that mucked with a > URI > is the domain associated with the URI that was overwritten/lost, etc. > [/MB] > > /Hans Erik van Elburg > > > > On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes > wrote: > > > Hi John, > > Thanks for all your feedback thus far on this topic. I have a > couple > comments below [MB]. > > Mary. > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Elwell, John > Sent: Friday, March 13, 2009 11:31 AM > To: Hans Erik van Elburg > > Cc: sip@ietf.org > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 13 March 2009 14:52 > > To: Elwell, John > > Cc: sip@ietf.org > > Subject: Re: [Sip] Issue 3 - two tags (was RE: > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > It knows when it rewrites the Request-URI due to a location > lookup --> > > > tag "aor". > > It knows (is configured to) when it rewrites the Request-URI > with a > > value that leads the request to target with a different > identity then > > the one that has been replaced --> tag new entry "istarget". > > It knows when it rewrites the Request-URI with a value and > this leads > > to the first History-Info entry being recorded --> tag > "istarget". > [JRE] It does not know that this is the first target, because > upstream > nodes may have retargeted without inserting H-I. In any case, > the To > header field URI is the first target, so we don't need that > anyway. > > [MB] John is correct. There is no rule about tagging the first > History-Info entry. It may be tagged if the next node changes > the > request-URI via a service lookup or some other manner such as > configuration.[/MB] > > > I can accept that a proxy might know, having done a LS look-up, > whether > the new URI is a registered contact or some other URI, and on > that basis > it could choose whether or not to insert a single tag. I > thought > that > was the basis on which we agreed to go ahead with this updated > to RFC > 4424, rather than following the loose route draft. It is not > clear to me > that a proxy would have enough information to make a 3-way > choice. > > [MB] My understanding is that there are just two ways in which > the > request-URI changes if you are using loose routing. It's either > changed > due to a lookup in a location server, whose information was > populated by > the UA during registration, OR it is changed due to > configuration data > (either system, user, etc.). In both cases, obviously, the > proxy > that is > doing this is responsible for the domain of the request-URI in > the > incoming request. If it were not the case, then all the proxy > can do is > forward the outgoing request to the next hop. So, I think that > may be > where the concept of a 3rd choice comes in. But, as far as > tagging, we > (as I understand it) at least were discussing the potential of > two tags > only - i.e., further differentiating the cases that are > currently all > captured by the "retarget" as defined in 4244bis, which is the > same > mechanism that is specified in the target-uri document EXCEPT > that > document was only capturing the service lookups, which we > believe is > incorrect. [/MB] > > > John > > > > > ---remainder of theread snipped by Mary. -------- > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-1-1038211793 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Yeah, I tought about that too. Not sure how to handle it.

On Mar 14, 2009, at 0:55, "Hans Erik van Elburg" <ietf.hanserik@gmail.com> wrote:

I just realised that there is an additional problem that makes it even harder to do any distinction.

A UA may register as a contact an AOR of another user or resource. Effectively this causes the request to be forwarded to the other user by overwriting the Request-URI.

So the fact that the Request-URI was overwritten due to a location lookup, doesn't tell you a bit about the nature of the rewrite.

/Hans Erik van Elburg


On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes <mary.barnes@nortel.com> wrote:
Responses below [MB].

________________________________

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Friday, March 13, 2009 4:17 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Elwell, John; sip@ietf.org
Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt


I guess you mean that you agree with John that such rule can not be
reliably construed.
[MB] Which rule?  I fully agree we can discern the 3 cases as I
explained below. Per 16.5 (Determining Request Targets) in RFC 3261,
these are unique and recognized situations. The reason I refer to loose
routing is that it's my understanding it is far more commonly used and
RFC 3261 doesn't even describe strict routing - it focuses on loose
routing and strict routing support is for 2543 backwards compatibility
as I understood. But, actually it makes no difference to History-Info
processing.  The important thing really, is that you MUST tag the old
entry as you are doing the processing per 16.5 as that information is
lost by the time you get around to adding the next History-Info header
in section 16.6 ( Request Forwarding). I think one thing that might be
being missed in this thread is that I have been very careful to rely
explicitly on what is described in 16.5 - that a must read to understand
what I am saying - again there is a lack of clarity in that section and
we can suggest clarifications once we all can finally agree appropriate
terms. If you'd like me to pull the explicit text that supports
everything I've been saying, I can do so, but it's somewhat a waste of
time. [/MB]

I dont think I have seen convincing proof that such is the case.
[MB] And, I'm not saying that you can't construct such a rule - indeed I
am saying that you certainly should be able to per RFC 3261 section
16.5.  Can you point out what text below that suggests I am saying that?
[/MB]

Are you also saying that we may only consider loose routing being used?
[MB] Nope. [/MB]

Further for "configured mappings" for which we never saw a proper
definition. But assuming that this is a proxy that can be configured to
do a Request-URI  rewrite based on some configured setting.
[MB] The concept of "configured mappings" is described in RFC 3261 -
perhaps not with the level of granularity or specificity that some might
desire, but it's there - it's initially described as an abstract
location service (1st Paragraph section 16.5).  And, then later it
specifies that a proxy can determine "targets" (3261 term not mine) just
about any ole way it wants, so I don't know that we need to define a new
term for "configured mappings" per se - there is no limitation as to the
mechanism one can use to determine the request-URI for the outgoing
request (once it is determined that the Proxy is ALLOWED  to overwrite
the request-URI - the right domain, etc.),  This is a fundamental SIP
concept that many products use to give a (human) user flexibility in
configuring where an incoming call might terminate. So, I see no issue
at all is specifying two tags to capture this rewrite as it's already in
section 16.5 that this is information that a Proxy should be able to
derive. [/MB]

In that case there are two variants of such mapping:
1. A mapping that changes the identity of the target to be reached.
(This is what call forwarding or diversion does normally.)
2. A mapping that only changes  the next hop route taken towards the
target identity that has not been changed.

For the UAS it only matters that the home domain does the tagging
consistently and correctly if it wants to rely on such information.
[MB] I don't know that I agree it's the home domain - it's a proxy that
has responsibility for the domain in the request-URI that is able to do
the service lookup or using any other sort of mapping to determine the
new URI for the request-URI in the outgoing request.  I don't know that
we want to restrict that to the "home" domain. If we restrict it to the
home domain, then that implies that we are only tagging the entries that
are determined based on service lookup in a Registrar (per RFC 3261's
definition of a "home domain").  [/MB]

Otherwise we would have to start adding information about the domain
that added a specific hi-entry, if one wants to be sure who added the
particular hi-entry.
[MB] I'm not sure why this would be needed and I wasn't espousing that
it would - we know by definition that the domain that mucked with a URI
is the domain associated with the URI that was overwritten/lost, etc.
[/MB]

/Hans Erik van Elburg



On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes <mary.barnes@nortel.com>
wrote:


       Hi John,

       Thanks for all your feedback thus far on this topic. I have a
couple
       comments below [MB].

       Mary.


       -----Original Message-----
       From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
Behalf Of

       Elwell, John
       Sent: Friday, March 13, 2009 11:31 AM
       To: Hans Erik van Elburg

       Cc: sip@ietf.org
       Subject: Re: [Sip] Issue 3 - two tags (was RE:
       I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt




       > -----Original Message-----
       > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
       > Sent: 13 March 2009 14:52
       > To: Elwell, John
       > Cc: sip@ietf.org
       > Subject: Re: [Sip] Issue 3 - two tags (was RE:
       > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
       >
       > It knows when it rewrites the Request-URI due to a location
lookup -->

       > tag "aor".
       > It knows (is configured to) when it rewrites the Request-URI
with a
       > value that leads the request to target with a different
identity then
       > the one that has been replaced --> tag new entry "istarget".
       > It knows when it rewrites the Request-URI with a value and
this leads
       > to the first History-Info entry being recorded --> tag
"istarget".
       [JRE] It does not know that this is the first target, because
upstream
       nodes may have retargeted without inserting H-I. In any case,
the To
       header field URI is the first target, so we don't need that
anyway.

       [MB] John is correct. There is no rule about tagging the first
       History-Info entry. It may be tagged if the next node changes
the
       request-URI via a service lookup or some other manner such as
       configuration.[/MB]


       I can accept that a proxy might know, having done a LS look-up,
whether
       the new URI is a registered contact or some other URI, and on
that basis
       it could choose whether or not to insert a single tag. I thought
that
       was the basis on which we agreed to go ahead with this updated
to RFC
       4424, rather than following the loose route draft. It is not
clear to me
       that a proxy would have enough information to make a 3-way
choice.

       [MB] My understanding is that there are just two ways in which
the
       request-URI changes if you are using loose routing. It's either
changed
       due to a lookup in a location server, whose information was
populated by
       the UA during registration, OR it is changed due to
configuration data
       (either system, user, etc.). In both cases, obviously, the proxy
that is
       doing this is responsible for the domain of the request-URI in
the
       incoming request. If it were not the case, then all the proxy
can do is
       forward the outgoing request to the next hop. So, I think that
may be
       where the concept of a 3rd choice comes in. But, as far as
tagging, we
       (as I understand it) at least were discussing the potential of
two tags
       only - i.e., further differentiating the cases that are
currently all
       captured by the "retarget" as defined in 4244bis, which is the
same
       mechanism that is specified in the target-uri document EXCEPT
that
       document was only capturing the service lookups, which we
believe is
       incorrect. [/MB]


       John


       >
---remainder of theread snipped by Mary. --------

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--Apple-Mail-1-1038211793-- From christer.holmberg@ericsson.com Sat Mar 14 16:54:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EEA33A6A48 for ; Sat, 14 Mar 2009 16:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.734 X-Spam-Level: X-Spam-Status: No, score=-5.734 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpD3ITAsFfQt for ; Sat, 14 Mar 2009 16:54:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9BA6D3A6950 for ; Sat, 14 Mar 2009 16:54:26 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 922BF20331; Sun, 15 Mar 2009 00:54:54 +0100 (CET) X-AuditID: c1b4fb3e-ac09abb0000023da-50-49bc43ce448e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5873420054; Sun, 15 Mar 2009 00:54:54 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Mar 2009 00:54:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Mar 2009 00:50:16 +0100 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1CDCB4C4@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 3 - two tags (wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: Acmkei8qLAHgu2URQ8aFrPem9+QLcQAOLZ0gABME++A= References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com><9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com><9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CDCB4C4@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Hans Erik van Elburg" , X-OriginalArrivalTime: 14 Mar 2009 23:54:54.0120 (UTC) FILETIME=[457D6A80:01C9A500] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Issue 3 - two tags (wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 23:54:28 -0000 When someone is calling the AOR, it will be replaced with the registered contact. Does it matter is someone else registered the contact/AOR? The call is not for that someone. Regards, Christer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Saturday, March 14, 2009 4:47 PM To: Hans Erik van Elburg; sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Correct, you don't know anything about the URI that overwrites the request-URI. BUT, you know the type of URI that was overwritten (with respect to how it is used at the incoming Proxy). You know that the request URI that was overwritten was one of the types we've been discussing - i.e., a URI that can be used for a service Lookup in a Registrar, whether that URI is mapped, configured, etc. or whether that URI is just for a proxy hop - i.e., it's not a URI for which the proxy is responsible. And, you are using that tag against the URI that is being overwritten. =20 Mary.=20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: Saturday, March 14, 2009 2:55 AM To: sip@ietf.org List Subject: Re: [Sip] Issue 3 - two tags (was RE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I just realised that there is an additional problem that makes it even harder to do any distinction. A UA may register as a contact an AOR of another user or resource. Effectively this causes the request to be forwarded to the other user by overwriting the Request-URI. So the fact that the Request-URI was overwritten due to a location lookup, doesn't tell you a bit about the nature of the rewrite. /Hans Erik van Elburg On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes wrote: Responses below [MB]. =09 ________________________________ =09 From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] =09 Sent: Friday, March 13, 2009 4:17 PM =09 To: Barnes, Mary (RICH2:AR00) =09 Cc: Elwell, John; sip@ietf.org =09 Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt =09 =09 =09 I guess you mean that you agree with John that such rule can not be reliably construed. =09 [MB] Which rule? I fully agree we can discern the 3 cases as I explained below. Per 16.5 (Determining Request Targets) in RFC 3261, these are unique and recognized situations. The reason I refer to loose routing is that it's my understanding it is far more commonly used and RFC 3261 doesn't even describe strict routing - it focuses on loose routing and strict routing support is for 2543 backwards compatibility as I understood. But, actually it makes no difference to History-Info processing. The important thing really, is that you MUST tag the old entry as you are doing the processing per 16.5 as that information is lost by the time you get around to adding the next History-Info header in section 16.6 ( Request Forwarding). I think one thing that might be being missed in this thread is that I have been very careful to rely explicitly on what is described in 16.5 - that a must read to understand what I am saying - again there is a lack of clarity in that section and we can suggest clarifications once we all can finally agree appropriate terms. If you'd like me to pull the explicit text that supports everything I've been saying, I can do so, but it's somewhat a waste of time. [/MB] =09 I dont think I have seen convincing proof that such is the case. =09 [MB] And, I'm not saying that you can't construct such a rule - indeed I am saying that you certainly should be able to per RFC 3261 section 16.5. Can you point out what text below that suggests I am saying that? [/MB] =09 Are you also saying that we may only consider loose routing being used? =09 [MB] Nope. [/MB] =09 Further for "configured mappings" for which we never saw a proper definition. But assuming that this is a proxy that can be configured to do a Request-URI rewrite based on some configured setting. =09 [MB] The concept of "configured mappings" is described in RFC 3261 - perhaps not with the level of granularity or specificity that some might desire, but it's there - it's initially described as an abstract location service (1st Paragraph section 16.5). And, then later it specifies that a proxy can determine "targets" (3261 term not mine) just about any ole way it wants, so I don't know that we need to define a new term for "configured mappings" per se - there is no limitation as to the mechanism one can use to determine the request-URI for the outgoing request (once it is determined that the Proxy is ALLOWED to overwrite the request-URI - the right domain, etc.), This is a fundamental SIP concept that many products use to give a (human) user flexibility in configuring where an incoming call might terminate. So, I see no issue at all is specifying two tags to capture this rewrite as it's already in section 16.5 that this is information that a Proxy should be able to derive. [/MB] =09 In that case there are two variants of such mapping: 1. A mapping that changes the identity of the target to be reached. (This is what call forwarding or diversion does normally.) 2. A mapping that only changes the next hop route taken towards the target identity that has not been changed. =09 For the UAS it only matters that the home domain does the tagging consistently and correctly if it wants to rely on such information. =09 [MB] I don't know that I agree it's the home domain - it's a proxy that has responsibility for the domain in the request-URI that is able to do the service lookup or using any other sort of mapping to determine the new URI for the request-URI in the outgoing request. I don't know that we want to restrict that to the "home" domain. If we restrict it to the home domain, then that implies that we are only tagging the entries that are determined based on service lookup in a Registrar (per RFC 3261's definition of a "home domain"). [/MB] =09 Otherwise we would have to start adding information about the domain that added a specific hi-entry, if one wants to be sure who added the particular hi-entry. =09 [MB] I'm not sure why this would be needed and I wasn't espousing that it would - we know by definition that the domain that mucked with a URI is the domain associated with the URI that was overwritten/lost, etc. [/MB] =09 /Hans Erik van Elburg =09 =09 =09 ---remainder of theread snipped by Mary. -------- =09 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From ietf.hanserik@gmail.com Sun Mar 15 12:23:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CEA28C123 for ; Sun, 15 Mar 2009 12:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2zWhB7sbTIT for ; Sun, 15 Mar 2009 12:23:31 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 73E6628C0FF for ; Sun, 15 Mar 2009 12:23:31 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 25so836967eya.31 for ; Sun, 15 Mar 2009 12:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=sZRffXHBQDbXf0mzzb2tw/thh1s5/l95QvvPMQhxTi0=; b=aVp4k8pChWEqpW413WaLZiwsjEY8tpVakN2lA1hE8bj4J2b9zvKSUPQOmnUqW8pBAw BK9eRzNwmQAoglod3y/daSBUmpIvMFvfGg1oPcfl/g4XIG4l7MAFFz8bX9inWoW/1d38 6tXDLlu+a532R9aTMk32X6M2v43n5rOUKxGHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qbwft7bb8llKLp8KOoXcSJ546sBvnKJPEHaTXf5NcHj180HRSDd1hg9Zy7idN4V7Mj Ld6G59Kcyt0NcPe9b8PR00L31pveKLzQ3b1Q4/eLt1Yx3mkgy8wpIIpK5ufDO7LHGaQ2 m1nZmrGTTOsp57lhupPoYCJ4UbhYMrWG4mKDs= Received: by 10.216.35.204 with SMTP id u54mr1526789wea.182.1237145051638; Sun, 15 Mar 2009 12:24:11 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id c5sm8158464nfi.28.2009.03.15.12.24.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Mar 2009 12:24:11 -0700 (PDT) Message-ID: <49BD55DA.20301@gmail.com> Date: Sun, 15 Mar 2009 20:24:10 +0100 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Christer Holmberg References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com><9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com><9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CDCB4C4@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 19:23:32 -0000 The point is that the registered contact could be an AOR of another user. /Hans Erik Christer Holmberg wrote: > When someone is calling the AOR, it will be replaced with the registered > contact. Does it matter is someone else registered the contact/AOR? The > call is not for that someone. > > Regards, > > Christer > > From christer.holmberg@ericsson.com Sun Mar 15 13:29:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CE928C0E5 for ; Sun, 15 Mar 2009 13:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.739 X-Spam-Level: X-Spam-Status: No, score=-5.739 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SynM5eahDLGz for ; Sun, 15 Mar 2009 13:29:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 927023A685C for ; Sun, 15 Mar 2009 13:29:25 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3C6212102D; Sun, 15 Mar 2009 21:30:05 +0100 (CET) X-AuditID: c1b4fb3e-ad89dbb0000023da-cd-49bd654df286 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 216E52005C; Sun, 15 Mar 2009 21:30:05 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Mar 2009 21:30:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Mar 2009 21:30:04 +0100 Message-ID: In-Reply-To: <49BD55DA.20301@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 3 - two tags (wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Thread-Index: Acmlo57/Cl09H08yQ42CXpJrOZYVDQACOeeg References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com><9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com><9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CDCB4C4@zrc2hxm0.corp.nortel.com> <49BD55DA.20301@gmail.com> From: "Christer Holmberg" To: "Hans Erik van Elburg" X-OriginalArrivalTime: 15 Mar 2009 20:30:04.0959 (UTC) FILETIME=[D2FE02F0:01C9A5AC] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 20:29:26 -0000 Hi,=20 >The point is that the registered contact could be an AOR of another user. Ok, now I understand. Yes, that is an interesting case, eventhough I guess it's really not the correct usage of the registration procedure. Regards, Christer /Hans Erik Christer Holmberg wrote: > When someone is calling the AOR, it will be replaced with the=20 > registered contact. Does it matter is someone else registered the=20 > contact/AOR? The call is not for that someone. > > Regards, > > Christer > > =20 From dean.willis@softarmor.com Sun Mar 15 18:03:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19373A6B55 for ; Sun, 15 Mar 2009 18:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGZxSGExTsfv for ; Sun, 15 Mar 2009 18:03:19 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DFC1F3A67E7 for ; Sun, 15 Mar 2009 18:03:18 -0700 (PDT) Received: from [192.168.2.2] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2G13qqX007219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Mar 2009 20:03:53 -0500 Message-ID: <49BDA572.1050808@softarmor.com> Date: Sun, 15 Mar 2009 20:03:46 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Christer Holmberg References: <899F1518-6872-442E-AD3E-D3F343A605DC@ntt-at.com><9ae56b1e0903121425j760fc6aeyf181bca65f803fe4@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A281EF@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130733k135db506lf3a134e1406d44d0@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A28210@GBNTHT12009MSX.gb002.siemens.net><9ae56b1e0903130751i5c9718abwbd44a6371130d258@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D001A2832E@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1CDCAC9E@zrc2hxm0.corp.nortel.com><9ae56b1e0903131417q75a0f630u70df2929324cef7d@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF1CDCB21A@zrc2hxm0.corp.nortel.com><9ae56b1e0903140054l467fcd8eu50676ea31c914734@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1CDCB4C4@zrc2hxm0.corp.nortel.com> <49BD55DA.20301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] Issue 3 - two tags (wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 01:03:20 -0000 Christer Holmberg wrote: > Hi, > >> The point is that the registered contact could be an AOR of another > user. > > Ok, now I understand. Yes, that is an interesting case, eventhough I > guess it's really not the correct usage of the registration procedure. > Any contact could be an AOR, not a final destination, in that any UA could also decide to become a proxy and send the call somewhere else. Such a determination might be made on a call-by-call basis. In such case, two possibilities apply: 1) the transformation is a reroute, in that the identity of the target is not being changed, just the location at which that target is being sought. 2) The transformation is a retarget, in that the identity of the target is being sought after the transformation is different than the identity being sought before the transformation. Of course, it is possible for a proxy making such a transformation to not know the identity of the target. In such a case, it is impossible for the proxy to inform the UAC of the transformation and thereby avoid an unanticipated respondent scenario. This is the world we live in for ALL proxy operations today, and it has its drawbacks. -- Dean From rco@iptel.org Mon Mar 16 02:45:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AEB3A698E for ; Mon, 16 Mar 2009 02:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQs85r0H9HYF for ; Mon, 16 Mar 2009 02:45:45 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E6E063A6A6F for ; Mon, 16 Mar 2009 02:45:44 -0700 (PDT) Received: by mail.iptel.org (Postfix, from userid 103) id A1EB51810C68; Mon, 16 Mar 2009 10:46:25 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 7AC3F1810C68; Mon, 16 Mar 2009 10:46:24 +0100 (CET) Message-ID: <49BE1FEF.4020008@iptel.org> Date: Mon, 16 Mar 2009 10:46:23 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jonathan Rosenberg References: <49AE593F.6080807@iptel.org> <49BBA27C.4050805@cisco.com> In-Reply-To: <49BBA27C.4050805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 09:45:46 -0000 Jonathan Rosenberg wrote: > Raphael and others, > > Thanks for putting this together. > > Considering for a moment figure 1, this attack is possible only if UAs > accept incoming requests from any place, and not just their proxy. In > practice, this is seldom allowed. Indeed, if it is allowed, there are > worse attacks than this which can be launched (free phone calls, spam > calling, etc.). Using the SIP recommended TLS between UA and proxy > also mitigates that. > That's right, and also the reason we called this the basic attack. Using TLS would be indeed a good choice, unfortunately, only few providers do offer it to their customers (but of course, only for the small panel I know of, and those I use). > So really figure 2 is the interesting one. However, this attack > assumes that Alice has credentials on multiple systems. Again, in > practice, this is extremely uncommon. Certainly none of the existing > deployed enterprise or service provider consumer deployments are of > this nature. I understand that this might not be a common case, as the common case is more focused on a vonage (or alike) customer, receiving a ready-configured phone that just has to be pluged into the residential gateway. However, a lot of SIP freaks like us do have a lot of configured accounts on the same phone, and not only for test purposes. For my part, my home phone is connected with 3 accounts: one default (PSTN), my iptel.org account, and another provider that own one of our PSTN numbers (only inbound). I have seen one year ago an application for a residential gateway implementing a SIP least cost router. It was available as an unofficial upgrade for a very popular type of resential gateway. In the case, the configuration was at its minimum: all the required config was downloaded by the least cost router application. All you had to do was to create some accounts at some PSTN provider, and configure them into the box, which would do the rest. I can believe that this kind of application could become more popular, just like they were in the PSTN. > > > As such, I dont think this attack is likely in practice. However, in > theory it is possible. The essence of the attack is that the victim is > providing credentials to an unauthenticated server (since the attacker > is acting like a server, asking for credentials). In that way, as > others have pointed out, it is similar to baiting attacks that have > been previously documented. With SIP it is most easily remedied by a > rule which says, 'don't pass credentials for domain X to a server that > is not domain X'. Which means that you exclude any relays in between. I think it also implies reverse DNS lookups, right? > Server identity can be verified by normal server-only auth between a > client and its server, but even that is not needed. Right, mutual authentication seems to be the best way. > A client will know which domain its proxy is representing, and once > connected, it only provides credentials for that domain. > What do you mean by "connected"? And why should a UA only provide credentials for one domain only? Is that about TCP or SCTP connections? and providing only credentials for a particular domain on a particular connection? -Raphael. From drage@alcatel-lucent.com Mon Mar 16 04:33:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431A73A6A62 for ; Mon, 16 Mar 2009 04:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Laqn9cX7yuXH for ; Mon, 16 Mar 2009 04:33:20 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 30C8B3A681C for ; Mon, 16 Mar 2009 04:33:19 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2GBXxfF031388 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Mar 2009 12:33:59 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 16 Mar 2009 12:33:59 +0100 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Mon, 16 Mar 2009 12:33:58 +0100 Thread-Topic: WGLC for draft-ietf-sip-location-conveyance Thread-Index: AcmmKxiopQ/kVxMlTgGAHR0pJwMi3A== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6756ADFD1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "draft-ietf-sip-location-conveyance@tools.ietf.org" Subject: [Sip] WGLC for draft-ietf-sip-location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 11:33:21 -0000 (As WG chair) This is to initiate a WGLC for comments on draft-ietf-sip-location-conveyan= ce http://tools.ietf.org/id/draft-ietf-sip-location-conveyance-13.txt as proposed standard. This is a one week WGLC and therefore please supply your comments by close = of Monday 23rd March 2009. While we acknowledge this may interrupt your reading for the forthcoming IE= TF meeting, please add this to your reading list and comment. We will take steps to see that people have actually read this and are eithe= r OK or not, so if you do so read it, please send an email to the chairs in= dicating this, even if you have no comments. If necessary we will go for a = further period of WGLC after the meeting, but to be honest, we'd rather avo= id this and get this somewhat aged document out of the door. Comments obviously to the list and editors, and it would help if you give t= he proposed correction (or even some hint of it) along with the change. regards Keith= From jdrosen@cisco.com Mon Mar 16 13:45:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C826F3A6AB3 for ; Mon, 16 Mar 2009 13:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmOHOaxh3h6S for ; Mon, 16 Mar 2009 13:45:22 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BAE323A6987 for ; Mon, 16 Mar 2009 13:45:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,374,1233532800"; d="scan'208";a="143153113" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2009 20:46:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2GKk5K8009426; Mon, 16 Mar 2009 13:46:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2GKk5p7013358; Mon, 16 Mar 2009 20:46:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 13:46:05 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 13:46:04 -0700 Message-ID: <49BEBA8C.2020406@cisco.com> Date: Mon, 16 Mar 2009 16:46:04 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Raphael Coeffic References: <49AE593F.6080807@iptel.org> <49BBA27C.4050805@cisco.com> <49BE1FEF.4020008@iptel.org> In-Reply-To: <49BE1FEF.4020008@iptel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2009 20:46:04.0802 (UTC) FILETIME=[39842E20:01C9A678] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2175; t=1237236365; x=1238100365; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20draft-state-sip-relay-attack-00 |Sender:=20; bh=PJEJVPr0jg8c3KDcE9Or+oVHTxXXMGYcXJdOL2oTLWg=; b=UgzF2i5OO1cfTs1Gp3n44vOvPZXEAoH3X1YfVrO3kRw1vayknL7BkzgKyk 6EWE3lESoRLYH7rRmHIFxg5pssV6BX0pF2chfjoH0OfWVe8Hi1khbdiaK4BZ +G17gKNLlX2OIUHMfXi55f/8VV2uw4OR96wr0Nz7v5zONoCsOrsdg=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 20:45:23 -0000 Raphael Coeffic wrote: >> As such, I dont think this attack is likely in practice. However, in >> theory it is possible. The essence of the attack is that the victim is >> providing credentials to an unauthenticated server (since the attacker >> is acting like a server, asking for credentials). In that way, as >> others have pointed out, it is similar to baiting attacks that have >> been previously documented. With SIP it is most easily remedied by a >> rule which says, 'don't pass credentials for domain X to a server that >> is not domain X'. > Which means that you exclude any relays in between. I think it also > implies reverse DNS lookups, right? No - no reverse DNS. And I am excluding cases where, you are connected (meaning, the domain you registered to) to one domain and making a call through that domain reach another domain which requires your credentials. I think that is very unlikely. > >> Server identity can be verified by normal server-only auth between a >> client and its server, but even that is not needed. > Right, mutual authentication seems to be the best way. > >> A client will know which domain its proxy is representing, and once >> connected, it only provides credentials for that domain. >> > What do you mean by "connected"? And why should a UA only provide > credentials for one domain only? I'm saying, when a phone registers or makes a call, it does so by connecting to a SIP server, through a domain name or IP config or whatever. THat server will have an associated credential. For any request sent to that server, it should never provide a credential except the one associated with it. Your attack is possible only when the client sends credentials for a domain, different than the one it is currently registered or placed the call through in the first place. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From jmpolk@cisco.com Mon Mar 16 13:52:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9380B3A6C16 for ; Mon, 16 Mar 2009 13:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnsM04EinX+G for ; Mon, 16 Mar 2009 13:52:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AB3423A6C15 for ; Mon, 16 Mar 2009 13:52:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,374,1233532800"; d="scan'208";a="142387627" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2009 20:53:22 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2GKrLpc007482 for ; Mon, 16 Mar 2009 13:53:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2GKrLFX022768 for ; Mon, 16 Mar 2009 20:53:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 13:53:21 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.16.37]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 13:53:20 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Mar 2009 15:53:19 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2009 20:53:21.0098 (UTC) FILETIME=[3D91AAA0:01C9A679] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=651; t=1237236801; x=1238100801; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20New=20rev=20of=20Location=20Conveyance=20(to=20 -13) |Sender:=20; bh=jLiDuEFXtnggIYn4Ny8/axxMchg/Le/Jh7LHxGorqMM=; b=d0lmJG/4Y64o/ULAHPSklJ4pD5w0ZdSph40YR1UFNlFqMIU3ZTs56vxj6s q/Hkh2LT6GmZfTLWc6RUpmgwdFT0Asaf9zCFh3KX2zcCY3eG6jXufmDS8sHC R41cyQJnTP; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Sip] New rev of Location Conveyance (to -13) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 20:52:40 -0000 SIP I've revved Location Conveyance, which the chairs just announced a 1 week WGLC for it. I would appreciate some reviews, even just giving this doc a thumbs up (to the list of course). http://tools.ietf.org/id/draft-ietf-sip-location-conveyance-13.txt The changes are slight, and only centered on one topic, which is the text surrounding the Geolocation header's ABNF wrt the placement of the "routing-allowed" header parameter. I made the text consistent with the The diff is here http://tools.ietf.org/wg/sip/draft-ietf-sip-location-conveyance/draft-ietf-sip-location-conveyance-13-from-12.diff.html Thanks James From lists@ohlmeier.org Mon Mar 16 15:00:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6D23A659B for ; Mon, 16 Mar 2009 15:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3zLIfH8fe7x for ; Mon, 16 Mar 2009 15:00:18 -0700 (PDT) Received: from bespin.rfc3261.net (cl-395.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:18a::2]) by core3.amsl.com (Postfix) with ESMTP id 80AC23A680A for ; Mon, 16 Mar 2009 15:00:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bespin.rfc3261.net (Postfix) with ESMTP id D88207F97; Mon, 16 Mar 2009 23:00:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bespin.rfc3261.net Received: from bespin.rfc3261.net ([127.0.0.1]) by localhost (bespin.rfc3261.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP5hHg1u1lSr; Mon, 16 Mar 2009 23:00:58 +0100 (CET) Received: from Nils-MacBook-2.local (unknown [78.52.229.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bespin.rfc3261.net (Postfix) with ESMTPSA id 741547F82; Mon, 16 Mar 2009 23:00:58 +0100 (CET) Message-ID: <49BECC19.9080704@ohlmeier.org> Date: Mon, 16 Mar 2009 23:00:57 +0100 From: Nils Ohlmeier User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Jonathan Rosenberg References: <49AE593F.6080807@iptel.org> <49BBA27C.4050805@cisco.com> <49BE1FEF.4020008@iptel.org> <49BEBA8C.2020406@cisco.com> In-Reply-To: <49BEBA8C.2020406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 22:00:19 -0000 >>> Server identity can be verified by normal server-only auth between a >>> client and its server, but even that is not needed. >> Right, mutual authentication seems to be the best way. >> >>> A client will know which domain its proxy is representing, and once >>> connected, it only provides credentials for that domain. >>> >> What do you mean by "connected"? And why should a UA only provide >> credentials for one domain only? > > I'm saying, when a phone registers or makes a call, it does so by > connecting to a SIP server, through a domain name or IP config or > whatever. THat server will have an associated credential. For any > request sent to that server, it should never provide a credential except > the one associated with it. > > Your attack is possible only when the client sends credentials for a > domain, different than the one it is currently registered or placed the > call through in the first place. And the SIP server which relays the INVITE from the attacker to the victim has to drop (?) the challenge if it receives such from the attacker (at least if the realm is identical to the one used by the server itself). This is basically the same description which I provided already earlier. The only open "issue" is then relaying of 407/401 replies from downstream elements by the proxy. I agree with Jonathan that I also do not believe that this actually a real world scenario. But mutual authentication in the challenge might help to solve this issue if people insist of keeping this scenario. Regards Nils From marianne.mohali@orange-ftgroup.com Mon Mar 16 15:11:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B003A6B49 for ; Mon, 16 Mar 2009 15:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1ni+2IcQ-g5 for ; Mon, 16 Mar 2009 15:11:09 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id EEBD23A6B46 for ; Mon, 16 Mar 2009 15:11:08 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 23:11:17 +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: Mon, 16 Mar 2009 23:11:14 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026064C8CFC@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sAABMLoAAAAx1hAAA2O9MAACv+6wALvzPfA= References: <20090304151501.4951728C331@core3.amsl.com><1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com> From: To: , X-OriginalArrivalTime: 16 Mar 2009 22:11:17.0261 (UTC) FILETIME=[20C783D0:01C9A684] Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 22:11:10 -0000 Hi Mary and Fran=E7ois, I have a suggestion and few comments on the document. ** To make the History-Info header usefull for applications and services = interactions, it could be interesting to be able to include in the = hi-target-to-uri IARI and ICSC values as described in TS 24.229 (3GPP) = wich ar coded as URN. An example of an ICSI for a 3GPP defined IMS = communication service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel Do you think, this kind of enhancement for Histroy-Info header could be = added in the document ? ** Section 4.1: About Retarget (hi-target), it is indicated "A retarget = parameter is not added for a hi-entry when it is first added in a = History- Info header, but rather is added when the retargeting actually occurs". = It is indicated when the Retarget indication should be added but it = could be good to add an information on where the parameter should be = added (associated to the retargeting hi-targeted-to-uri). This is just = to be clear on the History-Info header structure.=20 I have the same comment for the Reason header escaped in the = History-Info. About that, there is an inconsistency between Reason = header associated to the retargeting URI and cause-param parameter = (RFC4458) associated to the retargeted-to URI. This should be corrected = in RFC4458 but I don't know if it is possible. ** Section 4.5.1 and following: in the call flows there is a "retarget" = parmeter inserted in the second INVITE by Proxy1 when sending the = request to Proxy2. In my understanding, it should only be added (in the = same place) by Proxy2 when retargeting the request to Bob. Did I miss = something ? ** Privacy: I also think that it should be recommended in the document = to use the Privacy header with the value "history" escaped in the = hi-entries rather than directly in the INVITE request. =20 Best Regards, Marianne From dean.willis@softarmor.com Mon Mar 16 15:56:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F7B3A6B24 for ; Mon, 16 Mar 2009 15:56:22 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65-qOpqcRJ7k for ; Mon, 16 Mar 2009 15:56:20 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C58553A6A26 for ; Mon, 16 Mar 2009 15:56:20 -0700 (PDT) Received: from [192.168.2.101] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2GMuvNm014113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 16 Mar 2009 17:57:02 -0500 Message-Id: From: Dean Willis To: "sip@ietf.org List" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Mar 2009 17:57:02 -0500 X-Mailer: Apple Mail (2.930.3) Subject: [Sip] Publication requested for draft-ietf-sip-record-route-fix-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 22:56:22 -0000 We have requested publication of this WG effort as a BCP. I'd like to thank Nils for volunteering to serve as the draft shepherd, and for preparing most of the writeup below. -- Dean Willis, SIP WG co-chair. Writeup follows: The SIP working group would like to request publication of draft-ietf- sip-record-route-fix-06. This is a product of the SIP working group and is intended for Best Current Practice status. Nils Ohlmeier will serve as the draft shepherd, supported by SIP working group chair Dean Willis. A write-up, prepared by Nils, is attached. [This template version is dated September 17, 2008.] (for draft-ietf-sip-record-route-fix-06) (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The Document Shepherd for this document is Nils Ohlmeier. I have read this version of the draft and believe it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has had in-depth reviews from working group members with no concerns. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? As the document describes a best current practice which is widely deployed and the document got several reviews there are no concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I believe the described technique should be documented and I have no concerns with the document. There have been no IPR disclosures for this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus appears to be strong. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No one has expressed any discontent with this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document shepherd has personally verified that this version of the document satisfies all of the ID nits, bar a warning about legal boilerplate about pre-RFC5378 work. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has been split into normative and informative references. All normative references are stable. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? This document has an IANA considerations section with no actions for the IANA, which matches the body of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? SIP messages in examples have been manually checked and appear to be valid. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Multi-homed SIP proxies (having two or more interfaces) raise special requirements when handling SIP requests that have different ingress and egress interfaces. One technique that has been widely deployed is to insert a single Record-Route header describing the egress interface. When another request in the same dialog then traverses the proxy in a reverse direction, the proxy must edit the headers to reflect the new egress interface. This document formalizes another technique that has also been widely deployed and found to be simpler and more effective. Using this technique, the proxy inserts two record-route headers, one for the ingress interface and one for the egress interface. This keeps the route symmetric, such that it can be traversed in the reverse direction without requiring examination and editing by the proxy, thereby reducing system complexity and processing load in the proxy. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The biggest discussion around this document was which status this document should get. The working group decided to target for Best Current Practice and against a normative update of RFC3261. Work on this document began in March 2007 and the WGLC was held in July 2008. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document specifically addresses an area of SIP that has been an interoperability problem in the past. The SIPit interoperability events have seen many problems in the area of Record-Route handling in multi homed scenarios (including traversal between different sub networks and changes of transport or IP protocol). The described technique is widely deployed in several SIP proxies already. This document has been reviewed by many participants over the lifetime of the document, by the following members of the WG: - Francois Audet - Jonathan Rosenberg - Cullen Jennings - Paul Kyzivat - Robert Sparks - Nils Ohlmeier From drage@alcatel-lucent.com Mon Mar 16 16:54:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38833A691A for ; Mon, 16 Mar 2009 16:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDP39EQ-a6un for ; Mon, 16 Mar 2009 16:54:17 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 838193A6829 for ; Mon, 16 Mar 2009 16:54:16 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2GNsvw9023733 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Mar 2009 00:54:57 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 17 Mar 2009 00:54:57 +0100 From: "DRAGE, Keith (Keith)" To: "marianne.mohali@orange-ftgroup.com" , "mary.barnes@nortel.com" , "audet@nortel.com" Date: Tue, 17 Mar 2009 00:54:55 +0100 Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sAABMLoAAAAx1hAAA2O9MAACv+6wALvzPfAAG/o9cA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6756AE219@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <20090304151501.4951728C331@core3.amsl.com><1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com> <7DBAFEC6A76F3E42817DF1EBE64CB026064C8CFC@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026064C8CFC@ftrdmel2> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sip@ietf.org" Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 23:54:18 -0000 You wrote: > ** To make the History-Info header usefull for applications=20 > and services interactions, it could be interesting to be able=20 > to include in the hi-target-to-uri IARI and ICSC values as=20 > described in TS 24.229 (3GPP) wich ar coded as URN. An=20 > example of an ICSI for a 3GPP defined IMS communication=20 > service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel > Do you think, this kind of enhancement for Histroy-Info=20 > header could be added in the document ? Question: What have these values to do with the history of a retargetting? Keith=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of marianne.mohali@orange-ftgroup.com > Sent: Monday, March 16, 2009 10:11 PM > To: mary.barnes@nortel.com; audet@nortel.com > Cc: sip@ietf.org > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt >=20 >=20 > Hi Mary and Fran=E7ois, >=20 > I have a suggestion and few comments on the document. >=20 > ** To make the History-Info header usefull for applications=20 > and services interactions, it could be interesting to be able=20 > to include in the hi-target-to-uri IARI and ICSC values as=20 > described in TS 24.229 (3GPP) wich ar coded as URN. An=20 > example of an ICSI for a 3GPP defined IMS communication=20 > service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel > Do you think, this kind of enhancement for Histroy-Info=20 > header could be added in the document ? >=20 > ** Section 4.1: About Retarget (hi-target), it is indicated=20 > "A retarget parameter is not added for a hi-entry when it is=20 > first added in a History- > Info header, but rather is added when the retargeting=20 > actually occurs". It is indicated when the Retarget=20 > indication should be added but it could be good to add an=20 > information on where the parameter should be added=20 > (associated to the retargeting hi-targeted-to-uri). This is=20 > just to be clear on the History-Info header structure.=20 > I have the same comment for the Reason header escaped in the=20 > History-Info. About that, there is an inconsistency between=20 > Reason header associated to the retargeting URI and=20 > cause-param parameter (RFC4458) associated to the=20 > retargeted-to URI. This should be corrected in RFC4458 but I=20 > don't know if it is possible. >=20 > ** Section 4.5.1 and following: in the call flows there is a=20 > "retarget" parmeter inserted in the second INVITE by Proxy1=20 > when sending the request to Proxy2. In my understanding, it=20 > should only be added (in the same place) by Proxy2 when=20 > retargeting the request to Bob. Did I miss something ? >=20 > ** Privacy: I also think that it should be recommended in the=20 > document to use the Privacy header with the value "history"=20 > escaped in the hi-entries rather than directly in the INVITE=20 > request. =20 >=20 >=20 > Best Regards, > Marianne > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip > = From rco@iptel.org Tue Mar 17 02:48:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAFF53A67DA for ; Tue, 17 Mar 2009 02:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpVf8pQoAsFt for ; Tue, 17 Mar 2009 02:48:15 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 8A0533A697B for ; Tue, 17 Mar 2009 02:48:15 -0700 (PDT) Received: by mail.iptel.org (Postfix, from userid 103) id 4083B18111E4; Tue, 17 Mar 2009 10:48:57 +0100 (CET) Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 2B1A81810BFB; Tue, 17 Mar 2009 10:48:56 +0100 (CET) Message-ID: <49BF7207.5080709@iptel.org> Date: Tue, 17 Mar 2009 10:48:55 +0100 From: Raphael Coeffic User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Nils Ohlmeier References: <49AE593F.6080807@iptel.org> <49BBA27C.4050805@cisco.com> <49BE1FEF.4020008@iptel.org> <49BEBA8C.2020406@cisco.com> <49BECC19.9080704@ohlmeier.org> In-Reply-To: <49BECC19.9080704@ohlmeier.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 09:48:16 -0000 Nils, Jonathan, You may be aware of it or not, however, we have already implemented this scenario at iptel.org. This is because iptel.org does not have any own PSTN gateway. In this case, the user can configure a PSTN gateway he whishes to use when such a number is dialed. We implemented like this to cope with all the low-end phones that do not provide multiple accounts, or do not offer a convenient way for the user to provide routing rules. Even cisco and snom phones (at least those we have) are not able to select the outbound account on their own, based on the R-URI. On the other hand, this is very easy to offer at the proxy level, provided that my proxy does relay challenges and responses to the UA (in this case, the realm is different). So, as a conclusion, I do not think we are talking about theory, but about real existing applications. Of course, you could also store your other PSTN credentials at the proxy, and make it deal with the authentication for you. However, I'm quite sure you wouldn't be very confident about that, would you? Regards, Raphael. Nils Ohlmeier wrote: >>>> Server identity can be verified by normal server-only auth between a >>>> client and its server, but even that is not needed. >>> Right, mutual authentication seems to be the best way. >>> >>>> A client will know which domain its proxy is representing, and once >>>> connected, it only provides credentials for that domain. >>>> >>> What do you mean by "connected"? And why should a UA only provide >>> credentials for one domain only? >> >> I'm saying, when a phone registers or makes a call, it does so by >> connecting to a SIP server, through a domain name or IP config or >> whatever. THat server will have an associated credential. For any >> request sent to that server, it should never provide a credential except >> the one associated with it. >> >> Your attack is possible only when the client sends credentials for a >> domain, different than the one it is currently registered or placed the >> call through in the first place. > > And the SIP server which relays the INVITE from the attacker to the > victim has to drop (?) the challenge if it receives such from the > attacker (at least if the realm is identical to the one used by the > server itself). > > This is basically the same description which I provided already earlier. > > The only open "issue" is then relaying of 407/401 replies from > downstream elements by the proxy. I agree with Jonathan that I also do > not believe that this actually a real world scenario. But mutual > authentication in the challenge might help to solve this issue if > people insist of keeping this scenario. > > Regards > Nils From victor.pascual.avila@gmail.com Tue Mar 17 03:16:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F313A684C for ; Tue, 17 Mar 2009 03:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVZVbzc0DzIn for ; Tue, 17 Mar 2009 03:16:53 -0700 (PDT) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id CB6E128C136 for ; Tue, 17 Mar 2009 03:16:52 -0700 (PDT) Received: by ewy25 with SMTP id 25so3798183ewy.37 for ; Tue, 17 Mar 2009 03:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eX7xL7JZ/GGLDy5CJtjM54n7ORj4EwSzin69HvJuRCQ=; b=RVH3alOQdXsPpqp8ymWuz3RNtVculto1ga4FU7GHH6d/trlttnix5zr+7heNoKcrz9 ERPO4hmP5I3EOs5qIobXQn6V7yAXCHkSQjSeIGrXgpZQ/LrEZ72z+0rL7uru1S/751vw 4Gh5kXvZH2AdunBh1YAa5YsUgXf25aa8eZDJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V6kxzC8BM4d54mjvj/0IQYbwC9vxd63UJg3YDTph5EAXwyqKiT8fb6dGHSruVkodEb DNC5lC/ljWUebOiHQp0Ft1R8JNMbet2PJLgmWjOnG6XkjJOyESIPYkCShC+uqmMG/V5W tIDOPMYBt5glnQ1+p7vzXyloEQ6LMUCm7lZ9c= MIME-Version: 1.0 Received: by 10.210.13.17 with SMTP id 17mr4396227ebm.15.1237285055370; Tue, 17 Mar 2009 03:17:35 -0700 (PDT) In-Reply-To: <49BF7207.5080709@iptel.org> References: <49AE593F.6080807@iptel.org> <49BBA27C.4050805@cisco.com> <49BE1FEF.4020008@iptel.org> <49BEBA8C.2020406@cisco.com> <49BECC19.9080704@ohlmeier.org> <49BF7207.5080709@iptel.org> Date: Tue, 17 Mar 2009 11:17:35 +0100 Message-ID: <618e24240903170317s11aa5454ycfa0ab7b5708f10f@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Raphael Coeffic Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 10:16:54 -0000 On Tue, Mar 17, 2009 at 10:48 AM, Raphael Coeffic wrote: > You may be aware of it or not, however, we have already implemented this > scenario at iptel.org. This is because iptel.org does not have any own PS= TN > gateway. In this case, the user can configure a PSTN gateway he whishes t= o > use when such a number is dialed. We implemented like this to cope with a= ll > the low-end phones that do not provide multiple accounts, or do not offer= a > convenient way for the user to provide routing rules. I agree-- some terminating domains may require authentication. Indeed, this is defined in rfc3665 as a BCP. In Section 3.3 (Session with Multiple Proxy Authentication), Proxy 1 is relaying challenges and responses for different (sub)domains. > So, as a conclusion, I do not think we are talking about theory, but abou= t > real existing applications. Of course, you could also store your other PS= TN > credentials at the proxy, and make it deal with the authentication for yo= u. > However, I'm quite sure you wouldn't be very confident about that, would > you? Once again, IMHO this should be as much end-to-end as possible. Some folks are still using SIP as a protocol for the (open) Internet. Cheers, --=20 Victor Pascual =C3=81vila From marianne.mohali@orange-ftgroup.com Thu Mar 19 02:52:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02113A6A85 for ; Thu, 19 Mar 2009 02:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghl+Z+1Lmqld for ; Thu, 19 Mar 2009 02:52:51 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 9EF5C3A6AAB for ; Thu, 19 Mar 2009 02:52:50 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Mar 2009 10:53:34 +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, 19 Mar 2009 10:53:31 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026064FF116@ftrdmel2> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6756AE219@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sAABMLoAAAAx1hAAA2O9MAACv+6wALvzPfAAG/o9cAB4rjrA References: <20090304151501.4951728C331@core3.amsl.com><1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com><7DBAFEC6A76F3E42817DF1EBE64CB026064C8CFC@ftrdmel2> <28B7C3AA2A7ABA4A841F11217ABE78D6756AE219@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: To: X-OriginalArrivalTime: 19 Mar 2009 09:53:34.0195 (UTC) FILETIME=[912CE430:01C9A878] Cc: sip@ietf.org, audet@nortel.com, mary.barnes@nortel.com Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 09:52:52 -0000 Hi Keith, Let's just talk about IARI. My idea was just to suggest a trail to = improve History-Info. Before to create new things (headers or = parameters), we should look what is available and reusable. If it is not = conceivable to use IARI values in a History-Info header allowing a proxy = server to indicate what has been done in term of service, could you = please give a reason.=20 Best Regards, Marianne=20 -----Message d'origine----- De : DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Envoy=E9 : mardi 17 mars 2009 00:55 =C0 : MOHALI Marianne RD-CORE-ISS; mary.barnes@nortel.com; = audet@nortel.com Cc : sip@ietf.org Objet : RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt You wrote: > ** To make the History-Info header usefull for applications and=20 > services interactions, it could be interesting to be able to include=20 > in the hi-target-to-uri IARI and ICSC values as described in TS 24.229 = > (3GPP) wich ar coded as URN. An example of an ICSI for a 3GPP defined=20 > IMS communication service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel > Do you think, this kind of enhancement for Histroy-Info header could=20 > be added in the document ? Question: What have these values to do with the history of a = retargetting? Keith=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > marianne.mohali@orange-ftgroup.com > Sent: Monday, March 16, 2009 10:11 PM > To: mary.barnes@nortel.com; audet@nortel.com > Cc: sip@ietf.org > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt >=20 >=20 > Hi Mary and Fran=E7ois, >=20 > I have a suggestion and few comments on the document. >=20 > ** To make the History-Info header usefull for applications and=20 > services interactions, it could be interesting to be able to include=20 > in the hi-target-to-uri IARI and ICSC values as described in TS 24.229 = > (3GPP) wich ar coded as URN. An example of an ICSI for a 3GPP defined=20 > IMS communication service is: urn:urn-xxx:3gpp-service.ims.icsi.mmtel > Do you think, this kind of enhancement for Histroy-Info header could=20 > be added in the document ? >=20 > ** Section 4.1: About Retarget (hi-target), it is indicated "A=20 > retarget parameter is not added for a hi-entry when it is first added=20 > in a History- Info header, but rather is added when the retargeting=20 > actually occurs". It is indicated when the Retarget > indication should be added but it could be good to add an=20 > information on where the parameter should be added (associated to the=20 > retargeting hi-targeted-to-uri). This is > just to be clear on the History-Info header structure.=20 > I have the same comment for the Reason header escaped in the=20 > History-Info. About that, there is an inconsistency between > Reason header associated to the retargeting URI and=20 > cause-param parameter (RFC4458) associated to the retargeted-to URI.=20 > This should be corrected in RFC4458 but I > don't know if it is possible. >=20 > ** Section 4.5.1 and following: in the call flows there is a=20 > "retarget" parmeter inserted in the second INVITE by Proxy1 when=20 > sending the request to Proxy2. In my understanding, it should only be=20 > added (in the same place) by Proxy2 when retargeting the request to=20 > Bob. Did I miss something ? >=20 > ** Privacy: I also think that it should be recommended in the document = > to use the Privacy header with the value "history" > escaped in the hi-entries rather than directly in the INVITE request. >=20 >=20 > Best Regards, > Marianne > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 From ietf.hanserik@gmail.com Thu Mar 19 03:50:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B40528C139 for ; Thu, 19 Mar 2009 03:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsVIbKoygBdh for ; Thu, 19 Mar 2009 03:50:28 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id 5CFE928C13A for ; Thu, 19 Mar 2009 03:50:27 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id h3so92924nfh.39 for ; Thu, 19 Mar 2009 03:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+VLxFu1F1YQSbhk/14z5wcw72YgdEjiVKniz2e58wuA=; b=HpWLjBlfGft9F/9Mib+QociiQ9Jmz7c2UVL+J1iCEtgvOZiOL6QCiApnqcudxt7lHb fi4fO+iW1XQ5U4p/PzEa7XAtdsdbDKDSE4v8D6bXVCEZM0TjXfwgdmvmiubl2aDPaklp p2ZywCRo15QX3LO8fY9e3I5aPy6+oCO10/YcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FA1yoOwCwNZ74tMnRV2jjPthIA02W3sSnvlnkrqMbapQXKmbhXNPTNgRMpblZ2qWWq xPSX6FOSFdc9w5cj0rHFdH1XrMDwX662GKQz5q9/kEa44wlBjWWRZQibRvloG1N7B8Ae m9yOfMuTDFqJPNmOlDYNJaeN1HdL848aOMPUk= MIME-Version: 1.0 Received: by 10.216.28.15 with SMTP id f15mr684111wea.30.1237459871891; Thu, 19 Mar 2009 03:51:11 -0700 (PDT) In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026064FF116@ftrdmel2> References: <20090304151501.4951728C331@core3.amsl.com> <1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com> <7DBAFEC6A76F3E42817DF1EBE64CB026064C8CFC@ftrdmel2> <28B7C3AA2A7ABA4A841F11217ABE78D6756AE219@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7DBAFEC6A76F3E42817DF1EBE64CB026064FF116@ftrdmel2> Date: Thu, 19 Mar 2009 11:51:11 +0100 Message-ID: <9ae56b1e0903190351v4e9efcb0x2829eb61dd345c7c@mail.gmail.com> From: Hans Erik van Elburg To: mary.barnes@nortel.com Content-Type: multipart/alternative; boundary=00504502d2f61682570465769454 Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 10:50:29 -0000 --00504502d2f61682570465769454 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mary, Other discussion on the list triggered the following question when looking at how Request-URI's are recorded in 4244. Assume: A UAS that receiving the History-Info in a request. The UAS needs the original parameters that where present on a particular recorded Request-URI. Q1: Does the current 4244 text ensure that the Request-URI parameters are recorded? Q2: Assuming they are recorded, how to distinguish parameters that where originally present and those that where added in the History-Info recording process? Q3: What was the design objective for not having reason headers etc be recorded as hi-param? I.e. why is the recorded URI modified? Best Regards, /Hans Erik van Elburg --00504502d2f61682570465769454 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mary,

Other discussion on the list triggered the following questi= on when looking at how Request-URI's are recorded in 4244.

Assum= e: A UAS that receiving the History-Info in a request. The UAS needs the or= iginal parameters that where present on a particular recorded Request-URI.<= br>
Q1: Does the current 4244 text ensure that the Request-URI parameters a= re recorded?
Q2: Assuming they are recorded, how to distinguish paramete= rs that where originally present and those that where added in the History-= Info recording process?
Q3: What was the design objective for not having reason headers etc be reco= rded as hi-param? I.e. why is the recorded URI modified?

Best Regard= s,
/Hans Erik van Elburg


--00504502d2f61682570465769454-- From christer.holmberg@ericsson.com Thu Mar 19 07:33:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16143A67F6 for ; Thu, 19 Mar 2009 07:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.753 X-Spam-Level: X-Spam-Status: No, score=-5.753 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CiXDXo4q7GO for ; Thu, 19 Mar 2009 07:33:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6E1AA28C18A for ; Thu, 19 Mar 2009 07:33:44 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A42C920BE6 for ; Thu, 19 Mar 2009 15:34:28 +0100 (CET) X-AuditID: c1b4fb3c-abc84bb000004af0-d9-49c257f4db5d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6FF3220A60 for ; Thu, 19 Mar 2009 15:34:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 15:34:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A89F.CEA1E022" Date: Thu, 19 Mar 2009 15:34:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DEFINITION: Target, Address, Name, Retarget, Reroute Thread-Index: Acmon85KmKXhv5i9Q2eVr1KI7JfHPw== From: "Christer Holmberg" To: X-OriginalArrivalTime: 19 Mar 2009 14:34:28.0216 (UTC) FILETIME=[CEF46780:01C9A89F] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] DEFINITION: Target, Address, Name, Retarget, Reroute X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 14:33:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A89F.CEA1E022 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Hans Erik sent this text already earlier, but I would like to re-send it = as a separate thread. It is related to the definitions which I think we = should agree on. Regards, Christer Current target The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. This defintion only makes sense when the following definitions are used: Name: A name is a moniker for an entity which refers to it in a way which = reveals nothing about where it is in a network. In SIP, tel URI which = doesn't represent the location of the entity is a name.=20 Address: An address is an identifier for an entity which describes it by its = location on the network. In SIP, the SIP URI itself is a form of address = because the host part of the URI, the only mandatory part of the URI = besides the scheme itself, indicates the location of a SIP server that = can be used to handle the request. Route: Finally, a route is a sequence of SIP entities (including the UA = itself!) which are traversed in order to forward a request to an address = or name. Retarget (other term might be needed, as this is highly confusing): A Request-URI rewrite operation that changes the target identity of the = request. Reroute (other term might be needed): A Request-URI rewrite operation that does not change the current target = of the request, but determines the route/next hop taken to reach the = target-identity.=20 ------_=_NextPart_001_01C9A89F.CEA1E022 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DEFINITION: Target, Address, Name, Retarget, Reroute

Hi,

Hans Erik sent this text already = earlier, but I would like to re-send it as a separate thread. It is = related to the definitions which I think we should agree on.

Regards,

Christer




Current target

The current target of an initial request for a = dialog or standalone
request is the name or address to which the request is targeted, = i.e.
either the initial target inserted in the Request-URI by the UAC = that
originates the request, or when a retarget occurred, the target
provided in that retarget operation. Reroute and translation
operations never change the current target.


This defintion only makes sense when the following definitions are = used:

Name:

A name is a moniker for an entity which refers to = it in a way which reveals nothing about where it is in a network. In = SIP, tel URI which doesn't represent the location of the entity is a = name.

Address:

An address is an identifier for an entity which = describes it by its location on the network. In SIP, the SIP URI itself = is a form of address because the host part of the URI, the only = mandatory part of the URI besides the scheme itself, indicates the = location of a SIP server that can be used to handle the request.

Route:

Finally, a route is a sequence of SIP entities = (including the UA itself!) which are traversed in order to forward a = request to an address or name.

Retarget (other term might be needed, as = this is highly confusing):

A Request-URI rewrite operation that changes the = target identity of the request.

Reroute (other term might be needed):

A Request-URI rewrite operation that does not = change the current target of the request, but determines the route/next = hop taken to reach the target-identity.=A0

------_=_NextPart_001_01C9A89F.CEA1E022-- From drage@alcatel-lucent.com Thu Mar 19 15:46:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015513A6B9B for ; Thu, 19 Mar 2009 15:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhxLKJchrwDX for ; Thu, 19 Mar 2009 15:46:57 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id DA3D33A6902 for ; Thu, 19 Mar 2009 15:46:56 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2JMlePi010731 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Mar 2009 23:47:40 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 19 Mar 2009 23:47:40 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "sip@ietf.org" Date: Thu, 19 Mar 2009 23:47:39 +0100 Thread-Topic: DEFINITION: Target, Address, Name, Retarget, Reroute Thread-Index: Acmon85KmKXhv5i9Q2eVr1KI7JfHPwAOQVTg Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67577BA0B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Sip] DEFINITION: Target, Address, Name, Retarget, Reroute X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 22:46:58 -0000 Your definition of name implies that if a name contains any information at = all that could be addressing information, then it cannot be a name. If I re= ceive a greeting card that says "Greetings to the occupants of no. 10", tha= t to me is using "occupants of no. 10" as a name, even though it may also i= n other circumstances parts of it may form part of an address. =20 So I would suggest something more along the lines of: "A name is a moniker for an entity which refers to it in a way which is not= expected to reveal anything about where it is in a network. In SIP, tel UR= I which doesn't represent the location of the entity is a name." Also tel URIs still contain a domain name, so does that no make them potent= ially addressing information at least in this respect, in the same way as y= ou have described for the SIP URI in respect of addresses. regards Keith ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chri= ster Holmberg Sent: Thursday, March 19, 2009 2:34 PM To: sip@ietf.org Subject: [Sip] DEFINITION: Target, Address, Name, Retarget, Reroute =09 =09 =09 =09 Hi,=20 Hans Erik sent this text already earlier, but I would like to re-send it a= s a separate thread. It is related to the definitions which I think we shou= ld agree on. Regards,=20 Christer=20 Current target =09 The current target of an initial request for a dialog or standalone request is the name or address to which the request is targeted, i.e. either the initial target inserted in the Request-URI by the UAC that originates the request, or when a retarget occurred, the target provided in that retarget operation. Reroute and translation operations never change the current target. =09 =09 This defintion only makes sense when the following definitions are used: =09 Name: =09 A name is a moniker for an entity which refers to it in a way which reveal= s nothing about where it is in a network. In SIP, tel URI which doesn't rep= resent the location of the entity is a name. =09 Address: =09 An address is an identifier for an entity which describes it by its locati= on on the network. In SIP, the SIP URI itself is a form of address because = the host part of the URI, the only mandatory part of the URI besides the sc= heme itself, indicates the location of a SIP server that can be used to han= dle the request. =09 Route: =09 Finally, a route is a sequence of SIP entities (including the UA itself!) = which are traversed in order to forward a request to an address or name. =09 Retarget (other term might be needed, as this is highly confusing): =09 A Request-URI rewrite operation that changes the target identity of the re= quest. =09 Reroute (other term might be needed): =09 A Request-URI rewrite operation that does not change the current target of= the request, but determines the route/next hop taken to reach the target-i= dentity.=20 From drage@alcatel-lucent.com Thu Mar 19 15:46:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DC33A6902 for ; Thu, 19 Mar 2009 15:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djnKcjwg2iQJ for ; Thu, 19 Mar 2009 15:46:57 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id DAF6B3A6B0E for ; Thu, 19 Mar 2009 15:46:56 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2JMlfOF009900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Mar 2009 23:47:41 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 19 Mar 2009 23:47:41 +0100 From: "DRAGE, Keith (Keith)" To: "marianne.mohali@orange-ftgroup.com" Date: Thu, 19 Mar 2009 23:47:40 +0100 Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: Acmc3BxDJtHcuwTdRwWkLMp/RoYA4gFUHfkwAA7gimAAKyH/sAABMLoAAAAx1hAAA2O9MAACv+6wALvzPfAAG/o9cAB4rjrAABoXk2A= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67577BA0E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <20090304151501.4951728C331@core3.amsl.com><1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com><7DBAFEC6A76F3E42817DF1EBE64CB026064C8CFC@ftrdmel2> <28B7C3AA2A7ABA4A841F11217ABE78D6756AE219@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7DBAFEC6A76F3E42817DF1EBE64CB026064FF116@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026064FF116@ftrdmel2> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sip@ietf.org" , "audet@nortel.com" , "mary.barnes@nortel.com" Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 22:46:58 -0000 IARI is end to end (either user terminal or application) and is not changed= by intermediate call functionality.=20 Therefore any intermediate application that changes this is essentially mak= ing a new call that is not the original call. Think of something like a con= ference bridge. If you start recording IARI in History-Info, then that would suggest you re= cord all the other headers and bodies that are end to end information. regards Keith > -----Original Message----- > From: marianne.mohali@orange-ftgroup.com=20 > [mailto:marianne.mohali@orange-ftgroup.com]=20 > Sent: Thursday, March 19, 2009 9:54 AM > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org; mary.barnes@nortel.com; audet@nortel.com > Subject: RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt >=20 > Hi Keith, >=20 > Let's just talk about IARI. My idea was just to suggest a=20 > trail to improve History-Info. Before to create new things=20 > (headers or parameters), we should look what is available and=20 > reusable. If it is not conceivable to use IARI values in a=20 > History-Info header allowing a proxy server to indicate what=20 > has been done in term of service, could you please give a reason.=20 >=20 > Best Regards, > Marianne=20 >=20 > -----Message d'origine----- > De : DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Envoy=E9 : mardi 17 mars 2009 00:55 =C0 : MOHALI Marianne=20 > RD-CORE-ISS; mary.barnes@nortel.com; audet@nortel.com Cc :=20 > sip@ietf.org Objet : RE: [Sip] I-D=20 > Action:draft-barnes-sip-rfc4244bis-00.txt >=20 > You wrote: >=20 > > ** To make the History-Info header usefull for applications and=20 > > services interactions, it could be interesting to be able=20 > to include=20 > > in the hi-target-to-uri IARI and ICSC values as described=20 > in TS 24.229 > > (3GPP) wich ar coded as URN. An example of an ICSI for a=20 > 3GPP defined=20 > > IMS communication service is:=20 > urn:urn-xxx:3gpp-service.ims.icsi.mmtel > > Do you think, this kind of enhancement for Histroy-Info=20 > header could=20 > > be added in the document ? >=20 > Question: What have these values to do with the history of a=20 > retargetting? >=20 > Keith=20 >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > marianne.mohali@orange-ftgroup.com > > Sent: Monday, March 16, 2009 10:11 PM > > To: mary.barnes@nortel.com; audet@nortel.com > > Cc: sip@ietf.org > > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt > >=20 > >=20 > > Hi Mary and Fran=E7ois, > >=20 > > I have a suggestion and few comments on the document. > >=20 > > ** To make the History-Info header usefull for applications and=20 > > services interactions, it could be interesting to be able=20 > to include=20 > > in the hi-target-to-uri IARI and ICSC values as described=20 > in TS 24.229 > > (3GPP) wich ar coded as URN. An example of an ICSI for a=20 > 3GPP defined=20 > > IMS communication service is:=20 > urn:urn-xxx:3gpp-service.ims.icsi.mmtel > > Do you think, this kind of enhancement for Histroy-Info=20 > header could=20 > > be added in the document ? > >=20 > > ** Section 4.1: About Retarget (hi-target), it is indicated "A=20 > > retarget parameter is not added for a hi-entry when it is=20 > first added=20 > > in a History- Info header, but rather is added when the retargeting=20 > > actually occurs". It is indicated when the Retarget > > indication should be added but it could be good to add an=20 > > information on where the parameter should be added=20 > (associated to the=20 > > retargeting hi-targeted-to-uri). This is > > just to be clear on the History-Info header structure.=20 > > I have the same comment for the Reason header escaped in the=20 > > History-Info. About that, there is an inconsistency between > > Reason header associated to the retargeting URI and=20 > > cause-param parameter (RFC4458) associated to the=20 > retargeted-to URI.=20 > > This should be corrected in RFC4458 but I > > don't know if it is possible. > >=20 > > ** Section 4.5.1 and following: in the call flows there is a=20 > > "retarget" parmeter inserted in the second INVITE by Proxy1 when=20 > > sending the request to Proxy2. In my understanding, it=20 > should only be=20 > > added (in the same place) by Proxy2 when retargeting the request to=20 > > Bob. Did I miss something ? > >=20 > > ** Privacy: I also think that it should be recommended in=20 > the document=20 > > to use the Privacy header with the value "history" > > escaped in the hi-entries rather than directly in the=20 > INVITE request. > >=20 > >=20 > > Best Regards, > > Marianne > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > = From mary.barnes@nortel.com Thu Mar 19 22:33:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACCD93A69F7 for ; Thu, 19 Mar 2009 22:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuUW9OZqtbXG for ; Thu, 19 Mar 2009 22:33:29 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 732483A67A8 for ; Thu, 19 Mar 2009 22:33:29 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2K5XmZ19774; Fri, 20 Mar 2009 05:33:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A91D.7E4F487B" Date: Fri, 20 Mar 2009 00:33:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1BF5FD55@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt Thread-Index: AcmogKBkRB8dqebzR5aHKUJvyaRZzgAm0ms2AABfOm0= References: <20090304151501.4951728C331@core3.amsl.com><1ECE0EB50388174790F9694F77522CCF1CCA67CB@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CCF9E13@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1CD4B19A@zrc2hxm0.corp.nortel.com><7DBAFEC6A76F3E42817DF1EBE64CB026064C8CFC@ftrdmel2><28B7C3AA2A7ABA4A841F11217ABE78D6756AE219@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><7DBAFEC6A76F3E42817DF1EBE64CB026064FF116@ftrdmel2> <9ae56b1e0903190351v4e9efcb0x2829eb61dd345c7c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1BF5FD54@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Mary Barnes" , "Hans Erik van Elburg" , Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 05:33:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A91D.7E4F487B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Resending to include SIP WG mailing list. -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Fri 3/20/2009 12:32 AM To: Hans Erik van Elburg Subject: RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt =20 Hi Hans Erick, Responses below [MB]. Thanks, Mary. -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Thu 3/19/2009 5:51 AM To: Barnes, Mary (RICH2:AR00) Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt =20 Hi Mary, Other discussion on the list triggered the following question when = looking at how Request-URI's are recorded in 4244. Assume: A UAS that receiving the History-Info in a request. The UAS = needs the original parameters that where present on a particular recorded Request-URI. Q1: Does the current 4244 text ensure that the Request-URI parameters = are recorded? [MB] The current text doesn't specifically discuss Request-URI = parameters, but per the general rule that information is not removed = from messages, the parameters should be left intact. I can add something = to that affect to the next version to clarify that point. [/MB] Q2: Assuming they are recorded, how to distinguish parameters that where originally present and those that where added in the History-Info = recording process? [MB] History-Info doesn't add any new Request-URI parameters. The = Reason header is escaped in the Request-URI, but it's not something that = would be part of any SIP Request and would only appear in a Request-URI = that has been captured in the History-Info header. We could also add a = statement clarifying that to RFC 4244.=20 Q3: What was the design objective for not having reason headers etc be recorded as hi-param? I.e. why is the recorded URI modified? [MB] That was just a matter of reusing an existing header versus = defining a parameter that had the exact same information. This was an = issue discussed at IETF-55 in Nov 22 (Issue 2, chart 5): http://www.ietf.org/proceedings/02nov/slides/sipping-2/index.html You can see in those charts (and older versions of the drafts that you = may or may not be able to dig up) that the Reason was originally an = hi-param. The escaping also saves a few bytes per hi-entry. The = recorded URI is modified because the intent was to capture "why" that = URI was retargeted. You can also look at those charts above = (specifically chart 4 that has the ABNF) and see that we were originally = capturing two entries at each node - old and new. But, again, to make = the header more compact we simplified to just record the new and thus = have the "old" already captured by the time the request is received by = the next node. The Reason header is only added (to the "old" hi-entry) = in the case that the retargeted URI is in the domain for which the = entity doing the retargeting is responsible. [/MB] Best Regards, /Hans Erik van Elburg ------_=_NextPart_001_01C9A91D.7E4F487B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

Resending to include SIP WG mailing list.


-----Original Message-----
From: Barnes, Mary (RICH2:AR00)
Sent: Fri 3/20/2009 12:32 AM
To: Hans Erik van Elburg
Subject: RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

Hi Hans Erick,

Responses below [MB].

Thanks,
Mary.


-----Original Message-----
From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Thu 3/19/2009 5:51 AM
To: Barnes, Mary (RICH2:AR00)
Cc: sip@ietf.org
Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt

Hi Mary,

Other discussion on the list triggered the following question when = looking
at how Request-URI's are recorded in 4244.

Assume: A UAS that receiving the History-Info in a request. The UAS = needs
the original parameters that where present on a particular recorded
Request-URI.

Q1: Does the current 4244 text ensure that the Request-URI parameters = are
recorded?
[MB] The current text doesn't specifically discuss Request-URI = parameters, but per the general rule that information is not removed = from messages, the parameters should be left intact. I can add something = to that affect to the next version to clarify that point. [/MB]
Q2: Assuming they are recorded, how to distinguish parameters that = where
originally present and those that where added in the History-Info = recording
process?
[MB] History-Info doesn't add any new Request-URI parameters.  The = Reason header is escaped in the Request-URI, but it's not something that = would be part of any SIP Request and would only appear in a Request-URI = that has been captured in the History-Info header. We could also add a = statement clarifying that to RFC 4244.
Q3: What was the design objective for not having reason headers etc = be
recorded as hi-param? I.e. why is the recorded URI modified?
[MB] That was just a matter of reusing an existing header versus = defining a parameter that had the exact same information. This was an = issue discussed at IETF-55 in Nov 22 (Issue 2, chart 5):
http://www.ietf.org/proceedings/02nov/slides/sipping-2/index.html You can see in those charts (and older versions of the drafts that you = may or may not be able to dig up) that the Reason was originally an = hi-param. The escaping also saves a few bytes per hi-entry.   = The recorded URI is modified because the intent was to capture = "why" that URI was retargeted. You can also look at those = charts above (specifically chart 4 that has the ABNF) and see that we = were originally capturing two entries at each node - old and new. But, = again, to make the header more compact we simplified to just record the = new and thus have the "old" already captured by the time the = request is received by the next node. The Reason header is only added = (to the "old" hi-entry) in the case that the retargeted URI is = in the domain for which the entity doing the retargeting is responsible. = [/MB]

Best Regards,
/Hans Erik van Elburg

------_=_NextPart_001_01C9A91D.7E4F487B-- From gonzalo.camarillo@ericsson.com Fri Mar 20 03:47:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54FE3A6B8F for ; Fri, 20 Mar 2009 03:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.827 X-Spam-Level: X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=1.422, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s0gFk5v6W4R for ; Fri, 20 Mar 2009 03:47:01 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8B9813A6B18 for ; Fri, 20 Mar 2009 03:47:01 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2B9A7214B6 for ; Fri, 20 Mar 2009 11:47:28 +0100 (CET) X-AuditID: c1b4fb3c-ad487bb000004af0-0a-49c3743fcfb4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F037621475 for ; Fri, 20 Mar 2009 11:47:27 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 11:47:27 +0100 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 11:47:27 +0100 Message-ID: <49C3743F.1070406@ericsson.com> Date: Fri, 20 Mar 2009 12:47:27 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2009 10:47:27.0750 (UTC) FILETIME=[42EFFA60:01C9A949] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 10:47:02 -0000 Folks, as you know, RFC 3840 specifies how to indicate UA's capabilities using media feature tags. Section 12.1 of RFC 3840 creates the SIP Media Feature Tag Registration Tree. Media feature tags applicable to SIP are registered in this tree. http://www.ietf.org/rfc/rfc3840.txt RFC 2506 defines the global tree to register feature tags. Section 3.1.2 of RFC 2506 says: "A registration may be proposed for the global tree by anyone who has the need to allow for communication on a particular capability or preference". http://www.ietf.org/rfc/rfc2506.txt The currently registered feature tags in both the SIP and the global trees can be found at: http://www.iana.org/assignments/media-feature-tags As you can see, the only three feature tags registered in the global tree come from 3GPP. The issue we are facing is that the SIP and the global trees have different registration policies. The SIP registry requires an RFC defining the feature tag while the global tree only requires an expert review. Now, 3GPP would like to register two new feature tags: g.3gpp.icsi-ref, g.3gpp.iari-ref This is the description of how these feature tags will be used: "Each value of the Application Reference media feature-tag indicates the software applications supported by the agent. The values for this tag equal the IMS communication Service Identifier (ICSI) and IMS Application Reference Identifier (IARI) values supported by the agent. The Application Reference media feature tag is defined to fulfil the requirements for forking to an appropriate UE when multiple UEs are registered and dispatch to an appropriate application within the UE based upon the IMS communication Service Identifier (ICSI) and IMS Application Reference Identifier (IARI) values as stated in 3GPP TS 23.228. Multiple tag-values can be included in the Application Reference media feature-tag." The expert reviewer indicated that this tags will not contain simple features but rather more complex services, or feature sets, or application logic (pick your favorite term). Therefore, he did not find it appropriate to register them in the global tree. He suggested that RFC 2506 is amended so that it covers this type of more complex features. However, before going down that path, I would like to get comments from the SIP community. The underlying issue is that we need to decide which policy we want to apply to these types of registrations in SIP. 1) We decide that an RFC is always needed. Then, we can just use the SIP registry. We would probably need to clarify or to stress somewhere that the global tree is not appropriate for SIP tags. 2) We decide that an expert review is good enough. Then we would probably need to amend RFC 2506 or RFC 3840 to reflect this. Comments are welcome. Thanks, Gonzalo From pkyzivat@cisco.com Fri Mar 20 06:41:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DA03A6893 for ; Fri, 20 Mar 2009 06:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=3.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFJtROSrITzx for ; Fri, 20 Mar 2009 06:41:03 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7099F3A6833 for ; Fri, 20 Mar 2009 06:41:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,395,1233532800"; d="scan'208";a="144325356" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 20 Mar 2009 13:41:49 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2KDfnK5031387; Fri, 20 Mar 2009 09:41:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2KDfnsL025340; Fri, 20 Mar 2009 13:41:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 09:41:49 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 09:41:49 -0400 Message-ID: <49C39D1C.1040701@cisco.com> Date: Fri, 20 Mar 2009 09:41:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gonzalo Camarillo References: <49C3743F.1070406@ericsson.com> In-Reply-To: <49C3743F.1070406@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2009 13:41:49.0214 (UTC) FILETIME=[9E74B3E0:01C9A961] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4932; t=1237556509; x=1238420509; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Policy=20to=20register=20media= 20feature=20tags |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=fqY+3mmayXqvCizX2Ws/HvDfR9W+nyw1E5D769ZM2eE=; b=AqNre0z4u3Wi6y/xEuQQbvzq3i13KzPzX0UnYBrx+mvBQ6pT06pjq/DhHY FD96V5Ad6XnQI21lw9FRz64BLWrjJ8lh18HEcz9PNmRCqIipfFjy1SBtIEko SH8Hg/EQQt; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip Subject: Re: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 13:41:04 -0000 Some issues just never go away. :-( This seems to be a resurection of issues that first surfaced during the initial discussions of extended presence status many years ago. And it also harks back to discussions last year or the year before about communication service identifiers and application service identifiers. The problem is one of openness. Specifically, do you have to be "part of the club" in order to properly interoperate with a device that uses these identifiers to identify its preferences or capabilities. On one side were those who wanted capabilities and preferences to be stated in terms of feature tags that are well known and orthogonal. On the other side were those who prefer to associate arbitrary names to collections of features and then negotiate on the basis of the names of those collections. Using the latter approach its possible that interoperation will fail because the parties don't share a common name for a collection of features even though they both possess the necessary features to interoperate. I don't have a problem with independent groups defining new feature tags, as long as they are primitive and orthogonal to existing ones. But I do have a problem with defining feature tags that identify collections of features, especially when the mapping from the identifier to the collection of features is not public. The bottom line is that I think this sort of thing needs to be thrashed out within the sip community. So I think the RFC process is the right process. Thanks, Paul Gonzalo Camarillo wrote: > Folks, > > as you know, RFC 3840 specifies how to indicate UA's capabilities using > media feature tags. Section 12.1 of RFC 3840 creates the SIP Media > Feature Tag Registration Tree. Media feature tags applicable to SIP are > registered in this tree. > > http://www.ietf.org/rfc/rfc3840.txt > > RFC 2506 defines the global tree to register feature tags. Section 3.1.2 > of RFC 2506 says: "A registration may be proposed for the global tree by > anyone who has the need to allow for communication on a particular > capability or preference". > > http://www.ietf.org/rfc/rfc2506.txt > > The currently registered feature tags in both the SIP and the global > trees can be found at: > > http://www.iana.org/assignments/media-feature-tags > > As you can see, the only three feature tags registered in the global > tree come from 3GPP. > > The issue we are facing is that the SIP and the global trees have > different registration policies. The SIP registry requires an RFC > defining the feature tag while the global tree only requires an expert > review. > > Now, 3GPP would like to register two new feature tags: g.3gpp.icsi-ref, > g.3gpp.iari-ref > > This is the description of how these feature tags will be used: > > "Each value of the Application Reference media feature-tag indicates the > software applications supported by the agent. The values for this tag > equal the IMS communication Service Identifier (ICSI) and IMS > Application Reference Identifier (IARI) values supported by > the agent. The Application Reference media feature tag is > defined to fulfil the requirements for forking to an appropriate UE when > multiple UEs are registered and dispatch to an appropriate application > within the UE based upon the IMS communication Service Identifier > (ICSI) and IMS Application Reference Identifier (IARI) values as > stated in 3GPP TS 23.228. Multiple tag-values can be included in the > Application Reference media feature-tag." > > > The expert reviewer indicated that this tags will not contain simple > features but rather more complex services, or feature sets, or > application logic (pick your favorite term). Therefore, he did not find > it appropriate to register them in the global tree. He suggested that > RFC 2506 is amended so that it covers this type of more complex features. > > However, before going down that path, I would like to get comments from > the SIP community. The underlying issue is that we need to decide which > policy we want to apply to these types of registrations in SIP. > > 1) We decide that an RFC is always needed. Then, we can just use the SIP > registry. We would probably need to clarify or to stress somewhere that > the global tree is not appropriate for SIP tags. > > 2) We decide that an expert review is good enough. Then we would > probably need to amend RFC 2506 or RFC 3840 to reflect this. > > Comments are welcome. > > Thanks, > > Gonzalo > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From pkyzivat@cisco.com Fri Mar 20 06:46:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A553A6803 for ; Fri, 20 Mar 2009 06:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.784 X-Spam-Level: X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[AWL=2.215, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7Xt4SPLt7Wb for ; Fri, 20 Mar 2009 06:46:11 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7D9833A6946 for ; Fri, 20 Mar 2009 06:46:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,395,1233532800"; d="scan'208";a="68211912" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2009 13:46:57 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2KDkvZ2018450; Fri, 20 Mar 2009 09:46:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2KDkrBd027080; Fri, 20 Mar 2009 13:46:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 09:46:55 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 09:46:54 -0400 Message-ID: <49C39E4E.5090405@cisco.com> Date: Fri, 20 Mar 2009 09:46:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <28B7C3AA2A7ABA4A841F11217ABE78D67577BA0B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67577BA0B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2009 13:46:54.0917 (UTC) FILETIME=[54AB4750:01C9A962] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3777; t=1237556817; x=1238420817; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20DEFINITION=3A=20Target,=20Addre ss,=20Name,=20Retarget,=20Reroute |Sender:=20 |To:=20=22DRAGE,=20Keith=20(Keith)=22=20; bh=fJ+MSG12yMEo+7zAwSo90w+aHbiESANI5IXGxQ3RLDo=; b=psbsifqvlLw/jSapTg8xJfHmSpX3QUxR66Kpe6dcsIcc0RFbHx/PIzNCpa eahNMgzkdssAs4GUXsYBdtt/0g+6pYjkJi7jCHq4TApSP0Wej/NBqJPZIpGF vDZy6P+lWD; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "sip@ietf.org" , Christer Holmberg Subject: Re: [Sip] DEFINITION: Target, Address, Name, Retarget, Reroute X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 13:46:12 -0000 DRAGE, Keith (Keith) wrote: > Your definition of name implies that if a name contains any information at all that could be addressing information, then it cannot be a name. If I receive a greeting card that says "Greetings to the occupants of no. 10", that to me is using "occupants of no. 10" as a name, even though it may also in other circumstances parts of it may form part of an address. > > So I would suggest something more along the lines of: > > "A name is a moniker for an entity which refers to it in a way which is not expected to reveal anything about where it is in a network. In SIP, tel URI which doesn't represent the location of the entity is a name." > > Also tel URIs still contain a domain name, so does that no make them potentially addressing information at least in this respect, in the same way as you have described for the SIP URI in respect of addresses. Keith, I agreed with you up to this point. But tel URIs do not contain domain names. A sip URI, with user=phone contains the essence of a tel uri in its user part, and also contains a domain name, but that is still a sip URI, not a tel URI. (A minor exception to the above is a tel uri with a phone-context containing a domain name.) Thanks, Paul > regards > > Keith > > > > ________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, March 19, 2009 2:34 PM > To: sip@ietf.org > Subject: [Sip] DEFINITION: Target, Address, Name, Retarget, Reroute > > > > > > Hi, > > Hans Erik sent this text already earlier, but I would like to re-send it as a separate thread. It is related to the definitions which I think we should agree on. > > Regards, > > Christer > > > > > Current target > > The current target of an initial request for a dialog or standalone > request is the name or address to which the request is targeted, i.e. > either the initial target inserted in the Request-URI by the UAC that > originates the request, or when a retarget occurred, the target > provided in that retarget operation. Reroute and translation > operations never change the current target. > > > This defintion only makes sense when the following definitions are used: > > Name: > > A name is a moniker for an entity which refers to it in a way which reveals nothing about where it is in a network. In SIP, tel URI which doesn't represent the location of the entity is a name. > > Address: > > An address is an identifier for an entity which describes it by its location on the network. In SIP, the SIP URI itself is a form of address because the host part of the URI, the only mandatory part of the URI besides the scheme itself, indicates the location of a SIP server that can be used to handle the request. > > Route: > > Finally, a route is a sequence of SIP entities (including the UA itself!) which are traversed in order to forward a request to an address or name. > > Retarget (other term might be needed, as this is highly confusing): > > A Request-URI rewrite operation that changes the target identity of the request. > > Reroute (other term might be needed): > > A Request-URI rewrite operation that does not change the current target of the request, but determines the route/next hop taken to reach the target-identity. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From dworley@nortel.com Fri Mar 20 11:46:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905D528C124 for ; Fri, 20 Mar 2009 11:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mTz1D6cfUS1 for ; Fri, 20 Mar 2009 11:46:01 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 91E4D3A6846 for ; Fri, 20 Mar 2009 11:46:01 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2KIjoZ18879; Fri, 20 Mar 2009 18:45:50 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 14:46:13 -0400 From: "Dale Worley" To: Adam Roach In-Reply-To: <49ADB598.9000102@nostrum.com> References: <49ADB598.9000102@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 20 Mar 2009 14:46:13 -0400 Message-Id: <1237574773.3742.12.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2009 18:46:14.0170 (UTC) FILETIME=[2537CFA0:01C9A98C] Cc: SIP WG Subject: Re: [Sip] RFC3265bis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 18:46:02 -0000 On Tue, 2009-03-03 at 16:56 -0600, Adam Roach wrote: > After 6 years of testing at SIPits and other experience in the field, it > feels like time to fix some of the known bugs in RFC 3265. I've put > together a 3265bis that addresses most of the bugs that have been > reported to date (although some are called out as known issues): > > http://www.ietf.org/internet-drafts/draft-roach-sipcore-rfc3265bis-00.txt That looks good. I've only skimmed it yet, but it cleans up a lot of the things we've seen problems with. Dale From adam@nostrum.com Fri Mar 20 15:34:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E5A3A6C50 for ; Fri, 20 Mar 2009 15:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LbryFayX-7k for ; Fri, 20 Mar 2009 15:34:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6513F3A687A for ; Fri, 20 Mar 2009 15:34:30 -0700 (PDT) Received: from dhcp-47f7.meeting.ietf.org ([130.129.71.247]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2KMZERI092500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Mar 2009 17:35:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49C2D7E5.5050709@nostrum.com> Date: Thu, 19 Mar 2009 18:40:21 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.71.247 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9145/Fri Mar 20 09:59:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 22:34:31 -0000 Between Minneapolis and now, this document has become a lot more confusing, which I think bodes pretty ill for its hopes of being deployed. For example, in section 5: If the received initial request contains an 199 option tag, the UAS SHOULD NOT send a 199 response for a dialog on which it intends to send a final response... This reads as if sending a 199 response somehow absolves a UAS of sending a final response. Certainly this is not the intention of the draft (at least, not according to the text in section 7). Section 5 needs to be re-phrased to indicate what is actually intended here. In fact, on that topic, it's radically unclear to me how UASes fit into the entire scheme at all -- my understanding is that the 199 response is only sent by forking proxies. Given that a UAS is inherently an endpoint, the entirety of section 5 seems nonsensical. Either I'm missing something (in which case it needs some pretty explicit motivating text), or section 5 needs to be removed completely. In section 6: When a forking proxy receives a non-2xx final response that it recognizes as terminating one or more early dialogs, if the proxy does not intend to forward the final response immediately (in accordance with rules for a forking proxy) and the UAC has indicated support for the 199 response code, the proxy SHOULD generate and send a 199 response upstream for each early dialog terminated on the downstream side by the non-2xx final response, except for any early dialog for which the proxy has previously received and forwarded a 199 response. What? On my best run at reading that, I made it to about the 81st word before the first predicate clause fell out of my head. If it's really as complicated as the structure of this sentence makes it seem, we need a flowchart or some other simplifying mechanism. /a From ietf.hanserik@gmail.com Fri Mar 20 16:21:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CFD3A6AC9 for ; Fri, 20 Mar 2009 16:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVqYxf+JwjM4 for ; Fri, 20 Mar 2009 16:21:24 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id ED1883A69DC for ; Fri, 20 Mar 2009 16:21:23 -0700 (PDT) Received: by ewy9 with SMTP id 9so897875ewy.37 for ; Fri, 20 Mar 2009 16:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=z8dFRcAh76ZgJp94ezaXIFUSX1Y9KGLXCbZqVJJ+BJo=; b=GH4KY5+4Lmk6ZWuZ0+PJHJ01fL8FNl81QpqvX4ehm0qrFth8+gLOFMbiKTT+bzG1IA d2SS/Dkd+68egpgVWf2BAnc7UyG6LyiI1p2KSwdyKEv0JJklSvtZmU3ag+yNYjOO06JG s6sOqVRMp9WXgX+BpTwqAfZzjZ2sS2GBCLL4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SqQjgxYdLTY8IrYlqv+md/wnQyLgzpAM587pofYo6sv/xKYPwQtlcUAeuvov19fmY1 axB+1zRseTPHxAbEYB9oeWnoyQmoK5kUyq+CvYtHBZBbiOr/DpUmqT2CfVtX+go2NipG 40qoJ4MUqRdw1gpB5Qz3uVj0qQq8mudYmRleI= Received: by 10.216.72.209 with SMTP id t59mr1648841wed.27.1237591329934; Fri, 20 Mar 2009 16:22:09 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 23sm2836151eya.6.2009.03.20.16.22.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Mar 2009 16:22:09 -0700 (PDT) Message-ID: <49C42521.7080706@gmail.com> Date: Sat, 21 Mar 2009 00:22:09 +0100 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Paul Kyzivat References: <49C3743F.1070406@ericsson.com> <49C39D1C.1040701@cisco.com> In-Reply-To: <49C39D1C.1040701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip Subject: Re: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 23:21:25 -0000 Responses inline... /Hans Erik Paul Kyzivat wrote: > On one side were those who wanted capabilities and preferences to be > stated in terms of feature tags that are well known and orthogonal. On > the other side were those who prefer to associate arbitrary names to > collections of features and then negotiate on the basis of the names > of those collections. > > Using the latter approach its possible that interoperation will fail > because the parties don't share a common name for a collection of > features even though they both possess the necessary features to > interoperate. That is a feature. This interoperability "problem" only occurs when the originating party includes the header field parameters "require" and "explicit" in the Accept-Contact header field containing the feature tag. In this case the failure of the call when not all of the receiving UA's support the feature is intended! > I don't have a problem with independent groups defining new feature > tags, as long as they are primitive and orthogonal to existing ones. > But I do have a problem with defining feature tags that identify > collections of features, especially when the mapping from the > identifier to the collection of features is not public. Well who is going to determine what can be called a feature and what not. I also like to see where this principle is documented to apply to the global tree. > > The bottom line is that I think this sort of thing needs to be > thrashed out within the sip community. So I think the RFC process is > the right process. I think that bending the rules because some SIP people don't like on how other organisations are applying SIP in their solutions will alieanate those SIP users from that same SIP community. So I seriously hope we will not go down that path. /Hans Erik From jdrosen@cisco.com Sat Mar 21 07:27:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5317C3A6A3C for ; Sat, 21 Mar 2009 07:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plHx3Ee+upFo for ; Sat, 21 Mar 2009 07:27:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0C3113A6A06 for ; Sat, 21 Mar 2009 07:27:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,399,1233532800"; d="scan'208";a="271681928" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Mar 2009 14:28:35 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2LESYQA031296; Sat, 21 Mar 2009 07:28:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2LESYoN011882; Sat, 21 Mar 2009 14:28:34 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 07:28:34 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 07:28:34 -0700 Message-ID: <49C4F991.4080706@cisco.com> Date: Sat, 21 Mar 2009 10:28:33 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Robert Sparks References: <20090302143002.24E643A694C@core3.amsl.com> <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> In-Reply-To: <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2009 14:28:34.0539 (UTC) FILETIME=[50F913B0:01C9AA31] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3249; t=1237645715; x=1238509715; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Fwd=3A=20I-D=20Action=3Adraft-s parks-sip-3261-interop-statement-00.txt |Sender:=20; bh=Jv3W6EZD0c6Rt/PNkWKCHIH+RQgxGriH1eExnQE/GSU=; b=uGRNRNPZroI//V+7nLfBLHyUhGpTeJPhxChskUR59L4jm6vpGqgotMEXkQ 4AJk652oG/FZUbFPA51+8BnMSD8Fhi/FpKx75P9HrW76nEALkgBBr3fhPpJ1 V84eoms4f+mwW/5VjsmaMczpi8QgxiCkZk907yVP55mcRwfQJYlCQ=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP List Subject: Re: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 14:27:48 -0000 Thanks, Robert. Before commenting on the specific list of things, my meta-question is what exactly we plan to do with this list. I think we have agreed at previous meetings that we were not currently planning on taking SIP to draft. Do you think that has changed? The document does say: > While not required by process until > advancing to Draft, such a report would provide useful information to > guide where we focus our energy maintaing the standard at Proposed. its not clear to me, what this means. Will we take this list, run tests at sipit, and based on that define updates to 3261 to clarify? Does this imply that there are tests we're NOT running which we should be, that this draft helps us sort out? Thanks, Jonathan R. Robert Sparks wrote: > Also split out of steps-to-draft > > Begin forwarded message: > >> *From: *Internet-Drafts@ietf.org >> *Date: *March 2, 2009 8:30:02 AM CST >> *To: *i-d-announce@ietf.org >> *Subject: **I-D Action:draft-sparks-sip-3261-interop-statement-00.txt * >> *Reply-To: *internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : RFC3261 Interop Statement >> Author(s) : R. Sparks >> Filename : draft-sparks-sip-3261-interop-statement-00.txt >> Pages : 9 >> Date : 2009-03-02 >> >> This document captures an outline of the interoperability statements >> that will be collected to construct an interoperability report for >> RFC 3261. The outline is stil under review and should not be treated >> as complete, but will drive data collection at upcoming >> interoperability events. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statement-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > > ------------------------------------------------------------------------ > >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From jdrosen@cisco.com Sat Mar 21 07:58:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDF93A68C7 for ; Sat, 21 Mar 2009 07:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0zH07SFxw6L for ; Sat, 21 Mar 2009 07:58:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F35313A6A3C for ; Sat, 21 Mar 2009 07:58:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,399,1233532800"; d="scan'208";a="144777684" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 21 Mar 2009 14:59:18 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2LExIbM019317; Sat, 21 Mar 2009 07:59:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2LExI6s025713; Sat, 21 Mar 2009 14:59:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 07:59:18 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 07:59:18 -0700 Message-ID: <49C500C5.4000606@cisco.com> Date: Sat, 21 Mar 2009 10:59:17 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Robert Sparks References: <20090302144501.AB1473A68B8@core3.amsl.com> <2F9C3E56-3810-450D-B700-DB9048349875@nostrum.com> In-Reply-To: <2F9C3E56-3810-450D-B700-DB9048349875@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2009 14:59:18.0477 (UTC) FILETIME=[9C0BAFD0:01C9AA35] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5954; t=1237647558; x=1238511558; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Fwd=3A=20I-D=20Action=3Adraft-s parks-sip-invfix-03.txt |Sender:=20; bh=VKxP9KjhGxnFrRdd7Cygpu4E1WIwK8Z3L3o1ABu5ST8=; b=GC7zl5ay3CENcvobeC8r+te6HddIG+sJ8WR6YYQzs38PqA/+s2lp7lIpuC fnwYYUh/Ih3fgsMnaleWRkvfTTkUl1XO7HI1zs9Pxxv5MmDq0kfPMmyuP3Gz FQFUjFRNBCQKngcvFi8DdSCzJcYzva775mOhxbC06YrfPrQV0bOm8=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP List Subject: Re: [Sip] Fwd: I-D Action:draft-sparks-sip-invfix-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 14:58:32 -0000 Thanks, Robert. Comments below: > It modifies state transitions in the INVITE server state > machine to absorb retransmissions of the INVITE request after > encountering a unrecoverable transport error when sending a response. this little tidbit is not mentioned in section 3, whereas the other parts of this section (section 4) are mentioned. I think a paragraph describing this error is appropriate. > Implementations strictly conformant to [RFC3261] will process > retransmitted initial INVITE requests as new requests. Proxies may > forward them to different locations than the original. Proxies may > also be used as anonymizing forwarders of bulk traffic. should mention the consequences of not addressing this transport-error issue in my comment above. > 7.1. UAS Impacts > > To allow a UAS to recognize retransmissions of an INVITE as > retransmissions instead of new requests, a new state, "Accepted", is > added to the INVITE server transaction state machine. this change is not JUST for a UAS - its also for proxies implementing the server transaction machine, right? Is there a reason this is worded for UAS? > Timer L reflects the amount of time the TU will wait to > receive an ACK for the 2xx it is emitting before considering the > transaction failed. but an ACK-200 is not part of this transaction... also, I think its worth at least noting that this change does not 100% solve the problem. If the UAC and any server transaction between it, and the UAS, use a different value of T1, there can still be a problem. In particular if the value of T1 at the UAC is larger than the value at any of the downstream server transactions, the server transaction may be destroyed while the UAC remains in the calling state. > UAC Impacts > > In order to correctly distinguish retransmissions of 2xx responses > from stray 2xx responses, the INVITE client state machine is modified > to not transition immediately to "Terminated" on receipt of a 2xx > response. as above, this is not specific to UAC and covers proxy/b2b client transactions too, no? > Proxy Considerations > > A direct consequence of the change to the UAC state machine is that a > transaction-stateful proxy will not foward any stray INVITE > responses. It is not a consequence of the new state machines - but it is a change in behavior we are making. Meta-comment: A drawback of this change is that proxies and b2bua will now hold transaction state for 64*t1 seconds after the transaction is done, even for calls that set up immediately. In some implementations this may be a non-trivial increase in memory usage, and there may be other impacts (for example if an implementation had a non-optimized transaction matching mechanism which only worked well with a small number of transaction machines e.g., a linear search). I think this implication needs to be called out more strongly. You mention it as a security vulnerability, but its not just a security issue. -Jonathan R. Robert Sparks wrote: > This got a fairly big touch due to better handling of transport error > conditions. Please review this carefully. > > RjS > > Begin forwarded message: > >> *From: *Internet-Drafts@ietf.org >> *Date: *March 2, 2009 8:45:01 AM CST >> *To: *i-d-announce@ietf.org >> *Subject: **I-D Action:draft-sparks-sip-invfix-03.txt * >> *Reply-To: *internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Correct transaction handling for 200 responses to >> Session Initiation Protocol INVITE requests >> Author(s) : R. Sparks >> Filename : draft-sparks-sip-invfix-03.txt >> Pages : 20 >> Date : 2009-03-02 >> >> This document normatively updates RFC 3261, the Session Initiation >> Protocol (SIP), to address an error in the specified handling of >> success (200 class) responses to INVITE requests. Elements following >> RFC 3261 exactly will misidentify retransmissions of the request as a >> new, unassociated, request. The correction involves modifying the >> INVITE transaction state machines. The correction also changes the >> way responses that cannot be matched to an existing transaction are >> handled to address a security risk. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > > ------------------------------------------------------------------------ > >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From jdrosen@cisco.com Sat Mar 21 08:06:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F0428C103 for ; Sat, 21 Mar 2009 08:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2tWhWLlbKp5 for ; Sat, 21 Mar 2009 08:06:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4216728C0EC for ; Sat, 21 Mar 2009 08:06:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,399,1233532800"; d="scan'208";a="159425284" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 21 Mar 2009 15:07:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2LF7OdN013061 for ; Sat, 21 Mar 2009 08:07:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2LF7Ov8006376 for ; Sat, 21 Mar 2009 15:07:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 08:07:24 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 08:07:23 -0700 Message-ID: <49C502AB.9040103@cisco.com> Date: Sat, 21 Mar 2009 11:07:23 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2009 15:07:23.0850 (UTC) FILETIME=[BD59BAA0:01C9AA36] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1027; t=1237648044; x=1238512044; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-barnes-sip-rfc4244bis-00. txt |Sender:=20; bh=NOxhMmX5Yq39pPA3FX5pjk5sV6lBPQdpVdSxME16rec=; b=U97r1xpzw1UrdcVpqxj/f4NkeEDrbYR7XVDcGWkb4B7vapgiLRgRUe2Q4R +7Tppk6eKEJBoatvQMyPRKYU9i/kwnnxTl4JdWUVnD/mN0DRqsCKxcte6E3Y AIEYZepxEd; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 15:06:37 -0000 My main comment at this time, is that this bis document doesn't seem much different from the original. Section 10 calls out a bunch of things that I would put in the 'minor' category - certainly not worth a wholesale bis document if this is all we do. I think it'd be worth having a high level discussion on the changes we'd like to make to this document, and assess whether there are enough to warrant a bis. For example, many have complained about the complexity of HI; are there changes meant to help that? So far, frankly, the few comments on this draft have been suggestions for additions for the most part, and NOT simplifications. Is this meant as an omnibus for a bunch of extensions to HI? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From jdrosen@cisco.com Sat Mar 21 08:16:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E313A68BA for ; Sat, 21 Mar 2009 08:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iZ+vk530RNZ for ; Sat, 21 Mar 2009 08:16:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id EDE1228C0D0 for ; Sat, 21 Mar 2009 08:16:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,399,1233532800"; d="scan'208";a="68411860" Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2009 15:17:33 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id n2LFHXBV025657 for ; Sat, 21 Mar 2009 08:17:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2LFHXGc023537 for ; Sat, 21 Mar 2009 15:17:33 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 08:17:33 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 08:17:33 -0700 Message-ID: <49C5050C.5010907@cisco.com> Date: Sat, 21 Mar 2009 11:17:32 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2009 15:17:33.0649 (UTC) FILETIME=[28D1AC10:01C9AA38] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=846; t=1237648654; x=1238512654; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-kaplan-sip-secure-call-id -00.txt |Sender:=20; bh=56y6dQwOZC/leQal4TcUo5gKaSSV91ENqGY18NNNyMQ=; b=I3R/sPB+yPqTaJeuouRi9XJ5Jp+/4zuZxhp0Rw/2QoxGhT++fB5J6vO5O/ adtDg1To2iGnxHnf3bgu0dUDHQ9EkgimC6bpfv13+yM2AEDuwKmYbNqn8grM iam+ZD9YWo; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Subject: [Sip] comments on draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 15:16:49 -0000 Few comments. While this is not a bad idea, its not clear what the point of it is, given draft-kaplan-sip-session-id-01.txt suggests anyway a different header field for dialog identification through b2bua. Indeed the introduction in this document still talks about dialog correlation. Is this meant as a way to fix up existing call-id using extensions in a backwards compatible way, while session-id is for future things? I do apologize I did not follow much of the discussion at the end of last year if this was discussed then. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From jdrosen@cisco.com Sat Mar 21 08:28:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5253A692E for ; Sat, 21 Mar 2009 08:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9maeO+HME1Pd for ; Sat, 21 Mar 2009 08:28:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F1DB3A68BA for ; Sat, 21 Mar 2009 08:28:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,399,1233532800"; d="scan'208";a="271701739" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 21 Mar 2009 15:29:01 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id n2LFT1G2008641 for ; Sat, 21 Mar 2009 08:29:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2LFT1SJ001357 for ; Sat, 21 Mar 2009 15:29:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 08:29:00 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Mar 2009 08:29:00 -0700 Message-ID: <49C507BB.9010804@cisco.com> Date: Sat, 21 Mar 2009 11:28:59 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2009 15:29:00.0774 (UTC) FILETIME=[C260A060:01C9AA39] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3180; t=1237649341; x=1238513341; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-kaplan-sip-session-id-01= 20 |Sender:=20; bh=C6LYym4/OiRbDZa+AtkWC4b171azht1DsFPVQA6Q7Xw=; b=lBXtzw1vWj2pyeSIeaYgjEEg5US6EH3+BglgzOu0hRhKrEq65/XhhpwCTP Q9Z4V2mQ35kxnNu8FzKSNcuKjcGa4C9+EE7axdDyFlDhKQpu/C0ipYuIP7Wj SRREWKT+HZ; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Subject: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 15:28:14 -0000 I think we all agree that it would be nice if there was an identifier that worked through b2bua, which we could use to identify dialogs. However, I think the problem is far more complicated than this document talks about. The focus is on making it work through SBC type of boxes which aren't doing a lot of fancy call control, but are rewriting call-id and doing security things. There, I think the problem is easy. However, there are lots of cases where more complicated dialog manipulation mucks this up in a really horrible way. In particular, enterprise features like transfer, park/pickup, and so on, are often implemented by means of re-INVITEs on dialogs all anchored in the IP-PBX. For example, consider the following transfer implementation: A calls B. A calls C. Both calls are routed through an IP-PBX, which acts as a b2bua, and so we end up with something which looks like this: Please view in a fixed-width font such as Courier. +------------+ S1 S1 | | ------------ B --------| | A S2 | server | --------| | S2 | | ------------- C | | +------------+ Where S1 and S2 are the two session IDs. So far, so good. Now, A transfers the call to B. A sends a REFER on dialog S1. Like it or not, due to frequent REFER/transfer interop issues, this is sometimes implemented as a re-INVITE from the server, connecting B and C's media streams together, and then disconnecting A, so that you end up with: Please view in a fixed-width font such as Courier. +------------+ S1 | | ------------ B | | | server | | | S2 | | ------------- C | | +------------+ Now B and C are talking to each other. What is the session ID for this dialog? B and C were both originally the UAS on different dialogs with different session IDs! The problem happens more generally for any 3pcc operation, and the meta-issue is how to come up with a clear notion of who 'owns' the sessionID creation and destruction in cases where calls are transferred, moved, conferenced, parked and picked up all over the place. As such, a true comprehensive solution to this problem is much more complicated than just 'tell the SBCs to stop mucking with this header'. It would need to account for a wider range of 3pcc and other dialog manipulations which occur in the wild. Or, we could try to scope this in a more limited way, focusing on the basic A-calls-B case and solve just the SBC problem. Which is it? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From rjsparks@nostrum.com Sat Mar 21 08:34:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AE33A680D for ; Sat, 21 Mar 2009 08:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqYVr8Ou6rU2 for ; Sat, 21 Mar 2009 08:34:29 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 808663A682B for ; Sat, 21 Mar 2009 08:34:28 -0700 (PDT) Received: from dhcp-42f8.meeting.ietf.org (dhcp-42f8.meeting.ietf.org [130.129.66.248]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2LFYlhI067722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Mar 2009 10:34:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <702C34CC-1451-469C-AAC9-92AC4B913EAA@nostrum.com> From: Robert Sparks To: Jonathan Rosenberg In-Reply-To: <49C4F991.4080706@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Mar 2009 08:34:46 -0700 References: <20090302143002.24E643A694C@core3.amsl.com> <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> <49C4F991.4080706@cisco.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 130.129.66.248 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9147/Sat Mar 21 02:15:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP List Subject: Re: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 15:34:30 -0000 On Mar 21, 2009, at 7:28 AM, Jonathan Rosenberg wrote: > Thanks, Robert. > > Before commenting on the specific list of things, my meta-question > is what exactly we plan to do with this list. I think we have agreed > at previous meetings that we were not currently planning on taking > SIP to draft. Do you think that has changed? > > The document does say: > >> While not required by process until >> advancing to Draft, such a report would provide useful >> information to >> guide where we focus our energy maintaing the standard at Proposed. > > its not clear to me, what this means. Will we take this list, run > tests at sipit, and based on that define updates to 3261 to clarify? > Does this imply that there are tests we're NOT running which we > should be, that this draft helps us sort out? Yes - what I'm currently planning to do is start to collect interop statements on this list, evolve the list over time, and use that body of information to further inform what's implemented, what's giving people trouble, and what's not being used. > > > Thanks, > Jonathan R. > > Robert Sparks wrote: >> Also split out of steps-to-draft >> Begin forwarded message: >>> *From: *Internet-Drafts@ietf.org >>> *Date: *March 2, 2009 8:30:02 AM CST >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D Action:draft-sparks-sip-3261-interop- >>> statement-00.txt * >>> *Reply-To: *internet-drafts@ietf.org >> > >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : RFC3261 Interop Statement >>> Author(s) : R. Sparks >>> Filename : draft-sparks-sip-3261-interop-statement-00.txt >>> Pages : 9 >>> Date : 2009-03-02 >>> >>> This document captures an outline of the interoperability statements >>> that will be collected to construct an interoperability report for >>> RFC 3261. The outline is stil under review and should not be >>> treated >>> as complete, but will drive data collection at upcoming >>> interoperability events. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statement-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >> ------------------------------------------------------------------------ >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> ------------------------------------------------------------------------ >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com From rjsparks@nostrum.com Sat Mar 21 08:51:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3B83A698E for ; Sat, 21 Mar 2009 08:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deyRar2b+f1c for ; Sat, 21 Mar 2009 08:51:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6D8433A691B for ; Sat, 21 Mar 2009 08:51:04 -0700 (PDT) Received: from dhcp-42f8.meeting.ietf.org (dhcp-42f8.meeting.ietf.org [130.129.66.248]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2LFplFW069027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Mar 2009 10:51:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Jonathan Rosenberg In-Reply-To: <49C500C5.4000606@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Mar 2009 08:51:47 -0700 References: <20090302144501.AB1473A68B8@core3.amsl.com> <2F9C3E56-3810-450D-B700-DB9048349875@nostrum.com> <49C500C5.4000606@cisco.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 130.129.66.248 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9147/Sat Mar 21 02:15:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP List Subject: Re: [Sip] Fwd: I-D Action:draft-sparks-sip-invfix-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 15:51:06 -0000 On Mar 21, 2009, at 7:59 AM, Jonathan Rosenberg wrote: > Thanks, Robert. Comments below: > >> It modifies state transitions in the INVITE server state >> machine to absorb retransmissions of the INVITE request after >> encountering a unrecoverable transport error when sending a >> response. > > this little tidbit is not mentioned in section 3, whereas the other > parts of this section (section 4) are mentioned. I think a paragraph > describing this error is appropriate. Edit-itis. I will add such a paragraph. > > >> Implementations strictly conformant to [RFC3261] will process >> retransmitted initial INVITE requests as new requests. Proxies may >> forward them to different locations than the original. Proxies may >> also be used as anonymizing forwarders of bulk traffic. > > should mention the consequences of not addressing this transport- > error issue in my comment above. ok > > >> 7.1. UAS Impacts >> To allow a UAS to recognize retransmissions of an INVITE as >> retransmissions instead of new requests, a new state, "Accepted", >> is >> added to the INVITE server transaction state machine. > > this change is not JUST for a UAS - its also for proxies > implementing the server transaction machine, right? Is there a > reason this is worded for UAS? Hmm. I'm going to have to go read this through fairly carefully again. The change is to the client and server transaction state machines. It may be that the prose started to erroneously use UAC and UAS as synonyms for those state machines. Let me look through it and propose correction. > > >> Timer L reflects the amount of time the TU will wait to >> receive an ACK for the 2xx it is emitting before considering the >> transaction failed. > > but an ACK-200 is not part of this transaction... Right, the TU is tying those two transactions together. This is the period of time that the mentioned TU can be handing down 200s for retransmission. Given your question, it looks like I should change this motivation sentence to say that instead? > > > > also, I think its worth at least noting that this change does not > 100% solve the problem. If the UAC and any server transaction > between it, and the UAS, use a different value of T1, there can > still be a problem. In particular if the value of T1 at the UAC is > larger than the value at any of the downstream server transactions, > the server transaction may be destroyed while the UAC remains in the > calling state. I agree (and think there are other places where we should more strongly point out the pitfalls of changing T1 only in one part of a system). Could you propose text for this instance though? > > >> UAC Impacts >> In order to correctly distinguish retransmissions of 2xx responses >> from stray 2xx responses, the INVITE client state machine is >> modified >> to not transition immediately to "Terminated" on receipt of a 2xx >> response. > > as above, this is not specific to UAC and covers proxy/b2b client > transactions too, no? > >> Proxy Considerations >> A direct consequence of the change to the UAC state machine is >> that a >> transaction-stateful proxy will not foward any stray INVITE >> responses. > > It is not a consequence of the new state machines - but it is a > change in behavior we are making. I understand your objection, and think this may be another aspect of unintentional conflation of UAS/UAC with server and client state machines. When I propose a correction as mentioned above, I'll capture this. > > > > Meta-comment: A drawback of this change is that proxies and b2bua > will now hold transaction state for 64*t1 seconds after the > transaction is done, even for calls that set up immediately. In some > implementations this may be a non-trivial increase in memory usage, > and there may be other impacts (for example if an implementation had > a non-optimized transaction matching mechanism which only worked > well with a small number of transaction machines e.g., a linear > search). I think this implication needs to be called out more > strongly. You mention it as a security vulnerability, but its not > just a security issue. Where in the document would you think such a highlight would have the best impact? > > > -Jonathan R. > > Robert Sparks wrote: >> This got a fairly big touch due to better handling of transport >> error conditions. Please review this carefully. >> RjS >> Begin forwarded message: >>> *From: *Internet-Drafts@ietf.org >>> *Date: *March 2, 2009 8:45:01 AM CST >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D Action:draft-sparks-sip-invfix-03.txt * >>> *Reply-To: *internet-drafts@ietf.org >> > >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Correct transaction handling for 200 responses >>> to Session Initiation Protocol INVITE requests >>> Author(s) : R. Sparks >>> Filename : draft-sparks-sip-invfix-03.txt >>> Pages : 20 >>> Date : 2009-03-02 >>> >>> This document normatively updates RFC 3261, the Session Initiation >>> Protocol (SIP), to address an error in the specified handling of >>> success (200 class) responses to INVITE requests. Elements >>> following >>> RFC 3261 exactly will misidentify retransmissions of the request >>> as a >>> new, unassociated, request. The correction involves modifying the >>> INVITE transaction state machines. The correction also changes the >>> way responses that cannot be matched to an existing transaction are >>> handled to address a security risk. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-03.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >> ------------------------------------------------------------------------ >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> ------------------------------------------------------------------------ >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com From HKaplan@acmepacket.com Sat Mar 21 15:50:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49843A69C0 for ; Sat, 21 Mar 2009 15:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0wrv161y2vW for ; Sat, 21 Mar 2009 15:50:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3FE103A67E1 for ; Sat, 21 Mar 2009 15:50:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 21 Mar 2009 18:50:59 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 21 Mar 2009 18:50:58 -0400 From: Hadriel Kaplan To: Jonathan Rosenberg , IETF SIP List Date: Sat, 21 Mar 2009 18:50:56 -0400 Thread-Topic: [Sip] comments on draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmqODVNcG6t5FVqR9m28dgIYloFRQAPi0eg Message-ID: References: <49C5050C.5010907@cisco.com> In-Reply-To: <49C5050C.5010907@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] comments on draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 22:50:13 -0000 Hey Jonathan, Thanks for reviewing the draft! This draft is just about making UA's send = actual Call-ID values which do not reveal sensitive information, so that mi= ddleboxes are not made to change them purely for security purposes. The other draft, session-id, was changed - rev 02 is the latest - and that = rev is only about troubleshooting not dialog matching. This secure-call-id = draft is the one and only thing I propose for dialog matching purposes (and= it is the actual Call-ID header field value). -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Saturday, March 21, 2009 11:18 AM > To: IETF SIP List > Subject: [Sip] comments on draft-kaplan-sip-secure-call-id-00.txt >=20 > Few comments. >=20 > While this is not a bad idea, its not clear what the point of it is, > given draft-kaplan-sip-session-id-01.txt suggests anyway a different > header field for dialog identification through b2bua. Indeed the > introduction in this document still talks about dialog correlation. Is > this meant as a way to fix up existing call-id using extensions in a > backwards compatible way, while session-id is for future things? >=20 > I do apologize I did not follow much of the discussion at the end of > last year if this was discussed then. >=20 > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From HKaplan@acmepacket.com Sat Mar 21 16:03:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD343A6997 for ; Sat, 21 Mar 2009 16:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT+DjtuWhzKu for ; Sat, 21 Mar 2009 16:03:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C586D3A68B0 for ; Sat, 21 Mar 2009 16:03:47 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 21 Mar 2009 19:04:35 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 21 Mar 2009 19:04:35 -0400 From: Hadriel Kaplan To: Jonathan Rosenberg , IETF SIP List Date: Sat, 21 Mar 2009 19:04:32 -0400 Thread-Topic: [Sip] comments on draft-kaplan-sip-session-id-01 Thread-Index: AcmqOd2yqhhRcl8NR9OVTv99upsCtwAPaLnA Message-ID: References: <49C507BB.9010804@cisco.com> In-Reply-To: <49C507BB.9010804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 23:03:49 -0000 Hi Jonathan, Yeah there was some email discussion about the various cases whereby the se= ssion-id wouldn't match anymore. There are many, no doubt. My point back = then was that's ok: this is fixing cases that are broken, and not breaking = cases that are working, so it's improving the situation even if not with 10= 0% coverage. But I got the sense several folks didn't like the idea of not fixing 100% o= f the cases, so I updated this draft a couple weeks ago to rev-02, and remo= ved all the dialog-matching stuff and just made session-id for troubleshoot= ing purposes. I submitted secure-call-id to handle the Call-ID changing is= sues separately, in a different way. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Saturday, March 21, 2009 11:29 AM > To: IETF SIP List > Subject: [Sip] comments on draft-kaplan-sip-session-id-01 >=20 > I think we all agree that it would be nice if there was an identifier > that worked through b2bua, which we could use to identify dialogs. >=20 > However, I think the problem is far more complicated than this document > talks about. The focus is on making it work through SBC type of boxes > which aren't doing a lot of fancy call control, but are rewriting > call-id and doing security things. There, I think the problem is easy. >=20 > However, there are lots of cases where more complicated dialog > manipulation mucks this up in a really horrible way. In particular, > enterprise features like transfer, park/pickup, and so on, are often > implemented by means of re-INVITEs on dialogs all anchored in the > IP-PBX. For example, consider the following transfer implementation: >=20 > A calls B. A calls C. Both calls are routed through an IP-PBX, which > acts as a b2bua, and so we end up with something which looks like this: >=20 > Please view in a fixed-width font such as Courier. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > +------------+ S1 > S1 | | ------------ B > --------| | > A S2 | server | > --------| | S2 > | | ------------- C > | | > +------------+ >=20 > Where S1 and S2 are the two session IDs. So far, so good. Now, A > transfers the call to B. A sends a REFER on dialog S1. Like it or not, > due to frequent REFER/transfer interop issues, this is sometimes > implemented as a re-INVITE from the server, connecting B and C's media > streams together, and then disconnecting A, so that you end up with: >=20 > Please view in a fixed-width font such > as Courier. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > +------------+ S1 > | | ------------ B > | | > | server | > | | S2 > | | ------------- C > | | > +------------+ >=20 > Now B and C are talking to each other. What is the session ID for this > dialog? B and C were both originally the UAS on different dialogs with > different session IDs! >=20 > The problem happens more generally for any 3pcc operation, and the > meta-issue is how to come up with a clear notion of who 'owns' the > sessionID creation and destruction in cases where calls are transferred, > moved, conferenced, parked and picked up all over the place. >=20 > As such, a true comprehensive solution to this problem is much more > complicated than just 'tell the SBCs to stop mucking with this header'. > It would need to account for a wider range of 3pcc and other dialog > manipulations which occur in the wild. Or, we could try to scope this in > a more limited way, focusing on the basic A-calls-B case and solve just > the SBC problem. >=20 > Which is it? >=20 > -Jonathan R. >=20 > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From john.elwell@siemens.com Sun Mar 22 08:40:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575A228C240 for ; Sun, 22 Mar 2009 08:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZOXjbdoV3Ea for ; Sun, 22 Mar 2009 08:40:28 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 826CD28C236 for ; Sun, 22 Mar 2009 08:40:28 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGW00AA3ZKTP7@siemenscomms.co.uk> for sip@ietf.org; Sun, 22 Mar 2009 15:41:17 +0000 (GMT) Date: Sun, 22 Mar 2009 15:41:16 +0000 From: "Elwell, John" To: Adam Roach , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Comment on draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcmqUue95BZ4LZaCSj6/SiFfwZWvDA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 15:40:29 -0000 Adam, Thanks for producing this draft, which should set a good example for revisions of the other SIPCORE RFCs. I found little to comment on, apart from the following: In 4.5.1: "Notifiers MUST implement the GRUU extension defined in [I-D.ietf-sip-gruu], and MUST use a GRUU as their local target." 1. Is this just for a SUBSCRIBE-initiated dialog or for any dialog? 2. Should this be package-dependent? For example, there may be some event packages for which there is no need for subscribing to a resource on the same device. 3. What if the registrar doesn't support GRUU, and therefore the notifier is unable to obtain a GRUU? And by the way, in appendix C I didn't see a mention of changes relating to the use of GRUU. John From AUDET@nortel.com Sun Mar 22 09:10:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279943A6A37 for ; Sun, 22 Mar 2009 09:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGWf3eqluQIC for ; Sun, 22 Mar 2009 09:10:34 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0AAAB3A67F6 for ; Sun, 22 Mar 2009 09:10:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2MGAlM10631; Sun, 22 Mar 2009 16:10:47 GMT Received: from 47.102.152.167 ([47.102.152.167]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Mar 2009 16:11:11 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sun, 22 Mar 2009 09:11:07 -0700 From: "Francois Audet" To: Jonathan Rosenberg , SIP IETF , Mary BARNES , "B601:EXCH]"@zcars04e.nortel.com Message-ID: Thread-Topic: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt Thread-Index: AcmrCM6JQl7jVPxiTLCCOleoI30vAA== In-Reply-To: <49C502AB.9040103@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 16:10:35 -0000 Jonathan, you are correct, we have not done too many changes so far. In part because we are waiting on target-URI, in part because we didn't have enough time. And mostly, because we'd like to get agreement on how to proceed before. I'd like to discuss in the meeting. The problems with HI today, IMHO, are the following: - In order to make it work, today, people make "assumptions" about HI to be able to use it. Specifically, it is assumed that the first retargeting is listed, and so are the 2 last ones. This is then used by implementations as part of service logic and/or mapping to PSTN information (Original Called Number, Redirecting Number, Last Called Number). Unfortunately, HI (the spec) makes no such garantee: current usage however does. Furthermore, it is assumed that there are no recorded "routing" entries before the first one or between the last retarget and the final contact. One "simplification" that I would like to see is rules that makes the outcome predictable. First, I would like to mandate that at a minimum those entries (first, last two) are NEVER removed by proxies, and second, that retargets proper are labeled as such (as per target-URI discussion). That would greatly simplify History-Info. - There is a bug in ABNF. Corrected in current draft. - There is a gratuitous requirement that TLS be used on each hop for HI. I'd like to revisit that. Nobody enforces that, and I see no reason why HI would be treated differently than other similar headers (Via, Record-Route). - The examples are all wrong... They are all using Strict Routing. The chances of having an implementation using HI and Strict Routing in real life are close to zero. It makes the reading more complex, and makes HI look like some form of Record-Routing. - There have been some editorial comments on text being repetitive and wordy, and some proposals for simplification. - Finally, and importantly, the idea would be to integrate all the changes from target-URI, including the mid-path retarget (as per point one above), and the last-Contact replacement. On Mar21 2009 08:07 , "Jonathan Rosenberg" wrote: > My main comment at this time, is that this bis document doesn't seem > much different from the original. Section 10 calls out a bunch of things > that I would put in the 'minor' category - certainly not worth a > wholesale bis document if this is all we do. > > I think it'd be worth having a high level discussion on the changes we'd > like to make to this document, and assess whether there are enough to > warrant a bis. For example, many have complained about the complexity of > HI; are there changes meant to help that? So far, frankly, the few > comments on this draft have been suggestions for additions for the most > part, and NOT simplifications. Is this meant as an omnibus for a bunch > of extensions to HI? > > Thanks, > Jonathan R. From christer.holmberg@ericsson.com Sun Mar 22 09:48:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D113A6A60 for ; Sun, 22 Mar 2009 09:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1ISnC+YNs0X for ; Sun, 22 Mar 2009 09:48:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0E6503A6883 for ; Sun, 22 Mar 2009 09:48:45 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 89CD22095F; Sun, 22 Mar 2009 17:49:32 +0100 (CET) X-AuditID: c1b4fb3c-ad7f8bb000004c86-cb-49c66c1c121d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 582BA2004D; Sun, 22 Mar 2009 17:49:32 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 17:49:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Mar 2009 17:49:31 +0100 Message-ID: In-Reply-To: <49C2D7E5.5050709@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-199-06 Thread-Index: AcmprCvBUXIa1vfXSwCqsWBz79MHuwBX+q5w References: <49C2D7E5.5050709@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "SIP WG" X-OriginalArrivalTime: 22 Mar 2009 16:49:32.0137 (UTC) FILETIME=[2C81DD90:01C9AB0E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 16:48:46 -0000 Hi,=20 >Between Minneapolis and now, this document has become a lot more confusing, which I think=20 >bodes pretty ill for its hopes of being deployed. I can tell you it will be deployed, but let's focus on your comments :) >For example, in section 5: > > If the received initial request contains an 199 option tag, the UAS > SHOULD NOT send a 199 response for a dialog on which it intends to > send a final response... > >This reads as if sending a 199 response somehow absolves a UAS of sending a final response.=20 >Certainly this is not the intention of the draft (at least, not according to the text in=20 >section 7). Section 5 needs to be re-phrased to indicate what is actually intended here. I undrstand what you mean. The text can be read in a way that a UA could use 199 instead of the final response. That is certainly not the intention. The idea was to cover B2BUAs, which similar to forking proxies may not send final response for all dialogs. >In fact, on that topic, it's radically unclear to me how UASes fit into the entire scheme at=20 >all -- my understanding is that the 199 response is only sent by forking proxies. No, a UAS (both a UA and B2BUA) can also send it. This was discussed before, and there were no objections to allowing the UAS to send it. I do agree that end terminals normally may not send it, but you may have network entities (applicatoin servers, B2BUAs generating multiple dialogs etc) which will. >In section 6: > > When a forking proxy receives a non-2xx final response that it > recognizes as terminating one or more early dialogs, if the proxy > does not intend to forward the final response immediately (in > accordance with rules for a forking proxy) and the UAC has indicated > support for the 199 response code, the proxy SHOULD generate and send > a 199 response upstream for each early dialog terminated on the > downstream side by the non-2xx final response, except for any early > dialog for which the proxy has previously received and forwarded a > 199 response. > >What? On my best run at reading that, I made it to about the 81st word before the first=20 >predicate clause fell out of my head. If it's really as complicated as the structure of this=20 >sentence makes it seem, we need a flowchart or some other simplifying mechanism. I don't understand what is unclear, eventhough the wording and style may have some 3GPP influences :) Sure, there may be 81 words, but I think it describes what the proxy does in a rather straight forward way. I also don't see how a flowchart would make this text more clear, because the actions depends on what has/has not happened before. But, if you have a proposal on how to make the text more simple I am happy to incorporate that. Regards, Christer From eburger@standardstrack.com Sun Mar 22 14:20:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8975E3A6814 for ; Sun, 22 Mar 2009 14:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrMGaODVNPxj for ; Sun, 22 Mar 2009 14:20:34 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id CC5F73A6908 for ; Sun, 22 Mar 2009 14:20:34 -0700 (PDT) Received: from dhcp-45cc.meeting.ietf.org ([130.129.69.204]:65062) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LlV6b-0001Yn-87 for SIP@ietf.org; Sun, 22 Mar 2009 14:21:17 -0700 Message-Id: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> From: Eric Burger To: SIP IETF Content-Type: multipart/signed; boundary=Apple-Mail-40--407980048; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Mar 2009 10:59:01 -0700 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Sip] SIP INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 21:20:35 -0000 --Apple-Mail-40--407980048 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit In the hopes of making the discussion as short as possible in SIPPING: This is what we have consensus on the list: 1. Change all occurrences of "dialog mumble" with "dialog parameters" 2. Fix Table 1 to remove archaic references to 2543 3. Clarify language for overlapping INFOs and the "nil" package Open issues: We all agree on what the text says for the INVITE, UPDATE, and ACK methods, as well as the 101-299 (stuff counts) and 300-699 (something is broken, so it does not matter) response codes. It is probably sensible to exclude 100 from Recv-Info processing. Work for you? What about PRACK/PRACK 2xx? My vote is they count like everything else. What about you? Likewise, what about REFER/REFER 2xx? My vote here is INFO packages would be nonsensical during a refer, but perhaps you have a use case? If so, they work like everything else. The current text is pretty adamant that a missing Recv-Info means you do not (want to) understand Info Packages. If you start with a Recv- Info and you later drop the Recv-Info header, all bets are off. Are you happy with that? Since we do have Recv-Info: nil, we do have the opportunity to say we only change the Info Package set if a Recv-Info header is present. What do you think? Responses to the list now will hopefully make the discussion go swiftly. Likewise, if I have missed something, please bring it up now, NOT at the meeting. Recall this draft has finished WGLC. See you in SF, if you will be in SF; on Jabber if you will be remote; or via e-mail if you will be asynchronous. --Apple-Mail-40--407980048 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjIxNzU5MDFaMCMGCSqGSIb3 DQEJBDEWBBQ9kHVcSilccjUYHNuk37vEFspldTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBKfnh3hq3sKduTB7yHvD3PwRoCUGRm65easMZTEn/M94xK AgwFB3r46EtUsnPygkZm1TgroYYHLPKVCONjdtregMjobEOT46VAWKzFLJQJk3jM8LhjoEI536AI zdlxwMsBlxfrv9fw2Pd1yodkK/vYGuL9HkAwPTZ/+deO96hEcWJgFybydvntvYJ3+Dbqk8dYj3RG fDadN/rGg6Ebr/OOSEP39VHe0/h5MTv8afDeuY/phgMM6VqkpvPZgSIQtB8l43idDzgkZDc74Ky8 VGdCq2pko6m7/z6DUvhbD4fKP2UGkEzs3Q526OczQ4ePCIcKvkzefFFI3yzRnPs0WvoIAAAAAAAA --Apple-Mail-40--407980048-- From john.elwell@siemens.com Sun Mar 22 16:20:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E5D3A689C for ; Sun, 22 Mar 2009 16:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1wpyW6gRJWv for ; Sun, 22 Mar 2009 16:20:01 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 8C2433A659C for ; Sun, 22 Mar 2009 16:20:00 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGX00F3HKUMTC@siemenscomms.co.uk> for sip@ietf.org; Sun, 22 Mar 2009 23:20:46 +0000 (GMT) Date: Sun, 22 Mar 2009 23:20:44 +0000 From: "Elwell, John" In-reply-to: To: Francois Audet , Jonathan Rosenberg , SIP IETF , Mary BARNES , "B601:EXCH]"@zcars04e.nortel.com Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001AAD91F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt Thread-Index: AcmrCM6JQl7jVPxiTLCCOleoI30vAAAO9/Jg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49C502AB.9040103@cisco.com> Subject: Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 23:20:02 -0000 Part of the complexity is in the indexing mechanism. Do we really need this? John=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Francois Audet > Sent: 22 March 2009 16:11 > To: Jonathan Rosenberg; SIP IETF; Mary BARNES;=20 > "B601:EXCH]"@zcars04e.nortel.com > Subject: Re: [Sip] comments on draft-barnes-sip-rfc4244bis-00.txt >=20 > Jonathan, you are correct, we have not done too many changes so far. > In part because we are waiting on target-URI, in part because=20 > we didn't have > enough time. And mostly, because we'd like to get agreement on how to > proceed before. I'd like to discuss in the meeting. >=20 > The problems with HI today, IMHO, are the following: >=20 > - In order to make it work, today, people make "assumptions"=20 > about HI to > be able to use it. Specifically, it is assumed that the first > retargeting is listed, and so are the 2 last ones. This is then > used by implementations as part of service logic and/or mapping to > PSTN information (Original Called Number, Redirecting Number, Last > Called Number). Unfortunately, HI (the spec) makes no such garantee: > current usage however does. Furthermore, it is assumed that=20 > there are > no recorded "routing" entries before the first one or=20 > between the last > retarget and the final contact. One "simplification" that I=20 > would like > to see is rules that makes the outcome predictable. First,=20 > I would like > to mandate that at a minimum those entries (first, last=20 > two) are NEVER > removed by proxies, and second, that retargets proper are labeled as > such (as per target-URI discussion). That would greatly simplify > History-Info. >=20 > - There is a bug in ABNF. Corrected in current draft. >=20 > - There is a gratuitous requirement that TLS be used on each hop for > HI. I'd like to revisit that. Nobody enforces that, and I=20 > see no reason > why HI would be treated differently than other similar headers (Via, > Record-Route). >=20 > - The examples are all wrong... They are all using Strict Routing. The > chances of having an implementation using HI and Strict=20 > Routing in real > life are close to zero. It makes the reading more complex, and makes > HI look like some form of Record-Routing. >=20 > - There have been some editorial comments on text being repetitive and > wordy, and some proposals for simplification. >=20 > - Finally, and importantly, the idea would be to integrate all the > changes from target-URI, including the mid-path retarget=20 > (as per point > one above), and the last-Contact replacement. >=20 >=20 >=20 > On Mar21 2009 08:07 , "Jonathan Rosenberg" wrote: >=20 > > My main comment at this time, is that this bis document doesn't seem > > much different from the original. Section 10 calls out a=20 > bunch of things > > that I would put in the 'minor' category - certainly not worth a > > wholesale bis document if this is all we do. > >=20 > > I think it'd be worth having a high level discussion on the=20 > changes we'd > > like to make to this document, and assess whether there are=20 > enough to > > warrant a bis. For example, many have complained about the=20 > complexity of > > HI; are there changes meant to help that? So far, frankly, the few > > comments on this draft have been suggestions for additions=20 > for the most > > part, and NOT simplifications. Is this meant as an omnibus=20 > for a bunch > > of extensions to HI? > >=20 > > Thanks, > > Jonathan R. >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From adam@nostrum.com Sun Mar 22 16:23:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2DF23A659C for ; Sun, 22 Mar 2009 16:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9DxjeTDHWYp for ; Sun, 22 Mar 2009 16:23:20 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id BF8153A659B for ; Sun, 22 Mar 2009 16:23:19 -0700 (PDT) Received: from dhcp-47f7.meeting.ietf.org (dhcp-47f7.meeting.ietf.org [130.129.71.247]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2MNO5kE002940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Mar 2009 18:24:06 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49C6C895.9040204@nostrum.com> Date: Sun, 22 Mar 2009 16:24:05 -0700 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.71.247 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9149/Sun Mar 22 00:12:21 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip@ietf.org Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 23:23:21 -0000 Elwell, John wrote: > I found little to comment on, apart from the following: > > In 4.5.1: > "Notifiers MUST implement the GRUU extension defined in > [I-D.ietf-sip-gruu], and MUST use a GRUU as their local target." > > 1. Is this just for a SUBSCRIBE-initiated dialog or for any dialog? > The intention is that any UA capable of sending a NOTIFY message in any context will use a GRUU for all dialogs. This mechanism is to be used instead of dialog re-use. The most common case of dialog re-use right now is sending a SUBSCRIBE down an existing dialog that was initially established by an INVITE. So, for current use cases, using GRUU in INVITE dialogs is the most important thing. For future-proofing, we need to require GRUU for all dialogs. > 2. Should this be package-dependent? For example, there may be some > event packages for which there is no need for subscribing to a resource > on the same device. > I think it's likely to be too difficult to guess, ahead of time, which packages will never need to target the same device as another dialog. It's far too easy to envision a circumstance in which we say, "I can't think of any reason someone would need to target a specific device for package foo," only to discover a really clever usage several years later that we have accidentally precluded. > 3. What if the registrar doesn't support GRUU, and therefore the > notifier is unable to obtain a GRUU? > Note, first of all, that this constraint is placed on notifiers, and not on subscribers. For the vast majority of notifiers, a self-made GRUU (which requires no registrar support) is appropriate. However, your point is taken, and we should discuss circumstances in which registering clients that send NOTIFY messages request a GRUU from their registrar, yet receive none. Because of the true interoperability nightmare that has resulted from dialog sharing, my suggestion would be to disable notifier functionality on those endpoints under such circumstances (perhaps with an implementation option to fall back to 3265 behavior for the truly masochistic). > And by the way, in appendix C I didn't see a mention of changes relating > to the use of GRUU. > Sorry about that. My intention was to include that as part of C.1.21, but I left it out. /a From john.elwell@siemens.com Sun Mar 22 16:29:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEB43A6A60 for ; Sun, 22 Mar 2009 16:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkotVSflyhsU for ; Sun, 22 Mar 2009 16:29:29 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1158828C0E4 for ; Sun, 22 Mar 2009 16:29:29 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGX00F7QLAITC@siemenscomms.co.uk> for sip@ietf.org; Sun, 22 Mar 2009 23:30:18 +0000 (GMT) Date: Sun, 22 Mar 2009 23:30:15 +0000 From: "Elwell, John" In-reply-to: A To: Christer Holmberg , Adam Roach , SIP WG Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001AAD921@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] draft-ietf-sip-199-06 Thread-Index: AcmprCvBUXIa1vfXSwCqsWBz79MHuwBX+q5wAA5N7lA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49C2D7E5.5050709@nostrum.com> A Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 23:29:30 -0000 =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: 22 March 2009 16:50 > To: Adam Roach; SIP WG > Subject: Re: [Sip] draft-ietf-sip-199-06 >=20 >=20 > Hi,=20 >=20 > >Between Minneapolis and now, this document has become a lot more > confusing, which I think=20 > >bodes pretty ill for its hopes of being deployed. >=20 > I can tell you it will be deployed, but let's focus on your=20 > comments :) >=20 > >For example, in section 5: > > > > If the received initial request contains an 199 option=20 > tag, the UAS > > SHOULD NOT send a 199 response for a dialog on which it intends to > > send a final response... > > > >This reads as if sending a 199 response somehow absolves a UAS of > sending a final response.=20 > >Certainly this is not the intention of the draft (at least, not > according to the text in=20 > >section 7). Section 5 needs to be re-phrased to indicate what is > actually intended here. >=20 > I undrstand what you mean. The text can be read in a way that=20 > a UA could > use 199 instead of the final response. That is certainly not the > intention. The idea was to cover B2BUAs, which similar to forking > proxies may not send final response for all dialogs. >=20 > >In fact, on that topic, it's radically unclear to me how=20 > UASes fit into > the entire scheme at=20 > >all -- my understanding is that the 199 response is only sent by > forking proxies. >=20 > No, a UAS (both a UA and B2BUA) can also send it. This was discussed > before, and there were no objections to allowing the UAS to send it. >=20 > I do agree that end terminals normally may not send it, but=20 > you may have > network entities (applicatoin servers, B2BUAs generating multiple > dialogs etc) which will. [JRE] The reason we need to cover B2BAUs is that a B2BUA may behave like a proxy and withhold the sending of a final response until it receives responses from other branches it has created. So can we not have the same rule for any server (proxy or UAS), telling it what to do when a final response is withheld? This might make it simpler. There would not then be any need for a normal UAS to send 199. >=20 > >In section 6: > > > > When a forking proxy receives a non-2xx final response that it > > recognizes as terminating one or more early dialogs, if the proxy > > does not intend to forward the final response immediately (in > > accordance with rules for a forking proxy) and the UAC=20 > has indicated > > support for the 199 response code, the proxy SHOULD generate and > send > > a 199 response upstream for each early dialog terminated on the > > downstream side by the non-2xx final response, except for=20 > any early > > dialog for which the proxy has previously received and forwarded a > > 199 response. > > > >What? On my best run at reading that, I made it to about the=20 > 81st word > before the first=20 > >predicate clause fell out of my head. If it's really as=20 > complicated as > the structure of this=20 > >sentence makes it seem, we need a flowchart or some other simplifying > mechanism. >=20 > I don't understand what is unclear, eventhough the wording=20 > and style may > have some 3GPP influences :) Sure, there may be 81 words, but=20 > I think it > describes what the proxy does in a rather straight forward way. >=20 > I also don't see how a flowchart would make this text more clear, > because the actions depends on what has/has not happened=20 > before. But, if > you have a proposal on how to make the text more simple I am happy to > incorporate that. [JRE] I agree with Adam that it is unclear. When trying to write down a normative requirement that is dependent on multiple conditions, it often helps to list the conditions in a bulleted list, e.g.: If - foo1 - and foo2 - and not foo3 then do bar. John >=20 > Regards, >=20 > Christer > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From dwing@cisco.com Sun Mar 22 22:38:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FA83A677C for ; Sun, 22 Mar 2009 22:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDP8VrmDaExG for ; Sun, 22 Mar 2009 22:38:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E9C8E3A6765 for ; Sun, 22 Mar 2009 22:38:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,406,1233532800"; d="scan'208";a="159792699" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2009 05:38:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2N5d0CZ007799 for ; Sun, 22 Mar 2009 22:39:00 -0700 Received: from dwingwxp01 (sjc-vpn2-223.cisco.com [10.21.112.223]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2N5d0I4024520 for ; Mon, 23 Mar 2009 05:39:00 GMT From: "Dan Wing" To: Date: Sun, 22 Mar 2009 22:39:00 -0700 Message-ID: <006c01c9ab79$ab05b400$df70150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acmreaq+nEubSRzbThKWlV5xksNRQQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=69; t=1237786740; x=1238650740; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Skype=20for=20SIP |Sender:=20; bh=qor2Y0rkR7JfdrIPF5kqYryqNTEvXGkruWyFLMotUwk=; b=jo0rU3KONvxVn4L8/HJcJX/IyIdHGk2ZF2BABb9rP3RkDv1pNtuVoAVDJv 8FtogE44OUV3XbLEAPgfit2BNpTCIUVylwquM6eonIcjKL1RyNytTixuMzlE 0CQY43ZiED; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Sip] Skype for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 05:38:12 -0000 http://www.networkworld.com/news/2009/032309-skype-sip.html?hpg1=bn From christer.holmberg@ericsson.com Sun Mar 22 23:47:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976D13A67B5 for ; Sun, 22 Mar 2009 23:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.763 X-Spam-Level: X-Spam-Status: No, score=-5.763 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqumXLMRrja5 for ; Sun, 22 Mar 2009 23:47:35 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 686413A67A8 for ; Sun, 22 Mar 2009 23:47:35 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9CF10206D5; Mon, 23 Mar 2009 07:48:23 +0100 (CET) X-AuditID: c1b4fb3c-ae7fabb000004c86-89-49c730b7348e Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6D66D204DD; Mon, 23 Mar 2009 07:48:23 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 07:48:23 +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: Mon, 23 Mar 2009 07:48:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-199-06 Thread-Index: AcmprCvBUXIa1vfXSwCqsWBz79MHuwBX+q5wAA5N7lAADz1hDg== References: <49C2D7E5.5050709@nostrum.com> A <0D5F89FAC29E2C41B98A6A762007F5D001AAD921@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Adam Roach" , "SIP WG" X-OriginalArrivalTime: 23 Mar 2009 06:48:23.0277 (UTC) FILETIME=[5C3459D0:01C9AB83] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 06:47:36 -0000 Hi John, >>For example, in section 5: >> >> If the received initial request contains an 199 option tag, the UAS >> SHOULD NOT send a 199 response for a dialog on which it intends to >> send a final response... >> >>This reads as if sending a 199 response somehow absolves a UAS of = sending a final response.=20 >>Certainly this is not the intention of the draft (at least, not = according to the text in=20 >>section 7). Section 5 needs to be re-phrased to indicate what is = actually intended here. >=20 >I undrstand what you mean. The text can be read in a way that a UA = could >use 199 instead of the final response. That is certainly not the >intention. The idea was to cover B2BUAs, which similar to forking >proxies may not send final response for all dialogs. >=20 >>In fact, on that topic, it's radically unclear to me how UASes fit = into the entire scheme at=20 >>all -- my understanding is that the 199 response is only sent by = forking proxies. >=20 >No, a UAS (both a UA and B2BUA) can also send it. This was discussed >before, and there were no objections to allowing the UAS to send it. >=20 >I do agree that end terminals normally may not send it, but you may = have >network entities (applicatoin servers, B2BUAs generating multiple >dialogs etc) which will. >[JRE] The reason we need to cover B2BAUs is that a B2BUA may behave = like >a proxy and withhold the sending of a final response until it receives >responses from other branches it has created. So can we not have the >same rule for any server (proxy or UAS), telling it what to do when a >final response is withheld? This might make it simpler. There would not >then be any need for a normal UAS to send 199. You can have network entities which act as "normal" UAS, which also want = to send 199. They may e.g. have been configured to do so, since the = forking proxy does not support 199. Etc. And, the text already says that a UAS should not send a 199, unless it = has been configured to do so. But, I don't think we should forbid it = from doing so. >>In section 6: >> >> When a forking proxy receives a non-2xx final response that it >> recognizes as terminating one or more early dialogs, if the proxy >> does not intend to forward the final response immediately (in >> accordance with rules for a forking proxy) and the UAC has = indicated >> support for the 199 response code, the proxy SHOULD generate and = send >> a 199 response upstream for each early dialog terminated on the >> downstream side by the non-2xx final response, except for any early >> dialog for which the proxy has previously received and forwarded a >> 199 response. >> >>What? On my best run at reading that, I made it to about the 81st word >>before the first predicate clause fell out of my head. If it's really = as=20 >>complicated as the structure of this sentence makes it seem, we need a = flowchart or some other=20 >>simplifying mechanism. >=20 >I don't understand what is unclear, eventhough the wording and style = may >have some 3GPP influences :) Sure, there may be 81 words, but I think = it >describes what the proxy does in a rather straight forward way. >=20 >I also don't see how a flowchart would make this text more clear, >because the actions depends on what has/has not happened=20 >before. But, if you have a proposal on how to make the text more simple = I am happy to >incorporate that. >[JRE] I agree with Adam that it is unclear. When trying to write down a >normative requirement that is dependent on multiple conditions, it = often >helps to list the conditions in a bulleted list, e.g.: >If >- foo1 >- and foo2 >- and not foo3 >then do bar. I can try to do that, if people think it's more clear. Regards, Christer From ietf.hanserik@gmail.com Mon Mar 23 01:50:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB8C3A6B9B for ; Mon, 23 Mar 2009 01:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6B1MI-k4DNh for ; Mon, 23 Mar 2009 01:50:14 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id D07053A6A65 for ; Mon, 23 Mar 2009 01:50:13 -0700 (PDT) Received: by ewy9 with SMTP id 9so1511000ewy.37 for ; Mon, 23 Mar 2009 01:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ohg/lTMJEjCU5ajWrI3LIhk/WbWnPaTZBEOim2sySlg=; b=d8sKk3IZ5BDg07TibZbvEcL9BTYX2fBwHxxd/i2osenJ3XJHl7LoQjoXTJ80171QX/ dwpori+hx0pdis04jFq9KspJfREUdv6sTaON8lxkDq7HnwOTYyWgFFlmw87hyAaGh0y6 A/htvvJ2P5l3poN6shstsIs9SzMf25uWyfVnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T6j+V80A72zqRZ2+QuoVEfmmt8RNAqSfCmEk6TlA4pgYmD4xSDuVH0cjsTGtUqLuo1 JU+2AeKK3Ko8jsN4Tk0BqUJ9tfd4WlWr5IP/szNGMz9AxR5TxhTySA61kcZciL6b1J15 XTAKWTztmbWO1V/nZDaDKfI0Q9TqA+/aryGOc= MIME-Version: 1.0 Received: by 10.216.1.69 with SMTP id 47mr2152280wec.224.1237798262721; Mon, 23 Mar 2009 01:51:02 -0700 (PDT) In-Reply-To: References: <49C2D7E5.5050709@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D001AAD921@GBNTHT12009MSX.gb002.siemens.net> Date: Mon, 23 Mar 2009 09:51:02 +0100 Message-ID: <9ae56b1e0903230151l31f4d6e1hef5a7c47c53cf152@mail.gmail.com> From: Hans Erik van Elburg To: Christer Holmberg Content-Type: multipart/alternative; boundary=0016364d2933c0ce6d0465c55db3 Cc: SIP WG , Adam Roach , "Elwell, John" Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 08:50:15 -0000 --0016364d2933c0ce6d0465c55db3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes you should, people do think that ;-) /Hans Erik van Elburg On Mon, Mar 23, 2009 at 7:48 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I can try to do that, if people think it's more clear. --0016364d2933c0ce6d0465c55db3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes you should, people do think that ;-)

/Hans Erik va= n Elburg

On Mon, Mar 23, 2009 at 7:48 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:
I can try to do that, if people think it's more clear.

--0016364d2933c0ce6d0465c55db3-- From tom.taylor@rogers.com Mon Mar 23 05:34:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FA383A690E for ; Mon, 23 Mar 2009 05:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeE-KgULyrrx for ; Mon, 23 Mar 2009 05:34:30 -0700 (PDT) Received: from smtp128.rog.mail.re2.yahoo.com (smtp128.rog.mail.re2.yahoo.com [206.190.53.33]) by core3.amsl.com (Postfix) with SMTP id 3DA983A67A3 for ; Mon, 23 Mar 2009 05:34:29 -0700 (PDT) Received: (qmail 43350 invoked from network); 23 Mar 2009 12:35:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BNP0/qVcxVHb4PbzR+dxs12aGEu+fsx6jAc0o18pIBqqt3EFXSbEWgmS1nnNL4Rpt3QTizloUI/oumnYgIa8g63S8uziDcxGRHCWZe+HXLRNF8pVCCE3aDZ8B83hPo+E+cGcjz+Ymb5pSWgh12lkaaGXjDexkn+br14sdZ/FKzE= ; Received: from unknown (HELO ?12.149.133.253?) (tom.taylor@12.149.133.253 with plain) by smtp128.rog.mail.re2.yahoo.com with SMTP; 23 Mar 2009 12:35:19 -0000 X-YMail-OSG: ypJi9CEVM1mwDmBLEmn3oNYkwBntXMyi4TEvTQHg9PUIBvumJwdJ4.3z1R4mHlKrWw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C78202.9030604@rogers.com> Date: Mon, 23 Mar 2009 05:35:14 -0700 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <49C2D7E5.5050709@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP WG , Adam Roach Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 12:34:31 -0000 Some text , as requested. Christer Holmberg wrote: ... > >> In section 6: >> >> When a forking proxy receives a non-2xx final response that it >> recognizes as terminating one or more early dialogs, if the proxy >> does not intend to forward the final response immediately (in >> accordance with rules for a forking proxy) and the UAC has indicated >> support for the 199 response code, the proxy SHOULD generate and > send >> a 199 response upstream for each early dialog terminated on the >> downstream side by the non-2xx final response, except for any early >> dialog for which the proxy has previously received and forwarded a >> 199 response. >> ... My suggestion: "When a forking proxy receives a non-2xx final response that it recognizes as terminating one or more early dialogs, it SHOULD generate and send a 199 response upstream for each such early dialog satisfying the following conditions: -- the proxy does not intend to forward the final response immediately (in accordance with rules for a forking proxy); -- the UAC has indicated support for the 199 response code; -- the proxy has not already received and forwarded a 199 response for that early dialogue." From victor.pascual.avila@gmail.com Mon Mar 23 06:17:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D5A3A6BAF for ; Mon, 23 Mar 2009 06:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6coRKZlH6FfA for ; Mon, 23 Mar 2009 06:17:08 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id D87AA3A6858 for ; Mon, 23 Mar 2009 06:17:07 -0700 (PDT) Received: by ewy9 with SMTP id 9so1613641ewy.37 for ; Mon, 23 Mar 2009 06:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=irQaxVng7sL1EYxK1gCvKGlPDR208FZnXXdXehFLOHU=; b=dYRvsIukDkr0ofwo+GFYGFNtsDyU8Mqy848XSyuEGVT2yWsTevfKZqETgLHz3y4GN0 GT60OV3KdNsJkGYxIYBJ8HA9My7gDNtA/2KRBSN2RQAraGfht6XhYAhesj8sZwLhKFzR zqyNl600hwenf4115V6Qn02yYr5Bg8ks3K4Ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TG+KJ/1DkuSC45VebZj5xpnh7xXtGQ4rnlkpPhbrzWzRf6vgNMDLHKWsSrJNN8ge1r bhiJfLSXyp8sbCVlBK6ARIqOmujS8+Qgl56uNqwVYk+QPxMVkpif2o+QQ89DK3kM5pme T5SAcMYVS6VhEKR0RCJcymV+N0OOfEvjwF4R0= MIME-Version: 1.0 Received: by 10.210.141.17 with SMTP id o17mr1160897ebd.3.1237814276875; Mon, 23 Mar 2009 06:17:56 -0700 (PDT) In-Reply-To: <006c01c9ab79$ab05b400$df70150a@cisco.com> References: <006c01c9ab79$ab05b400$df70150a@cisco.com> Date: Mon, 23 Mar 2009 14:17:56 +0100 Message-ID: <618e24240903230617r41ae5459k8206db26a6162c4a@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org Subject: Re: [Sip] Skype for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:17:09 -0000 On Mon, Mar 23, 2009 at 6:39 AM, Dan Wing wrote: > http://www.networkworld.com/news/2009/032309-skype-sip.html?hpg1=3Dbn http://ecommmedia.com/blog/2009/03/mark-spencer-transcript.html --=20 Victor Pascual =C3=81vila From brett@broadsoft.com Mon Mar 23 06:19:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5A03A69D7 for ; Mon, 23 Mar 2009 06:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbmT3Aj2gqaz for ; Mon, 23 Mar 2009 06:19:11 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 8BECC3A6842 for ; Mon, 23 Mar 2009 06:19:11 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 23 Mar 2009 06:19:57 -0700 From: Brett Tate To: Eric Burger , SIP IETF Date: Mon, 23 Mar 2009 06:19:57 -0700 Thread-Topic: [Sip] SIP INFO Thread-Index: AcmrNCzLOLSjDQ3URTikHXQVAOWsHwAAnwuw Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10BFF48D69@mbx02.citservers.local> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> In-Reply-To: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] SIP INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:19:12 -0000 > We all agree on what the text says for the INVITE, UPDATE,=20 > and ACK methods, as well as the 101-299 (stuff counts) and=20 > 300-699 (something is broken, so it does not matter)=20 > response codes. In case it matters, ACK can't be authenticated and introduces more race con= ditions. RFC 3261 did not define Supported and Allow to be optional within an ACK. = I mention it in case there were similar race condition and authentication c= oncerns associated with using ACK to indicate/update what is supported and = allowed. > It is probably sensible to exclude 100 from Recv-Info processing. > Work for you? Yes. > What about PRACK/PRACK 2xx? My vote is they count like everything > else. What about you? Because of race conditions, I prefer the header not be allowed. However my= concerns would be partially alleviated if not required to include Recv-Inf= o to avoid disabling support. It has been awhile since I read RFC 3262 in depth. If UAS sends INVITE 2xx= while awaiting PRACK, should it return PRACK 481 or PRACK 200 upon receipt= of PRACK? If acceptable to return PRACK 200 during the race condition, sh= ould the PRACK's Recv-Info be ignored if received before or after ACK? If = it returns PRACK 200 and UAS receives PRACK 200 after INVITE 200, should th= e UAC ignore PRACK 200's Recv-Info? > Likewise, what about REFER/REFER 2xx? My vote here is INFO packages > would be nonsensical during a refer, but perhaps you have a use case? > If so, they work like everything else. I have no preference, especially if not required to include Recv-Info to av= oid disabling support. > The current text is pretty adamant that a missing Recv-Info means you > do not (want to) understand Info Packages. If you start with a Recv- > Info and you later drop the Recv-Info header, all bets are off. Are > you happy with that? =20 No. It requires uselessly adding the header everywhere. It increases race= condition complications. It shouldn't be more mandatory everywhere than Supported and Allow. I'm no= t opposed to making it mandatory within INVITE, re-INVITE, and their 2xx; i= t should at least be optional within UPDATE. Concerning other locations, I= 'm not opposed to it being optional although it introduces more potential f= or race conditions. > Since we do have Recv-Info: nil, we do have the opportunity to=20 > say we only change the Info Package set if a Recv-Info header=20 > is present. What do you think? I like the suggested modification. If retarget to a device not supporting the RFC, the modification potentiall= y raises the need for a Supported option-tag unless Recv-Info remains manda= tory (to avoid disabling) within a few locations. However B2BUAs can still= work around the issue if the working group doesn't want to define an optio= n-tag for the RFC. > Likewise, if I have missed something, please bring it up now, NOT at > the meeting. Recall this draft has finished WGLC. What was the outcome of INFO 489 response MUST trigger release of call disc= ussion? Thanks, Brett From pkyzivat@cisco.com Mon Mar 23 06:25:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5ED28C0F7 for ; Mon, 23 Mar 2009 06:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.638 X-Spam-Level: X-Spam-Status: No, score=-4.638 tagged_above=-999 required=5 tests=[AWL=1.961, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNem0cc3SCzd for ; Mon, 23 Mar 2009 06:25:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ABAE23A6842 for ; Mon, 23 Mar 2009 06:25:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,408,1233532800"; d="scan'208";a="68619856" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 23 Mar 2009 13:26:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2NDQP76028399; Mon, 23 Mar 2009 06:26:25 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2NDQNxm012438; Mon, 23 Mar 2009 13:26:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 09:26:24 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 09:26:24 -0400 Message-ID: <49C78DFF.3000906@cisco.com> Date: Mon, 23 Mar 2009 09:26:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hans Erik van Elburg References: <49C3743F.1070406@ericsson.com> <49C39D1C.1040701@cisco.com> <49C42521.7080706@gmail.com> In-Reply-To: <49C42521.7080706@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2009 13:26:24.0190 (UTC) FILETIME=[F6567DE0:01C9ABBA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4882; t=1237814785; x=1238678785; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Policy=20to=20register=20media= 20feature=20tags |Sender:=20; bh=5RhrTdxIGptwY9eAqu4vT6f6LPIF5BR3hG9uG/aliVk=; b=RJROZmsFU/ty2vG6Bx19aPs8BwNmNadVyQI1CQpjJbuL6b/Cnu2s6GoEo/ hBThj7573EcsUiUbGeZhZOrn/1t6DPAuMz71meNaukY/z0NxrD2eROWqkrex FTITLyfynS; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip Subject: Re: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:25:37 -0000 Inline... Hans Erik van Elburg wrote: > Responses inline... > > /Hans Erik > > Paul Kyzivat wrote: >> On one side were those who wanted capabilities and preferences to be >> stated in terms of feature tags that are well known and orthogonal. On >> the other side were those who prefer to associate arbitrary names to >> collections of features and then negotiate on the basis of the names >> of those collections. >> >> Using the latter approach its possible that interoperation will fail >> because the parties don't share a common name for a collection of >> features even though they both possess the necessary features to >> interoperate. > That is a feature. *what* is a feature? > This interoperability "problem" only occurs when the > originating party includes the header field parameters "require" and > "explicit" in the Accept-Contact header field containing the feature > tag. In this case the failure of the call when not all of the receiving > UA's support the feature is intended! Lets get tangible about this. (This is retracing old ground, but people sometimes have short memories.) Suppose Alice calls Bob. Alice has the latest and greatest 3gpp phone with the capability to make audio/video calls, and would prefer to do so if possible. Bob has an open source softphone running on his PC. It is fully capable of audio/video operation using a wide source of codecs. He also has a plain vanilla audio phone registered to the same AOR. Alice's phone will send an invite with offer containing audio and video media. It can also include callerprefs to bias the selection of device in favor of one that will support audio and video. It could do so a variety of different ways: - indicate preference for audio and video - indicate preference for the 3gpp "videophone" feature. - indicate preference for audio, video, *and* 3gpp "videophone" Assuming none of these *require* these features, the first and the last will both bias towards the softphone and result in an audio/video call. The middle will probably cause both of bob's phones to ring and audio/video will result if he happens to answer the softphone. The situation is worse if Alice *requires* both audio and video, and as a result *requires* the 3gpp videophone feature. The problem is one of orthogonality. the features should all be orthogonal to one another. If "3gpp videophone" encompasses "audio, video, and the 3gpp videophone look and feel", then it isn't orthogonal to the existing audio and video feature tags. If it only represents a preference for whatever extra goodies are provided by 3gpp over and above audio and video, then it may be a reasonable feature tag. (Note that I have no knowledge of how 3gpp intends to name an use features. I'm just exploring the possibilities.) >> I don't have a problem with independent groups defining new feature >> tags, as long as they are primitive and orthogonal to existing ones. >> But I do have a problem with defining feature tags that identify >> collections of features, especially when the mapping from the >> identifier to the collection of features is not public. > Well who is going to determine what can be called a feature and what not. > I also like to see where this principle is documented to apply to the > global tree. IMO it was probably a mistake to use the existing feature tag mechanism for callee caps in the first place. While there are some simmilarities, the intentions are quite different. But we are where we are. I don't know if we can impose additional rules on the global tree or not. I expect that imposing an orthogonality constraint might not be so controversial, and so *might* be possible. But the challenge may be in *defining* orthogonality in an application-independent way. It would be easier to do that in the context of sip, though still not trivial. >> The bottom line is that I think this sort of thing needs to be >> thrashed out within the sip community. So I think the RFC process is >> the right process. > I think that bending the rules because some SIP people don't like on how > other organisations are applying SIP in their solutions will alieanate > those SIP users from that same SIP community. So I seriously hope we > will not go down that path. Lets see what others say. IMO its important that those other communities don't use this mechanism to erect more walls around their garden. Thanks, Paul > /Hans Erik > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From eburger@standardstrack.com Mon Mar 23 06:28:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C283A6A65 for ; Mon, 23 Mar 2009 06:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA2nzvS4fMf3 for ; Mon, 23 Mar 2009 06:28:26 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 026E03A6807 for ; Mon, 23 Mar 2009 06:28:26 -0700 (PDT) Received: from [130.129.69.204] (port=53204 helo=dhcp-45cc.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LlkDI-00075O-7W; Mon, 23 Mar 2009 06:29:13 -0700 Message-Id: From: Eric Burger To: Brett Tate In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A10BFF48D69@mbx02.citservers.local> Content-Type: multipart/signed; boundary=Apple-Mail-78--337768691; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 06:29:12 -0700 References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48D69@mbx02.citservers.local> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIP IETF Subject: Re: [Sip] SIP INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:28:26 -0000 --Apple-Mail-78--337768691 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Mar 23, 2009, at 6:19 AM, Brett Tate wrote: > What was the outcome of INFO 489 response MUST trigger release of =20 > call discussion? Whoops - that was slide 2... =95Get a 489, can all still be fine? =95Option 1: Tear down dialog Something is hopelessly broken, give up =95Option 2: ignore it =96We say INFO does not change dialog state, and a 489 tearing down dialog changes state =96But, handling 489 differently for INFO makes INFO = =93special=94 =96But what if I said =93package X is OK=94 in an = INVITE, but there is glare between you sending an INFO from package X =20 and my dropping X in my ACK? Thoughts?= --Apple-Mail-78--337768691 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjMxMzI5MTNaMCMGCSqGSIb3 DQEJBDEWBBRU+xUbNn+rQ7SUt4wGmPn0OWDB9DCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBxvwlWsM6a+1y7ODJhlP+nMu34SGhYNXUzLVpz/VZjG0pK 2yXsKublXyuVVqdVow+GLTgGEGgMBUqIFwBMcOlkXchI87Y2ZJvnRzNckA1zOXYUMMu8dS/Ykcld sgWa6rZfRpKsMR+j15vZUOumpDzifVxWaoDBNrOYr/3zTu8fyYK3VLzqEyq8Igv8rkz8i6JORuoX MStdlBsJUZ7nfdFSYNPCXUXRBuRylVEUld6T+3K5aFhdCkBzbx+ltCShlk7UpzaEAhmCj1qk9RSG Yg5+Yk8sj8drl0x8Wp8b/6RjWKpiIvjTQz1Wo9Ty850Z5qyKxCtcFyLe39oZndn/k8WAAAAAAAAA --Apple-Mail-78--337768691-- From pkyzivat@cisco.com Mon Mar 23 06:55:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70A73A67D6 for ; Mon, 23 Mar 2009 06:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.856 X-Spam-Level: X-Spam-Status: No, score=-4.856 tagged_above=-999 required=5 tests=[AWL=1.743, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRPDMNel1v-L for ; Mon, 23 Mar 2009 06:55:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A8F743A685C for ; Mon, 23 Mar 2009 06:55:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,408,1233532800"; d="scan'208";a="272533010" Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2009 13:56:04 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id n2NDu4h2003371; Mon, 23 Mar 2009 06:56:04 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2NDtv3t014603; Mon, 23 Mar 2009 13:56:04 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 09:55:53 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 09:55:53 -0400 Message-ID: <49C794E8.7070802@cisco.com> Date: Mon, 23 Mar 2009 09:55:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Adam Roach References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <49C6C895.9040204@nostrum.com> In-Reply-To: <49C6C895.9040204@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2009 13:55:53.0221 (UTC) FILETIME=[14C33350:01C9ABBF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1144; t=1237816564; x=1238680564; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Comment=20on=20draft-roach-sipc ore-rfc3265bis-00 |Sender:=20; bh=ZLAYbeHdOCk6WZOa74A53yrQ95mL9II7EgXNtcrFJJM=; b=RvJaBjrptp1L/kh7uMDLblUSHwOVF2KDQOot5CCGS5XQh8dbfYOp3mHEZQ nksk5eLlaQDIHryoxgtvMHqHlDmkh05aiQlM0uRXs6NRYPsDi4OSTVmWN7Nc ucvyPknvhx; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:55:15 -0000 Adam Roach wrote: > Because of the true interoperability > nightmare that has resulted from dialog sharing, my suggestion would be > to disable notifier functionality on those endpoints under such > circumstances (perhaps with an implementation option to fall back to > 3265 behavior for the truly masochistic). Can you say more about the "true interoperability nightmare that has resulted from dialog sharing"? I understand that there undoubtedly are interop issues due to some UAs not supporting dialog sharing. There are also interop issues due to the UAs not supporting an event package, or not supporting GRUU, or whatever. Is one more of a nightmare than another? Dialog sharing has been a legal possibility since 3261 was published. So it shouldn't be a surprise to anybody. If somebody didn't implement support, well, what can you say? It was used primarily because contacts in dialogs often don't have the gruu property, and GRUU hasn't been widely implemented. Has that situation changed? Will 3265bis somehow result in widespread implementation of GRUU by registrars? Thanks, Paul From brett@broadsoft.com Mon Mar 23 06:57:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2743A69A3 for ; Mon, 23 Mar 2009 06:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmlnydhtIOUn for ; Mon, 23 Mar 2009 06:57:06 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 05E2F3A67D6 for ; Mon, 23 Mar 2009 06:57:06 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 23 Mar 2009 06:57:55 -0700 From: Brett Tate To: Eric Burger , SIP IETF Date: Mon, 23 Mar 2009 06:57:55 -0700 Thread-Topic: [Sip] SIP INFO Thread-Index: Acmru1+1Iv5PGRqUTOarHWD1Q2CJKAAAFGLA Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10BFF48D85@mbx02.citservers.local> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48D69@mbx02.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] SIP INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:57:06 -0000 Because of race/glare conditions, I prefer INFO 489 not MUST or SHOULD trig= ger the release of the call. Concerning calls, I see little difference bet= ween impacts of 489 and 405/501/420. Thus I prefer option 2. Option 2 appears reasonably consistent with notes 3 and 12 within RFC 5057 = section 5.1. > -----Original Message----- > From: Eric Burger [mailto:eburger@standardstrack.com] > Sent: Monday, March 23, 2009 9:29 AM > To: Brett Tate > Cc: SIP IETF > Subject: Re: [Sip] SIP INFO >=20 > On Mar 23, 2009, at 6:19 AM, Brett Tate wrote: > > What was the outcome of INFO 489 response MUST trigger release of > > call discussion? >=20 > Whoops - that was slide 2... >=20 > *Get a 489, can all still be fine? > *Option 1: Tear down dialog > Something is hopelessly broken, give up >=20 > *Option 2: ignore it > -We say INFO does not change dialog state, > and a 489 tearing down dialog changes state > -But, handling 489 differently for INFO makes INFO "special" > -But what if I said "package X is OK" in an INVITE, but there > is > glare between you sending an INFO from package X > and my > dropping X in my ACK? >=20 >=20 > Thoughts? From john.elwell@siemens.com Mon Mar 23 07:11:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D173A69A9 for ; Mon, 23 Mar 2009 07:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8SYu+sHFwqe for ; Mon, 23 Mar 2009 07:11:25 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 9D2063A693F for ; Mon, 23 Mar 2009 07:11:25 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KGY00094Q4EEE@siemenscomms.co.uk> for sip@ietf.org; Mon, 23 Mar 2009 14:12:14 +0000 (GMT) Date: Mon, 23 Mar 2009 14:12:13 +0000 From: "Elwell, John" In-reply-to: <49C78202.9030604@rogers.com> To: Tom Taylor , Christer Holmberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001AADCC7@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] draft-ietf-sip-199-06 Thread-Index: Acmrs9sbWQl6vKyCSjazL/gmgp5KxgADVKvA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49C2D7E5.5050709@nostrum.com> <49C78202.9030604@rogers.com> Cc: SIP WG , Adam Roach Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:11:26 -0000 =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Tom Taylor > Sent: 23 March 2009 12:35 > To: Christer Holmberg > Cc: SIP WG; Adam Roach > Subject: Re: [Sip] draft-ietf-sip-199-06 >=20 > Some text , as requested. >=20 > Christer Holmberg wrote: > ... > >=20 > >> In section 6: > >> > >> When a forking proxy receives a non-2xx final response that it > >> recognizes as terminating one or more early dialogs, if the proxy > >> does not intend to forward the final response immediately (in > >> accordance with rules for a forking proxy) and the UAC=20 > has indicated > >> support for the 199 response code, the proxy SHOULD generate and > > send > >> a 199 response upstream for each early dialog terminated on the > >> downstream side by the non-2xx final response, except=20 > for any early > >> dialog for which the proxy has previously received and=20 > forwarded a > >> 199 response. > >> > ... >=20 > My suggestion: >=20 > "When a forking proxy receives a non-2xx final response that it > recognizes as terminating one or more early dialogs, it=20 > SHOULD generate > and send a 199 response upstream for each such early dialog=20 > satisfying the > following conditions: > -- the proxy does not intend to forward the final response=20 > immediately > (in accordance with rules for a forking proxy); > -- the UAC has indicated support for the 199 response code; > -- the proxy has not already received and forwarded a 199=20 > response for > that early dialogue." [JRE] Make it clear that all 3 conditions must be true, e.g., by saying "satisfying all of the following conditions". John > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From pkyzivat@cisco.com Mon Mar 23 07:29:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD10E3A68C3 for ; Mon, 23 Mar 2009 07:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.173 X-Spam-Level: X-Spam-Status: No, score=-5.173 tagged_above=-999 required=5 tests=[AWL=1.426, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDLShB8i1Qgj for ; Mon, 23 Mar 2009 07:29:33 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2CA573A67E7 for ; Mon, 23 Mar 2009 07:29:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,408,1233532800"; d="scan'208";a="32207801" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 23 Mar 2009 14:30:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2NEUNku018249; Mon, 23 Mar 2009 07:30:23 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2NEULPS025833; Mon, 23 Mar 2009 14:30:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 10:30:21 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 10:30:20 -0400 Message-ID: <49C79CFD.1010408@cisco.com> Date: Mon, 23 Mar 2009 10:30:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Burger References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> In-Reply-To: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2009 14:30:20.0884 (UTC) FILETIME=[E52F8940:01C9ABC3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=649; t=1237818623; x=1238682623; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20SIP=20INFO |Sender:=20; bh=1tk1/ewoH5NXMpBx0W4BbhKspGUyGwyAoTTD2KtcvUI=; b=seWOjeMonwnMHwp5XaJhvBNavVUteQ7KKQ7n10llL7Jt5WpqRB4+0YSAav fV9hKgpeN1WRlrjm2HlGAJFvUBt5ru+Uwe4oVSjMYj+tzOjob3kSvgLCEiMu WEqLCp9FGl; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP IETF Subject: Re: [Sip] SIP INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:29:33 -0000 Eric Burger wrote: > Likewise, what about REFER/REFER 2xx? My vote here is INFO packages > would be nonsensical during a refer, but perhaps you have a use case? > If so, they work like everything else. REFER initiates subscription establishment, if not already within a dialog. But INFO belongs with INVITE dialog-usages, not subscriptions. So the INFO negotiation makes no sense in out-of-dialog REFERs. If the REFER is within an existing dialog that has an INVITE dialog usage, it is still (IIUC) technically not within the invite dialog usage. So it shouldn't be used for negotiating INFO packages. Thanks, Paul From dyork@voxeo.com Mon Mar 23 07:33:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7043A67DD for ; Mon, 23 Mar 2009 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cgBK5cKXFma for ; Mon, 23 Mar 2009 07:33:29 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id D2EC228C11E for ; Mon, 23 Mar 2009 07:33:28 -0700 (PDT) Received: from [66.65.231.233] (account dyork HELO pc-00144.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 39906094; Mon, 23 Mar 2009 14:34:18 +0000 Message-Id: <81F5ABBA-F762-4111-8130-0ECAC9064626@voxeo.com> From: Dan York To: Dan Wing In-Reply-To: <006c01c9ab79$ab05b400$df70150a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 10:34:16 -0400 References: <006c01c9ab79$ab05b400$df70150a@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: sip@ietf.org Subject: Re: [Sip] Skype for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:33:30 -0000 Dan, Yes, I was amused that Skype would announce this on the first day of IETF 74 (although I somehow wonder if Skype even knew). Two other posts on the topic that went into more detail (one of them is admittedly mine): http://www.disruptivetelephony.com/2009/03/skype-tears-down-more-walls-with-skype-for-sip.html http://voiceontheweb.biz/2009/03/business-long-distance-death-by-1000000-pbxs/ The big missing piece to me is that it can't do SIP -> Skype name. This new "Skype For SIP" service will support: - Skype Clients --> PBX - SkypeIn/Online numbers (PSTN) --> PBX - PBX --> SkypeOut (PSTN) So for outbound Skype becomes a "SIP service provider" for PSTN connectivity. But you still can't connect from your IP-PBX via SIP to a random Skype user, which could be interesting on a number of levels. Skype says they are open to exploring this during the beta period, though. The Skype folks I've spoken to also say they see this "Skype For SIP" with voice as only a first step... they say they do want to expand that interconnectivity to presence, video, etc. We'll see. Dan On Mar 23, 2009, at 1:39 AM, Dan Wing wrote: > http://www.networkworld.com/news/2009/032309-skype-sip.html?hpg1=bn -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build powerful voice applications quickly Find out how at http://www.voxeo.com/free From brett@broadsoft.com Mon Mar 23 08:17:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596953A6BA9 for ; Mon, 23 Mar 2009 08:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCQvvURaxmfc for ; Mon, 23 Mar 2009 08:17:57 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 51E7B3A6A15 for ; Mon, 23 Mar 2009 08:17:57 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 23 Mar 2009 08:18:47 -0700 From: Brett Tate To: SIP IETF , Paul Kyzivat Date: Mon, 23 Mar 2009 08:18:47 -0700 Thread-Topic: Is REFER within dialog part of INVITE or subscription usage? (was RE: [Sip] SIP INFO) Thread-Index: Acmrw+nBuhULxHuQSqOp+fzZUVcB4QAAfe5w Message-ID: <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> In-Reply-To: <49C79CFD.1010408@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 15:17:58 -0000 > If the REFER is within an existing dialog that has an INVITE=20 > dialog usage, it is still (IIUC) technically not within the=20 > invite dialog usage. So it shouldn't be used for negotiating=20 > INFO packages. Paul: Thanks for raising the issues. Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION usage, = or neither? I'm asking mainly because of REFER 481 impacts; however the answer also has= potential implications concerning draft-ietf-sip-info-events. RFC 5057 ap= pears to imply that it is part of the subscription usage; however I'm not p= ositive if my interpretation and/or RFC 5057 is correct. If REFER isn't considered part of the INVITE usage, how should REFER 481 be= interpreted? More specifically, should receiver of REFER 481 send BYE? Thanks, Brett From christer.holmberg@ericsson.com Mon Mar 23 09:24:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AEB53A6987 for ; Mon, 23 Mar 2009 09:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1PtvFDfvfuv for ; Mon, 23 Mar 2009 09:24:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0B1133A68E5 for ; Mon, 23 Mar 2009 09:24:25 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C22F82051D; Mon, 23 Mar 2009 17:25:14 +0100 (CET) X-AuditID: c1b4fb3e-abfb5bb000006d6d-7d-49c7b7ea7c1f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8EF0F20224; Mon, 23 Mar 2009 17:25:14 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 17:25:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 17:25:13 +0100 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001AADCC7@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-199-06 Thread-Index: Acmrs9sbWQl6vKyCSjazL/gmgp5KxgADVKvAAAR8YwA= References: <49C2D7E5.5050709@nostrum.com> <49C78202.9030604@rogers.com> <0D5F89FAC29E2C41B98A6A762007F5D001AADCC7@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Tom Taylor" X-OriginalArrivalTime: 23 Mar 2009 16:25:14.0468 (UTC) FILETIME=[F214FA40:01C9ABD3] X-Brightmail-Tracker: AAAAAA== Cc: SIP WG , Adam Roach Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:24:27 -0000 Hi, Thanks for the text, Tom! Regarding documenting that all 3 conditions must be fullfilled, and way is to write ";and" after each condition. "When a forking proxy receives a non-2xx final response that it recognizes as terminating one or more early dialogs, it SHOULD generate and send a 199 response upstream for each such early dialog satisfying the following conditions: -- the proxy does not intend to forward the final response immediately (in accordance with rules for a forking proxy);and -- the UAC has indicated support for the 199 response code;and -- the proxy has not already received and forwarded a 199 response for that early dialogue." Reegards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: Monday, March 23, 2009 4:12 PM To: Tom Taylor; Christer Holmberg Cc: SIP WG; Adam Roach Subject: RE: [Sip] draft-ietf-sip-199-06 =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > Tom Taylor > Sent: 23 March 2009 12:35 > To: Christer Holmberg > Cc: SIP WG; Adam Roach > Subject: Re: [Sip] draft-ietf-sip-199-06 >=20 > Some text , as requested. >=20 > Christer Holmberg wrote: > ... > >=20 > >> In section 6: > >> > >> When a forking proxy receives a non-2xx final response that it > >> recognizes as terminating one or more early dialogs, if the proxy > >> does not intend to forward the final response immediately (in > >> accordance with rules for a forking proxy) and the UAC > has indicated > >> support for the 199 response code, the proxy SHOULD generate and > > send > >> a 199 response upstream for each early dialog terminated on the > >> downstream side by the non-2xx final response, except > for any early > >> dialog for which the proxy has previously received and > forwarded a > >> 199 response. > >> > ... >=20 > My suggestion: >=20 > "When a forking proxy receives a non-2xx final response that it > recognizes as terminating one or more early dialogs, it SHOULD=20 > generate > and send a 199 response upstream for each such early dialog=20 > satisfying the > following conditions: > -- the proxy does not intend to forward the final response=20 > immediately > (in accordance with rules for a forking proxy); > -- the UAC has indicated support for the 199 response code; > -- the proxy has not already received and forwarded a 199 response=20 > for > that early dialogue." [JRE] Make it clear that all 3 conditions must be true, e.g., by saying "satisfying all of the following conditions". John > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 From dean.willis@softarmor.com Mon Mar 23 09:30:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D2928C1BC for ; Mon, 23 Mar 2009 09:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpU6NlNmQu05 for ; Mon, 23 Mar 2009 09:30:28 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 943FF28C1B6 for ; Mon, 23 Mar 2009 09:30:28 -0700 (PDT) Received: from [130.129.22.245] (dhcp-16f5.meeting.ietf.org [130.129.22.245]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2NGVG6E004484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Mar 2009 11:31:18 -0500 Message-ID: <49C7B951.5070901@softarmor.com> Date: Mon, 23 Mar 2009 09:31:13 -0700 From: Dean Willis User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Sip] skype for sip announced X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:30:31 -0000 Normally, I wouldn't mention product announcements here, but I thought this was quite interesting: http://blog.wired.com/business/2009/03/skype-means-bus.html -- dean From L.Liess@telekom.de Mon Mar 23 10:21:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C243A6C32 for ; Mon, 23 Mar 2009 10:21:18 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN07ngODcX+c for ; Mon, 23 Mar 2009 10:21:17 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id B146B3A6C2B for ; Mon, 23 Mar 2009 10:21:16 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 23 Mar 2009 18:22:04 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 18:22:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 23 Mar 2009 18:22:01 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A002C56288@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <49C507BB.9010804@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-kaplan-sip-session-id-01 Thread-Index: AcmqOc8i6CGlFmfxQEuKyMI6NBJMIwBllqLg References: <49C507BB.9010804@cisco.com> From: To: , , X-OriginalArrivalTime: 23 Mar 2009 17:22:04.0467 (UTC) FILETIME=[E2998830:01C9ABDB] Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:21:18 -0000 Jonathan, The Session-ID it's already on the way to be implemented because it's needed quite badly now. Most SIP services use B2BUAs. Their operation guys have big problems to correlate the call legs and find what's wrong when customers call because their SIP ATA-box doesn't work. I can guess your comment but there isn't anything we can do about it. The B2BUAs are there to stay.=20 The alternative to the Session-ID is every SIP serrvice implementing ist own proprietary stuff. We can not want this happen. We currently use the IP-address and ports in SDP for correlation in SIP and MGCP/MeGaCo. This covers now about 90% of the traffic, but this will change soon and we need something else. =20 I agree with you that there is a clear need to solve the whole problem. But I don't think we have a solution for it within the next eight weeks. So let's get the Session-ID agreed as soon as possible so people can use it. On the other side let's work on the more general problem. In my opinion, the current version of the context-ID requirements draft is intended to go into this direction, or did I miss something?=20 Laura=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jonathan Rosenberg > Sent: Saturday, March 21, 2009 4:29 Pm=20 > To: IETF SIP List > Subject: [Sip] comments on draft-kaplan-sip-session-id-01 >=20 > I think we all agree that it would be nice if there was an identifier=20 > that worked through b2bua, which we could use to identify dialogs. >=20 > However, I think the problem is far more complicated than=20 > this document=20 > talks about. The focus is on making it work through SBC type of boxes=20 > which aren't doing a lot of fancy call control, but are rewriting=20 > call-id and doing security things. There, I think the problem is easy. >=20 > However, there are lots of cases where more complicated dialog=20 > manipulation mucks this up in a really horrible way. In particular,=20 > enterprise features like transfer, park/pickup, and so on, are often=20 > implemented by means of re-INVITEs on dialogs all anchored in the=20 > IP-PBX. For example, consider the following transfer implementation: >=20 > A calls B. A calls C. Both calls are routed through an IP-PBX, which=20 > acts as a b2bua, and so we end up with something which looks=20 > like this: >=20 > Please view in a fixed-width font such as Courier. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > +------------+ S1 > S1 | | ------------ B > --------| | > A S2 | server | > --------| | S2 > | | ------------- C > | | > +------------+ >=20 > Where S1 and S2 are the two session IDs. So far, so good. Now, A=20 > transfers the call to B. A sends a REFER on dialog S1. Like=20 > it or not,=20 > due to frequent REFER/transfer interop issues, this is sometimes=20 > implemented as a re-INVITE from the server, connecting B and=20 > C's media=20 > streams together, and then disconnecting A, so that you end up with: >=20 > Please view in a fixed-width font such > as Courier. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > +------------+ S1 > | | ------------ B > | | > | server | > | | S2 > | | ------------- C > | | > +------------+ >=20 > Now B and C are talking to each other. What is the session ID=20 > for this=20 > dialog? B and C were both originally the UAS on different=20 > dialogs with=20 > different session IDs! >=20 > The problem happens more generally for any 3pcc operation, and the=20 > meta-issue is how to come up with a clear notion of who 'owns' the=20 > sessionID creation and destruction in cases where calls are=20 > transferred,=20 > moved, conferenced, parked and picked up all over the place. >=20 > As such, a true comprehensive solution to this problem is much more=20 > complicated than just 'tell the SBCs to stop mucking with=20 > this header'.=20 > It would need to account for a wider range of 3pcc and other dialog=20 > manipulations which occur in the wild. Or, we could try to=20 > scope this in=20 > a more limited way, focusing on the basic A-calls-B case and=20 > solve just=20 > the SBC problem. >=20 > Which is it? >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From ietf.hanserik@gmail.com Mon Mar 23 10:48:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5375A3A6936 for ; Mon, 23 Mar 2009 10:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41YRtyhH6OA6 for ; Mon, 23 Mar 2009 10:48:44 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 3D4A73A67E2 for ; Mon, 23 Mar 2009 10:48:44 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so486447eyf.31 for ; Mon, 23 Mar 2009 10:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+cwQAhCLvLkG7ei7tWdqiQjeACuyFHBmIxNbsvoHL/8=; b=I9fXTo89Exo+kbmwDnfWdg5u0lDMm1VPKc4uiJ0Ihx8/4WfVz87XHlZs9InbL31yzq sFhc4Vg91GQUSQO6dvBOf6TkWRAv05/C49IGYUx5UDAGCBcQj/0yOp9Pz4OhA3JPdfmx GtP36Tk5lZ3t69h/lArfK/S616Rxy2sXGhTMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nxVIc9CkeEFrWrCloYx1EFx91HcPU5NIVP2IsIq4scDZL0MA/Lm/whUBt8kpLMRSRR BsTuDOFf1RpwwfAezTt9brqgiiZUJZ3PkbimKDPr8DS+CexzHKGAjKO3E/gF1c7PPL5Y hcfPOMMugIBSgls5n63CbNfzUyTA8/PbkersE= MIME-Version: 1.0 Received: by 10.216.70.130 with SMTP id p2mr2403734wed.190.1237830573565; Mon, 23 Mar 2009 10:49:33 -0700 (PDT) In-Reply-To: <49C78DFF.3000906@cisco.com> References: <49C3743F.1070406@ericsson.com> <49C39D1C.1040701@cisco.com> <49C42521.7080706@gmail.com> <49C78DFF.3000906@cisco.com> Date: Mon, 23 Mar 2009 18:49:33 +0100 Message-ID: <9ae56b1e0903231049j53ad700cpc9b13e2d890551ba@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=00504502d175a127d20465cce33e Cc: sip Subject: Re: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:48:46 -0000 --00504502d175a127d20465cce33e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There is no rule stating that requiring "audio" and "video" will imply that you also require one of the new tags. In that sense these tags are completely orthogonal. If the caller adds "require" header field parameter then it is a consequence of the callerpreferences processing that some calls could fail that would otherwise have succeeded. If the caller added this, then this must have been its intention. That is the *feature* that RFC3841 provides to the caller. The 3gpp specification does not say that one has to use "require" header field parameter, it even warns that this might hamper interoperability. So I think your following sentence was a fair analysis of how the newly proposed tags are actually used/should be judged: "If it only represents a preference for whatever extra goodies are provided by 3gpp over and above audio and video, then it may be a reasonable feature tag." /Hans Erik van Elburg On Mon, Mar 23, 2009 at 2:26 PM, Paul Kyzivat wrote: > Inline... > > Hans Erik van Elburg wrote: > >> Responses inline... >> >> /Hans Erik >> >> Paul Kyzivat wrote: >> >>> On one side were those who wanted capabilities and preferences to be >>> stated in terms of feature tags that are well known and orthogonal. On the >>> other side were those who prefer to associate arbitrary names to collections >>> of features and then negotiate on the basis of the names of those >>> collections. >>> >>> Using the latter approach its possible that interoperation will fail >>> because the parties don't share a common name for a collection of features >>> even though they both possess the necessary features to interoperate. >>> >> That is a feature. >> > > *what* is a feature? > > This interoperability "problem" only occurs when the originating party >> includes the header field parameters "require" and "explicit" in the >> Accept-Contact header field containing the feature tag. In this case the >> failure of the call when not all of the receiving UA's support the feature >> is intended! >> > > Lets get tangible about this. (This is retracing old ground, but people > sometimes have short memories.) > > Suppose Alice calls Bob. Alice has the latest and greatest 3gpp phone with > the capability to make audio/video calls, and would prefer to do so if > possible. Bob has an open source softphone running on his PC. It is fully > capable of audio/video operation using a wide source of codecs. He also has > a plain vanilla audio phone registered to the same AOR. > > Alice's phone will send an invite with offer containing audio and video > media. It can also include callerprefs to bias the selection of device in > favor of one that will support audio and video. It could do so a variety of > different ways: > - indicate preference for audio and video > - indicate preference for the 3gpp "videophone" feature. > - indicate preference for audio, video, *and* 3gpp "videophone" > > Assuming none of these *require* these features, the first and the last > will both bias towards the softphone and result in an audio/video call. The > middle will probably cause both of bob's phones to ring and audio/video will > result if he happens to answer the softphone. > > The situation is worse if Alice *requires* both audio and video, and as a > result *requires* the 3gpp videophone feature. > > The problem is one of orthogonality. the features should all be orthogonal > to one another. If "3gpp videophone" encompasses "audio, video, and the 3gpp > videophone look and feel", then it isn't orthogonal to the existing audio > and video feature tags. If it only represents a preference for whatever > extra goodies are provided by 3gpp over and above audio and video, then it > may be a reasonable feature tag. > > (Note that I have no knowledge of how 3gpp intends to name an use features. > I'm just exploring the possibilities.) > > I don't have a problem with independent groups defining new feature tags, >>> as long as they are primitive and orthogonal to existing ones. But I do have >>> a problem with defining feature tags that identify collections of features, >>> especially when the mapping from the identifier to the collection of >>> features is not public. >>> >> Well who is going to determine what can be called a feature and what not. >> I also like to see where this principle is documented to apply to the >> global tree. >> > > IMO it was probably a mistake to use the existing feature tag mechanism for > callee caps in the first place. While there are some simmilarities, the > intentions are quite different. But we are where we are. > > I don't know if we can impose additional rules on the global tree or not. I > expect that imposing an orthogonality constraint might not be so > controversial, and so *might* be possible. But the challenge may be in > *defining* orthogonality in an application-independent way. It would be > easier to do that in the context of sip, though still not trivial. > > The bottom line is that I think this sort of thing needs to be thrashed >>> out within the sip community. So I think the RFC process is the right >>> process. >>> >> I think that bending the rules because some SIP people don't like on how >> other organisations are applying SIP in their solutions will alieanate those >> SIP users from that same SIP community. So I seriously hope we will not go >> down that path. >> > > Lets see what others say. > > IMO its important that those other communities don't use this mechanism to > erect more walls around their garden. > > Thanks, > Paul > > /Hans Erik >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> --00504502d175a127d20465cce33e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is no rule stating that requiring "audio" and "video&q= uot; will imply that you also require one of the new tags. In that sense th= ese tags are completely orthogonal.

If the caller adds "require= " header field parameter then it is a consequence of the callerprefere= nces processing that some calls could fail that would otherwise have succee= ded. If the caller added this, then this must have been its intention. That= is the *feature* that RFC3841 provides to the caller. The 3gpp specificati= on does not say that one has to use "require" header field parame= ter, it even warns that this might hamper interoperability.

So I think your following sentence was a fair analysis of how the newly= proposed tags are actually used/should be judged: "If it only represe= nts a preference for whatever extra goodies are provided by 3gpp over and above audio and video, then it may be a reasonable feature tag."

/Hans Erik van Elburg

On Mon, Mar 23, 2009 at 2:26 PM, Paul Ky= zivat <pkyzivat@= cisco.com> wrote:
Inline...


Hans Erik van Elburg wrote:
Responses inline...

/Hans Erik

Paul Kyzivat wrote:
On one side were those who wanted capabilities and preferences to be stated= in terms of feature tags that are well known and orthogonal. On the other = side were those who prefer to associate arbitrary names to collections of f= eatures and then negotiate on the basis of the names of those collections.<= br>
Using the latter approach its possible that interoperation will fail becaus= e the parties don't share a common name for a collection of features ev= en though they both possess the necessary features to interoperate.
That is a feature.

*what* is a feature?


This interoperability "problem" only occurs when the originating = party includes the header field parameters "require" and "ex= plicit" in the Accept-Contact header field containing the feature tag.= In this case the failure of the call when not all of the receiving =A0UA&#= 39;s support =A0the feature is intended!

Lets get tangible about this. (This is retracing old ground, but people som= etimes have short memories.)

Suppose Alice calls Bob. Alice has the latest and greatest 3gpp phone with = the capability to make audio/video calls, and would prefer to do so if poss= ible. Bob has an open source softphone running on his PC. It is fully capab= le of audio/video operation using a wide source of codecs. He also has a pl= ain vanilla audio phone registered to the same AOR.

Alice's phone will send an invite with offer containing audio and video= media. It can also include callerprefs to bias the selection of device in = favor of one that will support audio and video. It could do so a variety of= different ways:
- indicate preference for audio and video
- indicate preference for the 3gpp "videophone" feature.
- indicate preference for audio, video, *and* 3gpp "videophone"
Assuming none of these *require* these features, the first and the last wil= l both bias towards the softphone and result in an audio/video call. The mi= ddle will probably cause both of bob's phones to ring and audio/video w= ill result if he happens to answer the softphone.

The situation is worse if Alice *requires* both audio and video, and as a r= esult *requires* the 3gpp videophone feature.

The problem is one of orthogonality. the features should all be orthogonal = to one another. If "3gpp videophone" encompasses "audio, vid= eo, and the 3gpp videophone look and feel", then it isn't orthogon= al to the existing audio and video feature tags. If it only represents a pr= eference for whatever extra goodies are provided by 3gpp over and above aud= io and video, then it may be a reasonable feature tag.

(Note that I have no knowledge of how 3gpp intends to name an use features.= I'm just exploring the possibilities.)


I don't have a problem with independent groups defining new feature tag= s, as long as they are primitive and orthogonal to existing ones. But I do = have a problem with defining feature tags that identify collections of feat= ures, especially when the mapping from the identifier to the collection of = features is not public.
Well who is going to determine what can be called a feature and what not. I also like to see where this principle is documented to apply to the globa= l tree.

IMO it was probably a mistake to use the existing feature tag mechanism for= callee caps in the first place. While there are some simmilarities, the in= tentions are quite different. But we are where we are.

I don't know if we can impose additional rules on the global tree or no= t. I expect that imposing an orthogonality constraint might not be so contr= oversial, and so *might* be possible. But the challenge may be in *defining= * orthogonality in an application-independent way. It would be easier to do= that in the context of sip, though still not trivial.


The bottom line is that I think this sort of thing needs to be thrashed out= within the sip community. So I think the RFC process is the right process.=
I think that bending the rules because some SIP people don't like on ho= w other organisations are applying SIP in their solutions will alieanate th= ose SIP users from that same SIP community. So I seriously hope we will not= go down that path.

Lets see what others say.

IMO its important that those other communities don't use this mechanism= to erect more walls around their garden.

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

/Hans Erik

_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use s= ip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org<= /a> for new developments on the application of sip


--00504502d175a127d20465cce33e-- From pkyzivat@cisco.com Mon Mar 23 12:53:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FC128C1BB for ; Mon, 23 Mar 2009 12:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.292 X-Spam-Level: X-Spam-Status: No, score=-5.292 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leCWpyLcvMrZ for ; Mon, 23 Mar 2009 12:53:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C53CC28C148 for ; Mon, 23 Mar 2009 12:53:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,409,1233532800"; d="scan'208";a="40194498" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Mar 2009 19:54:17 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2NJsHlH023672; Mon, 23 Mar 2009 15:54:17 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2NJsHEi012273; Mon, 23 Mar 2009 19:54:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 15:54:17 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 15:54:16 -0400 Message-ID: <49C7E8DA.3050603@cisco.com> Date: Mon, 23 Mar 2009 15:54:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hans Erik van Elburg References: <49C3743F.1070406@ericsson.com> <49C39D1C.1040701@cisco.com> <49C42521.7080706@gmail.com> <49C78DFF.3000906@cisco.com> <9ae56b1e0903231049j53ad700cpc9b13e2d890551ba@mail.gmail.com> In-Reply-To: <9ae56b1e0903231049j53ad700cpc9b13e2d890551ba@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2009 19:54:16.0764 (UTC) FILETIME=[25DF77C0:01C9ABF1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7383; t=1237838057; x=1238702057; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Policy=20to=20register=20media= 20feature=20tags |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=qq1Pa99K96FgTl0O+i9JLfX4vvDttXgehUHyQMjtMo0=; b=b9vcidFQdG1HA8Iby2AbEEV0rYhiBFPZGdrUh42oMudN4sFZBMHQSOmax4 YqljuMEUD+YKmalxlwwMSMUFsQwXlQw04buyESK60e4aKTlfKtFxbjPfe9Vz inCfEr4OjO; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip Subject: Re: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 19:53:35 -0000 Hans Erik van Elburg wrote: > There is no rule stating that requiring "audio" and "video" will imply > that you also require one of the new tags. In that sense these tags are > completely orthogonal. Its good to hear that. While I had no specifics, I had hints to the contrary. I guess those were wrong. > If the caller adds "require" header field parameter then it is a > consequence of the callerpreferences processing that some calls could > fail that would otherwise have succeeded. If the caller added this, then > this must have been its intention. That is the *feature* that RFC3841 > provides to the caller. The 3gpp specification does not say that one has > to use "require" header field parameter, it even warns that this might > hamper interoperability. > > So I think your following sentence was a fair analysis of how the newly > proposed tags are actually used/should be judged: "If it only represents > a preference for whatever extra goodies are provided by 3gpp over and > above audio and video, then it may be a reasonable feature tag." If that is the intent, then I am reassured. Presumably the end user isn't actually selecting callerprefs. Rather the end user is just pushing a button on the phone to initiate a call, and some application on the phone is deciding what callerprefs to use. So in the end it will be a question of whether the app constructs the call to maximize interop, or not. Thanks, Paul > /Hans Erik van Elburg > > > On Mon, Mar 23, 2009 at 2:26 PM, Paul Kyzivat > wrote: > > Inline... > > > Hans Erik van Elburg wrote: > > Responses inline... > > /Hans Erik > > Paul Kyzivat wrote: > > On one side were those who wanted capabilities and > preferences to be stated in terms of feature tags that are > well known and orthogonal. On the other side were those who > prefer to associate arbitrary names to collections of > features and then negotiate on the basis of the names of > those collections. > > Using the latter approach its possible that interoperation > will fail because the parties don't share a common name for > a collection of features even though they both possess the > necessary features to interoperate. > > That is a feature. > > > *what* is a feature? > > > This interoperability "problem" only occurs when the originating > party includes the header field parameters "require" and > "explicit" in the Accept-Contact header field containing the > feature tag. In this case the failure of the call when not all > of the receiving UA's support the feature is intended! > > > Lets get tangible about this. (This is retracing old ground, but > people sometimes have short memories.) > > Suppose Alice calls Bob. Alice has the latest and greatest 3gpp > phone with the capability to make audio/video calls, and would > prefer to do so if possible. Bob has an open source softphone > running on his PC. It is fully capable of audio/video operation > using a wide source of codecs. He also has a plain vanilla audio > phone registered to the same AOR. > > Alice's phone will send an invite with offer containing audio and > video media. It can also include callerprefs to bias the selection > of device in favor of one that will support audio and video. It > could do so a variety of different ways: > - indicate preference for audio and video > - indicate preference for the 3gpp "videophone" feature. > - indicate preference for audio, video, *and* 3gpp "videophone" > > Assuming none of these *require* these features, the first and the > last will both bias towards the softphone and result in an > audio/video call. The middle will probably cause both of bob's > phones to ring and audio/video will result if he happens to answer > the softphone. > > The situation is worse if Alice *requires* both audio and video, and > as a result *requires* the 3gpp videophone feature. > > The problem is one of orthogonality. the features should all be > orthogonal to one another. If "3gpp videophone" encompasses "audio, > video, and the 3gpp videophone look and feel", then it isn't > orthogonal to the existing audio and video feature tags. If it only > represents a preference for whatever extra goodies are provided by > 3gpp over and above audio and video, then it may be a reasonable > feature tag. > > (Note that I have no knowledge of how 3gpp intends to name an use > features. I'm just exploring the possibilities.) > > > I don't have a problem with independent groups defining new > feature tags, as long as they are primitive and orthogonal > to existing ones. But I do have a problem with defining > feature tags that identify collections of features, > especially when the mapping from the identifier to the > collection of features is not public. > > Well who is going to determine what can be called a feature and > what not. > I also like to see where this principle is documented to apply > to the global tree. > > > IMO it was probably a mistake to use the existing feature tag > mechanism for callee caps in the first place. While there are some > simmilarities, the intentions are quite different. But we are where > we are. > > I don't know if we can impose additional rules on the global tree or > not. I expect that imposing an orthogonality constraint might not be > so controversial, and so *might* be possible. But the challenge may > be in *defining* orthogonality in an application-independent way. It > would be easier to do that in the context of sip, though still not > trivial. > > > The bottom line is that I think this sort of thing needs to > be thrashed out within the sip community. So I think the RFC > process is the right process. > > I think that bending the rules because some SIP people don't > like on how other organisations are applying SIP in their > solutions will alieanate those SIP users from that same SIP > community. So I seriously hope we will not go down that path. > > > Lets see what others say. > > IMO its important that those other communities don't use this > mechanism to erect more walls around their garden. > > Thanks, > Paul > > /Hans Erik > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on > current sip > Use sipping@ietf.org for new > developments on the application of sip > > From Adam.Uzelac@globalcrossing.com Mon Mar 23 13:59:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4C53A697F for ; Mon, 23 Mar 2009 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gOcO86pApNr for ; Mon, 23 Mar 2009 13:59:34 -0700 (PDT) Received: from mailsrv.ams.gblxint.com (unknown-141-roc.globalcrossing.com [209.130.177.141]) by core3.amsl.com (Postfix) with ESMTP id 9C7C63A6907 for ; Mon, 23 Mar 2009 13:59:34 -0700 (PDT) Received: from w3uspdyvs212.ams.gblxint.com (w3uspdyvs212.ams.gblxint.com [10.60.54.213]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 3FC8DE86FB; Mon, 23 Mar 2009 17:00:24 -0400 (EDT) Received: from w3uspdyvs240.ams.gblxint.com ([10.60.54.201]) by w3uspdyvs212.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 17:00:23 -0400 Received: from EVS20.ams.gblxint.com ([10.60.53.123]) by w3uspdyvs240.ams.gblxint.com ([10.60.54.201]) with mapi; Mon, 23 Mar 2009 17:00:22 -0400 From: "Uzelac, Adam" To: Dan York , Dan Wing Date: Mon, 23 Mar 2009 17:00:21 -0400 Thread-Topic: [Sip] Skype for SIP Thread-Index: AcmrxJVaA4dZHjfzRja43DiHFeNcCwANOFPg Message-ID: <278488ECD81E6A42A7289E84524D2A25AC18F3BD@EVS20.ams.gblxint.com> References: <006c01c9ab79$ab05b400$df70150a@cisco.com> <81F5ABBA-F762-4111-8130-0ECAC9064626@voxeo.com> In-Reply-To: <81F5ABBA-F762-4111-8130-0ECAC9064626@voxeo.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-OriginalArrivalTime: 23 Mar 2009 21:00:23.0362 (UTC) FILETIME=[62264A20:01C9ABFA] Cc: "sip@ietf.org" Subject: Re: [Sip] Skype for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 20:59:35 -0000 Skype for SIP =3D SKIP? > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Dan York > Sent: Monday, March 23, 2009 7:34 AM > To: Dan Wing > Cc: sip@ietf.org > Subject: Re: [Sip] Skype for SIP >=20 > Dan, >=20 > Yes, I was amused that Skype would announce this on the first day of > IETF 74 (although I somehow wonder if Skype even knew). Two other > posts on the topic that went into more detail (one of them is > admittedly mine): >=20 > http://www.disruptivetelephony.com/2009/03/skype-tears-down-more-walls- > with-skype-for-sip.html > http://voiceontheweb.biz/2009/03/business-long-distance-death-by- > 1000000-pbxs/ >=20 > The big missing piece to me is that it can't do SIP -> Skype name. > This new "Skype For SIP" service will support: >=20 > - Skype Clients --> PBX > - SkypeIn/Online numbers (PSTN) --> PBX > - PBX --> SkypeOut (PSTN) >=20 > So for outbound Skype becomes a "SIP service provider" for PSTN > connectivity. But you still can't connect from your IP-PBX via SIP to > a random Skype user, which could be interesting on a number of > levels. Skype says they are open to exploring this during the beta > period, though. The Skype folks I've spoken to also say they see this > "Skype For SIP" with voice as only a first step... they say they do > want to expand that interconnectivity to presence, video, etc. We'll > see. >=20 > Dan >=20 > On Mar 23, 2009, at 1:39 AM, Dan Wing wrote: >=20 > > http://www.networkworld.com/news/2009/032309-skype-sip.html?hpg1=3Dbn >=20 >=20 >=20 > -- > Dan York, Director of Conversations > Voxeo Corporation http://www.voxeo.com dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >=20 > Build powerful voice applications quickly > Find out how at http://www.voxeo.com/free >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From adam@nostrum.com Mon Mar 23 15:44:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE1128C1A9 for ; Mon, 23 Mar 2009 15:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPMfTZIL8GAW for ; Mon, 23 Mar 2009 15:44:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 01E2828C0DC for ; Mon, 23 Mar 2009 15:44:30 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2NMiu9e007218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 17:44:58 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49C810E6.9080006@nostrum.com> Date: Mon, 23 Mar 2009 15:44:54 -0700 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Paul Kyzivat References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <49C6C895.9040204@nostrum.com> <49C794E8.7070802@cisco.com> In-Reply-To: <49C794E8.7070802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9155/Mon Mar 23 12:26:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 22:44:32 -0000 Paul Kyzivat wrote: > > > Adam Roach wrote: > >> Because of the true interoperability nightmare that has resulted from >> dialog sharing, my suggestion would be to disable notifier >> functionality on those endpoints under such circumstances (perhaps >> with an implementation option to fall back to 3265 behavior for the >> truly masochistic). > > Can you say more about the "true interoperability nightmare that has > resulted from dialog sharing"? > > I understand that there undoubtedly are interop issues due to some UAs > not supporting dialog sharing. There are also interop issues due to > the UAs not supporting an event package, or not supporting GRUU, or > whatever. Is one more of a nightmare than another? It's not lack of support that worries me -- it's mismatched views of dialog and usage state between two endpoints who both think they've implemented dialog sharing. The problem is not that things negotiate down to a lesser set of capabilities -- it's that things act broken in a way that exposes this mixed-up view of whether a dialog (and its associated session/subscription) is active. > Dialog sharing has been a legal possibility since 3261 was published. > So it shouldn't be a surprise to anybody. If somebody didn't implement > support, well, what can you say? As one of the key perpetrators of that particular aspect of 3261, I'm comfortable in saying that we added it in a slapdash fashion at the 11th hour, without sufficient analysis (and I mean this in a self-deprecating way, without intending to cast aspersions on any of 3261's editors). Interactions between usages in a dialog were ridiculously underspecified. Robert spent a long time trying to rationalize this behavior after the fact, with the result being RFC 5057. And RFC 5057 really helps a lot for the minority of implementors who actually know it exists. However, the issue is complicated enough that it takes 26 pages to untangle it, and the rules are a tangle of exceptions. Go read 5057 again, and tell me that people are more likely to get that right than they are to get confused. > It was used primarily because contacts in dialogs often don't have the > gruu property, and GRUU hasn't been widely implemented. Has that > situation changed? Will 3265bis somehow result in widespread > implementation of GRUU by registrars? 3265bis is less mature than GRUU (in that one is a -00 individual draft, and the other is in the RFC editor queue). I think it's reasonable to rely on predecessor technologies. /a From adam@nostrum.com Mon Mar 23 16:22:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE57B28C12E for ; Mon, 23 Mar 2009 16:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOaOR66Vq1pm for ; Mon, 23 Mar 2009 16:22:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C4D253A69A8 for ; Mon, 23 Mar 2009 16:22:22 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2NNN7jb009937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 18:23:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49C819D9.50901@nostrum.com> Date: Mon, 23 Mar 2009 16:23:05 -0700 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <49C2D7E5.5050709@nostrum.com> A <0D5F89FAC29E2C41B98A6A762007F5D001AAD921@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9155/Mon Mar 23 12:26:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP WG , "Elwell, John" Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:22:24 -0000 Christer Holmberg wrote: > You can have network entities which act as "normal" UAS, which also > want to send 199. They may e.g. have been configured to do so, since > the forking proxy does not support 199. Etc. > And, the text already says that a UAS should not send a 199, unless it has been configured to do so. But, I don't think we should forbid it from doing so. > No, but you need to motivate why they might do so. Explain that they're sending it because they think there's an upstream forking proxy that won't. Explain that they might be a B2BUA that has created more than one early dialog with the caller, and wants to clean some of them up. It makes little sense to say that UAs can do this without some kind of explanation about why they would do so. /a From pkyzivat@cisco.com Mon Mar 23 16:24:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839BA3A6C3D for ; Mon, 23 Mar 2009 16:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76cGyKfJI01M for ; Mon, 23 Mar 2009 16:24:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E27223A6990 for ; Mon, 23 Mar 2009 16:24:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="40215678" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Mar 2009 23:25:23 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2NNPNUU020202; Mon, 23 Mar 2009 19:25:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2NNPNqN012672; Mon, 23 Mar 2009 23:25:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 19:25:23 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 19:25:23 -0400 Message-ID: <49C81A67.3030501@cisco.com> Date: Mon, 23 Mar 2009 19:25:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Adam Roach References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <49C6C895.9040204@nostrum.com> <49C794E8.7070802@cisco.com> <49C810E6.9080006@nostrum.com> In-Reply-To: <49C810E6.9080006@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2009 23:25:23.0281 (UTC) FILETIME=[A3B49410:01C9AC0E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4073; t=1237850723; x=1238714723; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Comment=20on=20draft-roach-sipc ore-rfc3265bis-00 |Sender:=20 |To:=20Adam=20Roach=20; bh=nXyzg0ROFlnUgIz6pWidBdlCi+cpiDY2QFvK+9PAeZ0=; b=kWsFH2BoE1Rlzb0MQJS/A5hML+Ua1bOSp6rYgVjtC+mt2h2RARMASLbh7S zsB2ZOG1Ln4dzTwE/QNLObbacB1Y37qbLDdGHyU7NvIX4qkdaq42NWn5r7VX EKN4Ga3MpO; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:24:35 -0000 Adam, Don't get me wrong. I think this is a problem any way you turn. I was pretty heavily involved in gruu. It certainly intended to solve a problem, but it too ended up much more complex than anybody hoped it would - to the point that I suspect there is a lot of reluctance to implement it, and a fair amount of potential to implement it wrong. On top of that, I suspect many feel they haven't needed it so far, and can get away without it, because the magic of SBCs eliminates the need. Also, I know of significant deployed uses of dialog sharing, that probably won't go away any time soon even after deprecation. If we had it to do over, I would not include dialog sharing in 3261. But despite the potential problems with it, I think that horse is out of the barn and will not be put back in, especially since that barn is on fire. IMO the more likely thing is to encourage everyone who can to put a ;gr on their contacts, and to make a best practice of using out-of-dialog subscriptions/refers, etc. whenever the target address has ;gr. But if it doesn't, then I think one should go ahead and use dialog sharing. Of course one is free to refrain from carrying out some feature rather than initiating it via dialog sharing, but if you are on the receiving end, then I think support is still expected. Thanks, Paul Adam Roach wrote: > Paul Kyzivat wrote: >> >> >> Adam Roach wrote: >> >>> Because of the true interoperability nightmare that has resulted from >>> dialog sharing, my suggestion would be to disable notifier >>> functionality on those endpoints under such circumstances (perhaps >>> with an implementation option to fall back to 3265 behavior for the >>> truly masochistic). >> >> Can you say more about the "true interoperability nightmare that has >> resulted from dialog sharing"? >> >> I understand that there undoubtedly are interop issues due to some UAs >> not supporting dialog sharing. There are also interop issues due to >> the UAs not supporting an event package, or not supporting GRUU, or >> whatever. Is one more of a nightmare than another? > > It's not lack of support that worries me -- it's mismatched views of > dialog and usage state between two endpoints who both think they've > implemented dialog sharing. The problem is not that things negotiate > down to a lesser set of capabilities -- it's that things act broken in a > way that exposes this mixed-up view of whether a dialog (and its > associated session/subscription) is active. > >> Dialog sharing has been a legal possibility since 3261 was published. >> So it shouldn't be a surprise to anybody. If somebody didn't implement >> support, well, what can you say? > > As one of the key perpetrators of that particular aspect of 3261, I'm > comfortable in saying that we added it in a slapdash fashion at the 11th > hour, without sufficient analysis (and I mean this in a self-deprecating > way, without intending to cast aspersions on any of 3261's editors). > Interactions between usages in a dialog were ridiculously > underspecified. Robert spent a long time trying to rationalize this > behavior after the fact, with the result being RFC 5057. And RFC 5057 > really helps a lot for the minority of implementors who actually know it > exists. However, the issue is complicated enough that it takes 26 pages > to untangle it, and the rules are a tangle of exceptions. Go read 5057 > again, and tell me that people are more likely to get that right than > they are to get confused. > >> It was used primarily because contacts in dialogs often don't have the >> gruu property, and GRUU hasn't been widely implemented. Has that >> situation changed? Will 3265bis somehow result in widespread >> implementation of GRUU by registrars? > > 3265bis is less mature than GRUU (in that one is a -00 individual draft, > and the other is in the RFC editor queue). I think it's reasonable to > rely on predecessor technologies. > > > /a > From christer.holmberg@ericsson.com Mon Mar 23 16:30:49 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB60A28C1A9 for ; Mon, 23 Mar 2009 16:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.768 X-Spam-Level: X-Spam-Status: No, score=-5.768 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFMNKCQjPZmd for ; Mon, 23 Mar 2009 16:30:48 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 169DA3A6C09 for ; Mon, 23 Mar 2009 16:30:48 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 62E832042C; Tue, 24 Mar 2009 00:31:37 +0100 (CET) X-AuditID: c1b4fb3c-aaf59bb000003f6e-98-49c81bd98b64 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3EB092025D; Tue, 24 Mar 2009 00:31:37 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 00:31:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 00:31:36 +0100 Message-ID: In-Reply-To: <49C819D9.50901@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-199-06 Thread-Index: AcmsDlgnsXt+tLLETou0bRquEr0BQQAAH50w References: <49C2D7E5.5050709@nostrum.com> A <0D5F89FAC29E2C41B98A6A762007F5D001AAD921@GBNTHT12009MSX.gb002.siemens.net> <49C819D9.50901@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 23 Mar 2009 23:31:37.0225 (UTC) FILETIME=[8297E790:01C9AC0F] X-Brightmail-Tracker: AAAAAA== Cc: SIP WG , "Elwell, John" Subject: Re: [Sip] draft-ietf-sip-199-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:30:49 -0000 Hi,=20 >>You can have network entities which act as "normal" UAS, which also=20 >>want to send 199. They may e.g. have been configured to do so, since=20 >>the forking proxy does not support 199. Etc. >>And, the text already says that a UAS should not send a 199, unless it has been configured to do so. But, I don't think=20 >>we should forbid it from doing so. > =20 > >No, but you need to motivate why they might do so. Explain that they're sending it because they think there's an upstream=20 >forking proxy that won't. Explain that they might be a B2BUA that has created more than one early dialog with the caller,=20 >and wants to clean some of them up. It makes little sense to say that UAs can do this without some kind of explanation=20 >about why they would do so. The text does talk about the case when the UAS knows, based on configuration, that the proxy does not support 199, but I agree that some text about UAS/B2BUAs creating more than one dialog can be added. Regards, Christer From adam@nostrum.com Mon Mar 23 16:42:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20BC3A69FF for ; Mon, 23 Mar 2009 16:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCeigRehGbdw for ; Mon, 23 Mar 2009 16:42:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8456D3A67DA for ; Mon, 23 Mar 2009 16:42:07 -0700 (PDT) Received: from [130.129.23.244] (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2NNgrVM011359 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Mar 2009 18:42:54 -0500 (CDT) (envelope-from adam@nostrum.com) User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 23 Mar 2009 16:42:52 -0700 From: Adam Roach To: Paul Kyzivat Message-ID: Thread-Topic: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcmsERTKNdxj/CDeNkudjRiRTuSLfA== In-Reply-To: <49C81A67.3030501@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9155/Mon Mar 23 12:26:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:42:08 -0000 On 3/23/09 4:25 PM, "Paul Kyzivat" wrote: > I was pretty heavily involved in gruu. It certainly intended to solve a > problem, but it too ended up much more complex than anybody hoped it > would - to the point that I suspect there is a lot of reluctance to > implement it, and a fair amount of potential to implement it wrong. It definitely spent a lot of its life being quite complicated. But I just recently re-read the version actually in the queue, and it seems much simpler and much more implementable than many of the drafts that preceded it. /a From dworley@nortel.com Mon Mar 23 16:50:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FAF28C219 for ; Mon, 23 Mar 2009 16:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.769 X-Spam-Level: X-Spam-Status: No, score=-6.769 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLwbRy+UWtRP for ; Mon, 23 Mar 2009 16:50:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7614A28C1F9 for ; Mon, 23 Mar 2009 16:50:15 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2NNoaj11485 for ; Mon, 23 Mar 2009 23:50:36 GMT Received: from [47.141.31.244] ([47.141.31.244]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 19:50:59 -0400 From: "Dale Worley" To: SIP In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 23 Mar 2009 19:50:53 -0400 Message-Id: <1237852253.16613.36.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2009 23:51:00.0446 (UTC) FILETIME=[37ED57E0:01C9AC12] Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:50:16 -0000 It seems that with a few adjustments we get to the point that the -bis- is quite reasonable and straightforward regarding "subscribe dialog re-use" issues. Clearly, we have to moderate 4.5.1 to "Notifiers MUST implement GRUU and SHOULD use a GRUU as their contact URI for all dialogs (including non-subscription dialogs)." The reason for the SHOULD is that it means what we must say, "use a GRUU unless there is a very good reason that you can't", by which we mean, "unless you can't get a GRUU" -- there being no other reason that a notifier can't use a GRUU fairly easily. 4.5.1 already requires a subscriber to use a separate dialog if the destination of the subscription is a GRUU. Actually, that sentence doesn't contain MUST, so it should be rephrased "If so, the subscriber MUST create the subscription on a new dialog, using the GRUU as the request URI for the new SUBSCRIBE." (Leaving unspecified the possibility that the subscriber could add Route headers to cope with mandatory outbound proxies and other odd circumstances.) In 4.5.2, it seems to me to be unwise to allow the notifier to respond 403 to subscriptions within existing dialogs, as that is a significant constriction of the current requirements. In the future, when -bis- has been implemented and subscribers can reasonably depend on all notifiers to implement it, then we can safely allow notifiers to be more particular. At least, we need to narrow the statement so that notifiers can only reject shared-dialog SUBSCRIBEs with 403 if the notifier always uses a GRUU as its contact URI. In regard to the long list following "To implement dialog sharing", is any of this material new? As far as I can tell, it is a summary of 3265/5057. If so, it should be explicitly labeled as such, and refer the reader to those RFCs as the normative text. If not, the relationship of this list with those RFCs needs to be made explicit. Dale From dworley@nortel.com Mon Mar 23 17:06:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F573A6A92 for ; Mon, 23 Mar 2009 17:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.754 X-Spam-Level: X-Spam-Status: No, score=-6.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkhLC1Tll+K1 for ; Mon, 23 Mar 2009 17:06:33 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 358293A6C67 for ; Mon, 23 Mar 2009 17:06:33 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2O06qu15177; Tue, 24 Mar 2009 00:06:52 GMT Received: from [47.141.31.244] ([47.141.31.244]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 20:07:16 -0400 From: "Dale Worley" To: Brett Tate In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 23 Mar 2009 20:07:14 -0400 Message-Id: <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 00:07:17.0011 (UTC) FILETIME=[7E015630:01C9AC14] Cc: SIP IETF , Paul Kyzivat Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:06:34 -0000 On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: > Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION > usage, or neither? > > I'm asking mainly because of REFER 481 impacts; however the answer > also has potential implications concerning draft-ietf-sip-info-events. > RFC 5057 appears to imply that it is part of the subscription usage; > however I'm not positive if my interpretation and/or RFC 5057 is > correct. > > If REFER isn't considered part of the INVITE usage, how should REFER > 481 be interpreted? More specifically, should receiver of REFER 481 > send BYE? I would argue that the REFER is part of the INVITE usage, because REFER in that context is intimately related to the INVITE usage -- it is intended to transfer the INVITE usage/dialog transferred to a different destination. And it seems quite safe that if the REFER receives a 481 response, the INVITE usage must not be functional any more, since the far end of that usage has denied that it can act on the REFER. Now it's possible that the REFER, if it is successful, is the first transaction of the subscription usage. But I don't think that has any paradoxical consequences, as by hypothesis, the REFER succeeded. Dale From adam@nostrum.com Mon Mar 23 17:31:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B58F28C1FA for ; Mon, 23 Mar 2009 17:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrrfCMwf9aVj for ; Mon, 23 Mar 2009 17:31:22 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7528A28C1EE for ; Mon, 23 Mar 2009 17:31:19 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2O0W7Nv014899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 19:32:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49C82A05.7070101@nostrum.com> Date: Mon, 23 Mar 2009 17:32:05 -0700 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dale Worley References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <1237852253.16613.36.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1237852253.16613.36.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9155/Mon Mar 23 12:26:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:31:23 -0000 Dale Worley wrote: > It seems that with a few adjustments we get to the point that the -bis- > is quite reasonable and straightforward regarding "subscribe dialog > re-use" issues. > > Clearly, we have to moderate 4.5.1 to "Notifiers MUST implement GRUU and > SHOULD use a GRUU as their contact URI for all dialogs (including > non-subscription dialogs)." The reason for the SHOULD is that it means > what we must say, "use a GRUU unless there is a very good reason that > you can't", by which we mean, "unless you can't get a GRUU" -- there > being no other reason that a notifier can't use a GRUU fairly easily. > That seems a reasonable approach, with the caveat that I'd call out the circumstances surrounding the SHOULD explicitly. That is, I would phrase it like "...MUST use GRUU as their contact URI for all dialogs unless they cannot obtain a GRUU. Note that the only circumstances in which a notifier cannot obtain a GRUU is when they don't meet the criteria for creating self-made GRUUs and their registrar does not support GRUU." > 4.5.1 already requires a subscriber to use a separate dialog if the > destination of the subscription is a GRUU. Actually, that sentence > doesn't contain MUST, so it should be rephrased "If so, the subscriber > MUST create the subscription on a new dialog, using the GRUU as the > request URI for the new SUBSCRIBE." (Leaving unspecified the > possibility that the subscriber could add Route headers to cope with > mandatory outbound proxies and other odd circumstances.) > I'm happy to rephrase this to be use RFC 2119 language. > In 4.5.2, it seems to me to be unwise to allow the notifier to respond > 403 to subscriptions within existing dialogs, as that is a significant > constriction of the current requirements. In what way? Implementors are still allowed to accept such incoming connections, but one of the key changes I think is necessary in this revision is to free implementors from the morass of coding for dialog sharing -- because MOST PEOPLE GET IT WRONG. I see little value with maintaining backwards "compatibility" with a feature that, by and large, wasn't compatible between multiple implementations in the first place. > In regard to the long list following "To implement dialog sharing", is > any of this material new? As far as I can tell, it is a summary of > 3265/5057. If so, it should be explicitly labeled as such, and refer > the reader to those RFCs as the normative text. If not, the > relationship of this list with those RFCs needs to be made explicit. > The list you refer to is copied from various parts of the original text (i.e., 3265). The intention is for this document to obsolete 3265, so referring to 3265 for procedures would make no sense. /a From rjsparks@nostrum.com Mon Mar 23 18:08:39 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F15C3A6917 for ; Mon, 23 Mar 2009 18:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqpO1EgDwR12 for ; Mon, 23 Mar 2009 18:08:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 287163A67D9 for ; Mon, 23 Mar 2009 18:08:37 -0700 (PDT) Received: from dhcp-12fe.meeting.ietf.org (dhcp-12fe.meeting.ietf.org [130.129.18.254]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2O19L0Q017349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Mar 2009 20:09:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <94085CC2-0CED-4C97-B58A-16738C53B2EF@nostrum.com> From: Robert Sparks To: Dale Worley In-Reply-To: <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 18:09:21 -0700 References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 130.129.18.254 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9155/Mon Mar 23 12:26:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP IETF , Paul Kyzivat , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:08:39 -0000 From a usage point of view, it is far more useful to model REFER as if it were a SUBSCRIBE request. It creates a subscribe usage if it succeeds. The impact it has on the invite usage if it fails is the same as if a FOO request failed (which depends on the failure). RjS On Mar 23, 2009, at 5:07 PM, Dale Worley wrote: > On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: >> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION >> usage, or neither? >> >> I'm asking mainly because of REFER 481 impacts; however the answer >> also has potential implications concerning draft-ietf-sip-info- >> events. >> RFC 5057 appears to imply that it is part of the subscription usage; >> however I'm not positive if my interpretation and/or RFC 5057 is >> correct. >> >> If REFER isn't considered part of the INVITE usage, how should REFER >> 481 be interpreted? More specifically, should receiver of REFER 481 >> send BYE? > > I would argue that the REFER is part of the INVITE usage, because > REFER > in that context is intimately related to the INVITE usage -- it is > intended to transfer the INVITE usage/dialog transferred to a > different > destination. > > And it seems quite safe that if the REFER receives a 481 response, the > INVITE usage must not be functional any more, since the far end of > that > usage has denied that it can act on the REFER. > > Now it's possible that the REFER, if it is successful, is the first > transaction of the subscription usage. But I don't think that has any > paradoxical consequences, as by hypothesis, the REFER succeeded. > > Dale > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From pkyzivat@cisco.com Mon Mar 23 18:09:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560D03A6969 for ; Mon, 23 Mar 2009 18:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.478 X-Spam-Level: X-Spam-Status: No, score=-5.478 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIIzejOj2wxZ for ; Mon, 23 Mar 2009 18:09:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8C9F93A67D9 for ; Mon, 23 Mar 2009 18:09:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="145580756" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2009 01:10:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2O1AYCo002804; Mon, 23 Mar 2009 21:10:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2O1AYQP010102; Tue, 24 Mar 2009 01:10:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 21:10:34 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 21:10:34 -0400 Message-ID: <49C832F7.506@cisco.com> Date: Mon, 23 Mar 2009 21:10:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Adam Roach References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <1237852253.16613.36.camel@victoria-pingtel-com.us.nortel.com> <49C82A05.7070101@nostrum.com> In-Reply-To: <49C82A05.7070101@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 01:10:34.0126 (UTC) FILETIME=[55431AE0:01C9AC1D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1703; t=1237857034; x=1238721034; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Comment=20on=20draft-roach-sipc ore-rfc3265bis-00 |Sender:=20 |To:=20Adam=20Roach=20; bh=zTAMR5LBzbG/sSGWhexNTCq35VFUJostRS0hSyew1z4=; b=rhJwOPzECUk/ToylfLxRBmRl5U8iH7YzFNYFZskxe9k2Di3gj2ZPfcH/D4 Aq8LuKPTIseZcKzaJw1l5lB6BsQigLpe1hE8jCPeJ+7pkdR6KTZH6jINW+zj 1jsH9KqWn2; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:09:56 -0000 Adam Roach wrote: >> In 4.5.2, it seems to me to be unwise to allow the notifier to respond >> 403 to subscriptions within existing dialogs, as that is a significant >> constriction of the current requirements. > > In what way? Implementors are still allowed to accept such incoming > connections, but one of the key changes I think is necessary in this > revision is to free implementors from the morass of coding for dialog > sharing -- because MOST PEOPLE GET IT WRONG. I see little value with > maintaining backwards "compatibility" with a feature that, by and large, > wasn't compatible between multiple implementations in the first place. I'd be interested in hearing in what ways "most people" get it wrong. Getting the common cases of dialog sharing right isn't so difficult. I expect that "most people" get corner cases wrong in lots of things. This only frees implementors if: - they are capable of creating their own gruus without registration - or they ONLY work with registrars that support GRUU. - and they only interact with other UAs that support 3265bis. Notably, any phone that *might* be attached to a registrar that doesn't support GRUU will need to support dialog sharing. And any UA that might establish a dialog with somebody that doesn't implement 3265bis should be prepared to have the other end initiate dialog sharing. I guess the question is whether the bis should indicate what should be done to maintain backward compatibility with 3265, or if that should simply be left for implementors to figure out for themselves. I can see the merit in leaving the old cruft out so that it *eventually* goes away. Thanks, Paul From pkyzivat@cisco.com Mon Mar 23 18:32:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAA428C277 for ; Mon, 23 Mar 2009 18:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkDsE6aD6hSl for ; Mon, 23 Mar 2009 18:32:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 93CC328C1E2 for ; Mon, 23 Mar 2009 18:32:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="160438329" Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2009 01:32:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2O1Wu21023682; Tue, 24 Mar 2009 12:32:57 +1100 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2O1WuhT012801; Tue, 24 Mar 2009 01:32:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 21:32:55 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 21:32:55 -0400 Message-ID: <49C83831.7010102@cisco.com> Date: Mon, 23 Mar 2009 21:32:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dale Worley References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 01:32:55.0624 (UTC) FILETIME=[74DB7480:01C9AC20] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3186; t=1237858377; x=1238722377; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Is=20REFER=20within=20dialog=20 part=20of=20INVITE=20or=20subscription=09usage?=0A=20(was=20 RE=3A=20SIP=20INFO) |Sender:=20; bh=YIltTsoSxeBJFScy0wyxytNNsf0S/m8NFm+F5xMtQlM=; b=C6IByYugZZktSyoT73kyR6PjQvH6+HwBumSentY28w+LsqozZV5rUP3Me+ w1KGE4VFeaFcvB8PoJp1/0aUfXiCnFxumDTTjXF09ALVNHf7iSxGL/iRWTro 8MQ6xkOcCXndTO6oyX9dURkgOjwfF09h3l7szGmClCudNZGZ4NAys=; Authentication-Results: syd-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:32:11 -0000 Dale Worley wrote: > On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: >> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION >> usage, or neither? >> >> I'm asking mainly because of REFER 481 impacts; however the answer >> also has potential implications concerning draft-ietf-sip-info-events. >> RFC 5057 appears to imply that it is part of the subscription usage; >> however I'm not positive if my interpretation and/or RFC 5057 is >> correct. >> >> If REFER isn't considered part of the INVITE usage, how should REFER >> 481 be interpreted? More specifically, should receiver of REFER 481 >> send BYE? > > I would argue that the REFER is part of the INVITE usage, because REFER > in that context is intimately related to the INVITE usage -- it is > intended to transfer the INVITE usage/dialog transferred to a different > destination. Well, I guess there is that implied association. (Part of the "do what *I* had in mind" approach that REFER has.) Since this was never spelled out, it could also be simply "while this isn't part of an INVITE usage, if there happens to be an INVITE usage, please refer that one." I guess the question is: would it be valid to send a REFER within an existing dialog that had no INVITE usage? If it were valid, presumably it would have the same meaning as sending one outside a dialog, except that the resulting subscription would share the dialog. I expect that is a usage it would be difficult to find in the wild. Ah, but now I want to reconsider. Remember that REFER can take a method name. So, rather than referring an INVITE, I could be referring MESSAGE, OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the association to the INVITE usage is probably meaningless. (Of course its meaningful for BYE.) > And it seems quite safe that if the REFER receives a 481 response, the > INVITE usage must not be functional any more, since the far end of that > usage has denied that it can act on the REFER. IIRC, 5057 decided that each dialog usage must get its own 481 before it goes away. I don't think there are any cases where a single 481 response can make multiple usages go away. So the important question is whether the REFER is part of the INVITE usage and so its 481 takes down the INVITE usage or not. That gets especially interesting if the dialog already had both an INVITE usage and a SUBSCRIBE usage. Does it make sense that the refer take down the INVITE usage and leave up the SUBSCRIBE usage? > Now it's possible that the REFER, if it is successful, is the first > transaction of the subscription usage. But I don't think that has any > paradoxical consequences, as by hypothesis, the REFER succeeded. Yeah, its already so weird, why not a little more weird? Also, I think it has recently been clarified that the 200 of a SUBSCRIBE should not be considered to create a dialog - that its the NOTIFY that creates the dialog. If so, then I suppose the same should be true of REFER. Bottom line: I can live with it either way, but think it should be documented one way or the other. Thanks, Paul From dworley@nortel.com Mon Mar 23 18:36:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A1528C295 for ; Mon, 23 Mar 2009 18:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.73 X-Spam-Level: X-Spam-Status: No, score=-6.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpuSSxv7Eq7i for ; Mon, 23 Mar 2009 18:36:41 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 676EA28C1E2 for ; Mon, 23 Mar 2009 18:36:41 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2O1asH08972; Tue, 24 Mar 2009 01:36:54 GMT Received: from [47.141.31.251] ([47.141.31.251]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 21:36:37 -0400 From: "Dale Worley" To: Adam Roach In-Reply-To: <49C82A05.7070101@nostrum.com> References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <1237852253.16613.36.camel@victoria-pingtel-com.us.nortel.com> <49C82A05.7070101@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 23 Mar 2009 21:36:35 -0400 Message-Id: <1237858595.16613.53.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 01:36:37.0192 (UTC) FILETIME=[F8EC0C80:01C9AC20] Cc: SIP Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:36:42 -0000 On Mon, 2009-03-23 at 17:32 -0700, Adam Roach wrote: > self-made GRUUs What is a "self-made GRUU"? > > In 4.5.2, it seems to me to be unwise to allow the notifier to respond > > 403 to subscriptions within existing dialogs, as that is a significant > > constriction of the current requirements. > > In what way? Implementors are still allowed to accept such incoming > connections, but one of the key changes I think is necessary in this > revision is to free implementors from the morass of coding for dialog > sharing -- because MOST PEOPLE GET IT WRONG. I see little value with > maintaining backwards "compatibility" with a feature that, by and large, > wasn't compatible between multiple implementations in the first place. That's a good point, although I fear that the real effect will be to free implementors from *fixing their implementations* if something is incorrect. At the least, I think that you *must* limit the ability to send 403 to devices that *are* using GRUUs as their contact. I can *easily* see an implementor implementing the "403" part of -bis- and deciding to omit the "GRUU contact" part. > > In regard to the long list following "To implement dialog sharing", is > > any of this material new? As far as I can tell, it is a summary of > > 3265/5057. If so, it should be explicitly labeled as such, and refer > > the reader to those RFCs as the normative text. If not, the > > relationship of this list with those RFCs needs to be made explicit. > > The list you refer to is copied from various parts of the original text > (i.e., 3265). The intention is for this document to obsolete 3265, so > referring to 3265 for procedures would make no sense. So you're saying that this list is *complete*? Dale From drage@alcatel-lucent.com Mon Mar 23 18:37:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E94228C290 for ; Mon, 23 Mar 2009 18:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUe-n+GwpbsP for ; Mon, 23 Mar 2009 18:37:12 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id BBB2B28C1E2 for ; Mon, 23 Mar 2009 18:37:11 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2O1c0j9025954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 24 Mar 2009 02:38:00 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 24 Mar 2009 02:38:00 +0100 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Tue, 24 Mar 2009 02:37:56 +0100 Thread-Topic: Current SIP status Thread-Index: AcmsIScJV/GZmiPhS3eb/m8F6gdAEA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67577C4DB@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [Sip] Current SIP status X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:37:13 -0000 (As WG chair) This is my current understanding of the status of the SIP deliverables regards Keith Documents published since IETF #73 (4 documents) ------------------------------------------------ draft-ietf-sip-answermode-07 (Proposed standard) Published as RFC 5373 Andrew Allen, Dean Willis draft-ietf-sip-hitchhikers-guide-05 (Informational) Published as RFC 5411 Jonathan Rosenberg draft-ietf-sip-rph-new-namespaces-04 (Proposed standard) Published as RFC 5478 James Polk draft-ietf-sip-fork-loop-fix-08 (Proposed standard) Published as RFC 5393 Robert Sparks, Scott Lawrence, Alan Hawrylyshen, Brian Campen Documents in RFC editor's queue (6 documents) --------------------------------------------- draft-ietf-sip-gruu-15 (Proposed standard) Keith Drage is document shepherd Currently in state: In RFC Editor's Queue - MISSREF (waiting for draft-ietf= -sip-outbound). draft-munakata-sip-privacy-guideline (Informational) Individual submission to RFC editor. Not from SIP WG. Currently in state: In RFC Editor Queue in AUTH48 draft-ietf-sip-ice-option-tag-02 (Proposed standard) Keith Drage is PROTO document shepherd Currently in state: In RFC Editor Queue draft-ietf-sip-sips-09 (Proposed standard) Dean Willis is PROTO document shepherd Currently in state: In RFC Editor's Queue - MISSREF (waiting for draft-ietf= -sip-outbound). draft-ietf-sip-media-security-requirements-09 (Informational) Dean Willis is PROTO document shepherd Currently in state: In RFC Editor Queue in AUTH48 draft-ietf-sip-dtls-srtp-framework-07 (Proposed standard) Dean Willis is PROTO document shepherd Currently in state: In RFC Editor Queue Documents with IESG (7 documents) ---------------------------------- draft-ietf-sip-certs-07 (Proposed standard) Dean Willis is PROTO document shepherd Publication requested 1st February 2008. Jon Peterson is responsible AD. Currently in state: Waiting for AD Go-Ahead draft-ietf-sip-xcapevent-04 (Proposed standard) Dean Willis is document shepherd OMA liaison - interaction with draft-ietf-simple-xcap-diff Publication requested 2nd July 2008 Currently in state: IESG Evaluation:: Revised ID Needed draft-ietf-sip-outbound-16 (Proposed standard) Publication requested 28th July 2008 Dean Willis is PROTO document shepherd Currently in state: Publication requested draft-ietf-sip-connect-reuse-13 Candidate: Proposed standard Publication requested 24th October 2008 Keith Drage is PROTO document shepherd Currently in state: AD Evaluation:: AD Followup draft-ietf-sip-session-policy-framework-05 Candidate: Proposed standard Publication requested 1st November 2008 Keith Drage is PROTO document shepherd Currently in state: IESG Evaluation:: Revised ID Needed draft-ietf-sip-record-route-fix-06 Candidate: Best Current Practice Publication requested 16th March 2009 Dean Willis is PROTO document shepherd Currently in state: Publication requested draft-ietf-sip-body-handling-06 Candidate: Proposed standard Publication requested 11th March 2009 Currently in state: Publication requested Documents returned to the WG from IESG (1 document) --------------------------------------------------- draft-ietf-sip-e2m-sec-06 (Proposed standard) Dean Willis is PROTO document shepherd=20 IESG last call completed 14th May 2007. No last call comments. Problems wit= h proposed standard status See draft-draft-rai-sip-header-process for possible process changes to allo= w progressing as experimental Current status: Dead Documents finished in the WG, awaiting submission to IESG (3 documents) ------------------------------------------------------------------------- draft-ietf-sip-domain-certs-02 Candidate: Informational ? Proposed standard Milestone for WGLC November 2007 WGLC initiated 22nd February 2008 to complete 7th March 2008 Keith Drage is PROTO document shepherd Milestone for submission to IESG September 2008 draft-ietf-sip-eku-03 Candidate: Proposed standard Milestone for WGLC November 2007 WGLC initiated 22nd February 2008 to complete 7th March 2008 Keith Drage is PROTO document shepherd Milestone for submission to IESG September 2008 draft-ietf-sip-subnot-etags-03 Agreed as WG item (subject to AD) at IETF#67 Candidate: proposed standard September 2007 -- Extension for use of etags in conditional notification to= WGLC WGLC initiated 4th September 2007 to complete 18th September 2007 Dean Willis is PROTO document shepherd December 2007 -- Extension for use in etags in conditional notification to = IESG (PS) Documents in working group last call (5 documents) -------------------------------------------------- draft-ietf-sip-location-conveyance-13 Candidate: Proposed standard Milestone for submission to IESG is December 2008 WGLC initiated 4th March 2007 to complete 2nd April 2007. WGLC initiated 16= th March 2009 to complete 23rd March 2009 Keith Drage is PROTO document shepherd draft-ietf-sip-saml-06 Candidate: Experimental Milestone for submission to IESG is December 2008 WGLC initiated 4th November 2008 to complete 18th November 2008 Keith Drage is PROTO document shepherd draft-ietf-sip-199-06 Candidate: Proposed standard WGLC initiated 4th November 2008 to complete 18th November 2008 Keith Drage is PROTO document shepherd Milestone for submission to IESG Nov 2008 draft-ietf-sip-ua-privacy-06 Candidate: Informational Milestone for submission to IESG April 2009 Keith Drage is PROTO document shepherd WGLC initiated 17th February 2009 to complete 2nd March 2009 on -03 version draft-ietf-sip-info-events-03 Candidate: Proposed standard WGLC initiated 16th February 2009 to complete 4th March 2009 on -03 version Milestone for submission to IESG is April 2009 Keith Drage is PROTO document shepherd Documents still in discussion in working group (2 documents) ------------------------------------------------------------ draft-ietf-sip-sec-flows-01 Candidate: Informational Milestone for WGLC is March 2009 Milestone for submission to IESG is July 2009 To a certain extent dependent on resolution of ideas in (and therefore wait= ing on them): draft-ietf-sip-sips-02 =20 draft-gurbani-sip-domain-certs-04=20 Dean Willis is PROTO document shepherd Draft expired and removed from drafts directory=20 draft-rosenberg-sip-target-uri-delivery-01=20 Agreed as WG item at IETF#67 Candidate: proposed standard December 2008: Delivering request-URI and parameters to UAS via proxy to WG= LC February 2009: Delivering request-URI and parameters to UAS via proxy to IE= SG (PS) Dean Willis is PROTO document shepherd Other WG work -------------- Essential corrections Milestone: 1st batch to IESG in March 2009 Robert Sparks to be lead editor Process in draft-drage-sip-essential-correction-03 Will roll in RFC 3420 and draft-ietf-sip-fork-loop-fix in first published v= ersion of RFC 3261 update See: http://www.softarmor.com/mediawiki/index.php/Essential_Corrections_Tra= cking Current documents under consideration: draft-ietf-sip-ipv6-abnf-fix-02 (WGLC complete) draft-sparks-sip-invfix-03 (WGLC complete but revised) Keith Drage is PROTO document shepherd Identify requirements for test matrix to move SIP to Draft Standard Milestone March 2009 Robert Sparks coordinating input Draft-sparks-sip-steps-to-draft-00 contains a proposal Now updated to: draft-sparks-sip-3261-interop-statement-00=20 draft-sparks-sip-3261-norm-ref-status-00 = From adam@nostrum.com Mon Mar 23 18:44:39 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2DCA3A6C7E for ; Mon, 23 Mar 2009 18:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A2u3v7U9qVA for ; Mon, 23 Mar 2009 18:44:39 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id ACBD83A6C7D for ; Mon, 23 Mar 2009 18:44:38 -0700 (PDT) Received: from [130.129.23.244] (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2O1jOjO019881 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Mar 2009 20:45:27 -0500 (CDT) (envelope-from adam@nostrum.com) User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 23 Mar 2009 18:45:24 -0700 From: Adam Roach To: Dale Worley Message-ID: Thread-Topic: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcmsIjLsc/MVp+yD8k6+HpCbfT2mPA== In-Reply-To: <1237858595.16613.53.camel@victoria-pingtel-com.us.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9155/Mon Mar 23 12:26:16 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:44:40 -0000 On 3/23/09 6:36 PM, "Dale Worley" wrote: > On Mon, 2009-03-23 at 17:32 -0700, Adam Roach wrote: >> self-made GRUUs > > What is a "self-made GRUU"? See http://tools.ietf.org/html/draft-ietf-sip-gruu-15#section-4.3 > At the least, I think that you *must* limit the ability to send 403 to > devices that *are* using GRUUs as their contact. I can *easily* see an > implementor implementing the "403" part of -bis- and deciding to omit > the "GRUU contact" part. Sounds reasonable. Of course, you can send a 403 to any request at any time according to local policy, but I see the potential need to warn people away from sending it for this particular reason under these particular circumstances. >> The list you refer to is copied from various parts of the original text >> (i.e., 3265). The intention is for this document to obsolete 3265, so >> referring to 3265 for procedures would make no sense. > > So you're saying that this list is *complete*? What I'm claiming right now is that it is a complete list of every sentence and clause in 3265 relating to the topic. A *complete* list would include the stuff in 5057 -- but I'm hesitant to suck in 20+ pages of information that is already specified elsewhere. /a From drage@alcatel-lucent.com Mon Mar 23 19:00:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2307C28C1E2; Mon, 23 Mar 2009 19:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S-Oxe-cRxks; Mon, 23 Mar 2009 19:00:09 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 2FC8828C10B; Mon, 23 Mar 2009 19:00:08 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2O20v3k005959 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 03:00:57 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 24 Mar 2009 03:00:57 +0100 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" , sipping Date: Tue, 24 Mar 2009 03:00:52 +0100 Thread-Topic: Slides for SIP and SIPPING sessions Thread-Index: AcmsJFwj9yT+3IENTXaCwtMRz44fEQ== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67577C4DF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sip-chairs@tools.ietf.org" , "sipping-chairs@tools.ietf.org" Subject: [Sip] Slides for SIP and SIPPING sessions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 02:00:10 -0000 (As SIP WG chair) Please make sure you submit your slides well before the start of the sessio= ns of SIP or SIPPING in which you are presenting. We would suggest deadline= s of: Tuesday 13:00 session - submit by Tuesday 9:00 Wednesday 13:00 session - submit by Wednesday 9:00 Friday 9:00 session - submit by Thursday 15:00 These are the latest time for submission - there is nothing wrong with send= ing them to us early. To avoid confusion, you may want to send them to both sets of chairs, given= the combined nature of the agenda this time round. regards Keith= From abhatnagar192006@gmail.com Mon Mar 23 20:29:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9113A690E for ; Mon, 23 Mar 2009 20:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgWS1dIoNIA0 for ; Mon, 23 Mar 2009 20:29:14 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 4C1BC3A67A3 for ; Mon, 23 Mar 2009 20:29:14 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3083431wfg.31 for ; Mon, 23 Mar 2009 20:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oENDJQrAHtTY5nxCGONI9oFPE8Bur5ZUV0Cv4fJEt6s=; b=tgraWqHcQmcufMdxqeNsZjUiXDL2s5uOHPHQF+5wIygVDgERnRXQgLVr5dF9JuSlzV iu9qzCY3ZDi3ryWZNITKLgONt24TpliWVyC0jFYOxWMiw5O0HtqtwkX5Xb1PyvVh1e72 xB+QiVJlfIafbqE/mpaeVnqu2Ge4pW61OTFpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uxdyhmhlckYTF9Oq1uMiNjyuEUSNgx9+LS9cqbsSWGjgJ7UNqRv4NXG2Pl0A7tvnyt OEwMblJwLx8Rv66iCeLMHtBMTkPfj8AslVEYzCyal+S7QGNJ2OR/eESnBu+1NZblZzEJ 1V8kp9zUmmpCbi9TTII+DGqVP5BgFtbpFyg1M= MIME-Version: 1.0 Received: by 10.142.207.8 with SMTP id e8mr3177997wfg.78.1237865404992; Mon, 23 Mar 2009 20:30:04 -0700 (PDT) In-Reply-To: <49C83831.7010102@cisco.com> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> Date: Tue, 24 Mar 2009 04:00:04 +0030 Message-ID: From: aayush bhatnagar To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 03:29:15 -0000 REFER if placed within the scope of the existing dialog usage of INVITE will reuse its dialog usage, and create an implicit subscription for the refer event package at the recipient. However, if the recipient chooses to reject the in dialog REFER request, the communication established by the INVITE should not be affected. Such a rejection scenario implies that the call transfer failed..however the existing active call should not be torn down. REFER if sent outside the scope of any exisiting dialog will behave as a dialog creating request and will establish a subscription at the recipient as described above. This subscription is only used to notify the status of the sip session referral to the originator and is seperate from any other subscribe usage that may have existed at the recipient. As far as accessing the referred resource is concerned...using the method parameter, it depends upon the business logic of the recipient of the REFER request. You may send a REFER to a conferencing server with a method INVITE to invite a user to join a conference. A method parameter with the value BYE would imply removal from the conference by the server and so on. I dont think you can include a SUBSCRIBE in the method parameter of the REFER request. You have no way of telling the event package usage of the subscription to the recipient, as the event header cannot be included in the REFER request. Moreover, you can never be sure whether the subscription usage is even applicable to the recipient or whether the recipient even supports it. aayush On 3/24/09, Paul Kyzivat wrote: > > > Dale Worley wrote: >> On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: >>> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION >>> usage, or neither? >>> >>> I'm asking mainly because of REFER 481 impacts; however the answer >>> also has potential implications concerning draft-ietf-sip-info-events. >>> RFC 5057 appears to imply that it is part of the subscription usage; >>> however I'm not positive if my interpretation and/or RFC 5057 is >>> correct. >>> >>> If REFER isn't considered part of the INVITE usage, how should REFER >>> 481 be interpreted? More specifically, should receiver of REFER 481 >>> send BYE? >> >> I would argue that the REFER is part of the INVITE usage, because REFER >> in that context is intimately related to the INVITE usage -- it is >> intended to transfer the INVITE usage/dialog transferred to a different >> destination. > > Well, I guess there is that implied association. (Part of the "do what > *I* had in mind" approach that REFER has.) Since this was never spelled > out, it could also be simply "while this isn't part of an INVITE usage, > if there happens to be an INVITE usage, please refer that one." > > I guess the question is: would it be valid to send a REFER within an > existing dialog that had no INVITE usage? If it were valid, presumably > it would have the same meaning as sending one outside a dialog, except > that the resulting subscription would share the dialog. I expect that is > a usage it would be difficult to find in the wild. > > Ah, but now I want to reconsider. Remember that REFER can take a method > name. So, rather than referring an INVITE, I could be referring MESSAGE, > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the > association to the INVITE usage is probably meaningless. (Of course its > meaningful for BYE.) > >> And it seems quite safe that if the REFER receives a 481 response, the >> INVITE usage must not be functional any more, since the far end of that >> usage has denied that it can act on the REFER. > > IIRC, 5057 decided that each dialog usage must get its own 481 before it > goes away. I don't think there are any cases where a single 481 response > can make multiple usages go away. > > So the important question is whether the REFER is part of the INVITE > usage and so its 481 takes down the INVITE usage or not. That gets > especially interesting if the dialog already had both an INVITE usage > and a SUBSCRIBE usage. Does it make sense that the refer take down the > INVITE usage and leave up the SUBSCRIBE usage? > >> Now it's possible that the REFER, if it is successful, is the first >> transaction of the subscription usage. But I don't think that has any >> paradoxical consequences, as by hypothesis, the REFER succeeded. > > Yeah, its already so weird, why not a little more weird? > > Also, I think it has recently been clarified that the 200 of a SUBSCRIBE > should not be considered to create a dialog - that its the NOTIFY that > creates the dialog. If so, then I suppose the same should be true of REFER. > > Bottom line: I can live with it either way, but think it should be > documented one way or the other. > > Thanks, > Paul > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From jiri@iptel.org Mon Mar 23 21:53:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6CB3A69DC for ; Mon, 23 Mar 2009 21:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXqZs8j92QUS for ; Mon, 23 Mar 2009 21:53:03 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 8F0633A692D for ; Mon, 23 Mar 2009 21:53:02 -0700 (PDT) Received: from dhcp-10b4.meeting.ietf.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 6E4FD1811CC9; Tue, 24 Mar 2009 05:53:51 +0100 (CET) Message-ID: <49C8675E.9080501@iptel.org> Date: Tue, 24 Mar 2009 05:53:50 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dean Willis References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 04:53:04 -0000 Dean Willis wrote: > > On Feb 23, 2009, at 3:37 PM, Dale Worley wrote: > >> I've been considering the following idea for a diagnostic tool, and I'd >> like to get some feedback on it. >> >> The goal is to be able to trace the progress of a SIP request through >> the network, including seeing the forking structure. We first need to >> pick a provisional response codes. It appears that "170" is not >> currently used. This response code is also used as an option-tag for >> this feature. The processing is that whenever a SIP element receives a >> request that contains "Supported: 170", the element will immediately (in >> addition to anything else that it would do with the request) send a 170 >> response upstream, containing the request as its body (media type >> message/sipfrag). > > > Your idea has merit. I believe Jiri Kuthan was working on something like > this a few years ago. the problem and solution has been quite the same as later appeared with the sip-frag based draft. (to reiterate: it is a problem for upstream troubleshooter to figure out what's going on downstream in a proxy chain, when it does not even know where the problem could have occured) In our proxy implementation we do don't reveal the whole SIP message in error replies, just very few items that are critical to locating the trouble. In particular, the current request URI, via-count, and upstream IP (from the error-producing hop's perspective). I don't think these pieces would be ever causing message size concerns in the field. This implementation works indeeed well in the field and is useful. A standard would be better to allow monitoring equipment to provide better troubleshooting capabilities. Nevertheless, I think that troubleshooting has been historically of rather marginal interest here, so I'm not sure if there is really an action to be made. -jiri for historical records: http://tools.ietf.org/id/draft-kuthan-sipping-diag-00.txt also: a great deal of troubleshooting information can be achieved using traceroute-like tool, sipsak. It takes no standard changes for its basic operation. Alas, for most qualified assertions more diagnostic information would be useful, or at least Warning header-field which would reveal who declined a request. (maybe a topic for a BCP? and religious discussions about benefits of being able to troubleshoot a network versus benefits of being able to hide it? ;-) > > I've also previously suggested a similar provisional response to inform > the UAC about retargeting being done by a proxy. In addition to > debugging, this helps avoid the unanticipated respondent problem. > > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From jiri@iptel.org Mon Mar 23 21:56:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3A828C133 for ; Mon, 23 Mar 2009 21:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVKeXnWPrTo4 for ; Mon, 23 Mar 2009 21:56:05 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 36F4328C121 for ; Mon, 23 Mar 2009 21:56:05 -0700 (PDT) Received: from dhcp-10b4.meeting.ietf.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id A93171811CC9; Tue, 24 Mar 2009 05:56:54 +0100 (CET) Message-ID: <49C86815.90409@iptel.org> Date: Tue, 24 Mar 2009 05:56:53 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Robert Sparks References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 04:56:08 -0000 Robert Sparks wrote: > Won't this run into exactly the same response-size obstacle that the > previous diagnostics work tripped up on? IMO, the most compelling piece of information is what one needs to learn about where an error occured in the SIP chain at all. at least turning on Warning HF. Ideally revealing current request URI too. This amount of information helps a lot but does not break message size constraints in the field. > It might help to spend some time trying to find some other pattern than > trying to use responses for moving the information you're trying to > capture around. > Source-routed requests in the opposite direction? (using content > indirection?) Subscribe/Notify? I'm a bit worried that SUB-NOT is another piece of complexity which is not necessarily helpful when a simple transaction fails. (chance is high SUB-NOT will fail too) -jiri > Maybe something else... > > RjS > > On Feb 23, 2009, at 3:37 PM, Dale Worley wrote: > >> I've been considering the following idea for a diagnostic tool, and I'd >> like to get some feedback on it. >> >> The goal is to be able to trace the progress of a SIP request through >> the network, including seeing the forking structure. We first need to >> pick a provisional response codes. It appears that "170" is not >> currently used. This response code is also used as an option-tag for >> this feature. The processing is that whenever a SIP element receives a >> request that contains "Supported: 170", the element will immediately (in >> addition to anything else that it would do with the request) send a 170 >> response upstream, containing the request as its body (media type >> message/sipfrag). >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From BPenfield@acmepacket.com Mon Mar 23 23:44:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FDA28C1A5 for ; Mon, 23 Mar 2009 23:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlRcKBqpcmyn for ; Mon, 23 Mar 2009 23:44:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6BD4E3A63EC for ; Mon, 23 Mar 2009 23:44:26 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 02:45:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Mar 2009 02:45:13 -0400 From: Bob Penfield To: Christer Holmberg Date: Tue, 24 Mar 2009 02:45:07 -0400 Thread-Topic: [Sip] I-D Action:draft-ietf-sip-199-06.txt Thread-Index: AcmbMKe+xsFi6kj+QB+gB2v3KJUGbABMpvRQAEOYpKAADKsk4AEpp3CgAn/zKyg= Message-ID: References: <20090302121502.4C42D3A6858@core3.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] I-D Action:draft-ietf-sip-199-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 06:44:27 -0000 The proxy only needs to use the top Via that it inserted. The proxy needs to keep a list of early dialogs associated with each client= transacton. As part of that early dialog state, it needs to have a flag to= indicate whether or not a 199 was received and forwarded by the proxy so t= hat no more than one 199 response is sent for a given dialog. When a 1xx re= sponse that creates an early dialog is received, the proxy adds the early d= ialog to the list (if it has not already). When the non-2xx final response = is received, it can generate 199 responses for each early dialog in the lis= t which has not already had a 199 sent. ________________________________________ From: Christer Holmberg [christer.holmberg@ericsson.com] Sent: Wednesday, March 11, 2009 9:20 AM To: Bob Penfield Cc: sip@ietf.org Subject: RE: [Sip] I-D Action:draft-ietf-sip-199-06.txt Hi Bob, >>>In fact, if the proxy is keeping track of early dialogs, under what >>>circumstances would it not be "able to identify additional early >>>dialogs which are terminated by the same non-2xx final response"? >> >>Just because the proxy keeps track of early dialogs, it doesn't >>necessarily know that an error response on early dialog X also >>terminates early dialog Y. In order to know that, the forking proxy >>needs to know that early dialogs X and Y come from the same forking >>proxy further down the path. >> > >Of course it can. If the proxy forwarded the request to Z, >and Z forked to X and Y, the provisional responses from X and >Y that created the early dialogs would have the same >branch-id. The error response from Z would have that same >branch-id. The proxy would know that all early dialogs >created by a 1xx with that branch-id would have terminated >(i.e. both X and Y). But, the branch-id is part of the Via, which is removed by each entity when forwarding the response. So, the forking proxy is never going to get the branch-id inserted by Z, is it? >>>Section 8 (199 Early Dialog Terminated) seems out of place. >>>Shouldn't this be in the introduction? or in an "Overview Of >>>Operation" between sections 3 and 4? >> >>I have tried to use other similar drafts as "template". >> >> >>>The text in Section 9 (Usage with SDP offer/answer) should be in >>>section 5 (User Agent Server behavior). >> >>I think it is good to have a separate chapter. Of course, I could refer >>to chapter 9 from chapter 5. > >My point is that all too often behavior requirements (MUST, >SHOULD, MAY, etc.) get buried is separate sections and folks >can miss them. If all the requirements are in the applicable >"behavior" section, they are easy to find and developers are less likely >to miss them. If you want it to be a separate section, make >it 5.1. All UAS requirements should be in section 5 or a >subsection thereof. > >>>The statement in section 10 recommending that the UAS send >>>199 unreliably should be in section 5. >>> >>>The statement in section 10 forbidding proxies from sending >>>199 reliably should be in section 6 (Proxy behavior). >> >>Same as for offer/answer. >> >>Since the 199 procedures related to offer/answer and reliable responses >>are special, I think it is good to have specific chapters for it. >> >The requirements/restrictions for reliable provisional >responses are very important. They could easily be missed by >having them in a separate chapter in the back of the >document. Again, all UAS behavior requirements should be in >section 5 (or sub-section) and all proxy behavior >requirements should be in chapter 6 (or sub-section). I'll think of something. But, as you ok with the text as such? It's only the location of the text which you have an issue with? Regards, Christer= From christer.holmberg@ericsson.com Tue Mar 24 00:10:01 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A8E3A68FB for ; Tue, 24 Mar 2009 00:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.772 X-Spam-Level: X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flCzidozaXs9 for ; Tue, 24 Mar 2009 00:10:00 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 42D6E3A63EC for ; Tue, 24 Mar 2009 00:10:00 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5E9332056A; Tue, 24 Mar 2009 08:10:49 +0100 (CET) X-AuditID: c1b4fb3c-aa758bb000003f6e-59-49c887794842 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2EAAF2050B; Tue, 24 Mar 2009 08:10:49 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 08:10:49 +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: Tue, 24 Mar 2009 08:07:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-199-06.txt Thread-Index: AcmbMKe+xsFi6kj+QB+gB2v3KJUGbABMpvRQAEOYpKAADKsk4AEpp3CgAn/zKygAARooZg== References: <20090302121502.4C42D3A6858@core3.amsl.com> , From: "Christer Holmberg" To: "Bob Penfield" X-OriginalArrivalTime: 24 Mar 2009 07:10:49.0116 (UTC) FILETIME=[A8CCD5C0:01C9AC4F] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-ietf-sip-199-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:10:01 -0000 Hi, =20 >The proxy only needs to use the top Via that it inserted. > >The proxy needs to keep a list of early dialogs associated with each = client transacton. As part of that=20 >early dialog state, it needs to have a flag to indicate whether or not = a 199 was received and forwarded by=20 >the proxy so that no more than one 199 response is sent for a given = dialog. When a 1xx response that creates=20 >an early dialog is received, the proxy adds the early dialog to the = list (if it has not already). When the=20 >non-2xx final response is received, it can generate 199 responses for = each early dialog in the list which=20 >has not already had a 199 sent. Yes, but the issue is how the proxy knows whether it has sent a 199 for = the early dialog indicated in the error response. The issue is whether the proxy can detect that a final response is = generated by another forking proxy, and therefor terminate more than one = early dialog. Maybe the Via mechanism you describe works... I need to draw some = figures :) Regards, Christer _______________________________________ From: Christer Holmberg [christer.holmberg@ericsson.com] Sent: Wednesday, March 11, 2009 9:20 AM To: Bob Penfield Cc: sip@ietf.org Subject: RE: [Sip] I-D Action:draft-ietf-sip-199-06.txt Hi Bob, >>>In fact, if the proxy is keeping track of early dialogs, under what >>>circumstances would it not be "able to identify additional early >>>dialogs which are terminated by the same non-2xx final response"? >> >>Just because the proxy keeps track of early dialogs, it doesn't >>necessarily know that an error response on early dialog X also >>terminates early dialog Y. In order to know that, the forking proxy >>needs to know that early dialogs X and Y come from the same forking >>proxy further down the path. >> > >Of course it can. If the proxy forwarded the request to Z, >and Z forked to X and Y, the provisional responses from X and >Y that created the early dialogs would have the same >branch-id. The error response from Z would have that same >branch-id. The proxy would know that all early dialogs >created by a 1xx with that branch-id would have terminated >(i.e. both X and Y). But, the branch-id is part of the Via, which is removed by each entity when forwarding the response. So, the forking proxy is never going to get the branch-id inserted by Z, is it? >>>Section 8 (199 Early Dialog Terminated) seems out of place. >>>Shouldn't this be in the introduction? or in an "Overview Of >>>Operation" between sections 3 and 4? >> >>I have tried to use other similar drafts as "template". >> >> >>>The text in Section 9 (Usage with SDP offer/answer) should be in >>>section 5 (User Agent Server behavior). >> >>I think it is good to have a separate chapter. Of course, I could refer >>to chapter 9 from chapter 5. > >My point is that all too often behavior requirements (MUST, >SHOULD, MAY, etc.) get buried is separate sections and folks >can miss them. If all the requirements are in the applicable >"behavior" section, they are easy to find and developers are less likely >to miss them. If you want it to be a separate section, make >it 5.1. All UAS requirements should be in section 5 or a >subsection thereof. > >>>The statement in section 10 recommending that the UAS send >>>199 unreliably should be in section 5. >>> >>>The statement in section 10 forbidding proxies from sending >>>199 reliably should be in section 6 (Proxy behavior). >> >>Same as for offer/answer. >> >>Since the 199 procedures related to offer/answer and reliable responses >>are special, I think it is good to have specific chapters for it. >> >The requirements/restrictions for reliable provisional >responses are very important. They could easily be missed by >having them in a separate chapter in the back of the >document. Again, all UAS behavior requirements should be in >section 5 (or sub-section) and all proxy behavior >requirements should be in chapter 6 (or sub-section). I'll think of something. But, as you ok with the text as such? It's only the location of the text which you have an issue with? Regards, Christer From sdoken@qualcomm.com Tue Mar 24 00:16:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363993A6A24 for ; Tue, 24 Mar 2009 00:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGDkZ+eL7XVt for ; Tue, 24 Mar 2009 00:16:26 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 160843A6952 for ; Tue, 24 Mar 2009 00:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1237879037; x=1269415037; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 Paul=20Kyzivat=20,=20Dale=20Worley=20 |CC:=20SIP=20IETF=20, =20Brett=20Tate=20|Date:=20Tue,=2024 =20Mar=202009=2000:17:09=20-0700|Subject:=20RE:=20[Sip] =20Is=20REFER=20within=20dialog=20part=20of=20INVITE=20or =20subscription=0D=0A=09usage?=20(was=20RE:=20SIP=20INFO) |Thread-Topic:=20[Sip]=20Is=20REFER=20within=20dialog=20p art=20of=20INVITE=20or=20subscription=0D=0A=09usage?=20(w as=20RE:=20SIP=20INFO)|Thread-Index:=20AcmsIMLcE9SNpRykRg WdgtAgIRfJEAALfx7w|Message-ID:=20 |References:=20<24ACC38D-8B7D-46E6-B767-73A33F6C9266@stan dardstrack.com>=0D=0A=09=09<49C79CFD.1010408@cisco.com> =0D=0A=09=09<9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@m bx02.citservers.local>=0D=0A=09<1237853234.16613.41.camel @victoria-pingtel-com.us.nortel.com>=0D=0A=20<49C83831.70 10102@cisco.com>|In-Reply-To:=20<49C83831.7010102@cisco.c om>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5562"=3B=20a=3D"16526468"; bh=DZP93JJmdRkdWU/opZYpGHw1tb2S8GSr4B2o3El8qHY=; b=GpDzxceN9hJ/YnI8HLa4fF1mshPjViPEHvQebjmmI/7ZAHPe6AXm2aug kyZtww9weITGDjaBaqLotJGl/AHtOfORKGBKnuFxCnnop3GPo5s/44CYD 9L/VYDMlmVcBg+ZHC2ICS6zeUjBPMqd6THcO7/DerBXMvXfzFvBLhOi3M A=; X-IronPort-AV: E=McAfee;i="5300,2777,5562"; a="16526468" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 00:17:16 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2O7HGhu019218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2009 00:17:16 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2O7HFfp016973 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 00:17:15 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Tue, 24 Mar 2009 00:17:15 -0700 From: "Doken, Serhad" To: Paul Kyzivat , Dale Worley Date: Tue, 24 Mar 2009 00:17:09 -0700 Thread-Topic: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) Thread-Index: AcmsIMLcE9SNpRykRgWdgtAgIRfJEAALfx7w Message-ID: References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> In-Reply-To: <49C83831.7010102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:16:27 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, March 23, 2009 6:33 PM > To: Dale Worley > Cc: SIP IETF; Brett Tate > Subject: Re: [Sip] Is REFER within dialog part of INVITE or > subscription usage? (was RE: SIP INFO) >=20 >=20 >=20 > Dale Worley wrote: > > On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: > >> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION > >> usage, or neither? > >> > >> I'm asking mainly because of REFER 481 impacts; however the answer > >> also has potential implications concerning draft-ietf-sip-info- > events. > >> RFC 5057 appears to imply that it is part of the subscription usage; > >> however I'm not positive if my interpretation and/or RFC 5057 is > >> correct. > >> > >> If REFER isn't considered part of the INVITE usage, how should REFER > >> 481 be interpreted? More specifically, should receiver of REFER 481 > >> send BYE? > > > > I would argue that the REFER is part of the INVITE usage, because > REFER > > in that context is intimately related to the INVITE usage -- it is > > intended to transfer the INVITE usage/dialog transferred to a > different > > destination. >=20 > Well, I guess there is that implied association. (Part of the "do what > *I* had in mind" approach that REFER has.) Since this was never spelled > out, it could also be simply "while this isn't part of an INVITE usage, > if there happens to be an INVITE usage, please refer that one." >=20 > I guess the question is: would it be valid to send a REFER within an > existing dialog that had no INVITE usage? If it were valid, presumably Yes, I think so. > it would have the same meaning as sending one outside a dialog, except > that the resulting subscription would share the dialog. I expect that > is > a usage it would be difficult to find in the wild. Consider a third party control application that forces an endpoint to regis= ter : REFER sip:phone.doken.com SIP/2.0 Refer-To: that triggers a REG to the registrar as : REGISTER sip:serhad@doken.com SIP/2.0 >=20 > Ah, but now I want to reconsider. Remember that REFER can take a method > name. So, rather than referring an INVITE, I could be referring > MESSAGE, > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the > association to the INVITE usage is probably meaningless. (Of course its > meaningful for BYE.) >=20 > > And it seems quite safe that if the REFER receives a 481 response, > the > > INVITE usage must not be functional any more, since the far end of > that > > usage has denied that it can act on the REFER. >=20 > IIRC, 5057 decided that each dialog usage must get its own 481 before > it > goes away. I don't think there are any cases where a single 481 > response > can make multiple usages go away. >=20 > So the important question is whether the REFER is part of the INVITE > usage and so its 481 takes down the INVITE usage or not. That gets > especially interesting if the dialog already had both an INVITE usage > and a SUBSCRIBE usage. Does it make sense that the refer take down the > INVITE usage and leave up the SUBSCRIBE usage? >=20 > > Now it's possible that the REFER, if it is successful, is the first > > transaction of the subscription usage. But I don't think that has > any > > paradoxical consequences, as by hypothesis, the REFER succeeded. >=20 > Yeah, its already so weird, why not a little more weird? >=20 > Also, I think it has recently been clarified that the 200 of a > SUBSCRIBE > should not be considered to create a dialog - that its the NOTIFY that > creates the dialog. If so, then I suppose the same should be true of > REFER. >=20 > Bottom line: I can live with it either way, but think it should be > documented one way or the other. >=20 > Thanks, > Paul > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From sdoken@qualcomm.com Tue Mar 24 00:31:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138FE3A6A9E for ; Tue, 24 Mar 2009 00:31:04 -0700 (PDT) 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=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlh8t5iZs01I for ; Tue, 24 Mar 2009 00:31:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A61143A6A84 for ; Tue, 24 Mar 2009 00:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1237879913; x=1269415913; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 aayush=20bhatnagar=20,=0D=0A =20=20=20=20=20=20=20=20Paul=20Kyzivat=0D=0A=09|CC:=20SIP=20IETF=20,=20Brett=20T ate=20|Date:=20Tue,=2024=20Mar=20200 9=2000:31:47=20-0700|Subject:=20RE:=20[Sip]=20Is=20REFER =20within=20dialog=20part=20of=20INVITE=20or=20subscripti on=0D=0A=09usage?=20(was=20RE:=20SIP=20INFO) |Thread-Topic:=20[Sip]=20Is=20REFER=20within=20dialog=20p art=20of=20INVITE=20or=20subscription=0D=0A=09usage?=20(w as=20RE:=20SIP=20INFO)|Thread-Index:=20AcmsMNuOBsZsXKO0Tz +pmfKYiD2r+AAIHFtw|Message-ID:=20 |References:=20<24ACC38D-8B7D-46E6-B767-73A33F6C9266@stan dardstrack.com>=0D=0A=09<49C79CFD.1010408@cisco.com>=0D =0A=09<9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.c itservers.local>=0D=0A=09<1237853234.16613.41.camel@victo ria-pingtel-com.us.nortel.com>=0D=0A=09<49C83831.7010102@ cisco.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5562"=3B=20a=3D"16526627"; bh=Z6zk7JfEK7i0ReCu3wtXsCvfEysryNbeebUQ1WQqGNE=; b=ALG2JhH1etfOzceCC/W0nUP5itImHc86NMNU4Kg4Vys2KPohDdVtiWDa nGXbv75YZmWBXBKFq0nftS8p/HykuiJ5Aj2QD7eKp/Lbx9HQ1Y35NZwGi NFZPCUtJVXB8wIWrUcTYgByINyDVUWIEux35m7GCSJiEdQH9O1HhGZixR g=; X-IronPort-AV: E=McAfee;i="5300,2777,5562"; a="16526627" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 00:31:53 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2O7Vrgt020195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2009 00:31:53 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2O7Vqmo012286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 00:31:52 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Tue, 24 Mar 2009 00:31:52 -0700 From: "Doken, Serhad" To: aayush bhatnagar , Paul Kyzivat Date: Tue, 24 Mar 2009 00:31:47 -0700 Thread-Topic: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) Thread-Index: AcmsMNuOBsZsXKO0Tz+pmfKYiD2r+AAIHFtw Message-ID: References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:31:04 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > aayush bhatnagar > Sent: Monday, March 23, 2009 8:30 PM > To: Paul Kyzivat > Cc: SIP IETF; Brett Tate > Subject: Re: [Sip] Is REFER within dialog part of INVITE or > subscription usage? (was RE: SIP INFO) >=20 > REFER if placed within the scope of the existing dialog usage of > INVITE will reuse its dialog usage, and create an implicit > subscription for the refer event package at the recipient. However, if > the recipient chooses to reject the in dialog REFER request, the > communication established by the INVITE should not be affected. Such a > rejection scenario implies that the call transfer failed..however the > existing active call should not be torn down. >=20 > REFER if sent outside the scope of any exisiting dialog will behave as > a dialog creating request and will establish a subscription at the > recipient as described above. This subscription is only used to notify > the status of the sip session referral to the originator and is > seperate from any other subscribe usage that may have existed at the > recipient. One can send a out of dialog, norefersub REFER and no dialog is established= at the recipient. Only an implicit subscription is created and a NTFY may = be sent or not sent at all. >=20 > As far as accessing the referred resource is concerned...using the > method parameter, it depends upon the business logic of the recipient > of the REFER request. You may send a REFER to a conferencing server > with a method INVITE to invite a user to join a conference. A method > parameter with the value BYE would imply removal from the conference > by the server and so on. >=20 > I dont think you can include a SUBSCRIBE in the method parameter of > the REFER request. You have no way of telling the event package usage > of the subscription to the recipient, as the event header cannot be It should be possible to do Refer-To: sip:serhad@doken.com;method=3DSUBSCRI= BE?Event=3Dpresence asking REFER receiver to send me a SUBSCRIBE in order t= o find out about my presence. > included in the REFER request. Moreover, you can never be sure whether > the subscription usage is even applicable to the recipient or whether > the recipient even supports it. >=20 > aayush >=20 > On 3/24/09, Paul Kyzivat wrote: > > > > > > Dale Worley wrote: > >> On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: > >>> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION > >>> usage, or neither? > >>> > >>> I'm asking mainly because of REFER 481 impacts; however the answer > >>> also has potential implications concerning draft-ietf-sip-info- > events. > >>> RFC 5057 appears to imply that it is part of the subscription > usage; > >>> however I'm not positive if my interpretation and/or RFC 5057 is > >>> correct. > >>> > >>> If REFER isn't considered part of the INVITE usage, how should > REFER > >>> 481 be interpreted? More specifically, should receiver of REFER > 481 > >>> send BYE? > >> > >> I would argue that the REFER is part of the INVITE usage, because > REFER > >> in that context is intimately related to the INVITE usage -- it is > >> intended to transfer the INVITE usage/dialog transferred to a > different > >> destination. > > > > Well, I guess there is that implied association. (Part of the "do > what > > *I* had in mind" approach that REFER has.) Since this was never > spelled > > out, it could also be simply "while this isn't part of an INVITE > usage, > > if there happens to be an INVITE usage, please refer that one." > > > > I guess the question is: would it be valid to send a REFER within an > > existing dialog that had no INVITE usage? If it were valid, > presumably > > it would have the same meaning as sending one outside a dialog, > except > > that the resulting subscription would share the dialog. I expect that > is > > a usage it would be difficult to find in the wild. > > > > Ah, but now I want to reconsider. Remember that REFER can take a > method > > name. So, rather than referring an INVITE, I could be referring > MESSAGE, > > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the > > association to the INVITE usage is probably meaningless. (Of course > its > > meaningful for BYE.) > > > >> And it seems quite safe that if the REFER receives a 481 response, > the > >> INVITE usage must not be functional any more, since the far end of > that > >> usage has denied that it can act on the REFER. > > > > IIRC, 5057 decided that each dialog usage must get its own 481 before > it > > goes away. I don't think there are any cases where a single 481 > response > > can make multiple usages go away. > > > > So the important question is whether the REFER is part of the INVITE > > usage and so its 481 takes down the INVITE usage or not. That gets > > especially interesting if the dialog already had both an INVITE > usage > > and a SUBSCRIBE usage. Does it make sense that the refer take down > the > > INVITE usage and leave up the SUBSCRIBE usage? > > > >> Now it's possible that the REFER, if it is successful, is the first > >> transaction of the subscription usage. But I don't think that has > any > >> paradoxical consequences, as by hypothesis, the REFER succeeded. > > > > Yeah, its already so weird, why not a little more weird? > > > > Also, I think it has recently been clarified that the 200 of a > SUBSCRIBE > > should not be considered to create a dialog - that its the NOTIFY > that > > creates the dialog. If so, then I suppose the same should be true of > REFER. > > > > Bottom line: I can live with it either way, but think it should be > > documented one way or the other. > > > > Thanks, > > Paul > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From sdoken@qualcomm.com Tue Mar 24 00:38:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9D53A6A80 for ; Tue, 24 Mar 2009 00:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.265 X-Spam-Level: X-Spam-Status: No, score=-105.265 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2vyn13kwEaP for ; Tue, 24 Mar 2009 00:38:19 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7155328C1A9 for ; Tue, 24 Mar 2009 00:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1237880350; x=1269416350; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 Robert=20Sparks=20,=20SIP=20List=20 |Date:=20Tue,=2024=20Mar=202009=2000:39:04 =20-0700|Subject:=20RE:=20[Sip]=20Fwd:=20I-D=0D=0A=20Acti on:draft-sparks-sip-3261-interop-statement-00.txt |Thread-Topic:=20[Sip]=20Fwd:=20I-D=0D=0A=20Action:draft- sparks-sip-3261-interop-statement-00.txt|Thread-Index:=20 AcmbdFQqAfqtfnkHQI6OPHnBoN4YfgA3w5Pg|Message-ID:=20|References:=20<20090302143002.24E643A694C@core3 .amsl.com>=0D=0A=20<6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@ nostrum.com>|In-Reply-To:=20<6D6239A7-DC74-44E4-8CAD-D14E AAC4AC67@nostrum.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F554NASAN EXMB09na_"|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfe e=3Bi=3D"5300,2777,5562"=3B=20a=3D"16541601"; bh=+wHwKMBBJmNU41YK4W+Mo15owEqnYzVrj9Lje6IpS+Q=; b=aovSCZSDUkGSYeox8s/xv2rFtxcfcSvt8ACSMp6FDLm6oVR/GjzuZZkK 9P1899A5KNeuUcSOwsedsBQv/ZIkyYBQnOQSXpfd0aIWoBUF1QjEWttjc QVqn4VRjnPkV2/n1v1u1dr6kkru8EpBDWziueAhSzpktT9hmzB1wrpmO3 U=; X-IronPort-AV: E=McAfee;i="5300,2777,5562"; a="16541601" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 00:39:10 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2O7d9wA006851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2009 00:39:10 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2O7d9eP032527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 00:39:09 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Tue, 24 Mar 2009 00:39:09 -0700 From: "Doken, Serhad" To: Robert Sparks , SIP List Date: Tue, 24 Mar 2009 00:39:04 -0700 Thread-Topic: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt Thread-Index: AcmbdFQqAfqtfnkHQI6OPHnBoN4YfgA3w5Pg Message-ID: References: <20090302143002.24E643A694C@core3.amsl.com> <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> In-Reply-To: <6D6239A7-DC74-44E4-8CAD-D14EAAC4AC67@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F554NASANEXMB09na_" MIME-Version: 1.0 Subject: Re: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 07:38:24 -0000 --_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F554NASANEXMB09na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Couple items for the list that popped to my mind (based on my share of inte= rop issues I've seen) : * Demonstrate correct recognition of when to retry requests and when to = give up (401/423/403/480/500/503 etc use cases) * Demonstrate correct implementations of retrying requests after the spe= cified time internal when servers are busy/overloaded etc Serhad ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Rober= t Sparks Sent: Monday, March 02, 2009 12:19 PM To: SIP List Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.t= xt Also split out of steps-to-draft Begin forwarded message: From: Internet-Drafts@ietf.org Date: March 2, 2009 8:30:02 AM CST To: i-d-announce@ietf.org Subject: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : RFC3261 Interop Statement Author(s) : R. Sparks Filename : draft-sparks-sip-3261-interop-statement-00.txt Pages : 9 Date : 2009-03-02 This document captures an outline of the interoperability statements that will be collected to construct an interoperability report for RFC 3261. The outline is stil under review and should not be treated as complete, but will drive data collection at upcoming interoperability events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-interop-statement= -00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F554NASANEXMB09na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Couple items for the list that popped to my mind (based on my s= hare of interop issues I’ve seen) :

 

  • Demonstrat= e correct recognition of when to retry requests and when to give up (401/423/403/480/500/503 etc use cases)
  • Demonstrat= e correct implementations of retrying requests after the specified time internal when servers are busy/overloaded etc

 

Serhad

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Robe= rt Sparks
Sent: Monday, March 02, 2009 12:19 PM
To: SIP List
Subject: [Sip] Fwd: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt

 

Also split out of steps-to-draft

 

Begin forwarded message:



Date: March 2, 2009 8:30:02 AM CST

Subject: I-D Action:draft-sparks-sip-3261-interop-statement-00.txt 

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

       &nbs= p;  Title           : RFC3261 Inter= op Statement
       &nbs= p;  Author(s)       : R. Sparks
       &nbs= p;  Filename        : draft-sparks-sip-3261-interop-statement-00.txt
       &nbs= p;  Pages           : 9
       &nbs= p;  Date            : 2009-03= -02

This document captures an outline of the interoperability statements
that will be collected to construct an interoperability report for
RFC 3261.  The outline is stil under review and should not be treated<= br> as complete, but will drive data collection at upcoming
interoperability events.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-3261-= interop-statement-00.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F554NASANEXMB09na_-- From abhatnagar192006@gmail.com Tue Mar 24 01:18:12 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B568F3A6896 for ; Tue, 24 Mar 2009 01:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GcNbFBQwuTO for ; Tue, 24 Mar 2009 01:18:11 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 4325C28C258 for ; Tue, 24 Mar 2009 01:18:09 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3203666wfg.31 for ; Tue, 24 Mar 2009 01:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KA/JVqHSJ3mGFh3jH9yiNx0WTdh8FZV5vPOU+eIktjY=; b=JIjjF9YwvSsYXPc4vlIX4iHK0jd5ghKBdaSX+a6CC9vgUDdo84+gjvvhaLtRSLQAnC /rkX2eL+vVahwKn9nMNvJJtK0iG+zlO8GUbHPCjhDFtDdqiXMDZuAvyMfj+CIKq4Ahki wCh26xxqVqjiNGnN+OKJhASTeJVb4OWPHWcgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=S15dcq0OtA7JjBPk71xZhS2iyJaYwQU5Qd/qrpkBQ7J5fZW0WkDkNdRw1LdygBoqZP oZzBDPub5uQk+cymY6j/WFcKroqLk2p8BfPGnNOzf2t3xQjmd4wQTMWbq8kfUqUozBEg QKKsJZ3f54v+bK1TgkTOjwPIEB1h31Rc/OQ+0= MIME-Version: 1.0 Received: by 10.143.5.21 with SMTP id h21mr3275206wfi.180.1237882740253; Tue, 24 Mar 2009 01:19:00 -0700 (PDT) In-Reply-To: References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> Date: Tue, 24 Mar 2009 13:49:00 +0530 Message-ID: From: aayush bhatnagar To: "Doken, Serhad" Content-Type: multipart/alternative; boundary=001636e0a64a01a6980465d90980 Cc: SIP IETF , Paul Kyzivat , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 08:18:12 -0000 --001636e0a64a01a6980465d90980 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >One can send a out of dialog, norefersub REFER and no dialog is established at the recipient. >Only an implicit subscription is created and a NTFY may be sent or not sent at all. you are right. >It should be possible to do Refer-To: sip:serhad@doken.com;method=SUBSCRIBE?>Event=presence asking REFER receiver to send me a SUBSCRIBE in order to find out about >my presence. In case the receiver is a server in the network, it must implement the role of a PNA. If its an endpoint, it will subscribe only after approval of the human user, else respond back with 400. I am not sure how many presence clients support forced subscriptions like this. On Tue, Mar 24, 2009 at 1:01 PM, Doken, Serhad wrote: > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > > aayush bhatnagar > > Sent: Monday, March 23, 2009 8:30 PM > > To: Paul Kyzivat > > Cc: SIP IETF; Brett Tate > > Subject: Re: [Sip] Is REFER within dialog part of INVITE or > > subscription usage? (was RE: SIP INFO) > > > > REFER if placed within the scope of the existing dialog usage of > > INVITE will reuse its dialog usage, and create an implicit > > subscription for the refer event package at the recipient. However, if > > the recipient chooses to reject the in dialog REFER request, the > > communication established by the INVITE should not be affected. Such a > > rejection scenario implies that the call transfer failed..however the > > existing active call should not be torn down. > > > > REFER if sent outside the scope of any exisiting dialog will behave as > > a dialog creating request and will establish a subscription at the > > recipient as described above. This subscription is only used to notify > > the status of the sip session referral to the originator and is > > seperate from any other subscribe usage that may have existed at the > > recipient. > > One can send a out of dialog, norefersub REFER and no dialog is established > at the recipient. Only an implicit subscription is created and a NTFY may be > sent or not sent at all. > > > > > As far as accessing the referred resource is concerned...using the > > method parameter, it depends upon the business logic of the recipient > > of the REFER request. You may send a REFER to a conferencing server > > with a method INVITE to invite a user to join a conference. A method > > parameter with the value BYE would imply removal from the conference > > by the server and so on. > > > > I dont think you can include a SUBSCRIBE in the method parameter of > > the REFER request. You have no way of telling the event package usage > > of the subscription to the recipient, as the event header cannot be > > It should be possible to do Refer-To: sip:serhad@doken.com;method=SUBSCRIBE?Event=presence > asking REFER receiver to send me a SUBSCRIBE in order to find out about my > presence. > > > included in the REFER request. Moreover, you can never be sure whether > > the subscription usage is even applicable to the recipient or whether > > the recipient even supports it. > > > > aayush > > > > On 3/24/09, Paul Kyzivat wrote: > > > > > > > > > Dale Worley wrote: > > >> On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: > > >>> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION > > >>> usage, or neither? > > >>> > > >>> I'm asking mainly because of REFER 481 impacts; however the answer > > >>> also has potential implications concerning draft-ietf-sip-info- > > events. > > >>> RFC 5057 appears to imply that it is part of the subscription > > usage; > > >>> however I'm not positive if my interpretation and/or RFC 5057 is > > >>> correct. > > >>> > > >>> If REFER isn't considered part of the INVITE usage, how should > > REFER > > >>> 481 be interpreted? More specifically, should receiver of REFER > > 481 > > >>> send BYE? > > >> > > >> I would argue that the REFER is part of the INVITE usage, because > > REFER > > >> in that context is intimately related to the INVITE usage -- it is > > >> intended to transfer the INVITE usage/dialog transferred to a > > different > > >> destination. > > > > > > Well, I guess there is that implied association. (Part of the "do > > what > > > *I* had in mind" approach that REFER has.) Since this was never > > spelled > > > out, it could also be simply "while this isn't part of an INVITE > > usage, > > > if there happens to be an INVITE usage, please refer that one." > > > > > > I guess the question is: would it be valid to send a REFER within an > > > existing dialog that had no INVITE usage? If it were valid, > > presumably > > > it would have the same meaning as sending one outside a dialog, > > except > > > that the resulting subscription would share the dialog. I expect that > > is > > > a usage it would be difficult to find in the wild. > > > > > > Ah, but now I want to reconsider. Remember that REFER can take a > > method > > > name. So, rather than referring an INVITE, I could be referring > > MESSAGE, > > > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the > > > association to the INVITE usage is probably meaningless. (Of course > > its > > > meaningful for BYE.) > > > > > >> And it seems quite safe that if the REFER receives a 481 response, > > the > > >> INVITE usage must not be functional any more, since the far end of > > that > > >> usage has denied that it can act on the REFER. > > > > > > IIRC, 5057 decided that each dialog usage must get its own 481 before > > it > > > goes away. I don't think there are any cases where a single 481 > > response > > > can make multiple usages go away. > > > > > > So the important question is whether the REFER is part of the INVITE > > > usage and so its 481 takes down the INVITE usage or not. That gets > > > especially interesting if the dialog already had both an INVITE > > usage > > > and a SUBSCRIBE usage. Does it make sense that the refer take down > > the > > > INVITE usage and leave up the SUBSCRIBE usage? > > > > > >> Now it's possible that the REFER, if it is successful, is the first > > >> transaction of the subscription usage. But I don't think that has > > any > > >> paradoxical consequences, as by hypothesis, the REFER succeeded. > > > > > > Yeah, its already so weird, why not a little more weird? > > > > > > Also, I think it has recently been clarified that the 200 of a > > SUBSCRIBE > > > should not be considered to create a dialog - that its the NOTIFY > > that > > > creates the dialog. If so, then I suppose the same should be true of > > REFER. > > > > > > Bottom line: I can live with it either way, but think it should be > > > documented one way or the other. > > > > > > Thanks, > > > Paul > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > --001636e0a64a01a6980465d90980 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >One can send a out of dialog, norefersub REFER and no dialog is establi= shed at the recipient. >Only an implicit subscription is created and a N= TFY may be sent or not sent at all.

you are right.=A0

>It should be possible to do Refer-To:=A0sip:serhad@doken.com;method=3DSUBSCRIBE?= >Event=3Dpresence asking REFER receiver to send me a SUBSCRIBE in order = to find out about >my presence.

In case the receiver is a server in the network, it mus= t implement the role of a PNA. If its an endpoint, it will subscribe only a= fter approval of the human user, else respond back with 400. I am not sure = how many presence clients support forced subscriptions like this.=A0

On Tue, Mar 24, 2009 at 1:01 PM, Doken, Serh= ad <sdoken@qual= comm.com> wrote:


> -----Original Message-----
> From: sip-bounces@ietf.org= [mailto:sip-bounces@ietf.org] = On Behalf Of
> aayush bhatnagar
> Sent: Monday, March 23, 2009 8:30 PM
> To: Paul Kyzivat
> Cc: SIP IETF; Brett Tate
> Subject: Re: [Sip] Is REFER within dialog part of INVITE or
> subscription usage? (was RE: SIP INFO)
>
> REFER if placed within the scope of the existi= ng dialog usage of
> INVITE will reuse its dialog usage, and create an implicit
> subscription for the refer event package at the recipient. However, if=
> the recipient chooses to reject the in dialog REFER request, the
> communication established by the INVITE should not be affected. Such a=
> rejection scenario implies that the call transfer failed..however the<= br> > existing active call should not be torn down.
>
> REFER if sent outside the scope of any exisiting dialog will behave as=
> a dialog creating request and will establish a subscription at the
> recipient as described above. This subscription is only used to notify=
> the status of the sip session referral to the originator and is
> seperate from any other subscribe usage that may have existed at the > recipient.

One can send a out of dialog, norefersub REFER and no dialog is estab= lished at the recipient. Only an implicit subscription is created and a NTF= Y may be sent or not sent at all.

>
> As far as accessing the referred resource is concerned...using the
> method parameter, it depends upon the business logic of the recipient<= br> > of the REFER request. You may send a REFER to a conferencing server > with a method INVITE to invite a user to join a conference. A method > parameter with the value BYE would imply removal from the conference > by the server and so on.
>
> I dont think you can include a SUBSCRIBE in the method parameter of > the REFER request. You have no way of telling the event package usage<= br> > of the subscription to the recipient, as the event header cannot be
It should be possible to do Refer-To: sip:serhad@doken.com;method=3DSUBSCRIBE?Event=3Dpresence ask= ing REFER receiver to send me a SUBSCRIBE in order to find out about my pre= sence.

> included in the REFER request. Moreover, you can never be sure whether=
> the subscription usage is even applicable to the recipient or whether<= br> > the recipient even supports it.
>
> aayush
>
> On 3/24/09, Paul Kyzivat <pky= zivat@cisco.com> wrote:
> >
> >
> > Dale Worley wrote:
> >> On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote:
> >>> Everyone: Is REFER within dialog part of INVITE usage, SU= BSCRIPTION
> >>> usage, or neither?
> >>>
> >>> I'm asking mainly because of REFER 481 impacts; howev= er the answer
> >>> also has potential implications concerning draft-ietf-sip= -info-
> events.
> >>> RFC 5057 appears to imply that it is part of the subscrip= tion
> usage;
> >>> however I'm not positive if my interpretation and/or = RFC 5057 is
> >>> correct.
> >>>
> >>> If REFER isn't considered part of the INVITE usage, h= ow should
> REFER
> >>> 481 be interpreted? =A0More specifically, should receiver= of REFER
> 481
> >>> send BYE?
> >>
> >> I would argue that the REFER is part of the INVITE usage, bec= ause
> REFER
> >> in that context is intimately related to the INVITE usage -- = it is
> >> intended to transfer the INVITE usage/dialog transferred to a=
> different
> >> destination.
> >
> > Well, I guess there is that implied association. (Part of the &qu= ot;do
> what
> > *I* had in mind" approach that REFER has.) Since this was ne= ver
> spelled
> > out, it could also be simply "while this isn't part of a= n INVITE
> usage,
> > if there happens to be an INVITE usage, please refer that one.&qu= ot;
> >
> > I guess the question is: would it be valid to send a REFER within= an
> > existing dialog that had no INVITE usage? If it were valid,
> presumably
> > it would have the same meaning as sending one outside a dialog, > except
> > that the resulting subscription would share the dialog. I expect = that
> is
> > a usage it would be difficult to find in the wild.
> >
> > Ah, but now I want to reconsider. Remember that REFER can take a<= br> > method
> > name. So, rather than referring an INVITE, I could be referring > MESSAGE,
> > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, = the
> > association to the INVITE usage is probably meaningless. (Of cour= se
> its
> > meaningful for BYE.)
> >
> >> And it seems quite safe that if the REFER receives a 481 resp= onse,
> the
> >> INVITE usage must not be functional any more, since the far e= nd of
> that
> >> usage has denied that it can act on the REFER.
> >
> > IIRC, 5057 decided that each dialog usage must get its own 481 be= fore
> it
> > goes away. I don't think there are any cases where a single 4= 81
> response
> > can make multiple usages go away.
> >
> > So the important question is whether the REFER is part of the INV= ITE
> > usage and so its 481 takes down the INVITE usage or not. That get= s
> > especially interesting if =A0the dialog already had both an INVIT= E
> usage
> > and a SUBSCRIBE usage. Does it make sense that the refer take dow= n
> the
> > INVITE usage and leave up the SUBSCRIBE usage?
> >
> >> Now it's possible that the REFER, if it is successful, is= the first
> >> transaction of the subscription usage. =A0But I don't thi= nk that has
> any
> >> paradoxical consequences, as by hypothesis, the REFER succeed= ed.
> >
> > Yeah, its already so weird, why not a little more weird?
> >
> > Also, I think it has recently been clarified that the 200 of a > SUBSCRIBE
> > should not be considered to create a dialog - that its the NOTIFY=
> that
> > creates the dialog. If so, then I suppose the same should be true= of
> REFER.
> >
> > Bottom line: I can live with it either way, but think it should b= e
> > documented one way or the other.
> >
> > =A0 =A0 Thanks,
> > =A0 =A0 Paul
> > _______________________________________________
> > Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol
> > Use sip-imple= mentors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for = new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implemento= rs@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new d= evelopments on the application of sip

--001636e0a64a01a6980465d90980-- From HKaplan@acmepacket.com Tue Mar 24 02:05:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E293A6BBE for ; Tue, 24 Mar 2009 02:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejdwxLRo5YHl for ; Tue, 24 Mar 2009 02:05:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 22B5C3A67B1 for ; Tue, 24 Mar 2009 02:05:34 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 05:06:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Mar 2009 05:06:24 -0400 From: Hadriel Kaplan To: Jiri Kuthan , Dean Willis Date: Tue, 24 Mar 2009 05:06:25 -0400 Thread-Topic: [Sip] Diagnostic idea Thread-Index: AcmsPJ8DUNWxQgkDRNOl24eFjN3qDgAIcJ3g Message-ID: References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> <49C8675E.9080501@iptel.org> In-Reply-To: <49C8675E.9080501@iptel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 09:05:35 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jir= i > Kuthan > Sent: Tuesday, March 24, 2009 12:54 AM >=20 > Nevertheless, I think that troubleshooting has been > historically of rather > marginal interest here, so I'm not sure if there is really an action to b= e > made. I think dealing with the operational aspects of SIP networks, especially wi= th troubleshooting them, is a topic whose time has come. There are at leas= t 3 recent drafts introducing mechanisms to aid in troubleshooting SIP. Pe= rsonally I think it's one of the next hurdles in growing SIP's adoption. >From a DISPATCH draft-routing-to-WG perspective, one could argue we actuall= y need a SipOps WG. -hadriel From HKaplan@acmepacket.com Tue Mar 24 06:34:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE6A3A67D8 for ; Tue, 24 Mar 2009 06:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBwr2lvKbISe for ; Tue, 24 Mar 2009 06:34:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5F7CD3A6AA1 for ; Tue, 24 Mar 2009 06:34:39 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 09:35:29 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Mar 2009 09:35:29 -0400 From: Hadriel Kaplan To: Adam Roach , "Elwell, John" Date: Tue, 24 Mar 2009 09:35:30 -0400 Thread-Topic: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcmrRU+s+T8UTCzMSyuQa07tEWuxlABPwhLA Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <49C6C895.9040204@nostrum.com> In-Reply-To: <49C6C895.9040204@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 13:34:40 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Ada= m > Roach > Sent: Sunday, March 22, 2009 7:24 PM >=20 > The intention is that any UA capable of sending a NOTIFY message in any > context will use a GRUU for all dialogs. This mechanism is to be used > instead of dialog re-use. The most common case of dialog re-use right > now is sending a SUBSCRIBE down an existing dialog that was initially > established by an INVITE. So, for current use cases, using GRUU in > INVITE dialogs is the most important thing. For future-proofing, we need > to require GRUU for all dialogs. =20 If the most common use-case for dialog-reuse of SUB/NOT is within INVITE di= alogs, then what you're really saying is all INVITE-receiving or INVITE-cre= ating UA's which also support receiving SUBSCRIBE must use GRUU's for the *= INVITE* dialog to begin with. That way the SUBSCRIBE can be sent to the sa= me far-end UA, right? Do you really think it's realistic to make such a requirement, to require c= hanges in INVITE-dialogs, for an update to rfc3265 Sub/Not that ostensibly = is to fix found issues and provide better interop? =20 GRUU is not what one would call a wildly successful mechanism, yet, and we = don't yet know what all of its deployment issues will be using it in INVITE= s. And the most popular implementation we've seen using gruu doesn't even = use the right param name (it uses an older gruu draft's param name). -hadriel From pkyzivat@cisco.com Tue Mar 24 07:14:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6193A68DD for ; Tue, 24 Mar 2009 07:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.618 X-Spam-Level: X-Spam-Status: No, score=-5.618 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOi4o3UIyNdt for ; Tue, 24 Mar 2009 07:14:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A804F3A6A29 for ; Tue, 24 Mar 2009 07:14:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,413,1233532800"; d="scan'208";a="160732542" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2009 14:15:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2OEF1iQ004503; Tue, 24 Mar 2009 07:15:01 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2OEF0dF020387; Tue, 24 Mar 2009 14:15:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:15:00 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:15:00 -0400 Message-ID: <49C8EAE3.8060105@cisco.com> Date: Tue, 24 Mar 2009 10:14:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Atle Monrad References: <49C3743F.1070406@ericsson.com> <49C39D1C.1040701@cisco.com> <61D8D34BB13CFE408D154529C120E079027F77F4@eseldmw101.eemea.ericsson.se> In-Reply-To: <61D8D34BB13CFE408D154529C120E079027F77F4@eseldmw101.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 14:15:00.0039 (UTC) FILETIME=[EABB7D70:01C9AC8A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10602; t=1237904101; x=1238768101; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Policy=20to=20register=20media= 20feature=20tags |Sender:=20; bh=3bmYvXXwuxiQLAdInCZA6SAJGf5KMHuhYftpoVpGh1U=; b=q+4vtNrV7v525H7VPEivp5+2eRRqs9uM5p9sebQj2Pusfgnam5iorc71zd tXrTll4JYvLeHH+zpwv5r5asWEQTsTEowvWrJJkIN7YE/IDrcD4AeD3fj0Py jrS6T4dtcG; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip , Gonzalo Camarillo Subject: Re: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:14:11 -0000 Atle Monrad wrote: > Paul > > For you information, the tags that 3gpp have specified and registered > are described in publicly available 3GPP specifications which are > referenced from the IANA registration. The same apply for the three tags > that are in the pipeline. The reason for this is to secure openness and > operability for vendors that want to support certain 3gpp-specific > capabilities. > > 3GPP would like to get all tags registered by IANA in order to secure > that the tags are public and thereby the reference to the specifications > where this particular 3GPP-functionality is specified is publicly > available. I agree that is a good thing. > To communicate these tags e-2-e is needed to support certain > 3gpp-capabilities, and I do not really see the linkage towards you > statement "On the other side were those who prefer to associate > arbitrary names to collections of features and then negotiate on the > basis of the names of those collections." I will take that statement back as being based only on old impressions, not on real facts. BUT, I still think there is reason to have *some* process to determine when something is a new independent feature, orthogonal to existing features, vs. one that turns out to overlap or conflict with existing features. For instance, I went and looked up the 3gpp tags that have already been registered. I found the following in the registration: g.3gpp.smsip: This feature-tag indicates that the device is capable of accepting SMS messages via SIP as specified by ETSI TS 124 341. Then I went and looked at ETSI TS 124 341, and found: > 5.3.3.4 Delivering a short message in a SIP MESSAGE request > > If a short message is received from the SMS-GMSC, the IP-SM-GW shall > extract the IMSI of the SM-over-IP receiver from the received message. > Then the IP-SM-GW shall obtain a corresponding public user identity and > deliver a SIP MESSAGE request with the following information: > > a) the Request-URI, which shall contain a public user identity of the > SM-over-IP receiver; > > b) the Accept-Contact header, which shall contain a "+g.3gpp.smsip" > parameter and the "explicit" and "require" tags according to RFC 3841 > [17]; > > Editor's Note: It is FFS whether the media feature tag value will be > hard coded or it will be an operator specific value distributed as part > of the service provisioning process. > > c) the Request-Disposition header which shall contain the "no-fork" > directive; > > d) the Content-Type header which shall contain > "application/vnd.3gpp.sms"; and > > e) the body of the request which shall contain an RP-DATA message as > defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS > user information encoded as specified in 3GPP TS 23.040 [3]. From a practical perspective, an SMS is pretty much equivalent to a MESSAGE message. Normally it contains *text*, and could be delivered in a basic MESSAGE with a body type of text/plain. In that form it could be received by anything that can handle a basic MESSAGE message. Yet the above turns the SMS into a *different* feature, that will *only* be delivered to UAs that support that unique, but non-orthogonal, feature. Even if SMS's aren't always just text, there are models to handle that more openly. For instance, multipart/alternative can be used to represent the message as text for those who only understand text, and as something richer for those who are capable of understanding that. My point is not to harp on this feature in particular, but only to use it as an example. If there were some discussion about new feature tags, of whether they are unique or could be factored some other way in order to coexist better with existing features, then the potential for interop would be improved. Thanks, Paul > Hope this clarifies > > Regards > /atle > ______ > > Atle Monrad > Standardisation > > ST-Ericsson > Product Group Mobile Platforms > > Televeien 1 > N-4820, Grimstad > Norway > www.stericsson.com > > > Office: +47 37 29 30 40 > Mobile: +47 45 41 06 65 > Fax: +47 37 04 23 70 > Email: atle.monrad@stericsson.com > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interception, unauthorized amendment, tampering and viruses, and we only > send and receive emails on the basis that we are not liable for any such > corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 20. mars 2009 14:42 > To: Gonzalo Camarillo > Cc: sip > Subject: Re: [Sip] Policy to register media feature tags > > Some issues just never go away. :-( > > This seems to be a resurection of issues that first surfaced during the > initial discussions of extended presence status many years ago. And it > also harks back to discussions last year or the year before about > communication service identifiers and application service identifiers. > > The problem is one of openness. Specifically, do you have to be "part of > the club" in order to properly interoperate with a device that uses > these identifiers to identify its preferences or capabilities. > > On one side were those who wanted capabilities and preferences to be > stated in terms of feature tags that are well known and orthogonal. On > the other side were those who prefer to associate arbitrary names to > collections of features and then negotiate on the basis of the names of > those collections. > > Using the latter approach its possible that interoperation will fail > because the parties don't share a common name for a collection of > features even though they both possess the necessary features to > interoperate. > > I don't have a problem with independent groups defining new feature > tags, as long as they are primitive and orthogonal to existing ones. But > I do have a problem with defining feature tags that identify collections > of features, especially when the mapping from the identifier to the > collection of features is not public. > > The bottom line is that I think this sort of thing needs to be thrashed > out within the sip community. So I think the RFC process is the right > process. > > Thanks, > Paul > > Gonzalo Camarillo wrote: >> Folks, >> >> as you know, RFC 3840 specifies how to indicate UA's capabilities >> using media feature tags. Section 12.1 of RFC 3840 creates the SIP >> Media Feature Tag Registration Tree. Media feature tags applicable to >> SIP are registered in this tree. >> >> http://www.ietf.org/rfc/rfc3840.txt >> >> RFC 2506 defines the global tree to register feature tags. Section >> 3.1.2 of RFC 2506 says: "A registration may be proposed for the global > >> tree by anyone who has the need to allow for communication on a >> particular capability or preference". >> >> http://www.ietf.org/rfc/rfc2506.txt >> >> The currently registered feature tags in both the SIP and the global >> trees can be found at: >> >> http://www.iana.org/assignments/media-feature-tags >> >> As you can see, the only three feature tags registered in the global >> tree come from 3GPP. >> >> The issue we are facing is that the SIP and the global trees have >> different registration policies. The SIP registry requires an RFC >> defining the feature tag while the global tree only requires an expert > >> review. >> >> Now, 3GPP would like to register two new feature tags: >> g.3gpp.icsi-ref, g.3gpp.iari-ref >> >> This is the description of how these feature tags will be used: >> >> "Each value of the Application Reference media feature-tag indicates >> the software applications supported by the agent. The values for this >> tag equal the IMS communication Service Identifier (ICSI) and IMS >> Application Reference Identifier (IARI) values supported by the agent. > >> The Application Reference media feature tag is defined to fulfil the >> requirements for forking to an appropriate UE when multiple UEs are >> registered and dispatch to an appropriate application within the UE >> based upon the IMS communication Service Identifier >> (ICSI) and IMS Application Reference Identifier (IARI) values as >> stated in 3GPP TS 23.228. Multiple tag-values can be included in the >> Application Reference media feature-tag." >> >> >> The expert reviewer indicated that this tags will not contain simple >> features but rather more complex services, or feature sets, or >> application logic (pick your favorite term). Therefore, he did not >> find it appropriate to register them in the global tree. He suggested >> that RFC 2506 is amended so that it covers this type of more complex > features. >> However, before going down that path, I would like to get comments >> from the SIP community. The underlying issue is that we need to decide > >> which policy we want to apply to these types of registrations in SIP. >> >> 1) We decide that an RFC is always needed. Then, we can just use the >> SIP registry. We would probably need to clarify or to stress somewhere > >> that the global tree is not appropriate for SIP tags. >> >> 2) We decide that an expert review is good enough. Then we would >> probably need to amend RFC 2506 or RFC 3840 to reflect this. >> >> Comments are welcome. >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > From pkyzivat@cisco.com Tue Mar 24 07:33:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4DD3A6AC0 for ; Tue, 24 Mar 2009 07:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXkXaSy8cues for ; Tue, 24 Mar 2009 07:33:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CC4323A6AAE for ; Tue, 24 Mar 2009 07:33:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,413,1233532800"; d="scan'208";a="273135985" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Mar 2009 14:34:35 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2OEYX7r003945; Tue, 24 Mar 2009 07:34:33 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2OEYX2Z017529; Tue, 24 Mar 2009 14:34:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:34:33 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:34:33 -0400 Message-ID: <49C8EF78.4030809@cisco.com> Date: Tue, 24 Mar 2009 10:34:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: aayush bhatnagar References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 14:34:33.0102 (UTC) FILETIME=[A5EEB2E0:01C9AC8D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7041; t=1237905273; x=1238769273; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Is=20REFER=20within=20dialog=20 part=20of=20INVITE=20or=20subscription=20=0A=20usage?=20(was =20RE=3A=20SIP=20INFO) |Sender:=20; bh=iCz8vB59ceOmSONG5yDky05aaLFve5ykduJQoe+RSME=; b=yJ8agiVfIN4tokbjfcxYfkwYiju7+OKyw25BvrBgfLDZEl853PNJDX5sc6 23raUaiHZms8Xp/SiAgfY6i4+Tt2pYjNkA7sY0wCLDd6m/oaNH7IxEzSbvK9 xKgpkQ53+6; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:33:45 -0000 What you say below is stated as *fact*. But the reason we are having this discussion is because its not entirely clear what the proper interpretation should be. So I will take your statements as being your *opinion* on the subject. Your opinion would be of more value if you gave the justifications for it. More inline. aayush bhatnagar wrote: > REFER if placed within the scope of the existing dialog usage of > INVITE will reuse its dialog usage, and create an implicit > subscription for the refer event package at the recipient. However, if > the recipient chooses to reject the in dialog REFER request, the > communication established by the INVITE should not be affected. Such a > rejection scenario implies that the call transfer failed..however the > existing active call should not be torn down. > REFER if sent outside the scope of any exisiting dialog will behave as > a dialog creating request and will establish a subscription at the > recipient as described above. This subscription is only used to notify > the status of the sip session referral to the originator and is > seperate from any other subscribe usage that may have existed at the > recipient. > > As far as accessing the referred resource is concerned...using the > method parameter, it depends upon the business logic of the recipient > of the REFER request. You may send a REFER to a conferencing server > with a method INVITE to invite a user to join a conference. A method > parameter with the value BYE would imply removal from the conference > by the server and so on. It has been observed before, that REFER is very weak in defining clearly what actions a particular REFER should elicit. Because it is unclear, your are right that some discretion on the part of the recipient is required. However that's a bad thing if the sender and receiver of the REFER don't agree on what the action should be. If I send a REFER to a conference focus, I probably expect it send an invite to the URI I supply and include the resulting session as another participant in the conference. If the focus decided instead that I just wanted it play a message to the recipient and then hang up, then I would be displeased. But that is a digression. My point in bringing up the method was that the method potentially may have nothing to do with the INVITE usage even when the REFER is sent within a dialog that has an INVITE usage. That is an argument for saying that the REFER is not part of the INVITE usage. > I dont think you can include a SUBSCRIBE in the method parameter of > the REFER request. You have no way of telling the event package usage > of the subscription to the recipient, as the event header cannot be > included in the REFER request. Moreover, you can never be sure whether > the subscription usage is even applicable to the recipient or whether > the recipient even supports it. There was already a reply to this. I think it is certainly possible to see how you could provide enough info to enable the recipient to generate a valid SUBSCRIBE request. It is indeed harder to imagine how you could expect the recipient to extract any value from the resulting subscription. But that is part of the magic of REFER that remains unresolved. Thanks, Paul > aayush > > On 3/24/09, Paul Kyzivat wrote: >> >> Dale Worley wrote: >>> On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: >>>> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION >>>> usage, or neither? >>>> >>>> I'm asking mainly because of REFER 481 impacts; however the answer >>>> also has potential implications concerning draft-ietf-sip-info-events. >>>> RFC 5057 appears to imply that it is part of the subscription usage; >>>> however I'm not positive if my interpretation and/or RFC 5057 is >>>> correct. >>>> >>>> If REFER isn't considered part of the INVITE usage, how should REFER >>>> 481 be interpreted? More specifically, should receiver of REFER 481 >>>> send BYE? >>> I would argue that the REFER is part of the INVITE usage, because REFER >>> in that context is intimately related to the INVITE usage -- it is >>> intended to transfer the INVITE usage/dialog transferred to a different >>> destination. >> Well, I guess there is that implied association. (Part of the "do what >> *I* had in mind" approach that REFER has.) Since this was never spelled >> out, it could also be simply "while this isn't part of an INVITE usage, >> if there happens to be an INVITE usage, please refer that one." >> >> I guess the question is: would it be valid to send a REFER within an >> existing dialog that had no INVITE usage? If it were valid, presumably >> it would have the same meaning as sending one outside a dialog, except >> that the resulting subscription would share the dialog. I expect that is >> a usage it would be difficult to find in the wild. >> >> Ah, but now I want to reconsider. Remember that REFER can take a method >> name. So, rather than referring an INVITE, I could be referring MESSAGE, >> OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the >> association to the INVITE usage is probably meaningless. (Of course its >> meaningful for BYE.) >> >>> And it seems quite safe that if the REFER receives a 481 response, the >>> INVITE usage must not be functional any more, since the far end of that >>> usage has denied that it can act on the REFER. >> IIRC, 5057 decided that each dialog usage must get its own 481 before it >> goes away. I don't think there are any cases where a single 481 response >> can make multiple usages go away. >> >> So the important question is whether the REFER is part of the INVITE >> usage and so its 481 takes down the INVITE usage or not. That gets >> especially interesting if the dialog already had both an INVITE usage >> and a SUBSCRIBE usage. Does it make sense that the refer take down the >> INVITE usage and leave up the SUBSCRIBE usage? >> >>> Now it's possible that the REFER, if it is successful, is the first >>> transaction of the subscription usage. But I don't think that has any >>> paradoxical consequences, as by hypothesis, the REFER succeeded. >> Yeah, its already so weird, why not a little more weird? >> >> Also, I think it has recently been clarified that the 200 of a SUBSCRIBE >> should not be considered to create a dialog - that its the NOTIFY that >> creates the dialog. If so, then I suppose the same should be true of REFER. >> >> Bottom line: I can live with it either way, but think it should be >> documented one way or the other. >> >> Thanks, >> Paul >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > From pkyzivat@cisco.com Tue Mar 24 07:42:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFCB3A6D23 for ; Tue, 24 Mar 2009 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z3bbHI4JD4D for ; Tue, 24 Mar 2009 07:42:36 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 069C73A6D25 for ; Tue, 24 Mar 2009 07:42:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,413,1233532800"; d="scan'208";a="40212562" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Mar 2009 14:43:26 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2OEhQuh008853; Tue, 24 Mar 2009 10:43:26 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2OEhQ05025627; Tue, 24 Mar 2009 14:43:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:43:26 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:43:26 -0400 Message-ID: <49C8F18D.1040800@cisco.com> Date: Tue, 24 Mar 2009 10:43:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Doken, Serhad" References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 14:43:26.0352 (UTC) FILETIME=[E3C63100:01C9AC8E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1568; t=1237905806; x=1238769806; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Is=20REFER=20within=20dialog=20 part=20of=20INVITE=20or=09subscription=09usage?=0A=20(was=20 RE=3A=20SIP=20INFO) |Sender:=20 |To:=20=22Doken,=20Serhad=22=20; bh=wby6kmbwF/CIxR3V0Ce1H+ZAXPA3n5uDCvmXJ5aMTLI=; b=sEXVKx/Z1bt+07iAmn5AJq5Mh52ck98ES+rVT9AjzNVtZjsicfHZp18vns Cjy0JsDRsYrkxG+TMW11kl3y7S66iK2SMxFc8PI5mICF4oOUt/EFosQxE5PR 84Us4OnYze; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:42:37 -0000 Doken, Serhad wrote: >> I guess the question is: would it be valid to send a REFER within an >> existing dialog that had no INVITE usage? If it were valid, presumably > > Yes, I think so. > > >> it would have the same meaning as sending one outside a dialog, except >> that the resulting subscription would share the dialog. I expect that >> is >> a usage it would be difficult to find in the wild. > > Consider a third party control application that forces an endpoint to register : > > REFER sip:phone.doken.com SIP/2.0 > Refer-To: > > that triggers a REG to the registrar as : > > REGISTER sip:serhad@doken.com SIP/2.0 You are suggesting that first this 3pcc application sends a SUBSCRIBE to this UA, establishing a dialog. Then it sends a REFER within the dialog, asking the UA REGISTER? That then would presumably result in a subscription to the refer event package sharing the dialog with the prior subscription. I guess this is *possible*, though I don't know *why* it would be done. What would the initial SUBSCRIBE be to, and how would it be established before the UA has registered? Are you aware of such usage in the wild? (Its incidental to this discussion, but REGISTER presents unique challenges because of the way addressing works for it. Contrary to your example above, we would typically expect that the To: would contain the full URI, while the R-URI would only be sip:doken.com. This would require more special case processing.) Thanks, Paul From BPenfield@acmepacket.com Tue Mar 24 09:34:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DFA3A698E for ; Tue, 24 Mar 2009 09:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUs1vRscjHEP for ; Tue, 24 Mar 2009 09:34:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 65BBD3A66B4 for ; Tue, 24 Mar 2009 09:34:47 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 12:35:37 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Mar 2009 12:35:37 -0400 From: Bob Penfield To: Christer Holmberg Date: Tue, 24 Mar 2009 12:35:35 -0400 Thread-Topic: [Sip] I-D Action:draft-ietf-sip-199-06.txt - early dialog state in proxy Thread-Index: AcmbMKe+xsFi6kj+QB+gB2v3KJUGbABMpvRQAEOYpKAADKsk4AEpp3CgAn/zKygAARooZgATl8cg Message-ID: References: <20090302121502.4C42D3A6858@core3.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] I-D Action:draft-ietf-sip-199-06.txt - early dialog state in proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:34:48 -0000 =20 > >Yes, but the issue is how the proxy knows whether it has sent a 199 for th= e early=20 >dialog indicated in the error response. Again, the proxy needs to have a list of early dialogs and within that stat= e data needs to remember whether or not a 199 has been sent/forwarded to th= e UAC. > >The issue is whether the proxy can detect that a final response is generat= ed by=20 >another forking proxy, and therefor terminate more than one early dialog. It does not matter whether the final response came from a forking proxy or = not. When a final response is received on a client transaction, the proxy h= as to assume that all downstream forks that the request created have been t= erminated. RFC 3261 requires that the proxies and UASes send only one non-2= xx final response, so any downstream proxy that forked the request would no= t send back a non-2xx final response until all of its forks completed. > >Maybe the Via mechanism you describe works... I need to draw some figures = :) > From christer.holmberg@ericsson.com Tue Mar 24 09:40:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7E828C299 for ; Tue, 24 Mar 2009 09:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.776 X-Spam-Level: X-Spam-Status: No, score=-5.776 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU7-cfFoJy8G for ; Tue, 24 Mar 2009 09:40:14 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B9F5528C296 for ; Tue, 24 Mar 2009 09:40:13 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F23120F42; Tue, 24 Mar 2009 17:41:03 +0100 (CET) X-AuditID: c1b4fb3c-aef61bb000003f6e-bb-49c90d1ff334 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 418F920EDE; Tue, 24 Mar 2009 17:41:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 17:41:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 17:41:02 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-199-06.txt - early dialog state in proxy Thread-Index: AcmbMKe+xsFi6kj+QB+gB2v3KJUGbABMpvRQAEOYpKAADKsk4AEpp3CgAn/zKygAARooZgATl8cgAABLnTA= References: <20090302121502.4C42D3A6858@core3.amsl.com> , From: "Christer Holmberg" To: "Bob Penfield" X-OriginalArrivalTime: 24 Mar 2009 16:41:02.0601 (UTC) FILETIME=[51A05790:01C9AC9F] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] I-D Action:draft-ietf-sip-199-06.txt - early dialog state in proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:40:14 -0000 Hi,=20 >>Yes, but the issue is how the proxy knows whether it has sent a 199 for the early dialog indicated in the error=20 >>response. > >Again, the proxy needs to have a list of early dialogs and within that state data needs to remember whether or not a 199=20 >has been sent/forwarded to the UAC. Again, I agree with you :) >>The issue is whether the proxy can detect that a final response is=20 >>generated by another forking proxy, and therefor terminate more than one early dialog. > >It does not matter whether the final response came from a forking proxy or not. When a final response is received on a=20 >client transaction, the proxy has to assume that all downstream forks that the request created have been terminated. RFC=20 >3261 requires that the proxies and UASes send only one non-2xx final response, so any downstream proxy that forked the=20 >request would not send back a non-2xx final response until all of its forks completed. Yes, and the issue was HOW the proxy knows WHICH downstream forks are terminated by the single final response. Your proposal is to look at the Via branch, and I think that may work. So, I think we're on the same page :) Regards, Christer From BPenfield@acmepacket.com Tue Mar 24 09:44:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307DC3A6D42 for ; Tue, 24 Mar 2009 09:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kn947V9STn6 for ; Tue, 24 Mar 2009 09:44:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 413E73A6D41 for ; Tue, 24 Mar 2009 09:44:53 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 12:45:44 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Mar 2009 12:45:43 -0400 From: Bob Penfield To: Hadriel Kaplan , Adam Roach , "Elwell, John" Date: Tue, 24 Mar 2009 12:45:40 -0400 Thread-Topic: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcmrRU+s+T8UTCzMSyuQa07tEWuxlABPwhLAAAaxobA= Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <49C6C895.9040204@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:44:54 -0000 =20 >GRUU is not what one would call a wildly successful mechanism, yet, and we= don't yet >know what all of its deployment issues will be using it in INVITEs. And t= he most >popular implementation we've seen using gruu doesn't even use the right pa= ram name >(it uses an older gruu draft's param name). I think its way too early to make any judgment on the success of GRUU since= it is not even an RFC yet. Many vendors have made the smart decision to no= t implement things in their core products until there is an RFC. When folks= start implementing it, INVITE will likely be the first place they do. Main= ly for call transfer use cases as well as subscriptions related to the INVI= TE usage. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From adam@nostrum.com Tue Mar 24 09:51:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACAF33A693E for ; Tue, 24 Mar 2009 09:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCFt5ZCyRzDS for ; Tue, 24 Mar 2009 09:51:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 782663A67CC for ; Tue, 24 Mar 2009 09:51:54 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2OGqeZH076491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 11:52:41 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49C90FD8.8010101@nostrum.com> Date: Tue, 24 Mar 2009 09:52:40 -0700 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hadriel Kaplan References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <49C6C895.9040204@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9159/Tue Mar 24 09:59:06 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:51:55 -0000 Hadriel Kaplan wrote: > If the most common use-case for dialog-reuse of SUB/NOT is within INVITE dialogs, then what you're really saying is all INVITE-receiving or INVITE-creating UA's which also support receiving SUBSCRIBE must use GRUU's for the *INVITE* dialog to begin with. That way the SUBSCRIBE can be sent to the same far-end UA, right? > That's the important part, yes. > Do you really think it's realistic to make such a requirement, to require changes in INVITE-dialogs, for an update to rfc3265 Sub/Not that ostensibly is to fix found issues and provide better interop? Yep. We knew, when we put dialog sharing in, that it was a horrible hack. I can probably even dig up the fossil record where we explicitly agreed (prior to 3265's publication) to go forward with what we acknowledged it to be a horrible hack, and further agreed to try to come up with a better way to do this in the future. I concede that consensus reached eight years ago can be overturned if we have new technical information, but this really *has* been the plan all along. In fact, getting GRUU in the editor's queue was one of the key triggers that led me to believe that we finally have the tools necessary to issue a bis, since dialog sharing was a known (and necessary) flaw at the time of publication. > GRUU is not what one would call a wildly successful mechanism, yet Of course it's not. It's not an RFC yet. After the whole multi-year TURN whipsaw experience, I'm stunned anyone bothers to implement anything before it has an RFC number assigned any more. But, suprisingly, they do: more than one in every eight implementations at SIPit 22 implemented GRUU. And, while I'm flattered that you think that the publication and/or the implementation of 3265bis will somehow outrun a document that's effectively at the finish line already, I think you are being somewhat over-optimistic in your evaluation. By the time 3265bis is an RFC, implementations will be further along. /a From HKaplan@acmepacket.com Tue Mar 24 10:54:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B347A3A6954 for ; Tue, 24 Mar 2009 10:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDXMMvEoBgpP for ; Tue, 24 Mar 2009 10:54:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B0B4C3A67CC for ; Tue, 24 Mar 2009 10:54:03 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 13:54:52 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 24 Mar 2009 13:54:49 -0400 From: Hadriel Kaplan To: Adam Roach Date: Tue, 24 Mar 2009 13:54:41 -0400 Thread-Topic: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcmsoPrJJpy0TnZ2SL+cv6cCB5q90wACDFug Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <49C6C895.9040204@nostrum.com> <49C90FD8.8010101@nostrum.com> In-Reply-To: <49C90FD8.8010101@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:54:04 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, March 24, 2009 12:53 PM > To: Hadriel Kaplan > > And, while I'm flattered that you think that the publication and/or the > implementation of 3265bis will somehow outrun a document that's > effectively at the finish line already, I think you are being somewhat > over-optimistic in your evaluation. By the time 3265bis is an RFC, > implementations will be further along. My concern was more that it has nothing to do with implementations - it has= to do with use. I find many new drafts getting early implementation at Si= pit's yet not finding them in actual use or even GA code. Just because we = publish an RFC does not mean a heck of a lot as to whether the market will = use it. :( -hadriel From Martin.Thomson@andrew.com Tue Mar 24 13:00:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B80328C123 for ; Tue, 24 Mar 2009 13:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+U27P5Dg5L6 for ; Tue, 24 Mar 2009 13:00:12 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6E89F28C16A for ; Tue, 24 Mar 2009 13:00:11 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_24_15_21_08 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Mar 2009 15:21:08 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 15:01:02 -0500 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, 24 Mar 2009 15:01:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] draft-ietf-sip-location-conveyance-13: WGLC comments Thread-Index: AcmqV+5eBchMQdJQR6aNTJrGKaY6WQCXkWpQ From: "Thomson, Martin" To: X-OriginalArrivalTime: 24 Mar 2009 20:01:02.0500 (UTC) FILETIME=[421F9E40:01C9ACBB] Subject: [Sip] FW: [Geopriv] draft-ietf-sip-location-conveyance-13: WGLC comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:00:13 -0000 QXMgZmFyIGFzIEkgYW0gYXdhcmUsIHRoZSBXR0xDIG9uIHRoaXMgZG9jdW1lbnQgYXR0cmFjdGVk IG5vIHJlc3BvbnNlIG9uIHRoZSBTSVAgV0cgbGlzdC4gIEkgY2FuJ3QgZW50aXJlbHkgYXR0cmli dXRlIHRoaXMgdG8gYW1iaXZhbGVuY2UsIGJ1dCB3b3VsZCBiZSBjb25jZXJuZWQgaWYgYW55b25l IGdvdCB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoZXJlIHdlcmUgbm8gaXNzdWVzIG9uIHRoaXMgZG9j dW1lbnQuDQoNClRoaXMgaXMgYSBkb2N1bWVudCB0aGF0IGhhcyBoYWQgbW9yZSBjaGFuZ2VzIHJl Y2VudGx5IGFuZCBpdCBpcyBzdGlsbDogKGEpIGRpZmZpY3VsdCB0byByZWFkLCBmYXIgdG9vIGxv bmc7IGFuZCAoYikgZ2VuZXJhdGluZyBsaXR0bGUgb3Igbm8gbGlzdCBkaXNjdXNzaW9uLg0KDQpU aGlzIGRvY3VtZW50IG5lZWRzIHRvIGJlIGZpbmlzaGVkLiAgSG93ZXZlciwgSSBkb24ndCBiZWxp ZXZlIHRoYXQgaXQgaXMgZml0IGZvciBwdWJsaWNhdGlvbi4NCg0KSSd2ZSBmb3J3YXJkZWQgY29t bWVudHMgZnJvbSBIYW5uZXMsIHdoaWNoIGFyZSB2ZXJ5IHNpbWlsYXIgdG8gdGhvc2UgSSBtYWRl IG1hbnkgbW9vbnMgYWdvLiAgVW5mb3J0dW5hdGVseSwgdGhlc2UgY29tbWVudHMgd2VyZSBzZW50 IHRvIHRoZSB3cm9uZyBsaXN0Lg0KDQpTby4uLiBpZiB5b3Ugd2FudCB0byBnZXQgb3Zlcmx5IHBy b2NlZHVyYWwsIHlvdSBtaWdodCBpbnRlcnByZXQgdGhlIHJlc3BvbnNlIGFzIHJlcHJlc2VudGlu ZyBjb25zZW5zdXMgZm9yIGFtYml2YWxlbmNlLiAgVGhhdCB3b3VsZCBiZSBhIG1pc3Rha2UuDQoN CkNoZWVycywNCk1hcnRpbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZ2Vv cHJpdi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Z2VvcHJpdi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6IFNhdHVyZGF5LCAyMSBNYXJjaCAy MDA5IDEyOjA1IFBNDQpUbzogJ0dFT1BSSVYnDQpTdWJqZWN0OiBbR2VvcHJpdl0gZHJhZnQtaWV0 Zi1zaXAtbG9jYXRpb24tY29udmV5YW5jZS0xMzogV0dMQyBjb21tZW50cw0KDQpJIHJlYWQgdGhy b3VnaA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXAtbG9jYXRpb24t Y29udmV5YW5jZS0xMy4gDQpJIGhhdmUgY29uY2VybmluZyB0aGUgY3VycmVudCB2ZXJzaW9uIG9m IHRoZSBkb2N1bWVudC4gDQoNCkhlcmUgYXJlIG15IGhpZ2gtbGV2ZWwgY29tbWVudHMuIERldGFp bGVkIGNvbW1lbnRzIG9uIHBhcGVyIGF2YWlsYWJsZSBmb3INCnRoZSBhdXRob3JzLiANCg0KKiBU aGUgZHJhZnQgY29tZXMgdXAgd2l0aCBuZXcgdGVybWlub2xvZ3kgZXZlbiB0aG91Z2ggd2UgaGF2 ZSB0aGVzZSB0ZXJtcw0KYWxyZWFkeSBkZWZpbmVkIGluIG90aGVyIGRvY3VtZW50cy4gVGhpcyBp cyBiYWQgKHRtKS4gDQpDaXRlIHRlcm1zIChhIGNvbW1vbiBhbmQgcHJlZmVycmVkIHByb2NlZHVy ZSkgb3IgY29weSB0aGUgdGV4dCBleGFjdGx5IChhbmQNCnF1b3RlIGl0KSByYXRoZXIgdGhhbiBk ZWZpbmluZyB5b3VyIG93bi4gVXNlbGVzcyBhbmQgYXMgd2Ugc2F3IGluIHJlY2VudA0KZGlzY3Vz c2lvbnMgaXMgcmF0aGVyIGhhcm1mdWwuIA0KDQoqIFRoZSBkb2N1bWVudCByZXBlYXRzIHN0dWZm IG92ZXIgYW5kIG92ZXIgYWdhaW4uIEdpdmVzIHRoZSByZWFkZXIgdGhlDQppbXByZXNzaW9uIHRo YXQgdGhpcyBpcyByb2NrZXQgc2NpZW5jZS4gQ291bGQgYmUgc2lnbmlmaWNhbnRseSBzaG9ydGVy LiANCg0KKiBUaGUgZHJhZnQgaGFzIHRvIGF2b2lkIHRoZSB0ZXJtICJ1c2luZyBwcm90b2NvbCIg YXQgYWxsIGNvc3RzLiBBcyB3ZSBrbm93LA0KdGhpcyB0ZXJtIGlzIHZlcnkgY29uZnVzaW5nLiAN Cg0KRXhhbXBsZTogICAgT3RoZXIgcHJvdG9jb2xzIHVzZWQgaW4gdGhlIExvY2F0aW9uIFVSSSBN VVNUIGJlIHJldmlld2VkDQphZ2FpbnN0DQogICB0aGUgUkZDIDM2OTMgY3JpdGVyaWEgZm9yIGEg VXNpbmcgUHJvdG9jb2wuDQoNCkluIGh1bWFuIHJlYWRhYmxlIGxhbmd1YWdlIHRoaXMgbWVhbnM6 IFlvdSBoYXZlIHRvIGNvbnNpZGVyIHNlY3VyaXR5IGFuZA0KcHJpdmFjeSB3aXRoIG5ldyBleHRl bnNpb25zLg0KDQoqIERvbid0IHVuZGVyc3RhbmQgd2h5IHRoaXMgZG9jdW1lbnQgZG9lcyBub3Qg YWxsb3cgYSBIRUxEIFVSSSB0byBiZQ0KY29udmV5ZWQuIEkgY29tbWVudGVkIHRoaXMgYWxyZWFk eSBzZXZlcmFsIHRpbWVzIGFuZCBnb3QgaWdub3JlZC4gDQoNClNlZSBTZWN0aW9uIDQuNS4gSGF2 aW5nIGFuIElBTkEgcmVnaXN0cnkgYXBwZWFycyB0byBiZSB0b3RhbGx5IGNyYXp5IHRvIG1lLg0K RXZlbiBzYXlpbmcgdGhhdCB0aGUgcHJvdG9jb2xzIGFyZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50 IGlzIGFsc28gbm90IGEgZ29vZA0KaWRlYS4gSSByZWFsbHkgd29uZGVyIHdoeSB0aGlzIGlzIHVz ZWZ1bCBnaXZlbiB0aGF0IHRoZSByZWNpcGllbnQgdGhlbiBqdXN0DQpjYW5ub3QgZmV0Y2ggbG9j YXRpb24gd2hlbiBpdCByZWNlaXZlcyBzb21ldGhpbmcgdGhhdCBpdCBkb2VzIG5vdA0KdW5kZXJz dGFuZC4gV2hhdCBpcyB0aGUgYmlnIGRlYWwgd2l0aCB0aGF0PyANCg0KKiBJcyAicm91dGluZy1h bGxvd2VkIiBwb2xpY3kgcmVhbGx5IHVzZWZ1bCBhbmQsIGlmIHNvLCBkb2VzIGl0IG5lZWQgdG8g YmUNCmluIHRoZSBTSVAgaGVhZGVyIHJhdGhlciB0aGFuIGluIHRoZSBQSURGLUxPIHdoZXJlIGFs bCB0aGUgb3RoZXIgcG9saWNpZXMNCmFyZT8gDQoNClRoZSBwcm9ibGVtIGlzLCBhZ2FpbiAoYWxz byBtZW50aW9uZWQgc2V2ZXJhbCB0aW1lcyksIHdpdGggdGhlIGxhY2sgb2YNCmRlc2NyaXB0aW9u IG9mIHRoZSByZWNpcGllbnQgaXMgZm9yIGEgUElERi1MTyB3aXRoIHJlc3BlY3QgdG8gdGhlDQon cmV0cmFuc21pc3Npb24tYWxsb3dlZCcgcG9saWN5LiBGb3IgZXhhbXBsZSwgaW4gYSBsb2NhdGlv biBhcHBsaWNhdGlvbg0Kd2hlcmUgdGhlIG1lc3NhZ2UgaXMgZGlyZWN0ZWQgdG93YXJkcyBhIFNl cnZpY2UgVVJOIHRoZSBpbnRlbmRlZCBiZWhhdmlvciBpcw0KdGhhdCB0aGVyZSBpcyBzb21lIGZv cm0gb2YgbG9jYXRpb24gYmFzZWQgcm91dGluZyBpbnZvbHZlZC4gDQoNCiogVGhpcyBkb2N1bWVu dCBpcyBhYm91dCB0aGUgdHJhbnNwb3J0IG9mIGEgUElERi1MTyBhbmQgbm90IGFib3V0IGRlcGxv eW1lbnQNCmNvbnNpZGVyYXRpb25zLg0KDQpFeGFtcGxlOiANCiINCiAgIEFkZGluZyBhIG5ldyBs b2NhdGlvblZhbHVlIHRvIGFuIGluLXRyYW5zaXQgcmVxdWVzdCBTSE9VTEQgTk9UDQogICBvY2N1 ciBmb3IgYXQgbGVhc3QgdHdvIHJlYXNvbnMsDQoNCiAgICMxIC0gU0lQIFNlcnZlcnMgYXJlIG5v dCB0aGUgYmVzdCBTaWdodGVycywgYXMgZGVmaW5lZCBieSBbUkZDMzY5M10sDQogICAgICAgIG9m IGdlb2dyYXBoaWNhbGx5IHdoZXJlIGEgVUFDIGNhbiBiZTsgbWVhbmluZyB0aGUgbG9jYXRpb24N CiAgICAgICAgaW5mb3JtYXRpb24gaXMgbm90IG5lY2Vzc2FyaWx5IHRoZSBncmVhdGVzdC4gIFRo ZXJlIE1BWSBiZQ0KICAgICAgICBleGNlcHRpb25zLCBidXQgdGhpcyBTSE9VTEQgYmUgdGhlIHJ1 bGUgb2YgdGh1bWIuDQoNCiAgICMyIC0gd2l0aG91dCBhcHByb3ByaWF0ZSBjYXV0aW9uIHRvIHRo ZSBmYWN0IHRoYXQgTG9jYXRpb24NCiAgICAgICAgUmVjaXBpZW50cyBtaWdodCBub3QgdW5kZXJz dGFuZCBob3cgdG8gcHJvY2VzcyBtb3JlIHRoYW4gb25lDQogICAgICAgIGxvY2F0aW9uLCBnaXZl biB0aGlzIGRvY3VtZW50J3MgbGltaXRlZCBndWlkYW5jZSBhcyB0byB3aGF0IGENCiAgICAgICAg TG9jYXRpb24gUmVjaXBpZW50IHNob3VsZCBkbyB3aGVuIHJlY2VpdmluZyBtb3JlIHRoYW4gb25l DQogICAgICAgIGxvY2F0aW9uICAoaS5lLiwgY3VycmVudGx5IG5vIHByaW9yaXR5IGluc3RydWN0 aW9ucyBhcmUgZ2l2ZW4NCiAgICAgICAgZm9yIHdoaWNoIGxvY2F0aW9uVmFsdWUgdG8gdXNlIGlm IHRoZXJlIGFyZSBtb3JlIHRoYW4gb25lKS4gIEENCiAgICAgICAgTG9jYXRpb24gUmVjaXBpZW50 IGNhbiBlYXNpbHkgYmUgY29uZnVzZWQgYnkgdG9vIG11Y2ggbG9jYXRpb24NCiAgICAgICAgaW5m b3JtYXRpb24sIHByb2R1Y2luZyB1bmRlc2lyYWJsZSByZXN1bHRzLiAgVGhlIDx0dXBsZSBpZD4N CiAgICAgICAgZWxlbWVudCBpbiB0aGUgUElERi1MTyBYTUwgaW5kaWNhdGVzIHdob3NlIGxvY2F0 aW9uIGlzDQogICAgICAgIGNvbnRhaW5lZCBpbiB0aGUgUElERi1MTy4NCiINCg0KVGhpcyBleGFt cGxlIGFsc28gc2hvd3MgaW5hcHByb3ByaWF0ZSB1c2FnZSBvZiBSRkMyMTE5IGxhbmd1YWdlIHdo aWNoIHNob3VsZA0KYmUgdXNlZCBmb3IgaW50ZXJvcGVyYWJpbGl0eSByYXRoZXIgdGhhbiBwaGls b3NvcGhpY2FsIHN0dWZmLiANCg0KV2Uga25vdyB3aG8gd2FudHMgc29tZSBvZiB0aGlzIGZ1bmN0 aW9uYWxpdHkgYW5kIHdoYXQgdGhlIGV4YWN0IHVzZSBjYXNlIGl0Lg0KDQoqIFRoZSBsb2NhdGlv bi1iYXNlZCBlcnJvciBjb2RlcyAoMTAwLCAyMDAsIDMwMCwgNDAwLCA1MDAgb24gcGFnZSAxNGZm KSBhcmUNCmV4dHJlbWx5IGZ1enp5LiBUaGV5IGNsZWFybHkgbGFjayBpbXBsZW1lbnRhdGlvbiBl eHBlcmllbmNlIChhcyB0aGUgdGV4dA0KY29udGludWVzbHkgcmVwZWF0cyBieSBzYXlpbmcgImZv ciBmdXR1cmUgd29yayIpIGFuZCBJIGJlbGlldmUgdGhleSBzaG91bGQNCmJlIHJlbW92ZWQgYW5k IGluY29ycG9yYXRlZCBpbiBhIGZ1dHVyZSB2ZXJzaW9uIHdoZW4gbW9yZSBpbXBsZW1lbnRhdGlv bg0KZXhwZXJpZW5jZSBpcyBhdmFpbGFibGUuIA0KDQoNCiogIiBTL01JTUUgY2FuIGJlIHVzZWQg Zm9yIGp1c3Qgc2lnbmluZywgYW5kIG5vdCBlbmNyeXB0aW5nLCBhDQogICBQSURGLUxPIG1lc3Nh Z2UgYm9keSB0byBlbnN1cmUgdGhlIGludGVncml0eSBvZiB0aGUgUElERi1MTyBpcw0KICAgbWFp bnRhaW5lZC4iDQoNCiAgSSBhbSBub3Qgc3VyZSB3aGF0IHRoaXMgbWVhbnMuIFMvTUlNRSBjYW5u b3Qgb25seSBiZSB1c2VkIGZvciBzaWduaW5nLiANCg0KIg0KICAgVXNlIG9mIHNlbGYtc2lnbmVk IGNlcnRpZmljYXRlcyBpcyBpbmFwcHJvcHJpYXRlIGZvciB1c2UgaW4NCiAgIHByb3RlY3Rpbmcg YSBQSURGLCBhcyB0aGUgc2VuZGVyIGRvZXMgbm90IGhhdmUgYSBzZWN1cmUgaWRlbnRpdHkgb2YN CiAgIHRoZSByZWNpcGllbnQuDQoiIA0KDQogVGhpcyBzZW50ZW5jZSBkb2VzIG5vdCBtYWtlIGEg bG90IG9mIHNlbnNlIHRvIG1lLiANCg0KKiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IG5lZWQgdG8g cmVwZWF0IHRoZSB0ZXh0IGZyb20gb3RoZXIgZG9jdW1lbnRzLg0KRXhhbXBsZTogDQogICAiIA0K ICAgV2hlbiB1c2luZyBMYnlSLCB0aGUgTGJ5UiBNVVNUIE5PVCBjb250YWluIGFueQ0KICAgdXNl ciBpZGVudGlmeWluZyBpbmZvcm1hdGlvbi4gRm9yIGV4YW1wbGUsIHVzZSBzb21ldGhpbmcNCiAg IHVuaWRlbnRpZmlhYmxlIGxpa2UNCiAgICIgDQoNCiAgQWxyZWFkeSBpbiB0aGUgTGJ5UiByZXF1 aXJlbWVudHMgZG9jdW1lbnQuIFJlZmVyZW5jZSBpdCAtLSBubyBuZWVkIHRvDQp3cml0ZSBuZXcg dGV4dC4gDQoNCiAgIE90aGVyIGV4YW1wbGVzIGNhbiBiZSBmb3VuZCB3aXRoIHRoZSBkZXNjcmlw dGlvbiBob3cNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt Z2VvcHJpdi1sb2MtZmlsdGVycy0wMy50eHQNCndvcmtzLiANCg0KKiAiDQpJZiB0aGUgTG9jYXRp b24gR2VuZXJhdG9yIHdpc2hlcyB0byBjb250cm9sIHdoZXRoZXIgYW55IGxvY2F0aW9uDQogICBp bmNsdWRlZCBpbiB0aGUgU0lQIHJlcXVlc3Qgb3IgYWRkZWQgYWxvbmcgdGhlIHNpZ25hbGluZyBw YXRoIG9mDQogICB0aGlzIHJlcXVlc3QgY2FuIGJlIHZpZXdlZCBmb3Igcm91dGluZyBkZWNpc2lv bnMsIHRoZSBMb2NhdGlvbg0KICAgR2VuZXJhdG9yIGFkZHMgYSBHZW9sb2NhdGlvbiBoZWFkZXIg dmFsdWUgaW5jbHVkaW5nIHRoZQ0KICAgInJvdXRpbmctYWxsb3dlZD1ubyIgcGFyYW1ldGVyLg0K IiANCg0KVGhlIFJ1bGUgTWFrZXIgY29udHJvbHMsIG5vdCB0aGUgTEcuIA0KDQoqIFJlbW90ZSB1 c2VsZXNzIHN0YXRlbWVudHMuIEV4YW1wbGU6ICANCiAgIg0KICAgVW5sZXNzIHN0YXRlZCBvdGhl cndpc2UgYnkgZnV0dXJlIHN0YW5kYXJkcy10cmFjayBwdWJsaWNhdGlvbihzKSwgYQ0KICAgTGJ5 UiBVUkkgb25seSBoYXMgbWVhbmluZyB3aXRoaW4gdGhlIEdlb2xvY2F0aW9uIGhlYWRlciBmaWVs ZCBhbmQNCiAgIE1VU1QgTk9UIGFwcGVhciBpbiBhbnkgb3RoZXIgU0lQIGhlYWRlciBmaWVsZC4N CiAgIiANCg0KKiBBdm9pZCBhdXRob3IgYmlhcy4NCg0KIlByb3hpZXMgaW5zZXJ0aW5nIGxvY2F0 aW9uIGZvciBsb2NhdGlvbi1iYXNlZCByb3V0aW5nIGFyZQ0KICAgdW5hYmxlIHRvIG1lZXQgdGhp cyByZXF1aXJlbWVudCwgYW5kIHN1Y2ggdXNlIGlzIE5PVCBSRUNPTU1FTkRFRC4iDQoNClRoZSBk b2N1bWVudCBkZWZpbmVzIGZ1bmN0aW9uYWxpdHkgdG8gYWxsb3cgdGhlIHByb3h5IHRvIGFkZCBs b2NhdGlvbiBhbmQgd2UNCmtub3cgd2hvIGlzIGdvaW5nIHRvIHVzZSB0aGlzLiANCg0KKiBBdm9p ZCBpbmFwcHJvcHJpYXRlIHRyZWF0bWVudCBvZiBzdWJqZWN0cyB0aGF0IGFyZSBkaXNjdXNzZWQg c29tZXdoZXJlDQplbHNlLg0KDQoiDQogICBPbmUgZmFjZXQgd2l0aGluIHRoaXMgZXh0ZW5zaW9u IGlzIHN1Y2ggdGhhdCBsb2NhdGlvbnMgY2FuIGJlIHBsYWNlZA0KICAgb24gYSByZW1vdGUgc2Vy dmVyLCBhY2Nlc3NpYmxlIHdpdGggdGhlIHBvc3Nlc3Npb24gb2YgYSBVUkkuICBUaGUNCiAgIGNv bmNlcHQgb2YgYW4gTGJ5UiBVUkkgaGFzIGl0cyBvd24gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMu ICBJdCBpcw0KICAgdGVtcHRpbmcgdG8gYXNzdW1lIHRoYXQgdGhlIGRlcmVmZXJlbmNlIHdvdWxk IGhhdmUgYXV0aGVudGljYXRpb24sDQogICBhdXRob3JpemF0aW9uIGFuZCBvdGhlciBzZWN1cml0 eSBtZWNoYW5pc21zIHRoYXQgbGltaXQgdGhlIGFjY2VzcyB0bw0KICAgaW5mb3JtYXRpb24uICBV bmZvcnR1bmF0ZWx5LCB0aGlzIG1pZ2h0IG5vdCBiZSB0cnVlLiAgVGhlIGFjY2Vzcw0KICAgbmV0 d29yayB0aGUgVUFDIGlzIGNvbm5lY3RlZCB0byBjYW4gYmUgdGhlIHNvdXJjZSBvZiBsb2NhdGlv bg0KICAgcmVmZXJlbmNlLCBhbmQgaXQgbWlnaHQgbm90IGhhdmUgYW55IGNyZWRlbnRpYWxpbmcg bWVjaGFuaXNtDQogICBzdWl0YWJsZSBmb3IgY29udHJvbGxpbmcgYWNjZXNzIHRvIGxvY2F0aW9u LiAgQ29uc2lkZXIsDQogICBzcGVjaWZpY2FsbHksIGEgbm9tYWRpYyB1c2VyIGNvbm5lY3RlZCB0 byBhbiBhY2Nlc3MgbmV0d29yayBpbiBhDQogICBob3RlbC4gIFRoZSBVQUMgaGFzIG5vIHdheSB0 byBwcm92aWRlIGEgY3JlZGVudGlhbCBhY2NlcHRhYmxlIHRvDQogICB0aGUgaG90ZWwgTG9jYXRp b24gU2VydmVyIChMUykgdG8gYW55IG9mIGl0cyBpbnRlbmRlZCBMb2NhdGlvbg0KICAgUmVjaXBp ZW50cy4gIFRoZSByZWNpcGllbnQgb2YgYSByZWZlcmVuY2UgZG9lcyBub3Qga25vdyBpZiBhDQog ICByZWZlcmVuY2UgaGFzIGFwcHJvcHJpYXRlIGF1dGhvcml6YXRpb24gcG9saWNpZXMgb3Igbm90 LiAgVGhlIExTDQogICBzaG91bGQgcHJvdmlkZSBsb2NhdGlvbiB0byBhbnkgcmVxdWVzdG9yLg0K Ig0KDQpUaGUgTGJ5UiBjYW4gaGF2ZSBwb2xpY2llcyBhdHRhY2hlZCB0byBpdCwgaWYgbmVlZGVk LiBXZSBoYXZlIHdvcmtlZCBvbg0Kc29sdXRpb25zIHRvIGdldCB0aGlzIHRvIHdvcmsuIA0KSWYg aW4gYSBwYXJ0aWN1bGFyIHNjZW5hcmlvIHBvbGljaWVzIGNhbm5vdCBiZSB1cGxvYWRlZCB0bywg Zm9yIGV4YW1wbGUsIGENCkxJUyB0aGVuIHB1dCB0aGUgcmVmZXJlbmNlIHNvbWV3aGVyZSBlbHNl IHdoZXJlIHlvdSBoYXZlIHRoZSBwb2xpY2llcy4gDQoNCiogUy9NSU1FIGV4YW1wbGUgaW4gdGhl IGFwcGVuZGl4IGlzbid0IHVzZWZ1bCBhcyBpdCBpcyBjdXJyZW50bHkgcHV0IGluDQp0aGVyZS4g RXZlcnlib2R5IGtub3dzIHRoYXQgUy9NSU1FIGFsbG93cyB5b3UgdG8gZW5jcnlwdCBhIE1JTUUg Ym9keS4gU28sIGlmDQp5b3Ugd2FudCB0byBwdXQgaXQgaW4gdGhlcmUgdGhlbiBlbmNyeXB0IHRo ZSBzdHVmZiBhbmQgYXR0YWNoIHRoZSBrZXlzIHNvDQp0aGF0IG90aGVyIGZvbGtzIGNhbiBkZWNy eXB0IGl0LiANCg0KQ2lhbw0KSGFubmVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpHZW9wcml2IG1haWxpbmcgbGlzdA0KR2VvcHJpdkBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0 aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQs IHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1t ZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBv Zg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpbbWYyXQ0K From eburger@standardstrack.com Tue Mar 24 13:46:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1803A69A1; Tue, 24 Mar 2009 13:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE7IpNRomV3P; Tue, 24 Mar 2009 13:46:14 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id A7B183A6989; Tue, 24 Mar 2009 13:46:14 -0700 (PDT) Received: from [130.129.87.195] (port=59152 helo=dhcp-57c3.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LmDWV-0001EO-MZ; Tue, 24 Mar 2009 13:46:59 -0700 Message-Id: <6C97F4BE-653C-4200-8732-8AC60DC09D82@standardstrack.com> From: Eric Burger To: SIP IETF , sipping Content-Type: multipart/signed; boundary=Apple-Mail-84--225097103; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 13:47:04 -0700 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Sip] UA Config Ad Hoc X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:46:15 -0000 --Apple-Mail-84--225097103 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The UA Config (SIPPING) Ad Hoc will be in Franciscan D from 7:45am - 9am on Wednesday, 3/25. Grab breakfast first - IETF breakfast is near the room. --Apple-Mail-84--225097103 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjQyMDQ3MDRaMCMGCSqGSIb3 DQEJBDEWBBRWHnkT/mOiIL0AHIljCGBllYc2UTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQC3FVsY6NEscoK/+qbrOXWbRMeh5EwsNORioA+uN+wbICTY sDl6ycQzBaDBqebb//tR64JUGExsJiAhbIDQFETkZRuVCTecuczgK66q3sXnvhnOdFE1rijSSVa1 NngfzVRzQk1ggeMyuy5IkajxSx9ZB109Q6/GLR8nqo6b3mVeeRKrYJ06X+J6P3XB+X+PtikYyeXW 7/mAyyZQMHLsoi288bOxv+fcDYYGRyz/xhDoB2NdS5L6yt9azdylA8l16dSIULJEnp0Ki2RjiMOG JSUduLwKsy8zRVGVHef+Um3otmWTRtsS910pkCO6stOELtBi4wDv7uqMGXxaMMCHsNDYAAAAAAAA --Apple-Mail-84--225097103-- From eburger@standardstrack.com Tue Mar 24 13:47:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79CE28C2BC; Tue, 24 Mar 2009 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVExSbA4tdJy; Tue, 24 Mar 2009 13:47:16 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 3447528C11B; Tue, 24 Mar 2009 13:47:16 -0700 (PDT) Received: from [130.129.87.195] (port=59154 helo=dhcp-57c3.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LmDXV-0001N6-2W; Tue, 24 Mar 2009 13:48:01 -0700 Message-Id: <93EC3C74-984A-41FA-953E-C43412212888@standardstrack.com> From: Eric Burger To: SIP IETF , sipping Content-Type: multipart/signed; boundary=Apple-Mail-85--225034638; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 13:48:06 -0700 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Sip] SIP-CLF Ad Hoc X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:47:17 -0000 --Apple-Mail-85--225034638 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The SIP-CLF (common log format) SIPPING ad hoc will be in Yosemite A from 3pm - 4pm on Wednesday 3/25. Jabber will be on the SIPPING channel. --Apple-Mail-85--225034638 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjQyMDQ4MDdaMCMGCSqGSIb3 DQEJBDEWBBQJvNeCTxYQpQGHJ8sXw5XPaqsrljCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBtgnJ7bHtAeqnq4EROIFQnQCPR44tNCI7UdTLXvsjcYDM7 lKH8djWjOnUtUMmqJNpnzh+PXS1X7gH41c7lMrgw3icxG/FBvjlSvA2INwZNRIJeDkz69VC2LvoS XSdyCNwECzg1Ra7Qe7YTjB7I2haIc5d2d5VC0UhN+Da6qh8S44TiLV3IpvE8LNX5T1rXxxkh23Fh G9nxAj/qki1/kT8qK19h8BsCRl7jkkYvkRB1nAna/iiq3npkTEt7Z54yLAzDgseTiDi5vFq7e96W 8QUOxI8cVBm48xfwWVzoB2VHCoqBozhHJwbDVCJvReyZLSRlO260qoSrMgYz9yjNa1qYAAAAAAAA --Apple-Mail-85--225034638-- From eburger@standardstrack.com Tue Mar 24 13:47:39 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710AD28C335; Tue, 24 Mar 2009 13:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deFEGLy3SNyt; Tue, 24 Mar 2009 13:47:38 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id BAF5D28C2F8; Tue, 24 Mar 2009 13:47:38 -0700 (PDT) Received: from [130.129.87.195] (port=59154 helo=dhcp-57c3.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LmDXr-0001N6-GZ; Tue, 24 Mar 2009 13:48:23 -0700 Message-Id: From: Eric Burger To: SIP IETF , sipping In-Reply-To: <6C97F4BE-653C-4200-8732-8AC60DC09D82@standardstrack.com> Content-Type: multipart/signed; boundary=Apple-Mail-86--225011799; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 13:48:29 -0700 References: <6C97F4BE-653C-4200-8732-8AC60DC09D82@standardstrack.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Sip] UA Config Ad Hoc X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:47:39 -0000 --Apple-Mail-86--225011799 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Jabber will be on the SIPPING channel. On Mar 24, 2009, at 1:47 PM, Eric Burger wrote: > The UA Config (SIPPING) Ad Hoc will be in Franciscan D from 7:45am > - 9am on Wednesday, 3/25. Grab breakfast first - IETF breakfast is > near the room. --Apple-Mail-86--225011799 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjQyMDQ4MjlaMCMGCSqGSIb3 DQEJBDEWBBQUhO3lllwQK3lkZjYW7jLwmNmtyzCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQC3+G4TyIPh8ZLbfPj2N/Vx4JHNM2e3Cgw1Ni7g5V3OolvU vkWWcYiJSKVuWH071v248fyIZlxlGdOWcfUzBFvRdXgzx81No3cNtg82r/Wt8b72cJW1TUNZzoL4 jIRDC95nEWxRrHSynNSK7AH5IXXR7MRcSxMsA58uDlKTQ86cQksyLzFfziN3IWZWRh+2ethvM0dF +PR9l5t/96s7I/m/BbiBFH/0Jui2It8HZJ9fOlXIUzOI8cjtlIp/DGI5POJwjv6rzSjRPvSiwZ43 aYN6vmLBvc7lM4Nop/1JDivUsw2P6ZxZMXjgyemHpQxUT3cU2AxO/dRo1tI8MKK+fAmlAAAAAAAA --Apple-Mail-86--225011799-- From jmpolk@cisco.com Tue Mar 24 16:09:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3673A6A89 for ; Tue, 24 Mar 2009 16:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz1QWN0QQfuF for ; Tue, 24 Mar 2009 16:09:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8BDF93A6C2D for ; Tue, 24 Mar 2009 16:09:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,415,1233532800"; d="scan'208";a="146117166" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2009 23:10:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2ONAFRM006470; Tue, 24 Mar 2009 16:10:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2ONAEso028620; Tue, 24 Mar 2009 23:10:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 16:10:15 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.23.126]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 16:10:14 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Mar 2009 18:10:13 -0500 To: "Thomson, Martin" , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2009 23:10:14.0610 (UTC) FILETIME=[B0822320:01C9ACD5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10421; t=1237936215; x=1238800215; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20FW=3A=20[Geopriv]=20draft-ietf- sip-location-conveyance-13=3A=0A=20=20WGLC=20comments |Sender:=20; bh=cphlGXvsbfLHGvvYcOdKT6Lq1fyx6M/87sM7eNCMAdE=; b=dZ+xs94GBDRNRuRX36Y2cFfGjOK9PrpusRSPM7E2MMbs8RDnbEMXXBUbe9 IZOolC0LUl0uBK7Vn47W88dOauELbZqIPui/lJPdJbygKiVmuY22u/eTD4I6 X9cO/Qbg9y; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Sip] FW: [Geopriv] draft-ietf-sip-location-conveyance-13: WGLC comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:09:24 -0000 At 03:01 PM 3/24/2009, Thomson, Martin wrote: >As far as I am aware, the WGLC on this document attracted no >response on the SIP WG list. I can't entirely attribute this to >ambivalence, but would be concerned if anyone got the impression >that there were no issues on this document. > >This is a document that has had more changes recently The only change that is recent is addressing the "routing-allowed" flag, which had very little new next. the biggest change in the last 4 years was 2 years ago, surrounding the errors section (which Hannes now says he wants removed, but the rest of the folks at that bar bof (2 years ago) didn't agree with him then, and it would leave this spec underspecified... so that's not a good option IMO). I haven't heard any really substantial change requests in the last 2 years - other than this "routing-allowed" flag issue, which I have addressed in the current doc. >and it is still: (a) difficult to read, far too long; and (b) >generating little or no list discussion. a lot of (b) can be attributed to this fact; the ID has existed since 2003, and perhaps folks are tired of reading the doc that has to deal with Geopriv's inconsistencies over the years. >This document needs to be finished. However, I don't believe that >it is fit for publication. I don't see comments to address here from you, so I cannot comment on those comments, and I certainly cannot address them either if I don't know what they are... >I've forwarded comments from Hannes, which are very similar to those >I made many moons ago. Unfortunately, these comments were sent to >the wrong list. > >So... if you want to get overly procedural, you might interpret the >response as representing consensus for ambivalence. That would be a mistake. > >Cheers, >Martin > >-----Original Message----- >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On >Behalf Of Hannes Tschofenig >Sent: Saturday, 21 March 2009 12:05 PM >To: 'GEOPRIV' >Subject: [Geopriv] draft-ietf-sip-location-conveyance-13: WGLC comments > >I read through >http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-13. >I have concerning the current version of the document. > >Here are my high-level comments. Detailed comments on paper available for >the authors. > >* The draft comes up with new terminology even though we have these terms >already defined in other documents. This is bad (tm). >Cite terms (a common and preferred procedure) or copy the text exactly (and >quote it) rather than defining your own. Useless and as we saw in recent >discussions is rather harmful. > >* The document repeats stuff over and over again. Gives the reader the >impression that this is rocket science. Could be significantly shorter. > >* The draft has to avoid the term "using protocol" at all costs. As we know, >this term is very confusing. > >Example: Other protocols used in the Location URI MUST be reviewed >against > the RFC 3693 criteria for a Using Protocol. > >In human readable language this means: You have to consider security and >privacy with new extensions. > >* Don't understand why this document does not allow a HELD URI to be >conveyed. I commented this already several times and got ignored. > >See Section 4.5. Having an IANA registry appears to be totally crazy to me. >Even saying that the protocols are mandatory to implement is also not a good >idea. I really wonder why this is useful given that the recipient then just >cannot fetch location when it receives something that it does not >understand. What is the big deal with that? > >* Is "routing-allowed" policy really useful and, if so, does it need to be >in the SIP header rather than in the PIDF-LO where all the other policies >are? > >The problem is, again (also mentioned several times), with the lack of >description of the recipient is for a PIDF-LO with respect to the >'retransmission-allowed' policy. For example, in a location application >where the message is directed towards a Service URN the intended behavior is >that there is some form of location based routing involved. > >* This document is about the transport of a PIDF-LO and not about deployment >considerations. > >Example: >" > Adding a new locationValue to an in-transit request SHOULD NOT > occur for at least two reasons, > > #1 - SIP Servers are not the best Sighters, as defined by [RFC3693], > of geographically where a UAC can be; meaning the location > information is not necessarily the greatest. There MAY be > exceptions, but this SHOULD be the rule of thumb. > > #2 - without appropriate caution to the fact that Location > Recipients might not understand how to process more than one > location, given this document's limited guidance as to what a > Location Recipient should do when receiving more than one > location (i.e., currently no priority instructions are given > for which locationValue to use if there are more than one). A > Location Recipient can easily be confused by too much location > information, producing undesirable results. The > element in the PIDF-LO XML indicates whose location is > contained in the PIDF-LO. >" > >This example also shows inappropriate usage of RFC2119 language which should >be used for interoperability rather than philosophical stuff. > >We know who wants some of this functionality and what the exact use case it. > >* The location-based error codes (100, 200, 300, 400, 500 on page 14ff) are >extremly fuzzy. They clearly lack implementation experience (as the text >continuesly repeats by saying "for future work") and I believe they should >be removed and incorporated in a future version when more implementation >experience is available. > > >* " S/MIME can be used for just signing, and not encrypting, a > PIDF-LO message body to ensure the integrity of the PIDF-LO is > maintained." > > I am not sure what this means. S/MIME cannot only be used for signing. > >" > Use of self-signed certificates is inappropriate for use in > protecting a PIDF, as the sender does not have a secure identity of > the recipient. >" > > This sentence does not make a lot of sense to me. > >* This document does not need to repeat the text from other documents. >Example: > " > When using LbyR, the LbyR MUST NOT contain any > user identifying information. For example, use something > unidentifiable like > " > > Already in the LbyR requirements document. Reference it -- no need to >write new text. > > Other examples can be found with the description how >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.txt >works. > >* " >If the Location Generator wishes to control whether any location > included in the SIP request or added along the signaling path of > this request can be viewed for routing decisions, the Location > Generator adds a Geolocation header value including the > "routing-allowed=no" parameter. >" > >The Rule Maker controls, not the LG. > >* Remote useless statements. Example: > " > Unless stated otherwise by future standards-track publication(s), a > LbyR URI only has meaning within the Geolocation header field and > MUST NOT appear in any other SIP header field. > " > >* Avoid author bias. > >"Proxies inserting location for location-based routing are > unable to meet this requirement, and such use is NOT RECOMMENDED." > >The document defines functionality to allow the proxy to add location and we >know who is going to use this. > >* Avoid inappropriate treatment of subjects that are discussed somewhere >else. > >" > One facet within this extension is such that locations can be placed > on a remote server, accessible with the possession of a URI. The > concept of an LbyR URI has its own security considerations. It is > tempting to assume that the dereference would have authentication, > authorization and other security mechanisms that limit the access to > information. Unfortunately, this might not be true. The access > network the UAC is connected to can be the source of location > reference, and it might not have any credentialing mechanism > suitable for controlling access to location. Consider, > specifically, a nomadic user connected to an access network in a > hotel. The UAC has no way to provide a credential acceptable to > the hotel Location Server (LS) to any of its intended Location > Recipients. The recipient of a reference does not know if a > reference has appropriate authorization policies or not. The LS > should provide location to any requestor. >" > >The LbyR can have policies attached to it, if needed. We have worked on >solutions to get this to work. >If in a particular scenario policies cannot be uploaded to, for example, a >LIS then put the reference somewhere else where you have the policies. > >* S/MIME example in the appendix isn't useful as it is currently put in >there. Everybody knows that S/MIME allows you to encrypt a MIME body. So, if >you want to put it in there then encrypt the stuff and attach the keys so >that other folks can decrypt it. > >Ciao >Hannes > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] >_______________________________________________ >Sip mailing list https://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip From dworley@nortel.com Tue Mar 24 16:53:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6E13A6859 for ; Tue, 24 Mar 2009 16:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.664 X-Spam-Level: X-Spam-Status: No, score=-6.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcM6EiaywMJL for ; Tue, 24 Mar 2009 16:53:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1E0AD3A682B for ; Tue, 24 Mar 2009 16:53:51 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2ONs9q16552; Tue, 24 Mar 2009 23:54:10 GMT Received: from [47.141.31.139] ([47.141.31.139]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 19:53:53 -0400 From: "Dale Worley" To: Adam Roach In-Reply-To: References: Content-Type: text/plain Organization: Nortel Networks Date: Tue, 24 Mar 2009 19:53:52 -0400 Message-Id: <1237938832.443.21.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 23:53:53.0779 (UTC) FILETIME=[C9A79C30:01C9ACDB] Cc: SIP Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:53:52 -0000 On Mon, 2009-03-23 at 18:45 -0700, Adam Roach wrote: > What I'm claiming right now is that it is a complete list of every sentence > and clause in 3265 relating to the topic. A *complete* list would include > the stuff in 5057 -- but I'm hesitant to suck in 20+ pages of information > that is already specified elsewhere. It wasn't clear to me that it included all the relevant parts of 3265, but since this document is intended to obsolete 3265, its text can't assert its own relationship to 3265. Of course, you can refer to 5057, because it won't be obsoleted. Dale From dworley@nortel.com Tue Mar 24 16:56:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D773A6945 for ; Tue, 24 Mar 2009 16:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.662 X-Spam-Level: X-Spam-Status: No, score=-6.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3PcKuUJSk8r for ; Tue, 24 Mar 2009 16:56:45 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5A9713A6941 for ; Tue, 24 Mar 2009 16:56:45 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2ONuaH17229; Tue, 24 Mar 2009 23:56:36 GMT Received: from [47.141.31.139] ([47.141.31.139]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 19:57:02 -0400 From: "Dale Worley" To: Adam Roach In-Reply-To: <49C90FD8.8010101@nostrum.com> References: <0D5F89FAC29E2C41B98A6A762007F5D001AAD8F3@GBNTHT12009MSX.gb002.siemens.net> <49C6C895.9040204@nostrum.com> <49C90FD8.8010101@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 24 Mar 2009 19:57:01 -0400 Message-Id: <1237939021.443.24.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 23:57:02.0860 (UTC) FILETIME=[3A5B14C0:01C9ACDC] Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:56:46 -0000 On Tue, 2009-03-24 at 09:52 -0700, Adam Roach wrote: > > GRUU is not what one would call a wildly successful mechanism, yet > > Of course it's not. It's not an RFC yet. After the whole multi-year TURN > whipsaw experience, I'm stunned anyone bothers to implement anything > before it has an RFC number assigned any more. But, suprisingly, they > do: more than one in every eight implementations at SIPit 22 implemented > GRUU. I'm not so concerned about getting GRUU implemented. It's known that GRUU is necessary to get many call-control mechanisms to work, so everyone assumes they'll have to implement it eventually. Dale From dworley@nortel.com Tue Mar 24 17:15:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DBFA3A69C0 for ; Tue, 24 Mar 2009 17:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.66 X-Spam-Level: X-Spam-Status: No, score=-6.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUl5LRod+Fju for ; Tue, 24 Mar 2009 17:15:53 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7644F3A698A for ; Tue, 24 Mar 2009 17:15:53 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2P0GDq20947; Wed, 25 Mar 2009 00:16:13 GMT Received: from [47.141.31.139] ([47.141.31.139]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 20:16:13 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <49C83831.7010102@cisco.com> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 24 Mar 2009 20:16:12 -0400 Message-Id: <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 00:16:13.0523 (UTC) FILETIME=[E8345230:01C9ACDE] Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:15:54 -0000 On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote: > > I would argue that the REFER is part of the INVITE usage, because REFER > > in that context is intimately related to the INVITE usage -- it is > > intended to transfer the INVITE usage/dialog transferred to a different > > destination. > > Well, I guess there is that implied association. (Part of the "do what > *I* had in mind" approach that REFER has.) Since this was never spelled > out, it could also be simply "while this isn't part of an INVITE usage, > if there happens to be an INVITE usage, please refer that one." > > I guess the question is: would it be valid to send a REFER within an > existing dialog that had no INVITE usage? If it were valid, presumably > it would have the same meaning as sending one outside a dialog, except > that the resulting subscription would share the dialog. I expect that is > a usage it would be difficult to find in the wild. That's a nice pathological case. But within the context of the current 5 possible meanings of REFER, it seems to be most parallel to the out-of-dialog REFER. > Ah, but now I want to reconsider. Remember that REFER can take a method > name. So, rather than referring an INVITE, I could be referring MESSAGE, > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the > association to the INVITE usage is probably meaningless. (Of course its > meaningful for BYE.) A fascinating possibility! But I'm not sure that we've ever defined how a REFER within a simple INVITE dialog, specifying a non-INVITE method should act. So there's no analog to follow. > > And it seems quite safe that if the REFER receives a 481 response, the > > INVITE usage must not be functional any more, since the far end of that > > usage has denied that it can act on the REFER. > > IIRC, 5057 decided that each dialog usage must get its own 481 before it > goes away. I don't think there are any cases where a single 481 response > can make multiple usages go away. > > So the important question is whether the REFER is part of the INVITE > usage and so its 481 takes down the INVITE usage or not. That gets > especially interesting if the dialog already had both an INVITE usage > and a SUBSCRIBE usage. Does it make sense that the refer take down the > INVITE usage and leave up the SUBSCRIBE usage? I think we're a victim of sloppy terminology here. If I send a REFER, and the far end responds 481, then clearly the far end knows of no INVITE usage, or otherwise it would not have responded 481. So I should delete my belief that there is an INVITE usage. Whether we consider the REFER in question to be "part of" the INVITE usage or not doesn't change anything -- the 481 is evidence that the far end has no knowledge of the usage. However, we do have this fine paradox: If we assume that a REFER within an established dialog that has no INVITE usage is to be treated as an out-of-dialog REFER, then *no* REFER will receive a 481 response! Indeed, if I send a REFER thinking that there is an active INVITE usage, but the far end believes the INVITE usage has ended, will cause the far end to do something (initiate an independent dialog) that is considerably different from what I expected (transfer the current INVITE usage). Dale From mary.barnes@nortel.com Tue Mar 24 17:40:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E1C3A68A7; Tue, 24 Mar 2009 17:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqMqkFDNUkHT; Tue, 24 Mar 2009 17:40:54 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 369393A6919; Tue, 24 Mar 2009 17:40:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2P0fEo26143; Wed, 25 Mar 2009 00:41:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ACE2.5A764FD5" Date: Tue, 24 Mar 2009 19:40:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1BF5FD82@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for SIP and SIPPING sessions Thread-Index: AcmsJFwj9yT+3IENTXaCwtMRz44fEQAvPon9 References: <28B7C3AA2A7ABA4A841F11217ABE78D67577C4DF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Mary Barnes" To: "DRAGE, Keith (Keith)" , , "sipping" Cc: sip-chairs@tools.ietf.org, sipping-chairs@tools.ietf.org Subject: Re: [Sip] [Sipping] Slides for SIP and SIPPING sessions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:40:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ACE2.5A764FD5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A reminder that we need all the charts for tomorrow's SIP WG session no = later than 9am so that we can get them all uploaded and on a single = computer for presenting. So, far we've gotten one presentation.=20 If you could please send the charts to both sets of chairs, that would = be helpful. Thanks, Mary.=20 -----Original Message----- From: sipping-bounces@ietf.org on behalf of DRAGE, Keith (Keith) Sent: Mon 3/23/2009 9:00 PM To: sip@ietf.org; sipping Cc: sip-chairs@tools.ietf.org; sipping-chairs@tools.ietf.org Subject: [Sipping] Slides for SIP and SIPPING sessions =20 (As SIP WG chair) Please make sure you submit your slides well before the start of the = sessions of SIP or SIPPING in which you are presenting. We would suggest = deadlines of: Tuesday 13:00 session - submit by Tuesday 9:00 Wednesday 13:00 session - submit by Wednesday 9:00 Friday 9:00 session - submit by Thursday 15:00 These are the latest time for submission - there is nothing wrong with = sending them to us early. To avoid confusion, you may want to send them to both sets of chairs, = given the combined nature of the agenda this time round. regards Keith _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C9ACE2.5A764FD5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Slides for SIP and SIPPING sessions

A reminder that we need all the charts for tomorrow's = SIP WG session no later than 9am so that we can get them all uploaded = and on a single computer for presenting. So, far we've gotten one = presentation.

If you could please send the charts to both sets of chairs, that would = be helpful.

Thanks,
Mary.


-----Original Message-----
From: sipping-bounces@ietf.org on behalf of DRAGE, Keith (Keith)
Sent: Mon 3/23/2009 9:00 PM
To: sip@ietf.org; sipping
Cc: sip-chairs@tools.ietf.org; sipping-chairs@tools.ietf.org
Subject: [Sipping] Slides for SIP and SIPPING sessions

(As SIP WG chair)

Please make sure you submit your slides well before the start of the = sessions of SIP or SIPPING in which you are presenting. We would suggest = deadlines of:

Tuesday 13:00 session - submit by Tuesday 9:00
Wednesday 13:00 session - submit by Wednesday 9:00
Friday 9:00 session - submit by Thursday 15:00

These are the latest time for submission - there is nothing wrong with = sending them to us early.

To avoid confusion, you may want to send them to both sets of chairs, = given the combined nature of the agenda this time round.

regards

Keith
_______________________________________________
Sipping mailing list  https://www.ietf.o= rg/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

------_=_NextPart_001_01C9ACE2.5A764FD5-- From spencer@wonderhamster.org Tue Mar 24 17:58:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8033A6A1E for ; Tue, 24 Mar 2009 17:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61y4ktk1rxbR for ; Tue, 24 Mar 2009 17:58:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id C54443A6A02 for ; Tue, 24 Mar 2009 17:58:17 -0700 (PDT) Received: from S73602b (dhcp-56ea.meeting.ietf.org [130.129.86.234]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LmHSN2Rnt-000g4l; Tue, 24 Mar 2009 20:59:04 -0400 Message-ID: <036C67C870DF4FA093CA6A614F24FEE4@china.huawei.com> From: "Spencer Dawkins" To: "Hadriel Kaplan" , "Jiri Kuthan" , "Dean Willis" References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com><49C8675E.9080501@iptel.org> Date: Tue, 24 Mar 2009 19:58:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18RSQHcwW6cZIaso0mi84IYuzULBDmOkWztOho NuZZe5WcM2RWGpw9bt0cUsGPp8gbpfMIhkGfUDZevHzPUavxnc bNc4OHboTnsL6KTJt97LHACPwSYpwdVFYycTGeQcMA= Cc: SIP Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:58:18 -0000 >> Nevertheless, I think that troubleshooting has been >> historically of rather >> marginal interest here, so I'm not sure if there is really an action to >> be >> made. > > I think dealing with the operational aspects of SIP networks, especially > with troubleshooting them, is a topic whose time has come. There are at > least 3 recent drafts introducing mechanisms to aid in troubleshooting > SIP. Personally I think it's one of the next hurdles in growing SIP's > adoption. > > From a DISPATCH draft-routing-to-WG perspective, one could argue we > actually need a SipOps WG. Hadriel, I really agree with this. I'm assuming that "operational aspects of SIP networks" is (1) big enough, and (2) obvious enough to justify requesting a traditional BOF (not sliding through DISPATCH). So, a couple of questions: (1) is that OK, based on the current view of DISPATCH? or should we be requesting DISPATCH time in Stockholm? and (2) do we have enough people with enough clue to propose a SIPOps BOF? Thanks, Spencer From abhatnagar192006@gmail.com Tue Mar 24 19:27:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886573A6AF2 for ; Tue, 24 Mar 2009 19:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAqmhsbauRlk for ; Tue, 24 Mar 2009 19:27:18 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 856223A6984 for ; Tue, 24 Mar 2009 19:27:18 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3661591wfg.31 for ; Tue, 24 Mar 2009 19:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zeGviXmJmnstyDTyj1I2zLJv9ftgWPmdTi3Nx6Bc3gM=; b=YFIBxANLlaoSGS/pnb0hu1OTQdAi6Nz1nsr4Rncf2svvPJ5hjx5uiDGAcl2/HD2FOk VXRnvIrx9zVIN+9reEcYzDCdFCzd2QkNRv5P6fGQ+sCq0MsDgXNbdx7ejpPK71/WxVZF A6N7Api0HykrYA58fcFeBujeMISMV1wd0ltZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vcMlvihcr35fWYuHh66R21KqZrTkdQSWNKNR645jJblB1yC91ZtxloZlOGwNd62SJ2 gMLObM3iTEqCpmodkgrmZwHNRdjXKTrfaKdgZ7TROR/Bys0wEZWlkofnbG4UMUA6KKBc iOgXwimvy0LWXhsEI1hTiM/3+F9dYpZg/+Ye8= MIME-Version: 1.0 Received: by 10.142.231.7 with SMTP id d7mr3673312wfh.285.1237948090119; Tue, 24 Mar 2009 19:28:10 -0700 (PDT) In-Reply-To: <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> Date: Wed, 25 Mar 2009 02:58:10 +0030 Message-ID: From: aayush bhatnagar To: Dale Worley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP IETF , Paul Kyzivat , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 02:27:19 -0000 If you send an in dialog request (REFER in our case), then you cannot decouple its semantics with the existing dialog usage. So saying that even if i send a REFER within an existing dialog, and still decouple it from the existing dialog usage will not be possible. If there were such a requirement, then REFER should have been sent as a standalone dialog creating request outside the INVITE usage. The recipient of the in dialog REFER will treat it like it should any in dialog request. It has no way to decide if this request potentially had nothing to do with the existing dialog usage. i agree with you when you say that an indialog refer receiving a 481 would mean that the INVITE dialog has been torn down. However, a refer dialog usage can also terminate, if the UAC sends a 481 in response to the NOTIFY sent by the UAS (Suppose the transaction did not match). This scenario may happen irrespective of whether the REFER was within the invite usage or created its own distinct dialog. If this happens when REFER was sent within an Invite dialog, then the UAC will be mistaken to clean up its INVITE dialog state. I did not understand one part in the paradox above when you said... "A REFER within an established dialog having no invite usage to be considered as an out of dialog REFER" Do you mean to imply a REFER in some other Subscribe event package dialog for example? aayush. On 3/25/09, Dale Worley wrote: > On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote: >> > I would argue that the REFER is part of the INVITE usage, because REFER >> > in that context is intimately related to the INVITE usage -- it is >> > intended to transfer the INVITE usage/dialog transferred to a different >> > destination. >> >> Well, I guess there is that implied association. (Part of the "do what >> *I* had in mind" approach that REFER has.) Since this was never spelled >> out, it could also be simply "while this isn't part of an INVITE usage, >> if there happens to be an INVITE usage, please refer that one." >> >> I guess the question is: would it be valid to send a REFER within an >> existing dialog that had no INVITE usage? If it were valid, presumably >> it would have the same meaning as sending one outside a dialog, except >> that the resulting subscription would share the dialog. I expect that is >> a usage it would be difficult to find in the wild. > > That's a nice pathological case. But within the context of the current > 5 possible meanings of REFER, it seems to be most parallel to the > out-of-dialog REFER. > >> Ah, but now I want to reconsider. Remember that REFER can take a method >> name. So, rather than referring an INVITE, I could be referring MESSAGE, >> OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the >> association to the INVITE usage is probably meaningless. (Of course its >> meaningful for BYE.) > > A fascinating possibility! But I'm not sure that we've ever defined how > a REFER within a simple INVITE dialog, specifying a non-INVITE method > should act. So there's no analog to follow. > >> > And it seems quite safe that if the REFER receives a 481 response, the >> > INVITE usage must not be functional any more, since the far end of that >> > usage has denied that it can act on the REFER. >> >> IIRC, 5057 decided that each dialog usage must get its own 481 before it >> goes away. I don't think there are any cases where a single 481 response >> can make multiple usages go away. >> >> So the important question is whether the REFER is part of the INVITE >> usage and so its 481 takes down the INVITE usage or not. That gets >> especially interesting if the dialog already had both an INVITE usage >> and a SUBSCRIBE usage. Does it make sense that the refer take down the >> INVITE usage and leave up the SUBSCRIBE usage? > > I think we're a victim of sloppy terminology here. If I send a REFER, > and the far end responds 481, then clearly the far end knows of no > INVITE usage, or otherwise it would not have responded 481. So I should > delete my belief that there is an INVITE usage. Whether we consider the > REFER in question to be "part of" the INVITE usage or not doesn't change > anything -- the 481 is evidence that the far end has no knowledge of the > usage. > > However, we do have this fine paradox: If we assume that a REFER within > an established dialog that has no INVITE usage is to be treated as an > out-of-dialog REFER, then *no* REFER will receive a 481 response! > Indeed, if I send a REFER thinking that there is an active INVITE usage, > but the far end believes the INVITE usage has ended, will cause the far > end to do something (initiate an independent dialog) that is > considerably different from what I expected (transfer the current INVITE > usage). > > Dale > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From dworley@nortel.com Tue Mar 24 22:04:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425943A6A62 for ; Tue, 24 Mar 2009 22:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0ukbzGVRgX9 for ; Tue, 24 Mar 2009 22:04:04 -0700 (PDT) Received: from your.mail.server.name.com (ip-66-80-12-66.dsl.sca.megapath.net [66.80.12.66]) by core3.amsl.com (Postfix) with SMTP id 943133A69AA for ; Tue, 24 Mar 2009 22:04:04 -0700 (PDT) Received: (qmail 19934 invoked from network); 25 Mar 2009 03:59:22 -0000 Received: from unknown (HELO ?10.61.32.115?) (10.61.32.115) by 0 with SMTP; 25 Mar 2009 03:59:22 -0000 From: Dale Worley To: Hadriel Kaplan In-Reply-To: References: Content-Type: text/plain Organization: Nortel Networks Date: Tue, 24 Mar 2009 23:59:19 -0400 Message-Id: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 05:04:05 -0000 I'm not sure how much benefit comes from this idea. On the one hand, it contains no mandate of the form "If the call-id is of format xxxxx, then SBCs WILL NOT change it." So there's SBC behavior in particular that an outside agent can depend on, even if it knows that all UAs in the system follow the I-D. My guess is that SBCs will munge the call-ids anyway, rather than trying to implement an algorithm to determine compliance -- on a UAC-by-UAC basis! The other side of this is that it makes life harder for anyone trying to diagnose problems. In sipX, we currently generate pseudo-random call-ids. Actually, the format is "s-XXXXXXXXXXX-NNN", where XXXXXXXX is pseudo-random and NNN is a sequence number. That way you can mentally say "dialog 7" and "dialog 45", but still get uniqueness. But we've got a work item to append the host DNS name to the format so that we can easily distinguish "dialog 45 from sipx1.example.com" and "dialog 45 from sipx2.example.com". Dale From dworley@nortel.com Tue Mar 24 22:09:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BC03A67B4 for ; Tue, 24 Mar 2009 22:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f8lgjfsuWqY for ; Tue, 24 Mar 2009 22:09:07 -0700 (PDT) Received: from your.mail.server.name.com (ip-66-80-12-66.dsl.sca.megapath.net [66.80.12.66]) by core3.amsl.com (Postfix) with SMTP id 774223A68A0 for ; Tue, 24 Mar 2009 22:09:07 -0700 (PDT) Received: (qmail 21048 invoked from network); 25 Mar 2009 04:04:25 -0000 Received: from unknown (HELO ?10.61.32.115?) (10.61.32.115) by 0 with SMTP; 25 Mar 2009 04:04:25 -0000 From: Dale Worley To: Eric Burger In-Reply-To: References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Mar 2009 00:04:23 -0400 Message-Id: <1237953863.22543.10.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit Cc: SIP IETF Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 05:09:08 -0000 On Fri, 2009-03-06 at 12:59 -0500, Eric Burger wrote: > Wouldn't SIP-CLF be a better way to go? Not really, because log files slice the universe of data the wrong way. A log file tells everything that happens at a particular element, almost all of which is irrelevant regarding a particular transaction. Transaction tracing is to extract the data relevant to a particular transaction, across all elements that handle that transaction. In many cases, the person doing the trace is not and should not be authorized to see the log of the elements the transaction traverses -- but they should be authorized to see what happened to that one transaction. Dale From dworley@nortel.com Tue Mar 24 22:17:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36AD3A67B7 for ; Tue, 24 Mar 2009 22:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll6tCh9xHo4z for ; Tue, 24 Mar 2009 22:17:53 -0700 (PDT) Received: from your.mail.server.name.com (ip-66-80-12-66.dsl.sca.megapath.net [66.80.12.66]) by core3.amsl.com (Postfix) with SMTP id D916F3A67B2 for ; Tue, 24 Mar 2009 22:17:52 -0700 (PDT) Received: (qmail 22831 invoked from network); 25 Mar 2009 04:13:07 -0000 Received: from unknown (HELO ?10.61.32.115?) (10.61.32.115) by 0 with SMTP; 25 Mar 2009 04:13:07 -0000 From: Dale Worley To: Hadriel Kaplan In-Reply-To: References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Mar 2009 00:13:00 -0400 Message-Id: <1237954380.22543.20.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit Cc: SIP Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 05:17:53 -0000 On Fri, 2009-03-06 at 12:52 -0500, Hadriel Kaplan wrote: > I appreciate that doing troubleshooting of SIP in SIP is very > appealing, but I'm worried about it. There are some real security > issues with this, even if we don't want to admit it. The reality is > that if this trace mechanism is actually adopted by any sizeable > measure, then middleboxes will be forced to munge the messages more > than they already do, to prevent it from being used/work. In other > words it's a self-defeating mechanism. Yes, there should be a mechanism so that a transit network can make itself appear to be a wire, to be one hop, with regard to the trace mechanism. But there is no reason that the routing on the *far side* of a transit network should be hidden from the UAC -- at least, from the point of view of the transit network, the far-end network might have policies. (I'm envisioning a world in which the UAC's end may be involved in complex service provisioning in which there may be more than one transit network and more than one element that provides complex call routing. Though a transit network should be able to hide its internal structure, the UAC has the right to know what element the transit network delivered the request to, since that is what the UAC is paying the transit network to do.) > Today you can do incrementing Max-Forwards traceroute, similar to the > ICMP traceroute TTL trick, and even that's gotten some folks worried > enough to make us munge the Max-Forwards value (despite the obvious > dangers in doing so). But anyway why isn't that type of trace enough > for your needs? I envision sending 20 INVITEs to the same request-URI, with gradually increasing Max-Forwards values. Any UAS that can be reached in less than the maximum number of hops will get hammered. And, as you say, SBCs are already trying to prevent that. > Also, a couple specific questions/comments regarding this draft: > > 1) You use the term "final response" a couple times as being sent in > the 170's body. How would a final response be sent in a 170 response, > since the 170 would be before a final response? Clearly, the 170 would have to be formulated after the final response is formulated. But I don't see any particular prohibition on that, and there isn't any real restriction in the order that responses are sent. > 2) You state that a UAC should not create an early-dialog for the 170, > but for any B2BUA in the path which did not know about this new trace > mechanism, wouldn't it create early dialogs on the b2bua since it > would treat it as a 183? I suppose it would. Which would be somewhat resource-inefficient. But I don't expect the fraction of requests that are traced to be over 0.1%, so it shouldn't be a problem in practice. Dale From dworley@nortel.com Tue Mar 24 22:31:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CE53A695D for ; Tue, 24 Mar 2009 22:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6MotAfvmmLy for ; Tue, 24 Mar 2009 22:31:21 -0700 (PDT) Received: from your.mail.server.name.com (ip-66-80-12-66.dsl.sca.megapath.net [66.80.12.66]) by core3.amsl.com (Postfix) with SMTP id 44FF63A68F2 for ; Tue, 24 Mar 2009 22:31:19 -0700 (PDT) Received: (qmail 26077 invoked from network); 25 Mar 2009 04:26:32 -0000 Received: from unknown (HELO ?10.61.32.115?) (10.61.32.115) by 0 with SMTP; 25 Mar 2009 04:26:32 -0000 From: Dale Worley To: IETF SIP List In-Reply-To: <49C507BB.9010804@cisco.com> References: <49C507BB.9010804@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Mar 2009 00:26:28 -0400 Message-Id: <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 05:31:22 -0000 On Sat, 2009-03-21 at 11:28 -0400, Jonathan Rosenberg wrote: > Now B and C are talking to each other. What is the session ID for this > dialog? B and C were both originally the UAS on different dialogs with > different session IDs! The essential problem (which also shows up in draft-loreto-sipping-context-id-requirements) is that you need to express a correlation between two dialogs, but the correlation is discovered after both of the dialogs have been initiated. If I may be immodest, the References header could a solution: State that two dialogs are related to each other by (effectively) naming both call-id's together, rather than by assigning them a common identifier when they are created. In regard to correlating the two legs of a call through an SBC, see section 5.2 of draft-worley-references-02. The SBC can put a References header in a message going out on one leg that contains the call-id of the dialog on the other leg, or vice-versa. If the SBC wants to be paranoid, it can create a pseudo-random pseudo-Call-Id and put it in a References header in two messages, one going out each leg. That's not elegant, but it's effective and safe -- and doesn't depend on the UAs. As far as I can tell, the References header handles all of the use cases people have stated. Dale From HKaplan@acmepacket.com Tue Mar 24 23:42:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4763A6A31 for ; Tue, 24 Mar 2009 23:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYvh1Denlkoh for ; Tue, 24 Mar 2009 23:42:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B12773A685B for ; Tue, 24 Mar 2009 23:42:29 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 02:43:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 25 Mar 2009 02:43:20 -0400 From: Hadriel Kaplan To: Dale Worley Date: Wed, 25 Mar 2009 02:43:22 -0400 Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmtBz5cwB9gtzcwTBeH3oF6CJhxsgAC4O5A Message-ID: References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 06:42:30 -0000 > -----Original Message----- > From: Dale Worley [mailto:dworley@nortel.com] > Sent: Tuesday, March 24, 2009 11:59 PM >=20 > I'm not sure how much benefit comes from this idea. > On the one hand, it contains no mandate of the form "If the call-id is > of format xxxxx, then SBCs WILL NOT change it." =20 Huh, you're right. I should add in a MUST NOT change it for security purpo= ses. Although realistically Call-ID's are changed by many B2BUA's other th= an SBC's for reasons other than security. This draft is only trying to rem= ove the incentive for changing them for security reasons. There is no way = to stop other B2BUA's from changing them for other reasons. (which is why I= have the session-id draft) > So there's SBC behavior > in particular that an outside agent can depend on, even if it knows that > all UAs in the system follow the I-D. My guess is that SBCs will munge > the call-ids anyway, rather than trying to implement an algorithm to > determine compliance -- on a UAC-by-UAC basis! Sure, SBC's may not follow this draft. So? UA's and other devices may not= follow any given draft/RFC. But right now there's actually a reasonably d= efendable rationale for why the Call-ID's should be changed. I'm trying to= get rid of that rationale. The owners of the SBC's will then be able to t= ell their vendors "go do this draft", if they find they need SIP extensions= to work which rely on the Call-ID not changing. The market will sort out = if that's valuable or not. =20 > The other side of this is that it makes life harder for anyone trying to > diagnose problems. In sipX, we currently generate pseudo-random > call-ids. Actually, the format is "s-XXXXXXXXXXX-NNN", where XXXXXXXX > is pseudo-random and NNN is a sequence number. That way you can > mentally say "dialog 7" and "dialog 45", but still get uniqueness. But > we've got a work item to append the host DNS name to the format so that > we can easily distinguish "dialog 45 from sipx1.example.com" and "dialog > 45 from sipx2.example.com". If you do that, SBC's will continue to change the Call-ID from your devices= . There's always a trade-off between revealing enough information to troub= leshoot/diagnose, and revealing information that can lead to abuse. -hadriel From HKaplan@acmepacket.com Wed Mar 25 00:09:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B384A3A696E for ; Wed, 25 Mar 2009 00:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sPSAhzHhrdD for ; Wed, 25 Mar 2009 00:09:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BAD3B3A67B2 for ; Wed, 25 Mar 2009 00:09:34 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 03:10:26 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 25 Mar 2009 03:10:25 -0400 From: Hadriel Kaplan To: Dale Worley , IETF SIP List Date: Wed, 25 Mar 2009 03:10:27 -0400 Thread-Topic: [Sip] comments on draft-kaplan-sip-session-id-01 Thread-Index: AcmtCyvK7i7Z2XGERwu5lUV/OazhuwACl+HQ Message-ID: References: <49C507BB.9010804@cisco.com> <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 07:09:35 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dal= e > Worley > Sent: Wednesday, March 25, 2009 12:26 AM >=20 > The essential problem (which also shows up in > draft-loreto-sipping-context-id-requirements) is that you need to > express a correlation between two dialogs, but the correlation is > discovered after both of the dialogs have been initiated. Yeah but I'm not trying to solve that scenario. Session-ID is only trying t= o create a dialog identifier for a single "end-end dialog" that survives B2= BUA's, for the purposes of troubleshooting that dialog. It's NOT trying to= correlate all subsequent dialogs, across all space/time, which may have so= me relationship to the original one. =20 For example, take Jonathan's example of two-calls get joined together with = a REFER processed by a PBX (I think that's one we've actually discussed bef= ore, but maybe not). There is dialog A and dialog B, and at some point hal= f of A and half of B are joined together with re-INVITEs. Personally I act= ually think that's a brand new session. Because had the REFER actually gon= e end-to-end, that's exactly what would have happened: dialog C would be cr= eated. Just because they happen to be re-using dialog identifiers (call-id= /tags) from the original A and B dialogs, is essentially just a nuance of S= IP protocol mechanics. From the user's perspective they got transferred, f= rom the admins/provider's perspective they got transferred, and from an arc= hitecture perspective they got transferred (i.e., the real "ends" of the di= alog have now changed). I don't debate that from a troubleshooting perspective it would be valuable= to know that the new C dialog was created from the original A and B dialog= s, but I'm not sure that needs to be known on the wire. I mean minimally t= he PBX logs will show it. But I can see the benefit for both. =20 > If I may be immodest, the References header could a solution: State > that two dialogs are related to each other by (effectively) naming both > call-id's together, rather than by assigning them a common identifier > when they are created. Yeah I think it adds value to have the References header. I just don't thi= nk it should be referencing Call-ID's, or else we'll have to replace that t= oo. It should be referencing Session-ID's or secure-call-id's. :) -hadriel From HKaplan@acmepacket.com Wed Mar 25 00:29:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99B73A6863 for ; Wed, 25 Mar 2009 00:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uimd0zP0s6yQ for ; Wed, 25 Mar 2009 00:29:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 20BA83A6853 for ; Wed, 25 Mar 2009 00:29:05 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 03:29:56 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 25 Mar 2009 03:29:56 -0400 From: Hadriel Kaplan To: Dale Worley Date: Wed, 25 Mar 2009 03:29:58 -0400 Thread-Topic: [Sip] SIP Tracing Facility Thread-Index: AcmtCSu4Ou9wiPr6RUGpJvx9mzWnFgAEIENQ Message-ID: References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> <1237954380.22543.20.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1237954380.22543.20.camel@victoria-pingtel-com.us.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 07:29:06 -0000 > -----Original Message----- > From: Dale Worley [mailto:dworley@nortel.com] > Sent: Wednesday, March 25, 2009 12:13 AM >=20 > (I'm envisioning a world in which the UAC's end may be involved in > complex service provisioning in which there may be more than one transit > network and more than one element that provides complex call routing. > Though a transit network should be able to hide its internal structure, > the UAC has the right to know what element the transit network delivered > the request to, since that is what the UAC is paying the transit network > to do.) IMO the UAC has no right to know any such thing. It has no rights - it's n= ot a human. The calling human has a right to know the far-end called human= it got delivered to. But they don't care nor have a right to know the *ho= st* element it got delivered to, or host elements it forked to but did not = succeed at, etc. It's none of their business, frankly. And if we're thinking the far-end terminating Enterprise or provider will w= ant to tell some originating Enterprise or provider what's going on inside = their network, well... once again we all live in different worlds. :) -hadriel=20 From web-usrn@ISI.EDU Wed Mar 25 03:47:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267333A6BDB for ; Wed, 25 Mar 2009 03:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.216 X-Spam-Level: X-Spam-Status: No, score=-17.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdQQORiZf-Ii for ; Wed, 25 Mar 2009 03:47:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 305C43A67FB for ; Wed, 25 Mar 2009 03:47:00 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2PAl1Df003689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2009 03:47:01 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2PAkxm7003686; Wed, 25 Mar 2009 03:46:59 -0700 (PDT) Date: Wed, 25 Mar 2009 03:46:59 -0700 (PDT) Message-Id: <200903251046.n2PAkxm7003686@boreas.isi.edu> To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, Gonzalo.Camarillo@ericsson.com, alan.johnston@wcom.com, jon.peterson@neustar.com, rsparks@dynamicsoft.com, mjh@icir.org, schooler@research.att.com, rjsparks@nostrum.com, jon.peterson@neustar.biz, fluffy@cisco.com, dean.willis@softarmor.com, drage@alcatel-lucent.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: jainp1979@gmail.com, sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] [Technical Errata Reported] RFC3261 (1742) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 10:47:02 -0000 The following errata report has been submitted for RFC3261, "SIP: Session Initiation Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=1742 -------------------------------------- Type: Technical Reported by: Pankaj Jain Section: 17.1.1.2 Original Text ------------- Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used. Corrected Text -------------- Timer D reflects the amount of time that the client transaction can remain in the "Completed" state when unreliable transports are used. Notes ----- server transaction => client transaction 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. -------------------------------------- RFC3261 (draft-ietf-sip-rfc2543bis-09) -------------------------------------- Title : SIP: Session Initiation Protocol Publication Date : June 2002 Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler Category : PROPOSED STANDARD Source : Session Initiation Protocol Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From pkyzivat@cisco.com Wed Mar 25 06:44:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB2A3A68AB for ; Wed, 25 Mar 2009 06:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQTG7-eIArDA for ; Wed, 25 Mar 2009 06:44:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AB89A3A6774 for ; Wed, 25 Mar 2009 06:44:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,419,1233532800"; d="scan'208";a="146389569" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2009 13:45:04 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2PDj4ua029005; Wed, 25 Mar 2009 06:45:04 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PDj2U1010733; Wed, 25 Mar 2009 13:45:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 09:45:03 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 09:45:02 -0400 Message-ID: <49CA355F.4040100@cisco.com> Date: Wed, 25 Mar 2009 09:45:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dale Worley References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 13:45:02.0608 (UTC) FILETIME=[E5CB0900:01C9AD4F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2987; t=1237988704; x=1238852704; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Is=20REFER=20within=20dialog=20 part=20of=20INVITE=20or=09subscription=09usage?=0A=20(was=20 RE=3A=20SIP=20INFO) |Sender:=20; bh=lXdtYD7Br4JyMwTPLuXxLpOsHreMPlI4ItgZHst3llg=; b=u7KcISe7u/6bRexc1m5JRkdwdA9NG1fKXkkc4S0cQ34ikEBUrtBKacksxd i52OwHk9fpD7c8xm5g11tHlOLfJRP7ntiuJZgHXS5xQxrtno1APXUSS87p+P l4sdI4Xf4c; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 13:44:13 -0000 Dale Worley wrote: >>> And it seems quite safe that if the REFER receives a 481 response, the >>> INVITE usage must not be functional any more, since the far end of that >>> usage has denied that it can act on the REFER. >> IIRC, 5057 decided that each dialog usage must get its own 481 before it >> goes away. I don't think there are any cases where a single 481 response >> can make multiple usages go away. >> >> So the important question is whether the REFER is part of the INVITE >> usage and so its 481 takes down the INVITE usage or not. That gets >> especially interesting if the dialog already had both an INVITE usage >> and a SUBSCRIBE usage. Does it make sense that the refer take down the >> INVITE usage and leave up the SUBSCRIBE usage? > > I think we're a victim of sloppy terminology here. If I send a REFER, > and the far end responds 481, then clearly the far end knows of no > INVITE usage, or otherwise it would not have responded 481. This is not "clear". There are (at least) two alternatives, depending on whether the recipient believes the REFER to be part of an INVITE usage or not. If it believes that it must be part of an INVITE usage (in the sense that BYE is known to be part of an INVITE usage), then the 481 response can mean that there is no INVITE usage, even though there is an existing matching dialog without an invite usage. If the recipient believes that the REFER is *not* part of any usage, then there can still be a 481 response, indicating that that there is no matching dialog. This is why its important to agree whether the REFER is to be considered part of an INVITE usage. > So I should > delete my belief that there is an INVITE usage. Whether we consider the > REFER in question to be "part of" the INVITE usage or not doesn't change > anything -- the 481 is evidence that the far end has no knowledge of the > usage. > > However, we do have this fine paradox: If we assume that a REFER within > an established dialog that has no INVITE usage is to be treated as an > out-of-dialog REFER, then *no* REFER will receive a 481 response! I disagree here. If the message is sent with dialog id info (notably, a To-tag in addition to a From-tag and Call-ID) then it should (or at least may) get a 481 response if there is no such matching dialog at the recipient. This is true even if the message is then to be treated as an out-of-dialog message. > Indeed, if I send a REFER thinking that there is an active INVITE usage, > but the far end believes the INVITE usage has ended, will cause the far > end to do something (initiate an independent dialog) that is > considerably different from what I expected (transfer the current INVITE > usage). That is why dialog matching should still be done. I have no business inventing a To-tag for you. It has to be *your* To-tag. If you don't recognize it then you send me a 481. Thanks, Paul From jiri@iptel.org Wed Mar 25 07:03:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B693A69F9 for ; Wed, 25 Mar 2009 07:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Arp4nu5ZMJJC for ; Wed, 25 Mar 2009 07:03:44 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id DD5783A693E for ; Wed, 25 Mar 2009 07:03:43 -0700 (PDT) Received: from dhcp-46c3.meeting.ietf.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 0EDB21811CD5; Wed, 25 Mar 2009 15:04:32 +0100 (CET) Message-ID: <49CA39F0.1010303@iptel.org> Date: Wed, 25 Mar 2009 15:04:32 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jonathan Rosenberg References: <49AE593F.6080807@iptel.org> <49BBA27C.4050805@cisco.com> In-Reply-To: <49BBA27C.4050805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] draft-state-sip-relay-attack-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:03:45 -0000 Jonathan Rosenberg wrote: > Rafael and others, > > Thanks for putting this together. > > Considering for a moment figure 1, this attack is possible only if UAs > accept incoming requests from any place, and not just their proxy. In > practice, this is seldom allowed. Hi Jonathan, I see two things with this argument: first being a practical, the other normative. on contrary to what you have observed, in the SIP deployments I'm aware of the SIP UA accept SIP from everywhere. That I consider a poor practice, but it seems to be the case. (perhaps a differnet market segment experience?) It has been also utilized in the DE attack last year -- attacker sent SIP packets directly to UAs. www.ipcom.at/fileadmin/public/2008-10-22_Analysis_of_a_VoIP_Attack.pdf I should be in position to do a live measurement of a quite SIP-UA-wise heterogenous SIP service, should we need more accurate field intelligence. The normative argument is that a SIP UA must be prepared to receive traffic for a dialog setup by an RFC3261 proxy, which has no obligation to record-route, and the traffic can therefore come from anywhere. Unless we standardize that the UAs are behind NATs, deprecate record-routing as optional or more seriously document BCPs (don't talk with strangers), a SIP-compliant UA is an open invitation for unsolicited traffic. I'm under impression that folks in this threads feel easy about the problem because they have all sorts of workarounds -- these however do not rely on any sort of normative reference and seem thus rather brittle. Possibly addressing some of these practices in a BCP could help to sort out some of that. Actually some ITSPs I know have been privately approaching their UA vendors and felt they have never made progress because there was no reference for such behaviour. -jiri > Indeed, if it is allowed, there are > worse attacks than this which can be launched (free phone calls, spam > calling, etc.). Using the SIP recommended TLS between UA and proxy also > mitigates that. > > So really figure 2 is the interesting one. However, this attack assumes > that Alice has credentials on multiple systems. Again, in practice, this > is extremely uncommon. Certainly none of the existing deployed > enterprise or service provider consumer deployments are of this nature. > > As such, I dont think this attack is likely in practice. However, in > theory it is possible. The essence of the attack is that the victim is > providing credentials to an unauthenticated server (since the attacker > is acting like a server, asking for credentials). In that way, as others > have pointed out, it is similar to baiting attacks that have been > previously documented. With SIP it is most easily remedied by a rule > which says, 'don't pass credentials for domain X to a server that is not > domain X'. Server identity can be verified by normal server-only auth > between a client and its server, but even that is not needed. A client > will know which domain its proxy is representing, and once connected, it > only provides credentials for that domain. > > -Jonathan R. > > > Raphael Coeffic wrote: >> Hello, >> >> a new internet draft has been published concerning the relay attack on >> digest authentication and SIP. The attack itself has been first >> disclosed 2 years ago by the maydnes team from the french INRIA. Until >> now, no document has been pushlished that documents the attack and >> provides guidance to SIP operators or handset manufacturers. >> >> http://tools.ietf.org/html/draft-state-sip-relay-attack-00 >> >> The appropriate mitigations of problem resolutions are still not 100% >> clear. We hope that this draft can help start a discussion on how to >> best resolve this problem. >> >> >> Regards, >> >> Raphael Coeffic. >> (on behalf of all the authors of this draft) >> >> --------------------------------------------------------------------------------------------------- >> >> >> Filename: draft-state-sip-relay-attack >> Version: 00 >> Staging URL: >> http://www3.ietf.org/proceedings/staging/draft-state-sip-relay-attack-00.txt >> >> Title: SIP digest authentication relay attack >> Creation_date: 2009-03-02 >> WG ID: Indvidual Submission >> Number_of_pages: 18 >> Abstract: >> The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism >> for creating, modifying, and terminating sessions with one or more >> participants. This document describes a vulnerability of SIP >> combined with HTTP Digest Access Authentication [RFC2617] through >> which an attacker can leverage the victim's credentials to send >> authenticated requests on his behalf. This attack is different from >> the man-in-the-middle (MITM) attack and does not require any >> eavesdropping, DNS or IP spoofing. >> >> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > From pkyzivat@cisco.com Wed Mar 25 07:05:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C913A6A78 for ; Wed, 25 Mar 2009 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5VdcdlZAHtl for ; Wed, 25 Mar 2009 07:05:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 713D03A6A42 for ; Wed, 25 Mar 2009 07:05:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,419,1233532800"; d="scan'208";a="146399645" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2009 14:06:11 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2PE6BR7007693; Wed, 25 Mar 2009 10:06:11 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2PE6BJl009473; Wed, 25 Mar 2009 14:06:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 10:06:11 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 10:06:10 -0400 Message-ID: <49CA3A52.8050903@cisco.com> Date: Wed, 25 Mar 2009 10:06:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: aayush bhatnagar References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 14:06:10.0678 (UTC) FILETIME=[D99F2960:01C9AD52] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7220; t=1237989971; x=1238853971; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Is=20REFER=20within=20dialog=20 part=20of=20INVITE=20or=20subscription=09usage?=0A=20(was=20 RE=3A=20SIP=20INFO) |Sender:=20 |To:=20aayush=20bhatnagar=20; bh=9lVwNl3RK0ZYVREih47MoDRpn5zNGm+k0682CGOO598=; b=rXBitnagOfy+2QTGo92Gi9a2Fmna0EdVJy2V8dPAm+YGU2XP4rFU2vqYBY fDiPwjKGlh0GQoveosYJdGuuXrdCwNXcUziPiPI1GqwTJDqFWDpWyCZeijxB ux9rjBBWbR; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:05:20 -0000 aayush bhatnagar wrote: > If you send an in dialog request (REFER in our case), then you cannot > decouple its semantics with the existing dialog usage. You say "*the* dialog usage" as if there can be only one. There could be more than one. It might be coupled to: - the *only* existing usage - to *one* of several existing usages - to *none* of the one or more existing usages For instance, I could have a dialog with just an INVITE usage (the common case) and within that dialog send a REFER of a MESSAGE. That MESSAGE really has nothing to do with the INVITE usage. > So saying that > even if i send a REFER within an existing dialog, and still decouple > it from the existing dialog usage will not be possible. > If there were such a requirement, then REFER should have been sent as > a standalone dialog creating request outside the INVITE usage. One can argue that it *should* have been. But that isn't the point of this discussion. In many cases using the same dialog as been an expedient to ensure reaching the same UA when you aren't sure the remote target url for the dialog is in fact routable. > The recipient of the in dialog REFER will treat it like it should any > in dialog request. It has no way to decide if this request potentially > had nothing to do with the existing dialog usage. You are being sloppy in your use of "dialog" and "dialog usage", as if you are not familiar with RFC 5057. If you aren't, please read it. > i agree with you when you say that an indialog refer receiving a 481 > would mean that the INVITE dialog has been torn down. See my reply to Dale. > However, a refer dialog usage can also terminate, if the UAC sends a > 481 in response to the NOTIFY sent by the UAS (Suppose the transaction > did not match). You need to spell out more details of the case. If it were the *first* NOTIFY, resulting from an in-dialog REFER, then that response would be indicative of a screwup somewhere. However, if there had been a prior NOTIFY on the refer subscription that indicated that the subscription was over, and then somehow *another* NOTIFY was sent, the 481 would be appropriate, indicating that the refer-usage was no longer present. > This scenario may happen irrespective of whether the > REFER was within the invite usage or created its own distinct dialog. > If this happens when REFER was sent within an Invite dialog, then the > UAC will be mistaken to clean up its INVITE dialog state. Go read 5057. The usages are to be handled separately. So this should *not* provoke the UAC to clean up its INVITE dialog usage. > I did not understand one part in the paradox above when you said... > "A REFER within an established dialog having no invite usage to be > considered as an out of dialog REFER" > Do you mean to imply a REFER in some other Subscribe event package > dialog for example? Yes, that is what I meant. I don't have any meaningful cases in mind, but it is a theoretical possibility. Paul > aayush. > > On 3/25/09, Dale Worley wrote: >> On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote: >>>> I would argue that the REFER is part of the INVITE usage, because REFER >>>> in that context is intimately related to the INVITE usage -- it is >>>> intended to transfer the INVITE usage/dialog transferred to a different >>>> destination. >>> Well, I guess there is that implied association. (Part of the "do what >>> *I* had in mind" approach that REFER has.) Since this was never spelled >>> out, it could also be simply "while this isn't part of an INVITE usage, >>> if there happens to be an INVITE usage, please refer that one." >>> >>> I guess the question is: would it be valid to send a REFER within an >>> existing dialog that had no INVITE usage? If it were valid, presumably >>> it would have the same meaning as sending one outside a dialog, except >>> that the resulting subscription would share the dialog. I expect that is >>> a usage it would be difficult to find in the wild. >> That's a nice pathological case. But within the context of the current >> 5 possible meanings of REFER, it seems to be most parallel to the >> out-of-dialog REFER. >> >>> Ah, but now I want to reconsider. Remember that REFER can take a method >>> name. So, rather than referring an INVITE, I could be referring MESSAGE, >>> OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the >>> association to the INVITE usage is probably meaningless. (Of course its >>> meaningful for BYE.) >> A fascinating possibility! But I'm not sure that we've ever defined how >> a REFER within a simple INVITE dialog, specifying a non-INVITE method >> should act. So there's no analog to follow. >> >>>> And it seems quite safe that if the REFER receives a 481 response, the >>>> INVITE usage must not be functional any more, since the far end of that >>>> usage has denied that it can act on the REFER. >>> IIRC, 5057 decided that each dialog usage must get its own 481 before it >>> goes away. I don't think there are any cases where a single 481 response >>> can make multiple usages go away. >>> >>> So the important question is whether the REFER is part of the INVITE >>> usage and so its 481 takes down the INVITE usage or not. That gets >>> especially interesting if the dialog already had both an INVITE usage >>> and a SUBSCRIBE usage. Does it make sense that the refer take down the >>> INVITE usage and leave up the SUBSCRIBE usage? >> I think we're a victim of sloppy terminology here. If I send a REFER, >> and the far end responds 481, then clearly the far end knows of no >> INVITE usage, or otherwise it would not have responded 481. So I should >> delete my belief that there is an INVITE usage. Whether we consider the >> REFER in question to be "part of" the INVITE usage or not doesn't change >> anything -- the 481 is evidence that the far end has no knowledge of the >> usage. >> >> However, we do have this fine paradox: If we assume that a REFER within >> an established dialog that has no INVITE usage is to be treated as an >> out-of-dialog REFER, then *no* REFER will receive a 481 response! >> Indeed, if I send a REFER thinking that there is an active INVITE usage, >> but the far end believes the INVITE usage has ended, will cause the far >> end to do something (initiate an independent dialog) that is >> considerably different from what I expected (transfer the current INVITE >> usage). >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From pkyzivat@cisco.com Wed Mar 25 08:09:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D27A3A69E0 for ; Wed, 25 Mar 2009 08:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOaFRHBu5n4I for ; Wed, 25 Mar 2009 08:08:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 371A53A6802 for ; Wed, 25 Mar 2009 08:08:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,419,1233532800"; d="scan'208";a="146426825" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2009 15:09:51 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2PF9pvs024320; Wed, 25 Mar 2009 08:09:51 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PF9onP019681; Wed, 25 Mar 2009 15:09:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 11:09:50 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 11:09:50 -0400 Message-ID: <49CA493F.6020600@cisco.com> Date: Wed, 25 Mar 2009 11:09:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hadriel Kaplan References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> <1237954380.22543.20.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 15:09:50.0388 (UTC) FILETIME=[BE58A740:01C9AD5B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1715; t=1237993791; x=1238857791; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20SIP=20Tracing=20Facility |Sender:=20; bh=DedCEf4DoYLWMQN50Vh1bkF0pUY5hxjjT7QJzbAVEuI=; b=MmqLAM1eXvnambIL8+Y+uu3sSWt+yc3fegbOQLXcsj+ZVu2w0br+GP5Msk V7XKMO0JKq4H1zgQ/mre75wXdzTrhjm5UYe5Bg1ebTsG8NB3V48+SM5zNapF PzIhxEnRhG; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIP Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:09:00 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Dale Worley [mailto:dworley@nortel.com] >> Sent: Wednesday, March 25, 2009 12:13 AM >> >> (I'm envisioning a world in which the UAC's end may be involved in >> complex service provisioning in which there may be more than one transit >> network and more than one element that provides complex call routing. >> Though a transit network should be able to hide its internal structure, >> the UAC has the right to know what element the transit network delivered >> the request to, since that is what the UAC is paying the transit network >> to do.) > > IMO the UAC has no right to know any such thing. It has no rights - it's not a human. The calling human has a right to know the far-end called human it got delivered to. But they don't care nor have a right to know the *host* element it got delivered to, or host elements it forked to but did not succeed at, etc. It's none of their business, frankly. > > And if we're thinking the far-end terminating Enterprise or provider will want to tell some originating Enterprise or provider what's going on inside their network, well... once again we all live in different worlds. :) I think Dale's point is that it should not be the business of the transit network to prevent the UAC from learning things about the path after it leaves the transit network. If the UAS network doesn't want that divulged, then fine. But if it is willing to have it divulged, then that should be fine too. A really good example of that is when the UAC and UAS networks are branches of the same organization, that use a sip service provider for their interconnect. Thanks, Paul From atle.monrad@stericsson.com Tue Mar 24 02:56:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174863A6CD1 for ; Tue, 24 Mar 2009 02:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJl5immDcp0G for ; Tue, 24 Mar 2009 02:56:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8870928C18E for ; Tue, 24 Mar 2009 02:56:51 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F008D20BA4 for ; Tue, 24 Mar 2009 10:57:40 +0100 (CET) X-AuditID: c1b4fb3c-adf5fbb000003f6e-35-49c8ae947a57 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 81B7720DA3 for ; Tue, 24 Mar 2009 10:57:40 +0100 (CET) Received: from eseldmw101.eemea.ericsson.se ([136.225.228.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:57:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 10:57:27 +0100 Message-ID: <61D8D34BB13CFE408D154529C120E079027F77BD@eseldmw101.eemea.ericsson.se> In-Reply-To: <49C3743F.1070406@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Policy to register media feature tags Thread-Index: AcmpSVcxGKjQ4YTnRdyt/4kgaUQNuACuh0pw References: <49C3743F.1070406@ericsson.com> From: "Atle Monrad" To: "Gonzalo Camarillo" , "sip" X-OriginalArrivalTime: 24 Mar 2009 09:57:27.0324 (UTC) FILETIME=[F0324DC0:01C9AC66] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 25 Mar 2009 08:15:14 -0700 Subject: Re: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 10:21:36 -0000 Hello=20 To use one registration policy for all kind of feature tags may be a "one size fits all" policy that in my view can lead to unnecessary bottlenecks and delays. Personally I find it useful how RFC 2506 describe various mechanisms for registration of feature tags, and think the current approach where a feature tag can be specified within one organization and subsequently registered by IANA works well and is a useful approach. At least it worked well for the first tags...=20 Similar ergistration is also performed for other parameters from IANA, and 3GPP has also "registration procedures" with other organizations as GSMA, TISPAN and OMA for various other parameters as well. In some cases the registration is made by 3GPP and in some cases the registration is made by other organisations. Who act as registrar depends on who "owns" the basic functionality of the parameter. Technical discussions are often held to find a solution, but when the technical discussions are held and a solution is chosen, the registration process is done to register and not to re-open the discussion.=20 3GPP has three feature tags described in 3GPP specifications and registered in the global tree and three more feature tags described in 3GPP specifications waiting for similar registrations by IANA. It might be useful to distinguish between the possible need for changing the process for registration of future tags and performing registration of tags that are in operation only missing the formal registration. I would assume that the current process is in operation until a new registration policy is available and agreed. Regards Atle Monrad=20 3GPP CT1 Chairman ______ Atle Monrad Standardisation ST-Ericsson Product Group Mobile Platforms =20 Televeien 1 N-4820, Grimstad Norway www.stericsson.com =20 Office: +47 37 29 30 40 Mobile: +47 45 41 06 65 Fax: +47 37 04 23 70 Email: atle.monrad@stericsson.com =09 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Gonzalo Camarillo Sent: 20. mars 2009 11:47 To: sip Subject: [Sip] Policy to register media feature tags Folks, as you know, RFC 3840 specifies how to indicate UA's capabilities using media feature tags. Section 12.1 of RFC 3840 creates the SIP Media Feature Tag Registration Tree. Media feature tags applicable to SIP are registered in this tree. http://www.ietf.org/rfc/rfc3840.txt RFC 2506 defines the global tree to register feature tags. Section 3.1.2 of RFC 2506 says: "A registration may be proposed for the global tree by anyone who has the need to allow for communication on a particular capability or preference". http://www.ietf.org/rfc/rfc2506.txt The currently registered feature tags in both the SIP and the global trees can be found at: http://www.iana.org/assignments/media-feature-tags As you can see, the only three feature tags registered in the global tree come from 3GPP. The issue we are facing is that the SIP and the global trees have different registration policies. The SIP registry requires an RFC defining the feature tag while the global tree only requires an expert review. Now, 3GPP would like to register two new feature tags: g.3gpp.icsi-ref, g.3gpp.iari-ref This is the description of how these feature tags will be used: "Each value of the Application Reference media feature-tag indicates the software applications supported by the agent. The values for this tag equal the IMS communication Service Identifier (ICSI) and IMS Application Reference Identifier (IARI) values supported by the agent. The Application Reference media feature tag is defined to fulfil the requirements for forking to an appropriate UE when multiple UEs are registered and dispatch to an appropriate application within the UE based upon the IMS communication Service Identifier (ICSI) and IMS Application Reference Identifier (IARI) values as stated in 3GPP TS 23.228. Multiple tag-values can be included in the Application Reference media feature-tag." The expert reviewer indicated that this tags will not contain simple features but rather more complex services, or feature sets, or application logic (pick your favorite term). Therefore, he did not find it appropriate to register them in the global tree. He suggested that RFC 2506 is amended so that it covers this type of more complex features. However, before going down that path, I would like to get comments from the SIP community. The underlying issue is that we need to decide which policy we want to apply to these types of registrations in SIP. 1) We decide that an RFC is always needed. Then, we can just use the SIP registry. We would probably need to clarify or to stress somewhere that the global tree is not appropriate for SIP tags. 2) We decide that an expert review is good enough. Then we would probably need to amend RFC 2506 or RFC 3840 to reflect this. Comments are welcome. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From atle.monrad@stericsson.com Tue Mar 24 03:35:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89E83A6981 for ; Tue, 24 Mar 2009 03:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2mvQcWwx1oM for ; Tue, 24 Mar 2009 03:35:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E03CC3A6CCE for ; Tue, 24 Mar 2009 03:35:51 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 42CD820599; Tue, 24 Mar 2009 11:36:41 +0100 (CET) X-AuditID: c1b4fb3e-aefbbbb000006d6d-bf-49c8b7b952c1 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 229E120514; Tue, 24 Mar 2009 11:36:41 +0100 (CET) Received: from eseldmw101.eemea.ericsson.se ([136.225.228.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 11:36:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 11:36:39 +0100 Message-ID: <61D8D34BB13CFE408D154529C120E079027F77F4@eseldmw101.eemea.ericsson.se> In-Reply-To: <49C39D1C.1040701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Policy to register media feature tags Thread-Index: AcmpYaazf0zUZJexQ8izOAU7LBpYNgDA7cpg References: <49C3743F.1070406@ericsson.com> <49C39D1C.1040701@cisco.com> From: "Atle Monrad" To: "Paul Kyzivat" , "Gonzalo Camarillo" X-OriginalArrivalTime: 24 Mar 2009 10:36:40.0530 (UTC) FILETIME=[6AD10B20:01C9AC6C] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 25 Mar 2009 08:15:24 -0700 Cc: sip Subject: Re: [Sip] Policy to register media feature tags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 10:35:53 -0000 Paul=20 For you information, the tags that 3gpp have specified and registered are described in publicly available 3GPP specifications which are referenced from the IANA registration. The same apply for the three tags that are in the pipeline. The reason for this is to secure openness and operability for vendors that want to support certain 3gpp-specific capabilities. 3GPP would like to get all tags registered by IANA in order to secure that the tags are public and thereby the reference to the specifications where this particular 3GPP-functionality is specified is publicly available.=20 To communicate these tags e-2-e is needed to support certain 3gpp-capabilities, and I do not really see the linkage towards you statement "On the other side were those who prefer to associate arbitrary names to collections of features and then negotiate on the basis of the names of those collections." Hope this clarifies Regards /atle ______ Atle Monrad Standardisation ST-Ericsson Product Group Mobile Platforms =20 Televeien 1 N-4820, Grimstad Norway www.stericsson.com =20 Office: +47 37 29 30 40 Mobile: +47 45 41 06 65 Fax: +47 37 04 23 70 Email: atle.monrad@stericsson.com =09 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 20. mars 2009 14:42 To: Gonzalo Camarillo Cc: sip Subject: Re: [Sip] Policy to register media feature tags Some issues just never go away. :-( This seems to be a resurection of issues that first surfaced during the initial discussions of extended presence status many years ago. And it also harks back to discussions last year or the year before about communication service identifiers and application service identifiers. The problem is one of openness. Specifically, do you have to be "part of the club" in order to properly interoperate with a device that uses these identifiers to identify its preferences or capabilities. On one side were those who wanted capabilities and preferences to be stated in terms of feature tags that are well known and orthogonal. On the other side were those who prefer to associate arbitrary names to collections of features and then negotiate on the basis of the names of those collections. Using the latter approach its possible that interoperation will fail because the parties don't share a common name for a collection of features even though they both possess the necessary features to interoperate. I don't have a problem with independent groups defining new feature tags, as long as they are primitive and orthogonal to existing ones. But I do have a problem with defining feature tags that identify collections of features, especially when the mapping from the identifier to the collection of features is not public. The bottom line is that I think this sort of thing needs to be thrashed out within the sip community. So I think the RFC process is the right process. Thanks, Paul Gonzalo Camarillo wrote: > Folks, >=20 > as you know, RFC 3840 specifies how to indicate UA's capabilities=20 > using media feature tags. Section 12.1 of RFC 3840 creates the SIP=20 > Media Feature Tag Registration Tree. Media feature tags applicable to=20 > SIP are registered in this tree. >=20 > http://www.ietf.org/rfc/rfc3840.txt >=20 > RFC 2506 defines the global tree to register feature tags. Section=20 > 3.1.2 of RFC 2506 says: "A registration may be proposed for the global > tree by anyone who has the need to allow for communication on a=20 > particular capability or preference". >=20 > http://www.ietf.org/rfc/rfc2506.txt >=20 > The currently registered feature tags in both the SIP and the global=20 > trees can be found at: >=20 > http://www.iana.org/assignments/media-feature-tags >=20 > As you can see, the only three feature tags registered in the global=20 > tree come from 3GPP. >=20 > The issue we are facing is that the SIP and the global trees have=20 > different registration policies. The SIP registry requires an RFC=20 > defining the feature tag while the global tree only requires an expert > review. >=20 > Now, 3GPP would like to register two new feature tags: =20 > g.3gpp.icsi-ref, g.3gpp.iari-ref >=20 > This is the description of how these feature tags will be used: >=20 > "Each value of the Application Reference media feature-tag indicates=20 > the software applications supported by the agent. The values for this=20 > tag equal the IMS communication Service Identifier (ICSI) and IMS=20 > Application Reference Identifier (IARI) values supported by the agent. > The Application Reference media feature tag is defined to fulfil the=20 > requirements for forking to an appropriate UE when multiple UEs are=20 > registered and dispatch to an appropriate application within the UE=20 > based upon the IMS communication Service Identifier > (ICSI) and IMS Application Reference Identifier (IARI) values as=20 > stated in 3GPP TS 23.228. Multiple tag-values can be included in the=20 > Application Reference media feature-tag." >=20 >=20 > The expert reviewer indicated that this tags will not contain simple=20 > features but rather more complex services, or feature sets, or=20 > application logic (pick your favorite term). Therefore, he did not=20 > find it appropriate to register them in the global tree. He suggested=20 > that RFC 2506 is amended so that it covers this type of more complex features. >=20 > However, before going down that path, I would like to get comments=20 > from the SIP community. The underlying issue is that we need to decide > which policy we want to apply to these types of registrations in SIP. >=20 > 1) We decide that an RFC is always needed. Then, we can just use the=20 > SIP registry. We would probably need to clarify or to stress somewhere > that the global tree is not appropriate for SIP tags. >=20 > 2) We decide that an expert review is good enough. Then we would=20 > probably need to amend RFC 2506 or RFC 3840 to reflect this. >=20 > Comments are welcome. >=20 > Thanks, >=20 > Gonzalo >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From vkg@alcatel-lucent.com Wed Mar 25 08:37:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38ED528C206 for ; Wed, 25 Mar 2009 08:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LTILPXx8oxg for ; Wed, 25 Mar 2009 08:37:23 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 2D16628C1D6 for ; Wed, 25 Mar 2009 08:37:23 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n2PFcEZJ016595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 10:38:14 -0500 (CDT) Received: from shoonya.ih.lucent.com (guard.research.bell-labs.com [135.104.2.10]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n2PFcDSf028819; Wed, 25 Mar 2009 10:38:13 -0500 (CDT) Message-ID: <49CA4FE6.2030608@alcatel-lucent.com> Date: Wed, 25 Mar 2009 10:38:14 -0500 From: Vijay Gurbani User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dale Worley References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> <1237953863.22543.10.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1237953863.22543.10.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: SIP IETF Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:37:24 -0000 Dale Worley wrote: > Not really, because log files slice the universe of data the wrong way. Not as much wrong as different; i.e., log files slice the universe of data a different way. > A log file tells everything that happens at a particular element, almost > all of which is irrelevant regarding a particular transaction. Depends. If that element is misbehaving -- either through flawed source code or because of external influences -- the state of a transaction preserved in a log file from the point of that element is of extreme interest for analysis. However, as you note, log files do not help in dynamic tracing of the transaction across a set of elements. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs From abhatnagar192006@gmail.com Wed Mar 25 09:21:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E5A3A6C0B for ; Wed, 25 Mar 2009 09:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UNSUB31=0.464] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxB8WQVSJIZh for ; Wed, 25 Mar 2009 09:21:20 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id B3F1C3A67D1 for ; Wed, 25 Mar 2009 09:21:19 -0700 (PDT) Received: by qyk36 with SMTP id 36so234152qyk.29 for ; Wed, 25 Mar 2009 09:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=HtK/RGrRnJUN5QRmo1K9QM/exu0YjauqnCdfS13VjeQ=; b=c5RBljcveLiln312lzzf3+HJovygJ9veTxnq9/Jy53GPSFbBaciCY6ae9ifREReFn/ aeG/IquIRk9XnM4zWIUZU/kP4lT37I1OK5L1uOHte2ynOB+mBqE/40/mDsOmMi/fP1N0 hs4QqOQYhXTWSXfI1KXOyWHaFscykOFU/Aul8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e9nWfD0MfHEIiChqb6itKSOmlSm6aXJJlF31ypvhYF9jdktvxluadIBWjZQPkegZHf gxTTQwrqqx+dkhYe0I2v0J2B7RrbP10rqmKOGQAPPFM8aldcMVSUh1A0vIu8zb+/0lfN FaKx4K0trIRQOPi3BuMh20Kc3IxcneoHczbYA= MIME-Version: 1.0 Received: by 10.142.157.6 with SMTP id f6mr3981517wfe.248.1237998131006; Wed, 25 Mar 2009 09:22:11 -0700 (PDT) In-Reply-To: <49CA3A52.8050903@cisco.com> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> <49CA3A52.8050903@cisco.com> Date: Wed, 25 Mar 2009 21:52:10 +0530 Message-ID: From: aayush bhatnagar To: Paul Kyzivat Content-Type: multipart/alternative; boundary=000e0cd241fcd4cdd90465f3e678 Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:21:22 -0000 --000e0cd241fcd4cdd90465f3e678 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >Go read 5057. The usages are to be handled separately. So this should *not* provoke the UAC >to clean up its INVITE dialog usage. I have read the relevant RFC. From 5057: -Existing implementations that destroy all other usages in the dialog will continue to function as -they do now, except that peers following the recommendation will attempt to do things with the -other usages and this element will return 481s for each of them until they are all gone. I think it is more feasible to destroy the entire dialog, than keeping on to 'hung' state until all the dialog usages are all gone as suggested above. I am familiar with implementations that clean up dialog state when they get a 481-dialog does not exist response, even if there were other 'active' usages of that dialog. The reason being, that if an implementation cannot find a matching dialog as characterized by the local tag, remote tag, call-id, local and remote sequence nos etc and has rejected the request by a 481, there is no point in keeping the dialog state at the UAC. As for example, if you receive a 481 response for a REFER sent within the INVITE dialog, there is no point in keeping the REFER usage alive. You probably sent the REFER to transfer a call, which the server complains that the call itself does not exist (481). Moreover from 5057: -Processing multiple usages correctly is not completely understood. -What is understood is difficult to implement and is very likely to -lead to interoperability problems. The best way to avoid the trouble -that comes with such complexity is to avoid it altogether. -When designing new applications or features that use SIP dialogs, do -not require endpoints to construct multiple usages to participate in -the application or use the feature. This is very true. By defining multiple dialog usages, you are essentially extending the dialog state (as defined by 3261) by adding more attributes to it (such as subscription duration etc). I cant think of a practical use case, where a subscription that shared the invite dialog usage still needed to be preserved, even when the original INVITE dialog was no longer active. As for example a subscription to the 'conference' event package sent within the scope of an INVITE dialog. If i leave the conference by sending a BYE, and my subscription's duration is still valid for an hour...will i still keep on getting redundant SIP notifications for changes to the membership to that conference ? In the sense of 5057, the subscribe usage will be preserved until it expires, or until the UAC explicitly un-subscribes, or the conference server has to send me a final NOTIFY with my subsription-state = terminated. It is not important that 5057 is allowing us many theoretical possibilities by presenting multiple dialog usages. What is more important is what extra do we get by reusing a dialog, and how do implementations leverage upon such a possibility and create meaningful applications around it ? I would like to share some examples: 1. As for example an application that can practically leverage upon 5057 may send a SUBSCRIBE to the 'dialog' event package (rfc 4235) that reuses the INVITE dialog can be used for creating SIP call tracing applications. 2. Other Implementations may include automatic callback applications by this mechanism (ring back when my sip phone is idle) etc. 3. Yet another application may send me by pre-paid account balance after i disconnect my ongoing dialog, as it is subscribed to my dialog state. In all these example applications, the endpoint receiving the SUBSCRIBE will need to send a NOTIFY that re-uses its existing INVITE dialog (NOTIFY acting as a target refresh in the sense of 5057). Best Regards aayush On Wed, Mar 25, 2009 at 7:36 PM, Paul Kyzivat wrote: > > > aayush bhatnagar wrote: > >> If you send an in dialog request (REFER in our case), then you cannot >> decouple its semantics with the existing dialog usage. >> > > You say "*the* dialog usage" as if there can be only one. There could be > more than one. It might be coupled to: > - the *only* existing usage > - to *one* of several existing usages > - to *none* of the one or more existing usages > > For instance, I could have a dialog with just an INVITE usage (the common > case) and within that dialog send a REFER of a MESSAGE. That MESSAGE really > has nothing to do with the INVITE usage. > > So saying that >> even if i send a REFER within an existing dialog, and still decouple >> it from the existing dialog usage will not be possible. >> If there were such a requirement, then REFER should have been sent as >> a standalone dialog creating request outside the INVITE usage. >> > > One can argue that it *should* have been. But that isn't the point of this > discussion. In many cases using the same dialog as been an expedient to > ensure reaching the same UA when you aren't sure the remote target url for > the dialog is in fact routable. > > The recipient of the in dialog REFER will treat it like it should any >> in dialog request. It has no way to decide if this request potentially >> had nothing to do with the existing dialog usage. >> > > You are being sloppy in your use of "dialog" and "dialog usage", as if you > are not familiar with RFC 5057. If you aren't, please read it. > > i agree with you when you say that an indialog refer receiving a 481 >> would mean that the INVITE dialog has been torn down. >> > > See my reply to Dale. > > However, a refer dialog usage can also terminate, if the UAC sends a >> 481 in response to the NOTIFY sent by the UAS (Suppose the transaction >> did not match). >> > > You need to spell out more details of the case. If it were the *first* > NOTIFY, resulting from an in-dialog REFER, then that response would be > indicative of a screwup somewhere. > > However, if there had been a prior NOTIFY on the refer subscription that > indicated that the subscription was over, and then somehow *another* NOTIFY > was sent, the 481 would be appropriate, indicating that the refer-usage was > no longer present. > > This scenario may happen irrespective of whether the >> REFER was within the invite usage or created its own distinct dialog. >> If this happens when REFER was sent within an Invite dialog, then the >> UAC will be mistaken to clean up its INVITE dialog state. >> > > Go read 5057. The usages are to be handled separately. So this should *not* > provoke the UAC to clean up its INVITE dialog usage. > > I did not understand one part in the paradox above when you said... >> "A REFER within an established dialog having no invite usage to be >> considered as an out of dialog REFER" >> Do you mean to imply a REFER in some other Subscribe event package >> dialog for example? >> > > Yes, that is what I meant. I don't have any meaningful cases in mind, but > it is a theoretical possibility. > > Paul > > > aayush. >> >> On 3/25/09, Dale Worley wrote: >> >>> On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote: >>> >>>> I would argue that the REFER is part of the INVITE usage, because REFER >>>>> in that context is intimately related to the INVITE usage -- it is >>>>> intended to transfer the INVITE usage/dialog transferred to a different >>>>> destination. >>>>> >>>> Well, I guess there is that implied association. (Part of the "do what >>>> *I* had in mind" approach that REFER has.) Since this was never spelled >>>> out, it could also be simply "while this isn't part of an INVITE usage, >>>> if there happens to be an INVITE usage, please refer that one." >>>> >>>> I guess the question is: would it be valid to send a REFER within an >>>> existing dialog that had no INVITE usage? If it were valid, presumably >>>> it would have the same meaning as sending one outside a dialog, except >>>> that the resulting subscription would share the dialog. I expect that is >>>> a usage it would be difficult to find in the wild. >>>> >>> That's a nice pathological case. But within the context of the current >>> 5 possible meanings of REFER, it seems to be most parallel to the >>> out-of-dialog REFER. >>> >>> Ah, but now I want to reconsider. Remember that REFER can take a method >>>> name. So, rather than referring an INVITE, I could be referring MESSAGE, >>>> OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the >>>> association to the INVITE usage is probably meaningless. (Of course its >>>> meaningful for BYE.) >>>> >>> A fascinating possibility! But I'm not sure that we've ever defined how >>> a REFER within a simple INVITE dialog, specifying a non-INVITE method >>> should act. So there's no analog to follow. >>> >>> And it seems quite safe that if the REFER receives a 481 response, the >>>>> INVITE usage must not be functional any more, since the far end of that >>>>> usage has denied that it can act on the REFER. >>>>> >>>> IIRC, 5057 decided that each dialog usage must get its own 481 before it >>>> goes away. I don't think there are any cases where a single 481 response >>>> can make multiple usages go away. >>>> >>>> So the important question is whether the REFER is part of the INVITE >>>> usage and so its 481 takes down the INVITE usage or not. That gets >>>> especially interesting if the dialog already had both an INVITE usage >>>> and a SUBSCRIBE usage. Does it make sense that the refer take down the >>>> INVITE usage and leave up the SUBSCRIBE usage? >>>> >>> I think we're a victim of sloppy terminology here. If I send a REFER, >>> and the far end responds 481, then clearly the far end knows of no >>> INVITE usage, or otherwise it would not have responded 481. So I should >>> delete my belief that there is an INVITE usage. Whether we consider the >>> REFER in question to be "part of" the INVITE usage or not doesn't change >>> anything -- the 481 is evidence that the far end has no knowledge of the >>> usage. >>> >>> However, we do have this fine paradox: If we assume that a REFER within >>> an established dialog that has no INVITE usage is to be treated as an >>> out-of-dialog REFER, then *no* REFER will receive a 481 response! >>> Indeed, if I send a REFER thinking that there is an active INVITE usage, >>> but the far end believes the INVITE usage has ended, will cause the far >>> end to do something (initiate an independent dialog) that is >>> considerably different from what I expected (transfer the current INVITE >>> usage). >>> >>> Dale >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> --000e0cd241fcd4cdd90465f3e678 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>Go = read 5057. The usages are to be handled separately. So this should *not* pr= ovoke the UAC >to clean up its INVITE dialog usage.

I have read the relevant RFC. From 5057:

-Existing implem= entations that destroy all other usages in the dialog will continue to func= tion as -they do now, except that peers following the recommendation will a= ttempt to do things with the -other usages and this element will return 481= s for each of them until they are all gone.

I think it is more feasible to destroy the entire dialo= g, than keeping on to 'hung' state until all the dialog usages are = all gone as suggested above. I am familiar with implementations that clean = up dialog state when they get a 481-dialog does not exist response, even if= there were other 'active' usages of that dialog.=A0

The reason being, that if an implementation cannot find= a matching dialog as characterized by the local tag, remote tag, call-id, = local and remote sequence nos etc and has rejected the request by a 481, th= ere is no point in keeping the dialog state at the UAC.

As for example, if you receive a 481 response for a REF= ER sent within the INVITE dialog, there is no point in keeping the REFER us= age alive. You probably sent the REFER to transfer a call, which the server= complains that the call itself does not exist (481).=A0

Moreover from 5057:

-Processin= g multiple usages correctly is not completely understood.
-What is= understood is difficult to implement and is very likely to
-lead to int= eroperability problems. The best way to avoid the trouble
-that comes with such complexity is to avoid it altogether.
-When design= ing new applications or features that use SIP dialogs, do
-not require e= ndpoints to construct multiple usages to participate in
-the application= or use the feature.

This is very true. By defining multiple dialog us= ages, you are essentially extending the dialog state (as defined by 3261) b= y adding more attributes to it (such as subscription duration etc). I cant = think of a practical use case, where a subscription that shared the invite = dialog usage still needed to be preserved, even when the original INVITE di= alog was no longer active.

As for example a subscription to the 'conference= 9; event package sent within the scope of an INVITE dialog. If i leave the = conference by sending a BYE, and my subscription's duration is still va= lid for an hour...will i still keep on getting redundant SIP notifications = for changes to the membership to that conference ? In the sense of 5057, th= e subscribe usage will be preserved until it expires, or until the UAC expl= icitly un-subscribes, or the conference server has to send me a final NOTIF= Y with my subsription-state =3D terminated.=A0

It is not important that 5057 is allowing us many theor= etical possibilities by presenting multiple dialog usages.=A0
What is more important is what extra do we get by reusing a dia= log, and how do implementations leverage upon such a possibility and create= meaningful applications around it ?

I would like to share some examples:

1. As for example an application that can practically leverage upon 5057 m= ay send a SUBSCRIBE to the 'dialog' event package (rfc 4235) that r= euses the INVITE dialog can be used for creating SIP call tracing applicati= ons.=A0

2. Other Implementations may include automatic callback= applications by this mechanism (ring back when my sip phone is idle) etc.<= /div>

3. Yet another application may send me by pre-paid= account balance after i disconnect my ongoing dialog, as it is subscribed = to my dialog state.

In all these example applications, the endpoint receivi= ng the SUBSCRIBE will need to send a NOTIFY that re-uses its existing INVIT= E dialog (NOTIFY acting as a target refresh in the sense of 5057).=A0

Best Regards

aayush
=

On Wed, Mar 25, 200= 9 at 7:36 PM, Paul Kyzivat <pkyzivat@cisco.com> wrote:


aayush bhatnagar wrote:
If you send an in dialog request (REFER in our case), then you cannot
decouple its semantics with the existing dialog usage.

You say "*the* dialog usage" as if there can be only one. There c= ould be more than one. It might be coupled to:
- the *only* existing usage
- to *one* of several existing usages
- to *none* of the one or more existing usages

For instance, I could have a dialog with just an INVITE usage (the common c= ase) and within that dialog send a REFER of a MESSAGE. That MESSAGE really = has nothing to do with the INVITE usage.


So saying that
even if i send a REFER within an existing dialog, and still decouple
it from the existing dialog usage will not be possible.
If there were such a requirement, then REFER should have been sent as
a standalone dialog creating request outside the INVITE usage.

One can argue that it *should* have been. But that isn't the point of t= his discussion. In many cases using the same dialog as been an expedient to= ensure reaching the same UA when you aren't sure the remote target url= for the dialog is in fact routable.


The recipient of the in dialog REFER will treat it like it should any
in dialog request. It has no way to decide if this request potentially
had nothing to do with the existing dialog usage.

You are being sloppy in your use of "dialog" and "dialog usa= ge", as if you are not familiar with RFC 5057. If you aren't, plea= se read it.


i agree with you when you say that an indialog refer receiving a 481
would mean that the INVITE dialog has been torn down.

See my reply to Dale.


However, a refer dialog usage can also terminate, if the UAC sends a
481 in response to the NOTIFY sent by the UAS (Suppose the transaction
did not match).

You need to spell out more details of the case. If it were the *first* NOTI= FY, resulting from an in-dialog REFER, then that response would be indicati= ve of a screwup somewhere.

However, if there had been a prior NOTIFY on the refer subscription that in= dicated that the subscription was over, and then somehow *another* NOTIFY w= as sent, the 481 would be appropriate, indicating that the refer-usage was = no longer present.


This scenario may happen irrespective of whether the
REFER was within the invite usage or created its own distinct dialog.
If this happens when REFER was sent within an Invite dialog, then the
UAC will be mistaken to clean up its INVITE dialog state.

Go read 5057. The usages are to be handled separately. So this should *not*= provoke the UAC to clean up its INVITE dialog usage.


I =A0did not understand one part in the paradox above when you said...
"A REFER within an established dialog having no invite usage to be
considered as an out of dialog REFER"
Do you mean to imply a REFER in some other Subscribe event package
dialog for example?

Yes, that is what I meant. I don't have any meaningful cases in mind, b= ut it is a theoretical possibility.

=A0 =A0 =A0 =A0Paul


aayush.

On 3/25/09, Dale Worley <dworley@nortel.com> wrote:
On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote:
I would argue that the REFER is part of the INVITE usage, because REFER
in that context is intimately related to the INVITE usage -- it is
intended to transfer the INVITE usage/dialog transferred to a different
destination.
Well, I guess there is that implied association. (Part of the "do what=
*I* had in mind" approach that REFER has.) Since this was never spelle= d
out, it could also be simply "while this isn't part of an INVITE u= sage,
if there happens to be an INVITE usage, please refer that one."

I guess the question is: would it be valid to send a REFER within an
existing dialog that had no INVITE usage? If it were valid, presumably
it would have the same meaning as sending one outside a dialog, except
that the resulting subscription would share the dialog. I expect that is a usage it would be difficult to find in the wild.
That's a nice pathological case. =A0But within the context of the curre= nt
5 possible meanings of REFER, it seems to be most parallel to the
out-of-dialog REFER.

Ah, but now I want to reconsider. Remember that REFER can take a method
name. So, rather than referring an INVITE, I could be referring MESSAGE, OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the
association to the INVITE usage is probably meaningless. (Of course its
meaningful for BYE.)
A fascinating possibility! =A0But I'm not sure that we've ever defi= ned how
a REFER within a simple INVITE dialog, specifying a non-INVITE method
should act. =A0So there's no analog to follow.

And it seems quite safe that if the REFER receives a 481 response, the
INVITE usage must not be functional any more, since the far end of that
usage has denied that it can act on the REFER.
IIRC, 5057 decided that each dialog usage must get its own 481 before it goes away. I don't think there are any cases where a single 481 respons= e
can make multiple usages go away.

So the important question is whether the REFER is part of the INVITE
usage and so its 481 takes down the INVITE usage or not. That gets
especially interesting if =A0the dialog already had both an INVITE usage and a SUBSCRIBE usage. Does it make sense that the refer take down the
INVITE usage and leave up the SUBSCRIBE usage?
I think we're a victim of sloppy terminology here. =A0If I send a REFER= ,
and the far end responds 481, then clearly the far end knows of no
INVITE usage, or otherwise it would not have responded 481. =A0So I should<= br> delete my belief that there is an INVITE usage. =A0Whether we consider the<= br> REFER in question to be "part of" the INVITE usage or not doesn&#= 39;t change
anything -- the 481 is evidence that the far end has no knowledge of the usage.

However, we do have this fine paradox: =A0If we assume that a REFER within<= br> an established dialog that has no INVITE usage is to be treated as an
out-of-dialog REFER, then *no* REFER will receive a 481 response!
Indeed, if I send a REFER thinking that there is an active INVITE usage, but the far end believes the INVITE usage has ended, will cause the far
end to do something (initiate an independent dialog) that is
considerably different from what I expected (transfer the current INVITE usage).

Dale


_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use s= ip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org<= /a> for new developments on the application of sip

_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use s= ip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org<= /a> for new developments on the application of sip


--000e0cd241fcd4cdd90465f3e678-- From theo@crazygreek.co.uk Wed Mar 25 09:28:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD413A68F6 for ; Wed, 25 Mar 2009 09:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.938 X-Spam-Level: X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3KHEdIp0Zcy for ; Wed, 25 Mar 2009 09:28:12 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id 642D93A6BF8 for ; Wed, 25 Mar 2009 09:28:05 -0700 (PDT) Received: from source ([72.14.220.159]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKScpbydyVRnQ7g+e3al1VYPV/O9lmE240@postini.com; Wed, 25 Mar 2009 09:28:58 PDT Received: by fg-out-1718.google.com with SMTP id d23so60875fga.13 for ; Wed, 25 Mar 2009 09:28:57 -0700 (PDT) MIME-Version: 1.0 Sender: theo@crazygreek.co.uk Received: by 10.86.83.1 with SMTP id g1mr111431fgb.60.1237998537079; Wed, 25 Mar 2009 09:28:57 -0700 (PDT) In-Reply-To: <036C67C870DF4FA093CA6A614F24FEE4@china.huawei.com> References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> <49C8675E.9080501@iptel.org> <036C67C870DF4FA093CA6A614F24FEE4@china.huawei.com> Date: Wed, 25 Mar 2009 16:28:57 +0000 X-Google-Sender-Auth: 71118d018cc5f645 Message-ID: <167dfb9b0903250928v413dad7bwf26f8e1284e79727@mail.gmail.com> From: Theo Zourzouvillys To: Spencer Dawkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP , Dean Willis Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:28:13 -0000 On Wed, Mar 25, 2009 at 12:58 AM, Spencer Dawkins wrote: > (2) do we have enough people with enough clue to propose a SIPOps BOF? I was going to suggest exactly this, I just hadn't worked out the process for doing it yet :) I think it would be a great, great idea and would love to see more focus on operations in the same was an dns, ipv6 etc does, or even something less formal like the IEPG on sunday morning? recent statistics show SIP has a huge penetration on the *public* internet - way more than i think any of us did. ~ Theo From L.Liess@telekom.de Wed Mar 25 09:44:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8093A6D51 for ; Wed, 25 Mar 2009 09:44:54 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pxaiMEPP9BV for ; Wed, 25 Mar 2009 09:44:53 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 5D5203A6D57 for ; Wed, 25 Mar 2009 09:44:53 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 25 Mar 2009 17:45:43 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 17:45:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 17:45:41 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A002CA651B@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <167dfb9b0903250928v413dad7bwf26f8e1284e79727@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Diagnostic idea Thread-Index: AcmtZuN0hQ64w97YRFCRXkhEw6HpQAAAVrJA References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com><49C8675E.9080501@iptel.org><036C67C870DF4FA093CA6A614F24FEE4@china.huawei.com> <167dfb9b0903250928v413dad7bwf26f8e1284e79727@mail.gmail.com> From: To: , X-OriginalArrivalTime: 25 Mar 2009 16:45:43.0502 (UTC) FILETIME=[23782EE0:01C9AD69] Cc: sip@ietf.org, dean.willis@softarmor.com Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:44:54 -0000 It's a great idea.=20 Laura > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Theo Zourzouvillys > Sent: Wednesday, March 25, 2009 5:29 PM > To: Spencer Dawkins > Cc: SIP; Dean Willis > Subject: Re: [Sip] Diagnostic idea >=20 > On Wed, Mar 25, 2009 at 12:58 AM, Spencer Dawkins > wrote: > > (2) do we have enough people with enough clue to propose a=20 > SIPOps BOF? >=20 > I was going to suggest exactly this, I just hadn't worked out the > process for doing it yet :) >=20 > I think it would be a great, great idea and would love to see more > focus on operations in the same was an dns, ipv6 etc does, or even > something less formal like the IEPG on sunday morning? >=20 > recent statistics show SIP has a huge penetration on the *public* > internet - way more than i think any of us did. >=20 > ~ Theo > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From victor.pascual.avila@gmail.com Wed Mar 25 09:48:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8490A3A677D for ; Wed, 25 Mar 2009 09:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20xC5vgc1Fxl for ; Wed, 25 Mar 2009 09:48:33 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id CECED3A67B0 for ; Wed, 25 Mar 2009 09:48:12 -0700 (PDT) Received: by ewy9 with SMTP id 9so153553ewy.37 for ; Wed, 25 Mar 2009 09:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=doIQ4bWYlfkzu59IDkMgUL1sDApZs7r4DwzCo5QHnlE=; b=BjOjkaRW6EABGO6E2nT6GL7VfV5kyZVUdYa0E5jnzk+1hNVMfOcJz3Beurs9cMrXms MmnmWS7AKbsCokUX/C2A2z0PPXW8+x8KknTXSyUpJGsrtXU088OSBAsVfVHOsuuDDIuy WWh+6rfp3y7qvjJga80Q7eDqZ3vYEHeOjr1oA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jx8Aqp2wXcOfjArL7kGEdmmW5quiImm5AmdenqE3Iy6RnX/BFpRNjRXfdaaq4Y+8X7 gnpoQa31d2oh1J4dhqOi+N40goIxT32Qj4gQoMEyYj9mzEzPuBkl+A57zLbbPfr3lvYr bPA9InHOLNNYAfBZ4Bry9cUkkbkSIWaYi+c2U= MIME-Version: 1.0 Received: by 10.210.76.4 with SMTP id y4mr7401047eba.12.1237999744303; Wed, 25 Mar 2009 09:49:04 -0700 (PDT) In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A002CA651B@S4DE9JSAANI.ost.t-com.de> References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> <49C8675E.9080501@iptel.org> <036C67C870DF4FA093CA6A614F24FEE4@china.huawei.com> <167dfb9b0903250928v413dad7bwf26f8e1284e79727@mail.gmail.com> <40FB0FFB97588246A1BEFB05759DC8A002CA651B@S4DE9JSAANI.ost.t-com.de> Date: Wed, 25 Mar 2009 17:49:04 +0100 Message-ID: <618e24240903250949q240acc3ey88b6d7257f89ea23@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: L.Liess@telekom.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, theo@voip.co.uk, dean.willis@softarmor.com Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:48:33 -0000 On Wed, Mar 25, 2009 at 5:45 PM, wrote: > > It's a great idea. +1 --=20 Victor Pascual =C3=81vila From jiri@iptel.org Wed Mar 25 09:48:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254F93A6B45 for ; Wed, 25 Mar 2009 09:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU9n-9Kta8Q9 for ; Wed, 25 Mar 2009 09:48:35 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 025D23A677D for ; Wed, 25 Mar 2009 09:48:35 -0700 (PDT) Received: from dhcp-10b4.meeting.ietf.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 86B751812D19; Wed, 25 Mar 2009 17:49:24 +0100 (CET) Message-ID: <49CA6093.9030909@iptel.org> Date: Wed, 25 Mar 2009 17:49:23 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Theo Zourzouvillys References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> <49C8675E.9080501@iptel.org> <036C67C870DF4FA093CA6A614F24FEE4@china.huawei.com> <167dfb9b0903250928v413dad7bwf26f8e1284e79727@mail.gmail.com> In-Reply-To: <167dfb9b0903250928v413dad7bwf26f8e1284e79727@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP , Dean Willis Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:48:36 -0000 Theo Zourzouvillys wrote: > On Wed, Mar 25, 2009 at 12:58 AM, Spencer Dawkins > wrote: >> (2) do we have enough people with enough clue to propose a SIPOps BOF? > > I was going to suggest exactly this, I just hadn't worked out the > process for doing it yet :) > > I think it would be a great, great idea and would love to see more > focus on operations in the same was an dns, ipv6 etc does, or even > something less formal like the IEPG on sunday morning? I think too, there is a large array of topics which are underrepresented and have large impact on the field. It seems too that the same important these are, the same unattractive they seem to many who prefer to focus their creative juices on building new stuff :-) anyhow, to be more specific: I think diagnostics (such as "proxy chain troublehooting",disclosing SIP routing decisions to monitoring equipment, ...), security BCPs (see the thread on how to mititage relay attacks, how to sort out all the identity mechanisms we have,security policies,..), some interop stuff (Hadriel's HOWTO for session id crossing over middleboxes...), global service discovery, and certainly more. > > recent statistics show SIP has a huge penetration on the *public* > internet - way more than i think any of us did. Some hard publicly disclosed numbers? Thanks! -jiri > > ~ Theo > From theo@crazygreek.co.uk Wed Mar 25 10:01:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABEB3A6BA1 for ; Wed, 25 Mar 2009 10:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTdKyPTKFL5v for ; Wed, 25 Mar 2009 10:01:47 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with SMTP id 3DE4B3A677D for ; Wed, 25 Mar 2009 10:01:47 -0700 (PDT) Received: from source ([209.85.220.166]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKScpjr6cCY4mWgJnJVnkDTtKkOTkbkLnW@postini.com; Wed, 25 Mar 2009 10:02:40 PDT Received: by mail-fx0-f166.google.com with SMTP id 10so152994fxm.18 for ; Wed, 25 Mar 2009 10:02:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <49CA6093.9030909@iptel.org> References: <1235425048.6505.66.camel@victoria-pingtel-com.us.nortel.com> <49C8675E.9080501@iptel.org> <036C67C870DF4FA093CA6A614F24FEE4@china.huawei.com> <167dfb9b0903250928v413dad7bwf26f8e1284e79727@mail.gmail.com> <49CA6093.9030909@iptel.org> Date: Wed, 25 Mar 2009 17:02:24 +0000 Received: by 10.86.4.14 with SMTP id 14mr196313fgd.2.1238000559451; Wed, 25 Mar 2009 10:02:39 -0700 (PDT) Message-ID: <167dfb9b0903251002m2fb6fae7kfa2804dfa65d25ea@mail.gmail.com> From: Theo Zourzouvillys To: Jiri Kuthan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP , Dean Willis Subject: Re: [Sip] Diagnostic idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:01:48 -0000 On Wed, Mar 25, 2009 at 4:49 PM, Jiri Kuthan wrote: > Some hard publicly disclosed numbers? wait until my presentation in SIP after lunch :-) lots of people have expressed interest in the stats - i've started doign regular scans fngerprinting, etc and will provide the full details publically over the next few weeks as well as ongoing graphs etc. i just need to find some time to put them up and provide web interface to the database, and have obviously been rather busy the last few weeks ;) ~ Theo From dworley@nortel.com Wed Mar 25 11:23:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437DD3A6D6B for ; Wed, 25 Mar 2009 11:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.656 X-Spam-Level: X-Spam-Status: No, score=-6.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mEHmRytmwNH for ; Wed, 25 Mar 2009 11:23:56 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 442F23A69B2 for ; Wed, 25 Mar 2009 11:23:56 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2PIOjn21109 for ; Wed, 25 Mar 2009 18:24:45 GMT Received: from [47.141.31.169] ([47.141.31.169]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 14:24:45 -0400 From: "Dale Worley" To: Vijay Gurbani In-Reply-To: <49CA4FE6.2030608@alcatel-lucent.com> References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> <1237953863.22543.10.camel@victoria-pingtel-com.us.nortel.com> <49CA4FE6.2030608@alcatel-lucent.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Mar 2009 14:24:44 -0400 Message-Id: <1238005484.4116.42.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 18:24:45.0441 (UTC) FILETIME=[F9241F10:01C9AD76] Cc: SIP IETF Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:23:57 -0000 On Wed, 2009-03-25 at 10:38 -0500, Vijay Gurbani wrote: > Dale Worley wrote: > > Not really, because log files slice the universe of data the wrong way. > > Not as much wrong as different; i.e., log files slice the universe of > data a different way. > > > A log file tells everything that happens at a particular element, almost > > all of which is irrelevant regarding a particular transaction. > > Depends. If that element is misbehaving -- either through flawed source > code or because of external influences -- the state of a transaction > preserved in a log file from the point of that element is of extreme > interest for analysis. > > However, as you note, log files do not help in dynamic tracing > of the transaction across a set of elements. As we both understand, the two mechanisms slice the universe of data in different ways, which are most useful for attacking different problems. What makes the problem more complex is that different elements have different owners, and one can reasonably say that the UAC-owner can look at the action of a proxy in regard to one of the UAC's requests, but not have the right to examine the proxy's full log. Conversely, taking the intersection of the two questions, a log file format should record at least enough information about a transaction as you would want in a trace facility. Dale From dworley@nortel.com Wed Mar 25 11:33:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7EC3A6D8B for ; Wed, 25 Mar 2009 11:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.654 X-Spam-Level: X-Spam-Status: No, score=-6.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-GccAGuoQ-G for ; Wed, 25 Mar 2009 11:33:27 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 34AAB3A6A79 for ; Wed, 25 Mar 2009 11:33:27 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2PIYGn23231; Wed, 25 Mar 2009 18:34:16 GMT Received: from [47.141.31.169] ([47.141.31.169]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 14:34:16 -0400 From: "Dale Worley" To: Hadriel Kaplan In-Reply-To: References: <1236191313.3771.20.camel@victoria-pingtel-com.us.nortel.com> <1237954380.22543.20.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Mar 2009 14:34:15 -0400 Message-Id: <1238006055.4116.50.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 18:34:16.0373 (UTC) FILETIME=[4D716E50:01C9AD78] Cc: SIP Subject: Re: [Sip] SIP Tracing Facility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:33:28 -0000 On Wed, 2009-03-25 at 03:29 -0400, Hadriel Kaplan wrote: > IMO the UAC has no right to know any such thing. It has no rights - > it's not a human. The calling human has a right to know the far-end > called human it got delivered to. But they don't care nor have a > right to know the *host* element it got delivered to, or host elements > it forked to but did not succeed at, etc. It's none of their > business, frankly. > > And if we're thinking the far-end terminating Enterprise or provider > will want to tell some originating Enterprise or provider what's going > on inside their network, well... once again we all live in different > worlds. :) I'm sure we live in different worlds. But there are considerable situations where the UAC's owner, or the enterprise or service provider supervising the UAC has rights to know quite a bit. The obvious case is when the owner has contracted with the transit network to provide particular intelligent routing services -- they're going to want to be able to verify that the transit network is performing as contracted. To construct a more interesting case, one that will be a reasonable business case within a year or two: - a UAC within an enterprise network - a transit network from the enterprise to a provider of intelligent call routing - the provider of intelligent call routing - another transit network from the provider to a destination enterprise - a UAS within the destination enterprise network Each of the last 4 operations may want to hide the details of its network, but the originator of the call should have the right (assuming that it's contracting for these services) to monitor the four connections between these networks. Dale From rjsparks@nostrum.com Wed Mar 25 13:06:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581693A6D73; Wed, 25 Mar 2009 13:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOO9OibTZSSH; Wed, 25 Mar 2009 13:06:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id ED81F3A6B91; Wed, 25 Mar 2009 13:06:07 -0700 (PDT) Received: from [130.129.18.254] (dhcp-12fe.meeting.ietf.org [130.129.18.254]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2PK6RYk098444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Mar 2009 15:06:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <29F5ACF3-4CB8-4B0D-A6D1-6F13C62BDE36@nostrum.com> From: Robert Sparks To: SIP IETF , simple mailing list Content-Type: multipart/alternative; boundary=Apple-Mail-26--141133477 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 13:06:27 -0700 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 130.129.18.254 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9167/Wed Mar 25 13:06:32 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Sip] Reminder: SIPit24 registration closes April 30 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:06:09 -0000 --Apple-Mail-26--141133477 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit SIPit 24 registration closes April 30. Please register now if you haven't done so already. Be sure to make your lodging reservations early. Links to more information, including the registration site are below. Thanks, RjS On Mar 3, 2009, at 8:51 AM, Robert Sparks wrote: > Registration for SIPit 24 is open! > SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan > hosted by JPNIC and NICT. > Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/ --Apple-Mail-26--141133477 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit SIPit 24 registration closes April 30. Please register now if you  
haven't done so already.

Be sure to make your lodging reservations early.

Links to more information, including the registration site are below.

Thanks,

RjS

On Mar 3, 2009, at 8:51 AM, Robert Sparks wrote:

Registration for SIPit 24 is open!
SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan  
hosted by JPNIC and NICT.
Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/
--Apple-Mail-26--141133477-- From pkyzivat@cisco.com Wed Mar 25 13:34:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03C73A6D5E for ; Wed, 25 Mar 2009 13:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB31=0.464] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PhIylRXa93h for ; Wed, 25 Mar 2009 13:34:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0FE403A6888 for ; Wed, 25 Mar 2009 13:34:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,421,1233532800"; d="scan'208";a="161621185" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2009 20:35:19 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2PKZJjB018429; Wed, 25 Mar 2009 13:35:19 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2PKZJ6E005795; Wed, 25 Mar 2009 20:35:19 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 16:35:18 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 16:35:18 -0400 Message-ID: <49CA958A.5060108@cisco.com> Date: Wed, 25 Mar 2009 16:35:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: aayush bhatnagar References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> <49CA3A52.8050903@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 20:35:18.0636 (UTC) FILETIME=[3616D2C0:01C9AD89] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15957; t=1238013319; x=1238877319; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Is=20REFER=20within=20dialog=20 part=20of=20INVITE=20or=20subscription=20=0A=20usage?=20(was =20RE=3A=20SIP=20INFO) |Sender:=20; bh=WiVR8IgR/JNCi71AxzB7uLS9YJum2dZsGN0y/RtmJ/A=; b=g4GBwHwY+EtxMwwrZjSS/ZRyCs26yFxeEN+UuIDA9kphlNviLGaO+CA2JE SMwGt9zGMJgC/Te2tNU20z8B5jzo71injFTcqD0PJD/g7vDxPCaJdgIXEuvL /Yy2gGJ0dc; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:34:28 -0000 aayush bhatnagar wrote: >>Go read 5057. The usages are to be handled separately. So this should > *not* provoke the UAC >to clean up its INVITE dialog usage. > > I have read the relevant RFC. From 5057: OK, sorry. It just sounded like you might not have. > -Existing implementations that destroy all other usages in the dialog > will continue to function as -they do now, except that peers following > the recommendation will attempt to do things with the -other usages and > this element will return 481s for each of them until they are all gone. > > I think it is more feasible to destroy the entire dialog, than keeping > on to 'hung' state until all the dialog usages are all gone as suggested > above. I am familiar with implementations that clean up dialog state > when they get a 481-dialog does not exist response, even if there were > other 'active' usages of that dialog. I'm not surprised. Its often "more feasible" to do the wrong thing than the right thing. But that doesn't make it right. While its not written in black and white in 3261, there is enough info there to infer that you need to treat them separately. > The reason being, that if an implementation cannot find a matching > dialog as characterized by the local tag, remote tag, call-id, local and > remote sequence nos etc and has rejected the request by a 481, there is > no point in keeping the dialog state at the UAC. This is all hashed out in 5057. The problem is that the 481 response is *ambiguous*. The way to maximize interop is to treat the 481 as meaning the least serious thing that it could mean - that only the usage has gone away. If it turns out that the whole dialog went away, then you will eventually find that out anyway. Of course it doesn't hurt to treat it as meaning all the usages went away if you would not continue all of them anyway. But if the other usage(s) continue to be of value then it you are hurting yourself by assuming they have gone away when they might not have. > As for example, if you receive a 481 response for a REFER sent within > the INVITE dialog, there is no point in keeping the REFER usage alive. > You probably sent the REFER to transfer a call, which the server > complains that the call itself does not exist (481). That's not the case of relevance. If you got a 481 for a REFER, the refer of course failed, and so there is no refer usage to keep alive. We are still, in this thread, trying to decide what a 481 to a REFER means. I think it won't be ambiguous - that it can *only* mean that the whole dialog is gone, since it is never associated with a preexisting usage. Even so, you would be well advised to probe any existing usages with in-usage messages to verify if they are alive, even though most likely they are not. > Moreover from 5057: > > -Processing multiple usages correctly is not completely understood. > -What is understood is difficult to implement and is very likely to > -lead to interoperability problems. The best way to avoid the trouble > -that comes with such complexity is to avoid it altogether. > -When designing new applications or features that use SIP dialogs, do > -not require endpoints to construct multiple usages to participate in > -the application or use the feature. > > This is very true. By defining multiple dialog usages, you are > essentially extending the dialog state (as defined by 3261) by adding > more attributes to it (such as subscription duration etc). I cant think > of a practical use case, where a subscription that shared the invite > dialog usage still needed to be preserved, even when the original INVITE > dialog was no longer active. We aren't *adding more attributes to it*. It is what it is and has been. It has been implicitly legal in spite of the problems. And it *is* used. There are even reasonable use cases for independent termination of the usages. For instance, a refer usage sharing a dialog with an invite usage may meaningfully survive after the invite usage terminates. > As for example a subscription to the 'conference' event package sent > within the scope of an INVITE dialog. If i leave the conference by > sending a BYE, and my subscription's duration is still valid for an > hour...will i still keep on getting redundant SIP notifications for > changes to the membership to that conference ? > In the sense of 5057, the > subscribe usage will be preserved until it expires, or until the UAC > explicitly un-subscribes, or the conference server has to send me a > final NOTIFY with my subsription-state = terminated. IMO that is exactly as it *should* be. If the subscriber doesn't want to maintain the subscription, it can simply wipe out the state of the subscription. Then when another NOTIFY is received, a 481 will be sent because there is no state, forcing the end of the usage. But *assuming* that the subscription *should* go away when the invite ends is, IMO, wrong. There may be valid reasons to retain the subscription. > It is not important that 5057 is allowing us many theoretical > possibilities by presenting multiple dialog usages. > > What is more important is what extra do we get by reusing a dialog, and > how do implementations leverage upon such a possibility and create > meaningful applications around it ? > > I would like to share some examples: > > 1. As for example an application that can practically leverage upon 5057 > may send a SUBSCRIBE to the 'dialog' event package (rfc 4235) that > reuses the INVITE dialog can be used for creating SIP call tracing > applications. > > 2. Other Implementations may include automatic callback applications by > this mechanism (ring back when my sip phone is idle) etc. > > 3. Yet another application may send me by pre-paid account balance after > i disconnect my ongoing dialog, as it is subscribed to my dialog state. > > In all these example applications, the endpoint receiving the SUBSCRIBE > will need to send a NOTIFY that re-uses its existing INVITE dialog > (NOTIFY acting as a target refresh in the sense of 5057). Sounds like you are in favor of dialog reuse. Paul > Best Regards > > aayush > > > On Wed, Mar 25, 2009 at 7:36 PM, Paul Kyzivat > wrote: > > > > aayush bhatnagar wrote: > > If you send an in dialog request (REFER in our case), then you > cannot > decouple its semantics with the existing dialog usage. > > > You say "*the* dialog usage" as if there can be only one. There > could be more than one. It might be coupled to: > - the *only* existing usage > - to *one* of several existing usages > - to *none* of the one or more existing usages > > For instance, I could have a dialog with just an INVITE usage (the > common case) and within that dialog send a REFER of a MESSAGE. That > MESSAGE really has nothing to do with the INVITE usage. > > > So saying that > even if i send a REFER within an existing dialog, and still decouple > it from the existing dialog usage will not be possible. > If there were such a requirement, then REFER should have been > sent as > a standalone dialog creating request outside the INVITE usage. > > > One can argue that it *should* have been. But that isn't the point > of this discussion. In many cases using the same dialog as been an > expedient to ensure reaching the same UA when you aren't sure the > remote target url for the dialog is in fact routable. > > > The recipient of the in dialog REFER will treat it like it > should any > in dialog request. It has no way to decide if this request > potentially > had nothing to do with the existing dialog usage. > > > You are being sloppy in your use of "dialog" and "dialog usage", as > if you are not familiar with RFC 5057. If you aren't, please read it. > > > i agree with you when you say that an indialog refer receiving a 481 > would mean that the INVITE dialog has been torn down. > > > See my reply to Dale. > > > However, a refer dialog usage can also terminate, if the UAC sends a > 481 in response to the NOTIFY sent by the UAS (Suppose the > transaction > did not match). > > > You need to spell out more details of the case. If it were the > *first* NOTIFY, resulting from an in-dialog REFER, then that > response would be indicative of a screwup somewhere. > > However, if there had been a prior NOTIFY on the refer subscription > that indicated that the subscription was over, and then somehow > *another* NOTIFY was sent, the 481 would be appropriate, indicating > that the refer-usage was no longer present. > > > This scenario may happen irrespective of whether the > REFER was within the invite usage or created its own distinct > dialog. > If this happens when REFER was sent within an Invite dialog, > then the > UAC will be mistaken to clean up its INVITE dialog state. > > > Go read 5057. The usages are to be handled separately. So this > should *not* provoke the UAC to clean up its INVITE dialog usage. > > > I did not understand one part in the paradox above when you said... > "A REFER within an established dialog having no invite usage to be > considered as an out of dialog REFER" > Do you mean to imply a REFER in some other Subscribe event package > dialog for example? > > > Yes, that is what I meant. I don't have any meaningful cases in > mind, but it is a theoretical possibility. > > Paul > > > aayush. > > On 3/25/09, Dale Worley > wrote: > > On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote: > > I would argue that the REFER is part of the INVITE > usage, because REFER > in that context is intimately related to the INVITE > usage -- it is > intended to transfer the INVITE usage/dialog > transferred to a different > destination. > > Well, I guess there is that implied association. (Part > of the "do what > *I* had in mind" approach that REFER has.) Since this > was never spelled > out, it could also be simply "while this isn't part of > an INVITE usage, > if there happens to be an INVITE usage, please refer > that one." > > I guess the question is: would it be valid to send a > REFER within an > existing dialog that had no INVITE usage? If it were > valid, presumably > it would have the same meaning as sending one outside a > dialog, except > that the resulting subscription would share the dialog. > I expect that is > a usage it would be difficult to find in the wild. > > That's a nice pathological case. But within the context of > the current > 5 possible meanings of REFER, it seems to be most parallel > to the > out-of-dialog REFER. > > Ah, but now I want to reconsider. Remember that REFER > can take a method > name. So, rather than referring an INVITE, I could be > referring MESSAGE, > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of > those cases, the > association to the INVITE usage is probably meaningless. > (Of course its > meaningful for BYE.) > > A fascinating possibility! But I'm not sure that we've ever > defined how > a REFER within a simple INVITE dialog, specifying a > non-INVITE method > should act. So there's no analog to follow. > > And it seems quite safe that if the REFER receives a > 481 response, the > INVITE usage must not be functional any more, since > the far end of that > usage has denied that it can act on the REFER. > > IIRC, 5057 decided that each dialog usage must get its > own 481 before it > goes away. I don't think there are any cases where a > single 481 response > can make multiple usages go away. > > So the important question is whether the REFER is part > of the INVITE > usage and so its 481 takes down the INVITE usage or not. > That gets > especially interesting if the dialog already had both > an INVITE usage > and a SUBSCRIBE usage. Does it make sense that the refer > take down the > INVITE usage and leave up the SUBSCRIBE usage? > > I think we're a victim of sloppy terminology here. If I > send a REFER, > and the far end responds 481, then clearly the far end knows > of no > INVITE usage, or otherwise it would not have responded 481. > So I should > delete my belief that there is an INVITE usage. Whether we > consider the > REFER in question to be "part of" the INVITE usage or not > doesn't change > anything -- the 481 is evidence that the far end has no > knowledge of the > usage. > > However, we do have this fine paradox: If we assume that a > REFER within > an established dialog that has no INVITE usage is to be > treated as an > out-of-dialog REFER, then *no* REFER will receive a 481 > response! > Indeed, if I send a REFER thinking that there is an active > INVITE usage, > but the far end believes the INVITE usage has ended, will > cause the far > end to do something (initiate an independent dialog) that is > considerably different from what I expected (transfer the > current INVITE > usage). > > Dale > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on > current sip > Use sipping@ietf.org for new > developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on > current sip > Use sipping@ietf.org for new > developments on the application of sip > > From jdrosen@cisco.com Wed Mar 25 13:50:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DB03A6D4A for ; Wed, 25 Mar 2009 13:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgB9MSswHn-w for ; Wed, 25 Mar 2009 13:50:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1840A3A68A1 for ; Wed, 25 Mar 2009 13:50:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,421,1233532800"; d="scan'208";a="161631437" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2009 20:51:16 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2PKpGna002439 for ; Wed, 25 Mar 2009 13:51:16 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2PKpGot008821 for ; Wed, 25 Mar 2009 20:51:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 13:51:16 -0700 Received: from [10.21.75.222] ([10.21.75.222]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 13:51:15 -0700 Message-ID: <49CA9943.1020808@cisco.com> Date: Wed, 25 Mar 2009 16:51:15 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 20:51:15.0827 (UTC) FILETIME=[709E9430:01C9AD8B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1009; t=1238014276; x=1238878276; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20The=20problem=20with=20draft-kaplan-sip-secure- call-id-00 |Sender:=20; bh=0lpmkN1gKSo/WuYkt0oGZZFz1cMkGd7WsyKVF5jfnL8=; b=QQLKww2ANA84Nqm8wveGmmA+GXYsBvnCwG3jFJyoIQIX7mTFwTYJYN6/g9 zhp+/8AbvnOHH534LpONvByu4jYXsuOuTn+AUXok/lR1VzACGgiyKSdCtpOH urJM4CXT8XWy09OTiLgA+uvQfe/siNui+UQPD+150TaiaxeGArf8Y=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:50:25 -0000 I didnt get a chance to say this at the mike. You *cannot* change the BNF for the call-id. If you did, you might end up with the following problem: A new UA gets built, compliant to this update. It is one of these 'aggressive parsing' UAs. It rejects any message which is not compliant to the BNF. An older, normal RFC-3261 compliant UA sends a call-id which includes the @-sign. According to the BNF of this updated 3261, and based on the strictness of this aggressive-parsing UAs, it rejects that request as non-compliant. As such, you need to keep the BNF, but change the normative language such that an endpoint MUST NOT include the [@ host] but MUST be prepared to receive it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From dworley@nortel.com Wed Mar 25 13:59:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59C43A6B80 for ; Wed, 25 Mar 2009 13:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.652 X-Spam-Level: X-Spam-Status: No, score=-6.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJTH5Z8FbZ+K for ; Wed, 25 Mar 2009 13:59:03 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C24C43A68C1 for ; Wed, 25 Mar 2009 13:59:02 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2PKxNQ12173; Wed, 25 Mar 2009 20:59:23 GMT Received: from [47.141.31.175] ([47.141.31.175]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 16:59:48 -0400 From: "Dale Worley" To: Hadriel Kaplan In-Reply-To: References: <49C507BB.9010804@cisco.com> <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 25 Mar 2009 16:59:47 -0400 Message-Id: <1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Mar 2009 20:59:48.0760 (UTC) FILETIME=[A259F180:01C9AD8C] Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:59:03 -0000 On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote: > > If I may be immodest, the References header could a solution: State > > that two dialogs are related to each other by (effectively) naming both > > call-id's together, rather than by assigning them a common identifier > > when they are created. > > Yeah I think it adds value to have the References header. I just > don't think it should be referencing Call-ID's, or else we'll have to > replace that too. It should be referencing Session-ID's or > secure-call-id's. :) Certainly in security-sensitive situations, referencing Call-IDs, or at least, ones created by UAs, would be undesirable. But down in section 5.2 it describes how to have the B2BUA generate "linking" identifiers: A possible solution to this problem is for the B2BUA to create a "phantom" Call-Id that is suitably random, and use it in References headers sent in both the initial request and response. By the transitivity property[Section 2], the dialogs on both sides of the B2BUA are declared to be related, even if the referenced dialog contains no messages. For two chained B2BUAs with no forking, this would give a message flow like this: UA 1 B2BUA 1 B2BUA 2 UA 2 ---> INVITE 123@aa.example.com Call-Id: qwerty@aa ---> INVITE 123@transit.example.com Call-Id: asdfgh@transit References: QAZWSXEDCRFV;rel=serial ---> INVITE 123@bb.example.com Call-Id: zxcvbn@bb References: QAZWSXEDCRFV ;rel=serial <--- SIP/2.0 200 OK Call-Id: zxcvbn@bb <--- SIP/2.0 200 OK Call-Id: asdfgh@transit References: QAZWSXEDCRFV;rel=serial <--- SIP/2.0 200 OK Call-Id: qwerty@aa References: QAZWSXEDCRFV;rel=serial Dale From HKaplan@acmepacket.com Wed Mar 25 14:04:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB41B28C136 for ; Wed, 25 Mar 2009 14:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtzVyEpiiVFf for ; Wed, 25 Mar 2009 14:04:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9005328C0D7 for ; Wed, 25 Mar 2009 14:04:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 17:05:22 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 25 Mar 2009 17:05:22 -0400 From: Hadriel Kaplan To: Jonathan Rosenberg , IETF SIP List Date: Wed, 25 Mar 2009 17:05:24 -0400 Thread-Topic: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 Thread-Index: Acmti4H9DUhX8XG6RBWyiOtwVOacvgAAakoQ Message-ID: References: <49CA9943.1020808@cisco.com> In-Reply-To: <49CA9943.1020808@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:04:32 -0000 Ooh, good point. Fair enough, I'll change that. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, March 25, 2009 4:51 PM > To: IETF SIP List > Subject: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 >=20 > I didnt get a chance to say this at the mike. >=20 > You *cannot* change the BNF for the call-id. If you did, you might end > up with the following problem: >=20 > A new UA gets built, compliant to this update. It is one of these > 'aggressive parsing' UAs. It rejects any message which is not compliant > to the BNF. An older, normal RFC-3261 compliant UA sends a call-id which > includes the @-sign. >=20 > According to the BNF of this updated 3261, and based on the strictness > of this aggressive-parsing UAs, it rejects that request as non-compliant. >=20 > As such, you need to keep the BNF, but change the normative language > such that an endpoint MUST NOT include the [@ host] but MUST be prepared > to receive it. >=20 > -Jonathan R. >=20 > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From drage@alcatel-lucent.com Wed Mar 25 14:19:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F033A6DAB for ; Wed, 25 Mar 2009 14:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khsnHfZNmneh for ; Wed, 25 Mar 2009 14:19:26 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id DAA7F3A67B3 for ; Wed, 25 Mar 2009 14:19:25 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2PLKFrS017835 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 25 Mar 2009 22:20:16 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 25 Mar 2009 22:20:16 +0100 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Wed, 25 Mar 2009 22:20:16 +0100 Thread-Topic: draft-kaplan-sip-secure-call-id-00 Thread-Index: Acmtj34LwVi3qW1FRdCBcgHPHZmfwQ== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE70A@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [Sip] draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:19:27 -0000 On: http://tools.ietf.org/id/draft-kaplan-sip-secure-call-id-00.txt=09 I believe the essential question at the moment is: "Do people see this as s= omething that solves problems or not?". However can I point out the process implications. The draft as currently provided updates RFC 3261 in my view. That essential= ly makes it SIP-CORE if the WG / charter changes go ahead. The draft appears to claim that it corrects a problem in RFC 3261? Is it an= essential correction? If so it should possible form part of our essential = corrections process, rather than ultimately generating a second draft. Doin= g so would certainly make some of the documentation implications in the sli= des as currently stated easier. So, is it an essential correction or a SIP = extension? I would claim there are no other standards track SIP documents. regards Keith From spencer@wonderhamster.org Wed Mar 25 14:20:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4C63A6DB2 for ; Wed, 25 Mar 2009 14:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBJfndCkKes2 for ; Wed, 25 Mar 2009 14:20:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5A6163A67B3 for ; Wed, 25 Mar 2009 14:20:05 -0700 (PDT) Received: from S73602b (dhcp-63fb.meeting.ietf.org [130.129.99.251]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LmaWt0E2A-000g20; Wed, 25 Mar 2009 17:20:57 -0400 Message-ID: <4E3645D2C8AF42C38FFD236833D3A35C@china.huawei.com> From: "Spencer Dawkins" To: "Jonathan Rosenberg" , "IETF SIP List" References: <49CA9943.1020808@cisco.com> Date: Wed, 25 Mar 2009 16:20:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18gFO8vuoEOxIQlccHBI+GYNPpbe0b6q+BGDZY CCrL4zhdhHwGSLU06q3aMyzUN33kfv+zJzgSxGL3hysrdsvTCo 3hZyd0HK9QT6BTf68ENI9HE0NU/O3zwiCGxJatgBJs= Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:20:06 -0000 I agree with Jonathan - this is the right way to go. Spencer >I didnt get a chance to say this at the mike. > > You *cannot* change the BNF for the call-id. If you did, you might end > up with the following problem: > > A new UA gets built, compliant to this update. It is one of these > 'aggressive parsing' UAs. It rejects any message which is not compliant > to the BNF. An older, normal RFC-3261 compliant UA sends a call-id which > includes the @-sign. > > According to the BNF of this updated 3261, and based on the strictness > of this aggressive-parsing UAs, it rejects that request as non-compliant. > > As such, you need to keep the BNF, but change the normative language > such that an endpoint MUST NOT include the [@ host] but MUST be prepared > to receive it. > > -Jonathan R. From vvenkatar@gmail.com Wed Mar 25 14:33:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380FB28C105 for ; Wed, 25 Mar 2009 14:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye4vkzV6XcPY for ; Wed, 25 Mar 2009 14:33:45 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id B64833A63EB for ; Wed, 25 Mar 2009 14:33:44 -0700 (PDT) Received: by bwz17 with SMTP id 17so255714bwz.37 for ; Wed, 25 Mar 2009 14:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5MYqnBwk/XPEjrvI/3+BKgRVJ5zkOw5TBqJus43YXEY=; b=cbiGFzFnad/z3Om7PoAossQawScYGPtijFzWiJ7f+qA75w9/gCFaqHZMHrDge/L6zP slCt+O1xcKCQ6rBuGAgm8Vr9pgBfPo3D7QhwBx70zBpAVNfDp0jwSvg1WBDNvBXqI+x7 E3l9HFECyRjdaOYuHiT8zRJPFPCrIF9uKvy8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MIRtVTcKU+ubTC2/m7imX3hYGJ+gPXuBMRNezeRwlJEeUkOOhMVd1COyG0LfSVw0gQ KS3DeTDweo2xq/D11w3wpB9mU9LP7Kmed4Bh3Tc4ZKSqcsXOc8UCRAlqGfVeMsiM//SR fcnptU+Iilvz5dqEv5LEqX8rdtvWIyt/qGtRg= MIME-Version: 1.0 Received: by 10.103.243.9 with SMTP id v9mr18989mur.91.1238016876182; Wed, 25 Mar 2009 14:34:36 -0700 (PDT) In-Reply-To: <49CA9943.1020808@cisco.com> References: <49CA9943.1020808@cisco.com> Date: Wed, 25 Mar 2009 14:34:36 -0700 Message-ID: <4ff4e7370903251434w2ef77beci231f3e2c4e42d2dc@mail.gmail.com> From: Venkatesh To: Jonathan Rosenberg Content-Type: multipart/alternative; boundary=0016369205b1217c050465f844ab Cc: IETF SIP List Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:33:46 -0000 --0016369205b1217c050465f844ab Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello: I am not sure that this alone will fix the problem in totality. If I were to use the reverse analogy i.e. what if a UA that conforms to this specification offers the request to a "aggressive parsing" UA that is only compliant with RFC 3261? If we are not planning on changing the BNF, I am wondering if this draft should simply say that the string after the "@" sign MUST NOT include a domain name, host address, MAC....? Or if this is ambiguous, simply say that the UA MUST generate *another* cryptographic identifier to be placed after the @ sign? Thanks, Venkatesh On Wed, Mar 25, 2009 at 1:51 PM, Jonathan Rosenberg wrote: > I didnt get a chance to say this at the mike. > > You *cannot* change the BNF for the call-id. If you did, you might end up > with the following problem: > > A new UA gets built, compliant to this update. It is one of these > 'aggressive parsing' UAs. It rejects any message which is not compliant to > the BNF. An older, normal RFC-3261 compliant UA sends a call-id which > includes the @-sign. > > According to the BNF of this updated 3261, and based on the strictness of > this aggressive-parsing UAs, it rejects that request as non-compliant. > > As such, you need to keep the BNF, but change the normative language such > that an endpoint MUST NOT include the [@ host] but MUST be prepared to > receive it. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --0016369205b1217c050465f844ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello:

I am not sure that this alone will fix the = problem in totality. If I were to use the reverse analogy i.e. what if a UA= that conforms to this specification offers the request to a "aggressi= ve parsing" UA that is only compliant with RFC 3261?

If we are not planning on changing the BNF, I am wondering i= f this draft should simply say that the string after the "@" sign= MUST NOT include a domain name, host address, MAC....? Or if this is=A0amb= iguous, simply say that the UA MUST generate *another* cryptographic identi= fier to be placed after the @ sign?

Thanks,
Venkatesh

On Wed, Mar 25, 2009 at 1:51 PM, Jonathan Rosenberg <jdrosen@cisco.com>= wrote:
I didnt get a chance to say this at the mik= e.

You *cannot* change the BNF for the call-id. If you did, you might end up w= ith the following problem:

A new UA gets built, compliant to this update. It is one of these 'aggr= essive parsing' UAs. It rejects any message which is not compliant to t= he BNF. An older, normal RFC-3261 compliant UA sends a call-id which includ= es the @-sign.

According to the BNF of this updated 3261, and based on the strictness of t= his aggressive-parsing UAs, it rejects that request as non-compliant.

As such, you need to keep the BNF, but change the normative language such t= hat an endpoint MUST NOT include the [@ host] but MUST be prepared to recei= ve it.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 111 Wood A= venue South
Cisco Fellow =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Iselin, NJ 08830
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PHONE: (408) 902-3084<= br> http://www.cisco.com=
_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use s= ip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org<= /a> for new developments on the application of sip

--0016369205b1217c050465f844ab-- From victor.pascual.avila@gmail.com Wed Mar 25 14:39:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDCA3A6BA4 for ; Wed, 25 Mar 2009 14:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIhro4QDWdZk for ; Wed, 25 Mar 2009 14:39:22 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id E2CA33A6B3A for ; Wed, 25 Mar 2009 14:39:21 -0700 (PDT) Received: by ewy9 with SMTP id 9so285411ewy.37 for ; Wed, 25 Mar 2009 14:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S+nfpkO73Ba0RoOYiSeSmVR3QGDJ6bKNAQaPJpkCssM=; b=gKVLbQrwU3OwFokVP6w1035hf0e7YA2SpMG7STFZ7jSpVBVo8SKEXWY3DtjTV/llws 8eRpMaecMd9GIwtRf7f5pzRrYoDBirXSaFe4zAwofeUPfi7CORtPr7iHhWMntla1Wg2A jEDOHL/t5nqsdbrZh0lcABUs7XcM3DmQqHNkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UWE1xL8+1Ze7tSJuCRJ+gov+yN9AlvOpHkFhKMmOqV3YPvNBftIPR2OlLOCZJyEiZf pB/Ph2YIQzkjfnEamalc6axYqxD+QruvvPTb1oI4BoNakMYN2dMLrOwd/EyNavO552uP zkvuEw4n/V/wsA5T0/yTb2LJ5jjzzM8PfzALA= MIME-Version: 1.0 Received: by 10.210.45.17 with SMTP id s17mr28819ebs.74.1238017213898; Wed, 25 Mar 2009 14:40:13 -0700 (PDT) In-Reply-To: <4ff4e7370903251434w2ef77beci231f3e2c4e42d2dc@mail.gmail.com> References: <49CA9943.1020808@cisco.com> <4ff4e7370903251434w2ef77beci231f3e2c4e42d2dc@mail.gmail.com> Date: Wed, 25 Mar 2009 22:40:13 +0100 Message-ID: <618e24240903251440wb473aaehc414e5f13a5128e0@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Venkatesh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF SIP List Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:39:22 -0000 On Wed, Mar 25, 2009 at 10:34 PM, Venkatesh wrote: (snip) > If we are not planning on changing the BNF, I am wondering if this draft > should simply say that the string after the "@" sign MUST NOT include a > domain name, host address, MAC....? Or if this is=C2=A0ambiguous, simply = say that > the UA MUST generate *another* cryptographic identifier to be placed afte= r > the @ sign? This would be fair enough. --=20 Victor Pascual =C3=81vila From vvenkatar@gmail.com Wed Mar 25 14:40:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF7E28C1A0 for ; Wed, 25 Mar 2009 14:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNwQkEpa1YBe for ; Wed, 25 Mar 2009 14:40:06 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by core3.amsl.com (Postfix) with ESMTP id E437828C17F for ; Wed, 25 Mar 2009 14:40:05 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w9so142350mue.9 for ; Wed, 25 Mar 2009 14:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uD/kwDxzCgq84z4D6VtYKgGtDrf+vBV1hzuTonoqNog=; b=xs9b43Axhpd/uR+9p/WVS6446QbsD66i2DWuFjGQZ73eO7Rg/AbM+5ZqFnHeEm1EmE Ql0srUrh+3WsMoxRE7u+ol+P1c1E13CxHp3PEhG1yYbMJst2aR1i3qt3U1xb5VCT5F6J NiT4sA9Cu+MQEL04VFhj6qWiBn2Z3S5VmHbbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z3HsciYzugmbfb51NqNBW/kYFbPTOdOB5YYKVdo2c42W1ZaRbuSfq51IXH9ZR3AQi3 lubhIH3TgRAiHGE550WkEMU8yfyU7kMUg2M5fume8h6fAoIb7rj049FwaX6zFWNb5air jTAlu0vmROt95uRwC+153XwobgQ3tgi8BTOf4= MIME-Version: 1.0 Received: by 10.103.92.10 with SMTP id u10mr42835mul.22.1238017257714; Wed, 25 Mar 2009 14:40:57 -0700 (PDT) In-Reply-To: <1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com> References: <49C507BB.9010804@cisco.com> <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> <1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com> Date: Wed, 25 Mar 2009 14:40:57 -0700 Message-ID: <4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> From: Venkatesh To: Dale Worley Content-Type: multipart/alternative; boundary=0016e6dd966fdf34950465f85aff Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:40:07 -0000 --0016e6dd966fdf34950465f85aff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A crazy thought occurred to me while I was reading this draft. If the intent is for debugging and such, I am wondering if there is any value in considering the re-use of the P-Charging-Vector header for this purpose? After all, this is supposed to be unique, required to be carried across Proxies, B2BUA's if one is present, reflected in CDR's if one is generated by an entity?? Agree that this header had specific intents and cannot span across "trust" boundaries, but I am not sure if a SP cares when the request 'leaves' their trust boundary? It seems to satisfy the requirement for debugging? Flame away :-). Venkatesh On Wed, Mar 25, 2009 at 1:59 PM, Dale Worley wrote: > On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote: > > > If I may be immodest, the References header could a solution: State > > > that two dialogs are related to each other by (effectively) naming both > > > call-id's together, rather than by assigning them a common identifier > > > when they are created. > > > > Yeah I think it adds value to have the References header. I just > > don't think it should be referencing Call-ID's, or else we'll have to > > replace that too. It should be referencing Session-ID's or > > secure-call-id's. :) > > Certainly in security-sensitive situations, referencing Call-IDs, or at > least, ones created by UAs, would be undesirable. But down in section > 5.2 it describes how to have the B2BUA generate "linking" identifiers: > > A possible solution to this problem is for the B2BUA to create a > "phantom" Call-Id that is suitably random, and use it in References > headers sent in both the initial request and response. By the > transitivity property[Section 2], the dialogs on both sides of the > B2BUA are declared to be related, even if the referenced dialog > contains no messages. > > For two chained B2BUAs with no forking, this would give a message > flow like this: > > UA 1 B2BUA 1 B2BUA 2 UA 2 > > ---> > INVITE 123@aa.example.com > Call-Id: qwerty@aa > > ---> > INVITE 123@transit.example.com > Call-Id: asdfgh@transit > References: QAZWSXEDCRFV;rel=serial > > ---> > INVITE 123@bb.example.com > Call-Id: zxcvbn@bb > References: QAZWSXEDCRFV > ;rel=serial > > <--- > SIP/2.0 200 OK > Call-Id: zxcvbn@bb > > <--- > SIP/2.0 200 OK > Call-Id: asdfgh@transit > References: QAZWSXEDCRFV;rel=serial > > <--- > SIP/2.0 200 OK > Call-Id: qwerty@aa > References: QAZWSXEDCRFV;rel=serial > > Dale > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --0016e6dd966fdf34950465f85aff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A crazy thought occurred to me while I was reading this draft. If the inten= t is for debugging and such, I am wondering if there is any value in consid= ering the re-use of the P-Charging-Vector header for this purpose? After al= l, this is supposed to be unique, required to be carried across Proxies, B2= BUA's if one is present, reflected in CDR's if one is generated by = an entity?? Agree that this header had specific intents and cannot span acr= oss "trust" boundaries, but I am not sure if a SP cares when the = request 'leaves' their trust boundary? It seems to satisfy the requ= irement for debugging? Flame away :-).

Venkatesh

On Wed, Mar 25, = 2009 at 1:59 PM, Dale Worley <dworley@nortel.com> wrote:
On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote:
> > If I may be immodest, the References header could a solution: =A0= State
> > that two dialogs are related to each other by (effectively) namin= g both
> > call-id's together, rather than by assigning them a common id= entifier
> > when they are created.
>
> Yeah I think it adds value to have the References header. =A0I just > don't think it should be referencing Call-ID's, or else we'= ;ll have to
> replace that too. =A0It should be referencing Session-ID's or
> secure-call-id's. =A0:)

Certainly in security-sensitive situations, referencing Call-IDs, or at
least, ones created by UAs, would be undesirable. =A0But down in section 5.2 it describes how to have the B2BUA generate "linking" identif= iers:

=A0 A possible solution to this problem is for the B2BUA to create a
=A0 "phantom" Call-Id that is suitably random, and use it in Ref= erences
=A0 headers sent in both the initial request and response. =A0By the
=A0 transitivity property[Section 2], the dialogs on both sides of the
=A0 B2BUA are declared to be related, even if the referenced dialog
=A0 contains no messages.

=A0 For two chained B2BUAs with no forking, this would give a message
=A0 flow like this:

=A0 =A0 =A0 UA 1 =A0 =A0 =A0 =A0 =A0 =A0B2BUA 1 =A0 =A0 =A0 =A0 B2BUA 2 = =A0 =A0 =A0 =A0 UA 2

=A0 =A0 =A0 =A0 =A0 =A0--->
=A0 =A0 =A0 =A0 =A0 =A0INVITE 123@aa= .example.com
=A0 =A0 =A0 =A0 =A0 =A0Call-Id: qwerty@aa

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--->
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0INVITE 123@transit.example.com
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Call-Id: asdfgh@tra= nsit
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0References: QAZWSXE= DCRFV;rel=3Dserial

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0--->
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0INVITE 123@bb.example.= com
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0Call-Id: zxcvbn@bb
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0References: QAZWSXEDCRFV
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 ;rel=3Dserial

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0<---
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0SIP/2.0 200 OK
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0Call-Id: zxcvbn@bb

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<---
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SIP/2.0 200 OK
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Call-Id: asdfgh@tra= nsit
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0References: QAZWSXE= DCRFV;rel=3Dserial

=A0 =A0 =A0 =A0 =A0 =A0<---
=A0 =A0 =A0 =A0 =A0 =A0SIP/2.0 200 OK
=A0 =A0 =A0 =A0 =A0 =A0Call-Id: qwerty@aa
=A0 =A0 =A0 =A0 =A0 =A0References: QAZWSXEDCRFV;rel=3Dserial

Dale


_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs= .columbia.edu for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip

--0016e6dd966fdf34950465f85aff-- From drage@alcatel-lucent.com Wed Mar 25 15:31:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9883A6C1D for ; Wed, 25 Mar 2009 15:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 878PrQjJKKpA for ; Wed, 25 Mar 2009 15:31:13 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 8F9C028C179 for ; Wed, 25 Mar 2009 15:31:12 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2PMW3CR026469 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 23:32:03 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 25 Mar 2009 23:32:03 +0100 From: "DRAGE, Keith (Keith)" To: Venkatesh , Dale Worley Date: Wed, 25 Mar 2009 23:32:00 +0100 Thread-Topic: [Sip] comments on draft-kaplan-sip-session-id-01 Thread-Index: Acmtkm0N4CijZeXvQ0euYZDnGM/86AABsZbQ Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE70C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49C507BB.9010804@cisco.com> <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> <1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com> <4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> In-Reply-To: <4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_28B7C3AA2A7ABA4A841F11217ABE78D6757BE70CFRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:31:14 -0000 --_000_28B7C3AA2A7ABA4A841F11217ABE78D6757BE70CFRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This only works if essentially your insertion and deletion requirements of = the header are the same as those required by your accounting system. Keith ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Venka= tesh Sent: Wednesday, March 25, 2009 9:41 PM To: Dale Worley Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 A crazy thought occurred to me while I was reading this draft. If the inten= t is for debugging and such, I am wondering if there is any value in consid= ering the re-use of the P-Charging-Vector header for this purpose? After al= l, this is supposed to be unique, required to be carried across Proxies, B2= BUA's if one is present, reflected in CDR's if one is generated by an entit= y?? Agree that this header had specific intents and cannot span across "tru= st" boundaries, but I am not sure if a SP cares when the request 'leaves' t= heir trust boundary? It seems to satisfy the requirement for debugging? Fla= me away :-). Venkatesh On Wed, Mar 25, 2009 at 1:59 PM, Dale Worley > wrote: On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote: > > If I may be immodest, the References header could a solution: State > > that two dialogs are related to each other by (effectively) naming both > > call-id's together, rather than by assigning them a common identifier > > when they are created. > > Yeah I think it adds value to have the References header. I just > don't think it should be referencing Call-ID's, or else we'll have to > replace that too. It should be referencing Session-ID's or > secure-call-id's. :) Certainly in security-sensitive situations, referencing Call-IDs, or at least, ones created by UAs, would be undesirable. But down in section 5.2 it describes how to have the B2BUA generate "linking" identifiers: A possible solution to this problem is for the B2BUA to create a "phantom" Call-Id that is suitably random, and use it in References headers sent in both the initial request and response. By the transitivity property[Section 2], the dialogs on both sides of the B2BUA are declared to be related, even if the referenced dialog contains no messages. For two chained B2BUAs with no forking, this would give a message flow like this: UA 1 B2BUA 1 B2BUA 2 UA 2 ---> INVITE 123@aa.example.com Call-Id: qwerty@aa ---> INVITE 123@transit.example.com Call-Id: asdfgh@transit References: QAZWSXEDCRFV;rel=3Dserial ---> INVITE 123@bb.example.com Call-Id: zxcvbn@bb References: QAZWSXEDCRFV ;rel=3Dserial <--- SIP/2.0 200 OK Call-Id: zxcvbn@bb <--- SIP/2.0 200 OK Call-Id: asdfgh@transit References: QAZWSXEDCRFV;rel=3Dserial <--- SIP/2.0 200 OK Call-Id: qwerty@aa References: QAZWSXEDCRFV;rel=3Dserial Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the a= pplication of sip --_000_28B7C3AA2A7ABA4A841F11217ABE78D6757BE70CFRMRSSXCHMBSB3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This only works if essentially your insertion and = deletion=20 requirements of the header are the same as those required by your accountin= g=20 system.
 
Keith

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Venkatesh
Sent:=20 Wednesday, March 25, 2009 9:41 PM
To: Dale Worley
Cc:= IETF=20 SIP List
Subject: Re: [Sip] comments on=20 draft-kaplan-sip-session-id-01

A crazy thought occurred to me while I was reading this draft.= If=20 the intent is for debugging and such, I am wondering if there is any valu= e in=20 considering the re-use of the P-Charging-Vector header for this purpose? = After=20 all, this is supposed to be unique, required to be carried across Proxies= ,=20 B2BUA's if one is present, reflected in CDR's if one is generated by an=20 entity?? Agree that this header had specific intents and cannot span acro= ss=20 "trust" boundaries, but I am not sure if a SP cares when the request 'lea= ves'=20 their trust boundary? It seems to satisfy the requirement for debugging? = Flame=20 away :-).

Venkatesh

On Wed, Mar 25, 2009 at 1:59 PM, Dale Worley <dworley@nortel.com> wrot= e:
On=20 Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote:
> > If I= may=20 be immodest, the References header could a solution:  State
>= ;=20 > that two dialogs are related to each other by (effectively) naming= =20 both
> > call-id's together, rather than by assigning them a c= ommon=20 identifier
> > when they are created.
>
> Yeah I t= hink=20 it adds value to have the References header.  I just
> don't= =20 think it should be referencing Call-ID's, or else we'll have to
>= =20 replace that too.  It should be referencing Session-ID's or
>= ;=20 secure-call-id's.  :)

Certainly in security-sensitive=20 situations, referencing Call-IDs, or at
least, ones created by UAs, = would=20 be undesirable.  But down in section
5.2 it describes how to ha= ve=20 the B2BUA generate "linking" identifiers:

  A possible solu= tion=20 to this problem is for the B2BUA to create a
  "phantom" Call-I= d=20 that is suitably random, and use it in References
  headers sen= t in=20 both the initial request and response.  By the
  transitiv= ity=20 property[Section 2], the dialogs on both sides of the
  B2BUA a= re=20 declared to be related, even if the referenced dialog
  contain= s no=20 messages.

  For two chained B2BUAs with no forking, this wo= uld=20 give a message
  flow like this:

      UA= 1=20            B2BUA 1       &= nbsp;=20 B2BUA 2         UA 2

      &n= bsp;=20    --->
           INVITE= 123@aa.example.com
  &nb= sp;=20        Call-Id: qwerty@aa

    &nbs= p;=20                    =20  --->
               = ;=20            INVITE 123@transit.example.com
=  =20                     &= nbsp;=20    Call-Id: asdfgh@transit
        &nb= sp;=20                  Reference= s:=20 QAZWSXEDCRFV;rel=3Dserial

          &nb= sp;=20                     &= nbsp;=20          --->
       = ;=20                     &= nbsp;=20              INVITE 123@bb.example.com
  &nb= sp;=20                     &= nbsp;=20                  Call-Id:= =20 zxcvbn@bb
                &n= bsp;=20                     &= nbsp;=20    References: QAZWSXEDCRFV
        &n= bsp;=20                     &= nbsp;=20                =20 ;rel=3Dserial

              &= nbsp;=20                     &= nbsp;=20      <---
           = ;=20                     &= nbsp;=20          SIP/2.0 200 OK
     = ;=20                     &= nbsp;=20                Call-Id:=20 zxcvbn@bb

               = ;=20            <---
     = ;=20                    =20  SIP/2.0 200 OK
             = ;=20              Call-Id:=20 asdfgh@transit
              &nbs= p;=20            References:=20 QAZWSXEDCRFV;rel=3Dserial

         =20  <---
           SIP/2.0 200=20 OK
           Call-Id: qwerty@aa
&n= bsp;=20          References:=20 QAZWSXEDCRFV;rel=3Dserial

Dale


______________________= _________________________
Sip=20 mailing list  https://www.ietf.org/mailman/listinfo/sip
This l= ist is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.co= lumbia.edu=20 for questions on current sip
Use sipping@ietf.org for new developme= nts on=20 the application of=20 sip

--_000_28B7C3AA2A7ABA4A841F11217ABE78D6757BE70CFRMRSSXCHMBSB3d_-- From mary.barnes@nortel.com Wed Mar 25 18:00:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13E83A6832; Wed, 25 Mar 2009 18:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS6QeW3FMEoI; Wed, 25 Mar 2009 18:00:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BEBC13A6805; Wed, 25 Mar 2009 18:00:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2Q11dj20385; Thu, 26 Mar 2009 01:01:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ADAE.65B8940D" Date: Wed, 25 Mar 2009 19:59:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1BF5FD92@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for SIP and SIPPING sessions Thread-Index: AcmsJFwj9yT+3IENTXaCwtMRz44fEQAvPon9ADMxuYU= References: <28B7C3AA2A7ABA4A841F11217ABE78D67577C4DF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF1BF5FD82@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: , Subject: [Sip] FW: [Sipping] Slides for SIP and SIPPING sessions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:00:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ADAE.65B8940D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 A reminder that we need all the charts for Friday's SIPPING WG session = no later than 1500 tomorrow (Thursday, March 26) so that we can get them = all uploaded and on a single computer for presenting. So, far we've = gotten one presentation.=20 If you could please send the charts to both sets of chairs, that would = be helpful, since this is another mixed session covering SIP and SIPPING = chartered/mature drafts. Thanks, Mary.=20 -----Original Message----- From: sipping-bounces@ietf.org on behalf of DRAGE, Keith (Keith) Sent: Mon 3/23/2009 9:00 PM To: sip@ietf.org; sipping Cc: sip-chairs@tools.ietf.org; sipping-chairs@tools.ietf.org Subject: [Sipping] Slides for SIP and SIPPING sessions =20 (As SIP WG chair) Please make sure you submit your slides well before the start of the = sessions of SIP or SIPPING in which you are presenting. We would suggest = deadlines of: Tuesday 13:00 session - submit by Tuesday 9:00 Wednesday 13:00 session - submit by Wednesday 9:00 Friday 9:00 session - submit by Thursday 15:00 These are the latest time for submission - there is nothing wrong with = sending them to us early. To avoid confusion, you may want to send them to both sets of chairs, = given the combined nature of the agenda this time round. regards Keith _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C9ADAE.65B8940D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [Sipping] Slides for SIP and SIPPING sessions


A reminder that we need all the charts for Friday's SIPPING WG session = no later than 1500 tomorrow (Thursday, March 26) so that we can get them = all uploaded and on a single computer for presenting. So, far we've = gotten one presentation.

If you could please send the charts to both sets of chairs, that would = be helpful, since this is another mixed session covering SIP and SIPPING = chartered/mature drafts.

Thanks,
Mary.


-----Original Message-----
From: sipping-bounces@ietf.org on behalf of DRAGE, Keith (Keith)
Sent: Mon 3/23/2009 9:00 PM
To: sip@ietf.org; sipping
Cc: sip-chairs@tools.ietf.org; sipping-chairs@tools.ietf.org
Subject: [Sipping] Slides for SIP and SIPPING sessions

(As SIP WG chair)

Please make sure you submit your slides well before the start of the = sessions of SIP or SIPPING in which you are presenting. We would suggest = deadlines of:

Tuesday 13:00 session - submit by Tuesday 9:00
Wednesday 13:00 session - submit by Wednesday 9:00
Friday 9:00 session - submit by Thursday 15:00

These are the latest time for submission - there is nothing wrong with = sending them to us early.

To avoid confusion, you may want to send them to both sets of chairs, = given the combined nature of the agenda this time round.

regards

Keith
_______________________________________________
Sipping mailing list  https://www.ietf.o= rg/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

------_=_NextPart_001_01C9ADAE.65B8940D-- From abhatnagar192006@gmail.com Wed Mar 25 18:51:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0F13A6AAF for ; Wed, 25 Mar 2009 18:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, SARE_UNSUB31=0.464] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f16xhty81XQE for ; Wed, 25 Mar 2009 18:51:17 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 4103928C170 for ; Wed, 25 Mar 2009 18:51:17 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2508426rvb.5 for ; Wed, 25 Mar 2009 18:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=57KpApXkvi7SpeVRbbVRDAlMOvAuZ+Md7lDd5XxlR8g=; b=oPKzKDl1Ro5qEuFS8Kc+KP+JOEJ/X9o3qDUE42oiENLcJ7Pcru4QBQ5pTDtzU/AO5w uSF45VTrDZwqBw182YTkj4o1f2q9mPD+7z3R/diqda7cv7TxuwdV4pGUcrJURmnc3VeK lkUhX193IzASfabbrY7WOMNMFLQ6qEo/+SU3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Sx40b5Mfuwf1E9N7FQR1tXPwLcTNaLe67MuOHgenpPASQkZlzewC0pXupsvJFYrZ6E 5yj3eLtE+NdfZVMQsLElMWg+mNYYhRVnnhxnshmOou+HU8y4ZhUWvBKQQum0WnyTvqJf CZLiqZwSbmEA2c3290EpO4h+W3JyinFjpfkVI= MIME-Version: 1.0 Received: by 10.142.177.5 with SMTP id z5mr104702wfe.346.1238032330171; Wed, 25 Mar 2009 18:52:10 -0700 (PDT) In-Reply-To: <49CA958A.5060108@cisco.com> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <1237940172.443.35.camel@victoria-pingtel-com.us.nortel.com> <49CA3A52.8050903@cisco.com> <49CA958A.5060108@cisco.com> Date: Thu, 26 Mar 2009 02:22:10 +0030 Message-ID: From: aayush bhatnagar To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:51:19 -0000 I am in favor of dialog reuse as long as i can achieve something by it practically. Coming from the IMS world, i am always on the lookout for creating interesting sip apps around new concepts. This RFC, i think also imposes certain functionality on the sip client (clients being in a very sorry state in IMS). aayush On 3/25/09, Paul Kyzivat wrote: > > > aayush bhatnagar wrote: >>>Go read 5057. The usages are to be handled separately. So this should >> *not* provoke the UAC >to clean up its INVITE dialog usage. >> >> I have read the relevant RFC. From 5057: > > OK, sorry. It just sounded like you might not have. > >> -Existing implementations that destroy all other usages in the dialog >> will continue to function as -they do now, except that peers following >> the recommendation will attempt to do things with the -other usages and >> this element will return 481s for each of them until they are all gone. >> >> I think it is more feasible to destroy the entire dialog, than keeping >> on to 'hung' state until all the dialog usages are all gone as suggested >> above. I am familiar with implementations that clean up dialog state >> when they get a 481-dialog does not exist response, even if there were >> other 'active' usages of that dialog. > > I'm not surprised. Its often "more feasible" to do the wrong thing than > the right thing. But that doesn't make it right. While its not written > in black and white in 3261, there is enough info there to infer that you > need to treat them separately. > >> The reason being, that if an implementation cannot find a matching >> dialog as characterized by the local tag, remote tag, call-id, local and >> remote sequence nos etc and has rejected the request by a 481, there is >> no point in keeping the dialog state at the UAC. > > This is all hashed out in 5057. The problem is that the 481 response is > *ambiguous*. The way to maximize interop is to treat the 481 as meaning > the least serious thing that it could mean - that only the usage has > gone away. If it turns out that the whole dialog went away, then you > will eventually find that out anyway. Of course it doesn't hurt to treat > it as meaning all the usages went away if you would not continue all of > them anyway. But if the other usage(s) continue to be of value then it > you are hurting yourself by assuming they have gone away when they might > not have. > >> As for example, if you receive a 481 response for a REFER sent within >> the INVITE dialog, there is no point in keeping the REFER usage alive. >> You probably sent the REFER to transfer a call, which the server >> complains that the call itself does not exist (481). > > That's not the case of relevance. If you got a 481 for a REFER, the > refer of course failed, and so there is no refer usage to keep alive. > > We are still, in this thread, trying to decide what a 481 to a REFER > means. I think it won't be ambiguous - that it can *only* mean that the > whole dialog is gone, since it is never associated with a preexisting usage. > > Even so, you would be well advised to probe any existing usages with > in-usage messages to verify if they are alive, even though most likely > they are not. > >> Moreover from 5057: >> >> -Processing multiple usages correctly is not completely understood. >> -What is understood is difficult to implement and is very likely to >> -lead to interoperability problems. The best way to avoid the trouble >> -that comes with such complexity is to avoid it altogether. >> -When designing new applications or features that use SIP dialogs, do >> -not require endpoints to construct multiple usages to participate in >> -the application or use the feature. >> >> This is very true. By defining multiple dialog usages, you are >> essentially extending the dialog state (as defined by 3261) by adding >> more attributes to it (such as subscription duration etc). I cant think >> of a practical use case, where a subscription that shared the invite >> dialog usage still needed to be preserved, even when the original INVITE >> dialog was no longer active. > > We aren't *adding more attributes to it*. It is what it is and has been. > It has been implicitly legal in spite of the problems. And it *is* used. > There are even reasonable use cases for independent termination of the > usages. For instance, a refer usage sharing a dialog with an invite > usage may meaningfully survive after the invite usage terminates. > >> As for example a subscription to the 'conference' event package sent >> within the scope of an INVITE dialog. If i leave the conference by >> sending a BYE, and my subscription's duration is still valid for an >> hour...will i still keep on getting redundant SIP notifications for >> changes to the membership to that conference ? > > >> In the sense of 5057, the >> subscribe usage will be preserved until it expires, or until the UAC >> explicitly un-subscribes, or the conference server has to send me a >> final NOTIFY with my subsription-state = terminated. > > IMO that is exactly as it *should* be. If the subscriber doesn't want to > maintain the subscription, it can simply wipe out the state of the > subscription. Then when another NOTIFY is received, a 481 will be sent > because there is no state, forcing the end of the usage. > > But *assuming* that the subscription *should* go away when the invite > ends is, IMO, wrong. There may be valid reasons to retain the subscription. > >> It is not important that 5057 is allowing us many theoretical >> possibilities by presenting multiple dialog usages. >> >> What is more important is what extra do we get by reusing a dialog, and >> how do implementations leverage upon such a possibility and create >> meaningful applications around it ? >> >> I would like to share some examples: >> >> 1. As for example an application that can practically leverage upon 5057 >> may send a SUBSCRIBE to the 'dialog' event package (rfc 4235) that >> reuses the INVITE dialog can be used for creating SIP call tracing >> applications. >> >> 2. Other Implementations may include automatic callback applications by >> this mechanism (ring back when my sip phone is idle) etc. >> >> 3. Yet another application may send me by pre-paid account balance after >> i disconnect my ongoing dialog, as it is subscribed to my dialog state. >> >> In all these example applications, the endpoint receiving the SUBSCRIBE >> will need to send a NOTIFY that re-uses its existing INVITE dialog >> (NOTIFY acting as a target refresh in the sense of 5057). > > Sounds like you are in favor of dialog reuse. > > Paul > >> Best Regards >> >> aayush >> >> >> On Wed, Mar 25, 2009 at 7:36 PM, Paul Kyzivat > > wrote: >> >> >> >> aayush bhatnagar wrote: >> >> If you send an in dialog request (REFER in our case), then you >> cannot >> decouple its semantics with the existing dialog usage. >> >> >> You say "*the* dialog usage" as if there can be only one. There >> could be more than one. It might be coupled to: >> - the *only* existing usage >> - to *one* of several existing usages >> - to *none* of the one or more existing usages >> >> For instance, I could have a dialog with just an INVITE usage (the >> common case) and within that dialog send a REFER of a MESSAGE. That >> MESSAGE really has nothing to do with the INVITE usage. >> >> >> So saying that >> even if i send a REFER within an existing dialog, and still >> decouple >> it from the existing dialog usage will not be possible. >> If there were such a requirement, then REFER should have been >> sent as >> a standalone dialog creating request outside the INVITE usage. >> >> >> One can argue that it *should* have been. But that isn't the point >> of this discussion. In many cases using the same dialog as been an >> expedient to ensure reaching the same UA when you aren't sure the >> remote target url for the dialog is in fact routable. >> >> >> The recipient of the in dialog REFER will treat it like it >> should any >> in dialog request. It has no way to decide if this request >> potentially >> had nothing to do with the existing dialog usage. >> >> >> You are being sloppy in your use of "dialog" and "dialog usage", as >> if you are not familiar with RFC 5057. If you aren't, please read it. >> >> >> i agree with you when you say that an indialog refer receiving a >> 481 >> would mean that the INVITE dialog has been torn down. >> >> >> See my reply to Dale. >> >> >> However, a refer dialog usage can also terminate, if the UAC sends >> a >> 481 in response to the NOTIFY sent by the UAS (Suppose the >> transaction >> did not match). >> >> >> You need to spell out more details of the case. If it were the >> *first* NOTIFY, resulting from an in-dialog REFER, then that >> response would be indicative of a screwup somewhere. >> >> However, if there had been a prior NOTIFY on the refer subscription >> that indicated that the subscription was over, and then somehow >> *another* NOTIFY was sent, the 481 would be appropriate, indicating >> that the refer-usage was no longer present. >> >> >> This scenario may happen irrespective of whether the >> REFER was within the invite usage or created its own distinct >> dialog. >> If this happens when REFER was sent within an Invite dialog, >> then the >> UAC will be mistaken to clean up its INVITE dialog state. >> >> >> Go read 5057. The usages are to be handled separately. So this >> should *not* provoke the UAC to clean up its INVITE dialog usage. >> >> >> I did not understand one part in the paradox above when you >> said... >> "A REFER within an established dialog having no invite usage to be >> considered as an out of dialog REFER" >> Do you mean to imply a REFER in some other Subscribe event package >> dialog for example? >> >> >> Yes, that is what I meant. I don't have any meaningful cases in >> mind, but it is a theoretical possibility. >> >> Paul >> >> >> aayush. >> >> On 3/25/09, Dale Worley > > wrote: >> >> On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote: >> >> I would argue that the REFER is part of the INVITE >> usage, because REFER >> in that context is intimately related to the INVITE >> usage -- it is >> intended to transfer the INVITE usage/dialog >> transferred to a different >> destination. >> >> Well, I guess there is that implied association. (Part >> of the "do what >> *I* had in mind" approach that REFER has.) Since this >> was never spelled >> out, it could also be simply "while this isn't part of >> an INVITE usage, >> if there happens to be an INVITE usage, please refer >> that one." >> >> I guess the question is: would it be valid to send a >> REFER within an >> existing dialog that had no INVITE usage? If it were >> valid, presumably >> it would have the same meaning as sending one outside a >> dialog, except >> that the resulting subscription would share the dialog. >> I expect that is >> a usage it would be difficult to find in the wild. >> >> That's a nice pathological case. But within the context of >> the current >> 5 possible meanings of REFER, it seems to be most parallel >> to the >> out-of-dialog REFER. >> >> Ah, but now I want to reconsider. Remember that REFER >> can take a method >> name. So, rather than referring an INVITE, I could be >> referring MESSAGE, >> OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of >> those cases, the >> association to the INVITE usage is probably meaningless. >> (Of course its >> meaningful for BYE.) >> >> A fascinating possibility! But I'm not sure that we've ever >> defined how >> a REFER within a simple INVITE dialog, specifying a >> non-INVITE method >> should act. So there's no analog to follow. >> >> And it seems quite safe that if the REFER receives a >> 481 response, the >> INVITE usage must not be functional any more, since >> the far end of that >> usage has denied that it can act on the REFER. >> >> IIRC, 5057 decided that each dialog usage must get its >> own 481 before it >> goes away. I don't think there are any cases where a >> single 481 response >> can make multiple usages go away. >> >> So the important question is whether the REFER is part >> of the INVITE >> usage and so its 481 takes down the INVITE usage or not. >> That gets >> especially interesting if the dialog already had both >> an INVITE usage >> and a SUBSCRIBE usage. Does it make sense that the refer >> take down the >> INVITE usage and leave up the SUBSCRIBE usage? >> >> I think we're a victim of sloppy terminology here. If I >> send a REFER, >> and the far end responds 481, then clearly the far end knows >> of no >> INVITE usage, or otherwise it would not have responded 481. >> So I should >> delete my belief that there is an INVITE usage. Whether we >> consider the >> REFER in question to be "part of" the INVITE usage or not >> doesn't change >> anything -- the 481 is evidence that the far end has no >> knowledge of the >> usage. >> >> However, we do have this fine paradox: If we assume that a >> REFER within >> an established dialog that has no INVITE usage is to be >> treated as an >> out-of-dialog REFER, then *no* REFER will receive a 481 >> response! >> Indeed, if I send a REFER thinking that there is an active >> INVITE usage, >> but the far end believes the INVITE usage has ended, will >> cause the far >> end to do something (initiate an independent dialog) that is >> considerably different from what I expected (transfer the >> current INVITE >> usage). >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current sip >> Use sipping@ietf.org for new >> developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu >> for questions on >> current sip >> Use sipping@ietf.org for new >> developments on the application of sip >> >> > From HKaplan@acmepacket.com Wed Mar 25 19:38:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3047C3A6809 for ; Wed, 25 Mar 2009 19:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgpO28l9I3Bk for ; Wed, 25 Mar 2009 19:38:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5E3683A6804 for ; Wed, 25 Mar 2009 19:38:49 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 22:39:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 25 Mar 2009 22:39:40 -0400 From: Hadriel Kaplan To: Venkatesh , Jonathan Rosenberg Date: Wed, 25 Mar 2009 22:39:41 -0400 Thread-Topic: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 Thread-Index: AcmtkZAgXok3sb6ZQv2i217Ar6G6wAAKEGcQ Message-ID: References: <49CA9943.1020808@cisco.com> <4ff4e7370903251434w2ef77beci231f3e2c4e42d2dc@mail.gmail.com> In-Reply-To: <4ff4e7370903251434w2ef77beci231f3e2c4e42d2dc@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFE9DFmail_" MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:38:55 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFE9DFmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 3261 made the @ and after it optional in ABNF. So a strict parser to 3= 261 must allow it. In fact we've seen plenty of Call-ID's without it, from= some very common equipment. We just can't change the BNF because a strict parser parsing to this new dr= aft would not accept 3261 call-id's. -hadriel ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Venka= tesh Sent: Wednesday, March 25, 2009 5:35 PM To: Jonathan Rosenberg Cc: IETF SIP List Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 Hello: I am not sure that this alone will fix the problem in totality. If I were t= o use the reverse analogy i.e. what if a UA that conforms to this specifica= tion offers the request to a "aggressive parsing" UA that is only compliant= with RFC 3261? If we are not planning on changing the BNF, I am wondering if this draft sh= ould simply say that the string after the "@" sign MUST NOT include a domai= n name, host address, MAC....? Or if this is ambiguous, simply say that the= UA MUST generate *another* cryptographic identifier to be placed after the= @ sign? Thanks, Venkatesh On Wed, Mar 25, 2009 at 1:51 PM, Jonathan Rosenberg > wrote: I didnt get a chance to say this at the mike. You *cannot* change the BNF for the call-id. If you did, you might end up w= ith the following problem: A new UA gets built, compliant to this update. It is one of these 'aggressi= ve parsing' UAs. It rejects any message which is not compliant to the BNF. = An older, normal RFC-3261 compliant UA sends a call-id which includes the @= -sign. According to the BNF of this updated 3261, and based on the strictness of t= his aggressive-parsing UAs, it rejects that request as non-compliant. As such, you need to keep the BNF, but change the normative language such t= hat an endpoint MUST NOT include the [@ host] but MUST be prepared to recei= ve it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the a= pplication of sip --_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFE9DFmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

RFC 3261 made the @ and after it optio= nal in ABNF.  So a strict parser to 3261 must allow it.  In fact we&#= 8217;ve seen plenty of Call-ID’s without it, from some very common equipment. =

We just can’t change the BNF bec= ause a strict parser parsing to this new draft would not accept 3261 call-idR= 17;s.

-hadriel

 

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Venkatesh
Sent: Wednesday, March 25, 2= 009 5:35 PM
To: Jonathan Rosenberg
Cc: IETF SIP List
Subject: Re: [Sip] The probl= em with draft-kaplan-sip-secure-call-id-00

 

Hello:

 

I am not sure that this alone will fix the problem in totality. If = I were to use the reverse analogy i.e. what if a UA that conforms to this specification offers the request to a "aggressive parsing" UA tha= t is only compliant with RFC 3261?

 

If we are not planning on changing the BNF, I am wondering if this draft should simply say that the string after the "@" sign MUST N= OT include a domain name, host address, MAC....? Or if this is ambiguous, simply say that the UA MUST generate *another* cryptographic identifier to = be placed after the @ sign?

 

Thanks,

Venkatesh

On Wed, Mar 25, 2009 at 1:51 PM, Jonathan Rosenberg <jdrosen@cisco.com> wrote:

I didnt get a chance to say this at the mike.

You *cannot* change the BNF for the call-id. If you did, you might end up w= ith the following problem:

A new UA gets built, compliant to this update. It is one of these 'aggressi= ve parsing' UAs. It rejects any message which is not compliant to the BNF. An older, normal RFC-3261 compliant UA sends a call-id which includes the @-si= gn.

According to the BNF of this updated 3261, and based on the strictness of t= his aggressive-parsing UAs, it rejects that request as non-compliant.

As such, you need to keep the BNF, but change the normative language such t= hat an endpoint MUST NOT include the [@ host] but MUST be prepared to receive i= t.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.             &nbs= p;     111 Wood Ave= nue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net=                      = ;   PHONE: (408) 902-3084
http://www.cisco.com=
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use s= ip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org<= /a> for new developments on the application of sip

 

--_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFE9DFmail_-- From HKaplan@acmepacket.com Wed Mar 25 19:43:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E173A6B49 for ; Wed, 25 Mar 2009 19:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzNHm74Exywn for ; Wed, 25 Mar 2009 19:43:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 265773A6D9F for ; Wed, 25 Mar 2009 19:43:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 22:44:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 25 Mar 2009 22:44:03 -0400 From: Hadriel Kaplan To: Venkatesh , Dale Worley Date: Wed, 25 Mar 2009 22:44:04 -0400 Thread-Topic: [Sip] comments on draft-kaplan-sip-session-id-01 Thread-Index: Acmtknk6amLwU0OcReid5V8AsBK5pgAKatYg Message-ID: References: <49C507BB.9010804@cisco.com> <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> <1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com> <4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> In-Reply-To: <4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFE9E5mail_" MIME-Version: 1.0 Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:43:13 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFE9E5mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yeah JDR mentioned the same thing. Unfortunately that header value is crea= ted by middleboxes and removed by middleboxes. -hadriel ________________________________ From: Venkatesh [mailto:vvenkatar@gmail.com] Sent: Wednesday, March 25, 2009 5:41 PM To: Dale Worley Cc: Hadriel Kaplan; IETF SIP List Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 A crazy thought occurred to me while I was reading this draft. If the inten= t is for debugging and such, I am wondering if there is any value in consid= ering the re-use of the P-Charging-Vector header for this purpose? After al= l, this is supposed to be unique, required to be carried across Proxies, B2= BUA's if one is present, reflected in CDR's if one is generated by an entit= y?? Agree that this header had specific intents and cannot span across "tru= st" boundaries, but I am not sure if a SP cares when the request 'leaves' t= heir trust boundary? It seems to satisfy the requirement for debugging? Fla= me away :-). Venkatesh On Wed, Mar 25, 2009 at 1:59 PM, Dale Worley > wrote: On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote: > > If I may be immodest, the References header could a solution: State > > that two dialogs are related to each other by (effectively) naming both > > call-id's together, rather than by assigning them a common identifier > > when they are created. > > Yeah I think it adds value to have the References header. I just > don't think it should be referencing Call-ID's, or else we'll have to > replace that too. It should be referencing Session-ID's or > secure-call-id's. :) Certainly in security-sensitive situations, referencing Call-IDs, or at least, ones created by UAs, would be undesirable. But down in section 5.2 it describes how to have the B2BUA generate "linking" identifiers: A possible solution to this problem is for the B2BUA to create a "phantom" Call-Id that is suitably random, and use it in References headers sent in both the initial request and response. By the transitivity property[Section 2], the dialogs on both sides of the B2BUA are declared to be related, even if the referenced dialog contains no messages. For two chained B2BUAs with no forking, this would give a message flow like this: UA 1 B2BUA 1 B2BUA 2 UA 2 ---> INVITE 123@aa.example.com Call-Id: qwerty@aa ---> INVITE 123@transit.example.com Call-Id: asdfgh@transit References: QAZWSXEDCRFV;rel=3Dserial ---> INVITE 123@bb.example.com Call-Id: zxcvbn@bb References: QAZWSXEDCRFV ;rel=3Dserial <--- SIP/2.0 200 OK Call-Id: zxcvbn@bb <--- SIP/2.0 200 OK Call-Id: asdfgh@transit References: QAZWSXEDCRFV;rel=3Dserial <--- SIP/2.0 200 OK Call-Id: qwerty@aa References: QAZWSXEDCRFV;rel=3Dserial Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the a= pplication of sip --_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFE9E5mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yeah JDR mentioned the same thing. &nb= sp;Unfortunately that header value is created by middleboxes and removed by middleboxes.

-hadriel

 

 

From: Venkates= h [mailto:vvenkatar@gmail.com]
Sent: Wednesday, March 25, 2= 009 5:41 PM
To: Dale Worley
Cc: Hadriel Kaplan; IETF SIP List
Subject: Re: [Sip] comments = on draft-kaplan-sip-session-id-01

 

A crazy thought occurred to me while I was reading this draft. If t= he intent is for debugging and such, I am wondering if there is any value in c= onsidering the re-use of the P-Charging-Vector header for this purpose? After all, thi= s is supposed to be unique, required to be carried across Proxies, B2BUA's if on= e is present, reflected in CDR's if one is generated by an entity?? Agree that t= his header had specific intents and cannot span across "trust" boundaries, but I am not sure if a SP cares when the request 'leaves' their trust boundary? It seems to satisfy the requirement for debugging? Flame aw= ay :-).

 

Venkatesh

On Wed, Mar 25, 2009 at 1:59 PM, Dale W= orley <dworley@nortel.com> wrote:=

On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote:
> > If I may be immodest, the References header could a solution:  State
> > that two dialogs are related to each other by (effectively) namin= g both
> > call-id's together, rather than by assigning them a common identi= fier
> > when they are created.
>
> Yeah I think it adds value to have the References header.  I just=
> don't think it should be referencing Call-ID's, or else we'll have to<= br> > replace that too.  It should be referencing Session-ID's or
> secure-call-id's.  :)

Certainly in security-sensitive situations, referencing Call-IDs, or at
least, ones created by UAs, would be undesirable.  But down in section=
5.2 it describes how to have the B2BUA generate "linking" identifiers:

  A possible solution to this problem is for the B2BUA to create a
  "phantom" Call-Id that is suitably random, and use it in References
  headers sent in both the initial request and response.  By the<= br>   transitivity property[Section 2], the dialogs on both sides of the   B2BUA are declared to be related, even if the referenced dialog
  contains no messages.

  For two chained B2BUAs with no forking, this would give a message   flow like this:

      UA 1            B2BUA 1         B2BUA 2         UA 2

           --->
           INVITE 123@aa.example.com
           Call-Id: qwerty@aa

                     = ;      --->
                     = ;      INVITE 123@t= ransit.example.com
                     = ;      Call-Id: asdfgh@transit
                     = ;      References: QAZWSXEDCRFV;rel=3Dserial

                     = ;                      --->
                     = ;                      INVITE 123@bb.example.com                      = ;                      Call-Id: zxcvbn@bb
                     = ;                      References: QAZWSXEDCRFV
                     = ;                      = ;     ;rel=3Dserial

                     = ;                      <---
                     = ;                      SIP/2.0 200 OK
                     = ;                      Call-Id: zxcvbn@bb

                     = ;      <---
                     = ;      SIP/2.0 200 OK
                     = ;      Call-Id: asdfgh@transit
                     = ;      References: QAZWSXEDCRFV;rel=3Dserial

           <---
           SIP/2.0 200 OK
           Call-Id: qwerty@aa
           References: QAZWSXEDCRFV;rel=3Dser= ial

Dale


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs= .columbia.edu for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip

 

--_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFE9E5mail_-- From chris@ns-technologies.com Thu Mar 26 07:36:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEFF3A69CD for ; Thu, 26 Mar 2009 07:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KubYn1Bj5mLk for ; Thu, 26 Mar 2009 07:36:25 -0700 (PDT) Received: from mk-filter-1-a-1.mail.uk.tiscali.com (mk-filter-1-a-1.mail.uk.tiscali.com [212.74.100.52]) by core3.amsl.com (Postfix) with ESMTP id 02A463A6920 for ; Thu, 26 Mar 2009 07:36:24 -0700 (PDT) X-Trace: 173132253/mk-filter-1.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/88.109.242.182/None/chris@ns-technologies.com X-SBRS: None X-RemoteIP: 88.109.242.182 X-IP-MAIL-FROM: chris@ns-technologies.com X-MUA: Thunderbird 2.0.0.21 (Windows/20090302) X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0BAGMwy0lYbfK2/2dsb2JhbAAIj3vDc4N2Bg X-IronPort-AV: E=Sophos;i="4.38,426,1233532800"; d="scan'208";a="173132253" Received: from 88-109-242-182.dynamic.dsl.as9105.com (HELO [192.168.1.3]) ([88.109.242.182]) by smtp.tiscali.co.uk with ESMTP; 26 Mar 2009 14:37:17 +0000 Message-ID: <49CB9307.4090405@ns-technologies.com> Date: Thu, 26 Mar 2009 14:36:55 +0000 From: Chris Boulton User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Sip] draft-boulton-sip-endpoint-view-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 14:36:26 -0000 Hi, A '00' Draft has been submitted to the IETF archives that can be retrieved from the following link - http://www.ietf.org/internet-drafts/draft-boulton-sip-endpoint-view-00.txt. The draft discusses some problems encountered when using certain SIP mechanisms in an application sequenced environment. All feedback welcomed. Thanks. Chris. From christer.holmberg@ericsson.com Thu Mar 26 10:40:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0A83A6A99 for ; Thu, 26 Mar 2009 10:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcUcL2myXh0Q for ; Thu, 26 Mar 2009 10:40:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A636A3A697B for ; Thu, 26 Mar 2009 10:40:31 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4159E21108 for ; Thu, 26 Mar 2009 18:41:24 +0100 (CET) X-AuditID: c1b4fb3e-adfb9bb000006d6d-b2-49cbbe44505a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 24F90210A4 for ; Thu, 26 Mar 2009 18:41:24 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 18:41:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AE3A.147471E1" Date: Thu, 26 Mar 2009 18:41:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIg== From: "Christer Holmberg" To: X-OriginalArrivalTime: 26 Mar 2009 17:41:23.0844 (UTC) FILETIME=[14E1AC40:01C9AE3A] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:40:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AE3A.147471E1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer ------_=_NextPart_001_01C9AE3A.147471E1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of draft-holmberg-sip-keep

Hi,

I've submitted a new version (-04) of = the keep draft.

The requirement text is now alligned = with the text shown on the slides during the SFO SIP WG = presentation.

There are no other changes in the = document from the previous version.

Regards,

Christer

------_=_NextPart_001_01C9AE3A.147471E1-- From L.Liess@telekom.de Thu Mar 26 10:52:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F8728C269 for ; Thu, 26 Mar 2009 10:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWgXoW0lJRSH for ; Thu, 26 Mar 2009 10:52:12 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 837F328C227 for ; Thu, 26 Mar 2009 10:52:12 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 26 Mar 2009 18:53:04 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 18:53:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AE3B.B5794827" Date: Thu, 26 Mar 2009 18:53:02 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A002CA6CBD@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-kaplan-sip-session-id-02 Thread-Index: Acmtknk6amLwU0OcReid5V8AsBK5pgAKatYgAB5O1YA= References: <49C507BB.9010804@cisco.com><1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com><1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com><4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> From: To: X-OriginalArrivalTime: 26 Mar 2009 17:53:03.0526 (UTC) FILETIME=[B5ECAC60:01C9AE3B] Cc: sip@ietf.org Subject: Re: [Sip] draft-kaplan-sip-session-id-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:52:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AE3B.B5794827 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hadriel, =20 My company operates a SIP service with B2BUAs. We are very interested in the progress of this draftt because without it trubleshooting is in many cases not possible. Every SIP service provider which uses B2BUAs runs sooner or later into this problem. From my point of view, the current version is quite mature and coud become soon a WG item.=20 =20 Laura Liess Deutsche Telekom =20 =20 ------_=_NextPart_001_01C9AE3B.B5794827 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hadriel,
 
My company operates a SIP service with = B2BUAs. We=20 are very interested in the progress of this draftt because without it=20 trubleshooting is in many cases not possible. Every SIP service provider = which=20 uses B2BUAs runs sooner or later into this problem. From my point = of view,=20 the current version is quite mature and coud become soon a WG=20 item. 
 
Laura Liess
Deutsche Telekom
 
  
= ------_=_NextPart_001_01C9AE3B.B5794827-- From mdolly@att.com Thu Mar 26 11:05:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6A43A6B6C for ; Thu, 26 Mar 2009 11:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTkReUVe3mZ3 for ; Thu, 26 Mar 2009 11:05:35 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id A6D063A6358 for ; Thu, 26 Mar 2009 11:05:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-11.tower-121.messagelabs.com!1238090786!28067148!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 30052 invoked from network); 26 Mar 2009 18:06:26 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 26 Mar 2009 18:06:26 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2QI6PG0032075 for ; Thu, 26 Mar 2009 14:06:26 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2QI6Lxu032041 for ; Thu, 26 Mar 2009 14:06:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AE3D.9188A7CA" Date: Thu, 26 Mar 2009 14:06:20 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02B4FEEA@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A002CA6CBD@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-kaplan-sip-session-id-02 Thread-Index: Acmtknk6amLwU0OcReid5V8AsBK5pgAKatYgAB5O1YAAAgmEQA== References: <49C507BB.9010804@cisco.com><1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com><1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com><4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> <40FB0FFB97588246A1BEFB05759DC8A002CA6CBD@S4DE9JSAANI.ost.t-com.de> From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: sip@ietf.org Subject: Re: [Sip] draft-kaplan-sip-session-id-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 18:05:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AE3D.9188A7CA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable We support this draft as well =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of L.Liess@telekom.de Sent: Thursday, March 26, 2009 1:53 PM To: HKaplan@acmepacket.com Cc: sip@ietf.org Subject: Re: [Sip] draft-kaplan-sip-session-id-02 =20 Hadriel, =20 My company operates a SIP service with B2BUAs. We are very interested in the progress of this draftt because without it trubleshooting is in many cases not possible. Every SIP service provider which uses B2BUAs runs sooner or later into this problem. From my point of view, the current version is quite mature and coud become soon a WG item.=20 =20 Laura Liess Deutsche Telekom =20 =20 ------_=_NextPart_001_01C9AE3D.9188A7CA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

We support this draft as well

 

From:= = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of L.Liess@telekom.de
Sent: Thursday, March 26, 2009 1:53 PM
To: HKaplan@acmepacket.com
Cc: sip@ietf.org
Subject: Re: [Sip] = draft-kaplan-sip-session-id-02

 

Hadriel,

 

My company operates a SIP service with B2BUAs. We are = very interested in the progress of this draftt because without it = trubleshooting is in many cases not possible. Every SIP service provider which uses B2BUAs = runs sooner or later into this problem. From my point of view, the = current version is quite mature and coud become soon a WG = item. 

 

Laura Liess

Deutsche Telekom

 

  

------_=_NextPart_001_01C9AE3D.9188A7CA-- From vvenkatar@gmail.com Thu Mar 26 14:31:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D9528C167 for ; Thu, 26 Mar 2009 14:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjgH5D6HLISe for ; Thu, 26 Mar 2009 14:31:54 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0A7B428C160 for ; Thu, 26 Mar 2009 14:31:53 -0700 (PDT) Received: by fxm2 with SMTP id 2so770053fxm.37 for ; Thu, 26 Mar 2009 14:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=69OTwhI/lePjAlM1BK7+5SO4DKdpTKeAHi2BwAVdqE0=; b=CDcODH0OnTx9BJ2rXk6MAK9L/DFVvhGvRcJ+LFoiPfos84yij8cXNfNJwo8LJNcNnh sHOWFisAT0TR7qeYD8iwNBfJlPaBQ9OfQJwoyjpW631KlsY9uUHEc66Ud7UTNy5OyZku XwTBoo5J7ysj/p2MwoY1yQ8GsKkkA1Erjw5Bs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NBCb6gaTRM1c4IlDNVBvKIgOo8HJefi2QKHXRWRAMAeAuCyEHQNVv4qH+1elmijO07 3h3lCEydulJdh1A+G6ZcsbZH9NBfviDureDHmGpzAwUKLqC7BVUbF2QfZwQr9F6cYDcE 26bgH1uagQNW7LFGQ+7ETJYHulCc9KjiF3A98= MIME-Version: 1.0 Received: by 10.103.247.14 with SMTP id z14mr80204mur.70.1238103166624; Thu, 26 Mar 2009 14:32:46 -0700 (PDT) In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE70C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49C507BB.9010804@cisco.com> <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> <1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com> <4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE70C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Thu, 26 Mar 2009 14:32:46 -0700 Message-ID: <4ff4e7370903261432o24afc450xd20bfabf2e0d94b1@mail.gmail.com> From: Venkatesh To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=001636765bbd7126ec04660c5b64 Cc: IETF SIP List Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 21:31:55 -0000 --001636765bbd7126ec04660c5b64 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thought per the 3GPP spec, this header got added at the first ingress point into the network and removed at the last egress point from the network? So, essentially you can trace the call using this header within your network? Venkatesh On Wed, Mar 25, 2009 at 3:32 PM, DRAGE, Keith (Keith) < drage@alcatel-lucent.com> wrote: > This only works if essentially your insertion and deletion requirements > of the header are the same as those required by your accounting system. > > Keith > > ------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On Behalf Of * > Venkatesh > *Sent:* Wednesday, March 25, 2009 9:41 PM > *To:* Dale Worley > *Cc:* IETF SIP List > *Subject:* Re: [Sip] comments on draft-kaplan-sip-session-id-01 > > A crazy thought occurred to me while I was reading this draft. If the > intent is for debugging and such, I am wondering if there is any value in > considering the re-use of the P-Charging-Vector header for this purpose? > After all, this is supposed to be unique, required to be carried across > Proxies, B2BUA's if one is present, reflected in CDR's if one is generated > by an entity?? Agree that this header had specific intents and cannot span > across "trust" boundaries, but I am not sure if a SP cares when the request > 'leaves' their trust boundary? It seems to satisfy the requirement for > debugging? Flame away :-). > Venkatesh > > On Wed, Mar 25, 2009 at 1:59 PM, Dale Worley wrote: > >> On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote: >> > > If I may be immodest, the References header could a solution: State >> > > that two dialogs are related to each other by (effectively) naming >> both >> > > call-id's together, rather than by assigning them a common identifier >> > > when they are created. >> > >> > Yeah I think it adds value to have the References header. I just >> > don't think it should be referencing Call-ID's, or else we'll have to >> > replace that too. It should be referencing Session-ID's or >> > secure-call-id's. :) >> >> Certainly in security-sensitive situations, referencing Call-IDs, or at >> least, ones created by UAs, would be undesirable. But down in section >> 5.2 it describes how to have the B2BUA generate "linking" identifiers: >> >> A possible solution to this problem is for the B2BUA to create a >> "phantom" Call-Id that is suitably random, and use it in References >> headers sent in both the initial request and response. By the >> transitivity property[Section 2], the dialogs on both sides of the >> B2BUA are declared to be related, even if the referenced dialog >> contains no messages. >> >> For two chained B2BUAs with no forking, this would give a message >> flow like this: >> >> UA 1 B2BUA 1 B2BUA 2 UA 2 >> >> ---> >> INVITE 123@aa.example.com >> Call-Id: qwerty@aa >> >> ---> >> INVITE 123@transit.example.com >> Call-Id: asdfgh@transit >> References: QAZWSXEDCRFV;rel=serial >> >> ---> >> INVITE 123@bb.example.com >> Call-Id: zxcvbn@bb >> References: QAZWSXEDCRFV >> ;rel=serial >> >> <--- >> SIP/2.0 200 OK >> Call-Id: zxcvbn@bb >> >> <--- >> SIP/2.0 200 OK >> Call-Id: asdfgh@transit >> References: QAZWSXEDCRFV;rel=serial >> >> <--- >> SIP/2.0 200 OK >> Call-Id: qwerty@aa >> References: QAZWSXEDCRFV;rel=serial >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > --001636765bbd7126ec04660c5b64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thought per the 3GPP spec, this header got added at the first ingress point= into the network and removed at the last egress point from the network? So= , essentially you can trace the call using this header within your network?=

Venkatesh

On Wed, Mar 25, = 2009 at 3:32 PM, DRAGE, Keith (Keith) <drage@alcatel-lucent.com> wrote:=
This only works if essentially your insertion and deletion=20 requirements of the header are the same as those required by your accountin= g=20 system.
=A0
Keith

From: sip-bounces@ietf.org=20 [mailto:sip-bou= nces@ietf.org] On Behalf Of Venkatesh
Sent:=20 Wednesday, March 25, 2009 9:41 PM
To: Dale Worley
Cc:= IETF=20 SIP List
Subject: Re: [Sip] comments on=20 draft-kaplan-sip-session-id-01

A crazy thought occurred to me while I was reading this draft.= If=20 the intent is for debugging and such, I am wondering if there is any valu= e in=20 considering the re-use of the P-Charging-Vector header for this purpose? = After=20 all, this is supposed to be unique, required to be carried across Proxies= ,=20 B2BUA's if one is present, reflected in CDR's if one is generated= by an=20 entity?? Agree that this header had specific intents and cannot span acro= ss=20 "trust" boundaries, but I am not sure if a SP cares when the re= quest 'leaves'=20 their trust boundary? It seems to satisfy the requirement for debugging? = Flame=20 away :-).

Venkatesh

On Wed, Mar 25, 2009 at 1:59 PM, Dale Worley <= span dir=3D"ltr"><dworley@nortel.com> wrote:
On=20 Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote:
> > If I= may=20 be immodest, the References header could a solution: =A0State
>= =20 > that two dialogs are related to each other by (effectively) naming= =20 both
> > call-id's together, rather than by assigning them= a common=20 identifier
> > when they are created.
>
> Yeah I t= hink=20 it adds value to have the References header. =A0I just
> don'= t=20 think it should be referencing Call-ID's, or else we'll have to=
>=20 replace that too. =A0It should be referencing Session-ID's or
&g= t;=20 secure-call-id's. =A0:)

Certainly in security-sensitive=20 situations, referencing Call-IDs, or at
least, ones created by UAs, = would=20 be undesirable. =A0But down in section
5.2 it describes how to have= =20 the B2BUA generate "linking" identifiers:

=A0 A possib= le solution=20 to this problem is for the B2BUA to create a
=A0 "phantom"= Call-Id=20 that is suitably random, and use it in References
=A0 headers sent i= n=20 both the initial request and response. =A0By the
=A0 transitivity=20 property[Section 2], the dialogs on both sides of the
=A0 B2BUA are= =20 declared to be related, even if the referenced dialog
=A0 contains n= o=20 messages.

=A0 For two chained B2BUAs with no forking, this would= =20 give a message
=A0 flow like this:

=A0 =A0 =A0 UA 1=20 =A0 =A0 =A0 =A0 =A0 =A0B2BUA 1 =A0 =A0 =A0 =A0=20 B2BUA 2 =A0 =A0 =A0 =A0 UA 2

=A0 =A0 =A0 =A0=20 =A0 =A0--->
=A0 =A0 =A0 =A0 =A0 =A0INVITE 123@aa.example.com
=A0 =A0=20 =A0 =A0 =A0 =A0Call-Id: qwerty@aa

=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0--->
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0INVITE 123@transit.example.com
=A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0Call-Id: asdfgh@transit
=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0References:=20 QAZWSXEDCRFV;rel=3Dserial

=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0--->
=A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0INVITE 123@bb.example.com
=A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Call-Id:=20 zxcvbn@bb
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0References: QAZWSXEDCRFV
=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 ;rel=3Dserial

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0<---
=A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0SIP/2.0 200 OK
=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Call-Id:=20 zxcvbn@bb

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0<---
=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0SIP/2.0 200 OK
=A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0Call-Id:=20 asdfgh@transit
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0References:=20 QAZWSXEDCRFV;rel=3Dserial

=A0 =A0 =A0 =A0 =A0=20 =A0<---
=A0 =A0 =A0 =A0 =A0 =A0SIP/2.0 200=20 OK
=A0 =A0 =A0 =A0 =A0 =A0Call-Id: qwerty@aa
=A0=20 =A0 =A0 =A0 =A0 =A0References:=20 QAZWSXEDCRFV;rel=3Dserial

Dale


______________________= _________________________
Sip=20 mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list= is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new developments on=20 the application of=20 sip


--001636765bbd7126ec04660c5b64-- From jiri@iptel.org Thu Mar 26 15:34:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8A13A6452 for ; Thu, 26 Mar 2009 15:34:04 -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.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJMsQspwgGs9 for ; Thu, 26 Mar 2009 15:34:03 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 6E45328C160 for ; Thu, 26 Mar 2009 15:33:45 -0700 (PDT) Received: from dhcp-46c3.meeting.ietf.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 4D84C1811230; Thu, 26 Mar 2009 23:34:29 +0100 (CET) Message-ID: <49CC02F4.6070507@iptel.org> Date: Thu, 26 Mar 2009 23:34:28 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hadriel Kaplan References: <49CA9943.1020808@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF SIP List Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:34:04 -0000 First of all I think it is definitely worth trying. Not being able to correlate dialogs through B2BUA is a big operational problem. I'm not sure that this will get really adopted (who knows what today's obfuscators choose to obfuscate tomorrow...). However in hope for solving this problem, presence of incentives for adoption and absence of any known harm it is definitely worth doing. Another idea how to accommodate receivers that are silly not to be liberal is using a fake IP address (popular 0.0.0.0). While not aesthetic at all, it could accommodate such receivers (under assumption they assign no syntactical meaning to it) and signal to B2BUA there is no disclosure of IP addresses. OTOH it could be time too to abandon 2543 legacy. Supporting strict routing and other ancient stuff like IP in callid does not seem worth the trouble to me. -jiri Hadriel Kaplan wrote: > Ooh, good point. Fair enough, I'll change that. > > -hadriel > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Jonathan Rosenberg >> Sent: Wednesday, March 25, 2009 4:51 PM >> To: IETF SIP List >> Subject: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 >> >> I didnt get a chance to say this at the mike. >> >> You *cannot* change the BNF for the call-id. If you did, you might end >> up with the following problem: >> >> A new UA gets built, compliant to this update. It is one of these >> 'aggressive parsing' UAs. It rejects any message which is not compliant >> to the BNF. An older, normal RFC-3261 compliant UA sends a call-id which >> includes the @-sign. >> >> According to the BNF of this updated 3261, and based on the strictness >> of this aggressive-parsing UAs, it rejects that request as non-compliant. >> >> As such, you need to keep the BNF, but change the normative language >> such that an endpoint MUST NOT include the [@ host] but MUST be prepared >> to receive it. >> >> -Jonathan R. >> >> -- >> Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South >> Cisco Fellow Iselin, NJ 08830 >> Cisco, Voice Technology Group >> jdrosen@cisco.com >> http://www.jdrosen.net PHONE: (408) 902-3084 >> http://www.cisco.com >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From mary.barnes@nortel.com Thu Mar 26 16:16:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7067628C14E for ; Thu, 26 Mar 2009 16:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlhCs6wc1eTg for ; Thu, 26 Mar 2009 16:16:07 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 547263A6ADB for ; Thu, 26 Mar 2009 16:16:07 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2QNGTB14647; Thu, 26 Mar 2009 23:16:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AE68.F536F2A9" Date: Thu, 26 Mar 2009 18:16:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8 References: From: "Mary Barnes" To: "Christer Holmberg" , Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 23:16:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AE68.F536F2A9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, Christer has updated the document based on the action item from = Wednesday's SIP session (chaired by SIPPING chairs and modeled as the = proposed DISPATCH WG). If folks could please review the document and = raise any concerns on the document now, that would be appreciated. We = ask specifically for an answer to the question: Do you support the = document being adopted as a WG document in RAI (WG tbd)? A simple "yes" = is fine, however, if you don't think we should adopt this document, = could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holm= berg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-k= eep-04.txt tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep =20 Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer ------_=_NextPart_001_01C9AE68.F536F2A9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of draft-holmberg-sip-keep

Hi folks,

Christer has updated the document based on the action item from = Wednesday's SIP session (chaired by SIPPING chairs and modeled as the = proposed DISPATCH WG).  If folks could please review the document = and raise any concerns on the document now, that would be appreciated. = We ask specifically for an answer to the question:  Do you support = the document being adopted as a WG document in RAI (WG tbd)?  A = simple "yes" is fine, however, if you don't think we should = adopt this document, could you please provide the reason.

For your convenience, here's the link to the document:
http://t= ools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And, the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ie= tf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/= draft-holmberg-sip-keep-04.txt
tinyurl: http://tinyurl.com/dfyvxz

Regards,
Mary
SIPPING WG co-chair


-----Original Message-----
From: sip-bounces@ietf.org on behalf of Christer Holmberg
Sent: Thu 3/26/2009 12:41 PM
To: sip@ietf.org
Subject: [Sip] New version of draft-holmberg-sip-keep


Hi,

I've submitted a new version (-04) of the keep draft.

The requirement text is now alligned with the text shown on the = slides
during the SFO SIP WG presentation.

There are no other changes in the document from the previous = version.

Regards,

Christer

------_=_NextPart_001_01C9AE68.F536F2A9-- From mdolly@att.com Thu Mar 26 16:34:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159FE3A69A2 for ; Thu, 26 Mar 2009 16:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbNncgwVykt2 for ; Thu, 26 Mar 2009 16:34:57 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 03D943A6AA8 for ; Thu, 26 Mar 2009 16:34:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-167.messagelabs.com!1238110549!9723565!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 9188 invoked from network); 26 Mar 2009 23:35:49 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-167.messagelabs.com with AES256-SHA encrypted SMTP; 26 Mar 2009 23:35:49 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2QNZmai022164 for ; Thu, 26 Mar 2009 19:35:48 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2QNZlPc022158 for ; Thu, 26 Mar 2009 19:35:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AE6B.96FD7CCA" Date: Thu, 26 Mar 2009 19:35:46 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02B5017C@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8AAEEY4A= References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Mary Barnes" , "Christer Holmberg" , Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 23:34:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AE6B.96FD7CCA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yes, we support this draft as a WG document. =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, March 26, 2009 7:17 PM To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep =20 Hi folks, Christer has updated the document based on the action item from Wednesday's SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATCH WG). If folks could please review the document and raise any concerns on the document now, that would be appreciated. We ask specifically for an answer to the question: Do you support the document being adopted as a WG document in RAI (WG tbd)? A simple "yes" is fine, however, if you don't think we should adopt this document, could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holm= b erg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-ke= e p-04.txt =20 tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer ------_=_NextPart_001_01C9AE6B.96FD7CCA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of draft-holmberg-sip-keep

Yes, we support this draft as a WG = document.

 

From:= sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Thursday, March 26, 2009 7:17 PM
To: Christer Holmberg; sip@ietf.org
Subject: Re: [Sip] New version of = draft-holmberg-sip-keep

 

Hi = folks,

Christer has updated the document based on the action item from = Wednesday's SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATCH WG).  If folks could please review the document and raise any = concerns on the document now, that would be appreciated. We ask specifically for an = answer to the question:  Do you support the document being adopted as a WG = document in RAI (WG tbd)?  A simple "yes" is fine, however, if you = don't think we should adopt this document, could you please provide the = reason.

For your convenience, here's the link to the document:
http://t= ools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And, the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools= .ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.= org/id/draft-holmberg-sip-keep-04.txt
tinyurl: http://tinyurl.com/dfyvxz

Regards,
Mary
SIPPING WG co-chair


-----Original Message-----
From: sip-bounces@ietf.org on behalf of Christer Holmberg
Sent: Thu 3/26/2009 12:41 PM
To: sip@ietf.org
Subject: [Sip] New version of draft-holmberg-sip-keep


Hi,

I've submitted a new version (-04) of the keep draft.

The requirement text is now alligned with the text shown on the = slides
during the SFO SIP WG presentation.

There are no other changes in the document from the previous = version.

Regards,

Christer

------_=_NextPart_001_01C9AE6B.96FD7CCA-- From HKaplan@acmepacket.com Thu Mar 26 17:09:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68773A6BE2 for ; Thu, 26 Mar 2009 17:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkkfXb+yY-CN for ; Thu, 26 Mar 2009 17:09:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1F3053A69FF for ; Thu, 26 Mar 2009 17:09:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 26 Mar 2009 20:10:34 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 26 Mar 2009 20:10:33 -0400 From: Hadriel Kaplan To: Mary Barnes , Christer Holmberg , "sip@ietf.org" Date: Thu, 26 Mar 2009 20:10:25 -0400 Thread-Topic: New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8AAI+zyA= Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFF985mail_" MIME-Version: 1.0 Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:09:45 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFF985mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "yes" ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary = Barnes Sent: Thursday, March 26, 2009 7:17 PM To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep Hi folks, Christer has updated the document based on the action item from Wednesday's= SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATC= H WG). If folks could please review the document and raise any concerns on= the document now, that would be appreciated. We ask specifically for an an= swer to the question: Do you support the document being adopted as a WG do= cument in RAI (WG tbd)? A simple "yes" is fine, however, if you don't thin= k we should adopt this document, could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holmbe= rg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-keep-= 04.txt tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer --_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFF985mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of draft-holmberg-sip-keep

“yes”

 

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Thursday, March 26, 20= 09 7:17 PM
To: Christer Holmberg; sip@ietf.org
Subject: Re: [Sip] New versi= on of draft-holmberg-sip-keep

 

<= span style=3D'font-size:10.0pt'>Hi folks,

Christer has updated the document based on the action item from Wednesday's= SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATCH WG).  If folks could please review the document and raise any concerns= on the document now, that would be appreciated. We ask specifically for an ans= wer to the question:  Do you support the document being adopted as a WG document in RAI (WG tbd)?  A simple "yes" is fine, however, = if you don't think we should adopt this document, could you please provide the reason.

For your convenience, here's the link to the document:
http://= tools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And, the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.= org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/d= raft-holmberg-sip-keep-04.txt
tinyurl: http://tinyurl.com/dfyvxz

Regards,
Mary
SIPPING WG co-chair


-----Original Message-----
From: sip-bounces@ietf.org on behalf of Christer Holmberg
Sent: Thu 3/26/2009 12:41 PM
To: sip@ietf.org
Subject: [Sip] New version of draft-holmberg-sip-keep


Hi,

I've submitted a new version (-04) of the keep draft.

The requirement text is now alligned with the text shown on the slides
during the SFO SIP WG presentation.

There are no other changes in the document from the previous version.

Regards,

Christer

--_000_E6C2E8958BA59A4FB960963D475F7AC314FEBFF985mail_-- From theo@crazygreek.co.uk Thu Mar 26 17:35:33 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259E33A685A for ; Thu, 26 Mar 2009 17:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2kQ2Xf0sMef for ; Thu, 26 Mar 2009 17:35:32 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with SMTP id 2CA573A6ACB for ; Thu, 26 Mar 2009 17:35:32 -0700 (PDT) Received: from source ([72.14.220.156]) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKScwfiknmIFA/xBAs40PHHRiFL0ZzxVzS@postini.com; Thu, 26 Mar 2009 17:36:26 PDT Received: by fg-out-1718.google.com with SMTP id 22so1073623fge.19 for ; Thu, 26 Mar 2009 17:36:25 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> Date: Fri, 27 Mar 2009 00:34:26 +0000 Received: by 10.86.66.16 with SMTP id o16mr46497fga.67.1238114185494; Thu, 26 Mar 2009 17:36:25 -0700 (PDT) Message-ID: <167dfb9b0903261734j3eb207e3xda340e7f01e74c31@mail.gmail.com> From: Theo Zourzouvillys To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Christer Holmberg Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:35:33 -0000 On Thu, Mar 26, 2009 at 11:16 PM, Mary Barnes wrote: > Do you support the document being adopted as a WG document in RAI (WG tbd)? yes ~ Theo Sent from: San Francisco California United States. From ietf.hanserik@gmail.com Thu Mar 26 17:52:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6BE28C1C1 for ; Thu, 26 Mar 2009 17:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa3vc7H9Qi7L for ; Thu, 26 Mar 2009 17:52:39 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 5250B28C187 for ; Thu, 26 Mar 2009 17:52:39 -0700 (PDT) Received: by ewy9 with SMTP id 9so853547ewy.37 for ; Thu, 26 Mar 2009 17:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=E5zn0LY1UWlMbJx+alUvZWX93ddcHQ2FsNPQK0hFbeU=; b=Q2SBbFHetPuQHeuh8z5/6uEfxgud8VMeU6NrlGuH4yTMWC1tE4FuXx53vJpegMjNVQ jguO5rixlCjBqF5ZtnTIP2kvEMl5YSEkgmKnUXR1didle9n5YakDktoORR9iXuIXTOR2 m35lN9Y1hOoAHCb9fJ9jL6oCzUsI47VkhZkJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IipOAoJMWQBKgwX/G6ySt/AjdjZDqC6+ipKH+hiO27JdmoBjyH8yI+u5FH/aFJH6+P VgkBczdtik93o7kI6bq1Tb9OyQO/rtOXXPiQ1svyEb6wYylMLrNGVGcUWqcTh521fQoL lKfUd6XJrQyGTj7mWOIus97vatoc0OFe8xM6I= Received: by 10.210.91.17 with SMTP id o17mr1173821ebb.24.1238115212574; Thu, 26 Mar 2009 17:53:32 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 10sm1258359eyd.23.2009.03.26.17.53.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Mar 2009 17:53:32 -0700 (PDT) Message-ID: <49CC238B.7020402@gmail.com> Date: Fri, 27 Mar 2009 01:53:31 +0100 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Christer Holmberg Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:52:40 -0000 "yes" Mary Barnes wrote: > > Hi folks, > > Christer has updated the document based on the action item from > Wednesday's SIP session (chaired by SIPPING chairs and modeled as the > proposed DISPATCH WG). If folks could please review the document and > raise any concerns on the document now, that would be appreciated. We > ask specifically for an answer to the question: Do you support the > document being adopted as a WG document in RAI (WG tbd)? A simple > "yes" is fine, however, if you don't think we should adopt this > document, could you please provide the reason. > > For your convenience, here's the link to the document: > http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt > And, the diff: > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt > > tinyurl: http://tinyurl.com/dfyvxz > > Regards, > Mary > SIPPING WG co-chair > > > -----Original Message----- > From: sip-bounces@ietf.org on behalf of Christer Holmberg > Sent: Thu 3/26/2009 12:41 PM > To: sip@ietf.org > Subject: [Sip] New version of draft-holmberg-sip-keep > > > Hi, > > I've submitted a new version (-04) of the keep draft. > > The requirement text is now alligned with the text shown on the slides > during the SFO SIP WG presentation. > > There are no other changes in the document from the previous version. > > Regards, > > Christer > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From BPenfield@acmepacket.com Thu Mar 26 17:57:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7E228C1D2 for ; Thu, 26 Mar 2009 17:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPhjBBW7EyAj for ; Thu, 26 Mar 2009 17:57:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 22C0828C1C9 for ; Thu, 26 Mar 2009 17:57:10 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 26 Mar 2009 20:58:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 26 Mar 2009 20:58:03 -0400 From: Bob Penfield To: Mary Barnes , Christer Holmberg , "sip@ietf.org" Date: Thu, 26 Mar 2009 20:58:01 -0400 Thread-Topic: New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8AAPf8TA= Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:57:11 -0000 >Do you support the document being adopted as a WG document in RAI (WG tbd)= ? =20 YES! ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary = Barnes Sent: Thursday, March 26, 2009 7:17 PM To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep Hi folks, Christer has updated the document based on the action item from Wednesday's= SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATC= H WG). If folks could please review the document and raise any concerns on= the document now, that would be appreciated. We ask specifically for an an= swer to the question: Do you support the document being adopted as a WG do= cument in RAI (WG tbd)? A simple "yes" is fine, however, if you don't thin= k we should adopt this document, could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holmbe= rg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-keep-= 04.txt tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer From Adam.Uzelac@globalcrossing.com Thu Mar 26 18:21:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96FA3A69F7 for ; Thu, 26 Mar 2009 18:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9FY5C+47zmY for ; Thu, 26 Mar 2009 18:21:07 -0700 (PDT) Received: from mailsrv.ams.gblxint.com (unknown-141-roc.globalcrossing.com [209.130.177.141]) by core3.amsl.com (Postfix) with ESMTP id 116733A693F for ; Thu, 26 Mar 2009 18:21:06 -0700 (PDT) Received: from w3uspdyvs212.ams.gblxint.com (w3uspdyvs212.ams.gblxint.com [10.60.54.213]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 9280DE8704; Thu, 26 Mar 2009 21:21:58 -0400 (EDT) Received: from w3uspdyvs240.ams.gblxint.com ([10.60.54.201]) by w3uspdyvs212.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 21:21:58 -0400 Received: from EVS20.ams.gblxint.com ([10.60.53.123]) by w3uspdyvs240.ams.gblxint.com ([10.60.54.201]) with mapi; Thu, 26 Mar 2009 21:21:58 -0400 From: "Uzelac, Adam" To: Theo Zourzouvillys , Mary Barnes Date: Thu, 26 Mar 2009 21:21:55 -0400 Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: AcmudBjGgGfyC+RbSEWeIiwGHMdoRQABksvg Message-ID: <278488ECD81E6A42A7289E84524D2A25AC307EFD@EVS20.ams.gblxint.com> References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <167dfb9b0903261734j3eb207e3xda340e7f01e74c31@mail.gmail.com> In-Reply-To: <167dfb9b0903261734j3eb207e3xda340e7f01e74c31@mail.gmail.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-OriginalArrivalTime: 27 Mar 2009 01:21:58.0417 (UTC) FILETIME=[6C5EE010:01C9AE7A] Cc: "sip@ietf.org" , Christer Holmberg Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 01:21:07 -0000 +1 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Theo Zourzouvillys > Sent: Thursday, March 26, 2009 5:34 PM > To: Mary Barnes > Cc: sip@ietf.org; Christer Holmberg > Subject: Re: [Sip] New version of draft-holmberg-sip-keep >=20 > On Thu, Mar 26, 2009 at 11:16 PM, Mary Barnes > wrote: >=20 > > Do you support the document being adopted as a WG document in RAI (WG > tbd)? >=20 > yes >=20 > ~ Theo >=20 > Sent from: San Francisco California United States. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From SBharrat@sonusnet.com Thu Mar 26 19:06:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177CE3A6AA4 for ; Thu, 26 Mar 2009 19:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxYAIf1jXS8m for ; Thu, 26 Mar 2009 19:06:16 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 3D9763A699A for ; Thu, 26 Mar 2009 19:06:15 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id n2R2760C006938; Thu, 26 Mar 2009 22:07:06 -0400 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, 26 Mar 2009 22:06:41 -0400 Message-ID: <637C77B6763BB54ABF989B6B21D5323502981F0B@sonusmail05.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8AAZR97U= References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> From: "Bharrat, Shaun" To: "Mary Barnes" , "Christer Holmberg" , Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 02:06:17 -0000 yes -----Original Message----- From: sip-bounces@ietf.org on behalf of Mary Barnes Sent: Thu 3/26/2009 7:16 PM To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep =20 Hi folks, Christer has updated the document based on the action item from = Wednesday's SIP session (chaired by SIPPING chairs and modeled as the = proposed DISPATCH WG). If folks could please review the document and = raise any concerns on the document now, that would be appreciated. We = ask specifically for an answer to the question: Do you support the = document being adopted as a WG document in RAI (WG tbd)? A simple "yes" = is fine, however, if you don't think we should adopt this document, = could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holm= berg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-k= eep-04.txt tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep =20 Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer From drage@alcatel-lucent.com Thu Mar 26 21:52:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AFC3A6BED for ; Thu, 26 Mar 2009 21:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvMEcpywj3Bb for ; Thu, 26 Mar 2009 21:52:12 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 127763A6A16 for ; Thu, 26 Mar 2009 21:52:11 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2R4r3N4023052 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Mar 2009 05:53:03 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 27 Mar 2009 05:53:03 +0100 From: "DRAGE, Keith (Keith)" To: Mary Barnes , Christer Holmberg , "sip@ietf.org" Date: Fri, 27 Mar 2009 05:53:03 +0100 Thread-Topic: New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8AAwd+9A= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE91E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_28B7C3AA2A7ABA4A841F11217ABE78D6757BE91EFRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 04:52:13 -0000 --_000_28B7C3AA2A7ABA4A841F11217ABE78D6757BE91EFRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As individual Support Keith ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary = Barnes Sent: Thursday, March 26, 2009 11:17 PM To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep Hi folks, Christer has updated the document based on the action item from Wednesday's= SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATC= H WG). If folks could please review the document and raise any concerns on= the document now, that would be appreciated. We ask specifically for an an= swer to the question: Do you support the document being adopted as a WG do= cument in RAI (WG tbd)? A simple "yes" is fine, however, if you don't thin= k we should adopt this document, could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holmbe= rg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-keep-= 04.txt tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer --_000_28B7C3AA2A7ABA4A841F11217ABE78D6757BE91EFRMRSSXCHMBSB3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of draft-holmberg-sip-keep
As individual
 
Support
 
Keith

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes
Sent:= =20 Thursday, March 26, 2009 11:17 PM
To: Christer Holmberg;=20 sip@ietf.org
Subject: Re: [Sip] New version of=20 draft-holmberg-sip-keep

Hi folks,

Christer has updated the document base= d on=20 the action item from Wednesday's SIP session (chaired by SIPPING chairs a= nd=20 modeled as the proposed DISPATCH WG).  If folks could please review = the=20 document and raise any concerns on the document now, that would be=20 appreciated. We ask specifically for an answer to the question:  Do = you=20 support the document being adopted as a WG document in RAI (WG tbd)? = ; A=20 simple "yes" is fine, however, if you don't think we should adopt this=20 document, could you please provide the reason.

For your convenienc= e,=20 here's the link to the document:
http://t= ools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And,=20 the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ie= tf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/i= d/draft-holmberg-sip-keep-04.txt
tinyurl:=20 http://tinyurl.com/dfyvxz

R= egards,
Mary
SIPPING=20 WG co-chair


-----Original Message-----
From:=20 sip-bounces@ietf.org on behalf of Christer Holmberg
Sent: Thu 3/26/200= 9=20 12:41 PM
To: sip@ietf.org
Subject: [Sip] New version of=20 draft-holmberg-sip-keep


Hi,

I've submitted a new versio= n=20 (-04) of the keep draft.

The requirement text is now alligned with= the=20 text shown on the slides
during the SFO SIP WG presentation.

Th= ere=20 are no other changes in the document from the previous=20 version.

Regards,

Christer

<= /BODY> --_000_28B7C3AA2A7ABA4A841F11217ABE78D6757BE91EFRMRSSXCHMBSB3d_-- From R.Jesske@telekom.de Thu Mar 26 21:52:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517853A6C16 for ; Thu, 26 Mar 2009 21:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTNqHjxM1Km7 for ; Thu, 26 Mar 2009 21:52:24 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 0B4143A6C05 for ; Thu, 26 Mar 2009 21:52:23 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 27 Mar 2009 05:53:14 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 05:53:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AE97.EF42926F" Date: Fri, 27 Mar 2009 05:53:13 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD4042503C0@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02B5017C@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8AAEEY4AACxqQAA== References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA02B5017C@gaalpa1msgusr7e.ugd.att.com> From: To: , , , X-OriginalArrivalTime: 27 Mar 2009 04:53:14.0330 (UTC) FILETIME=[EFCDB3A0:01C9AE97] Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 04:52:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AE97.EF42926F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Yes" We too. =20 Roland ________________________________ Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im Auftrag von = DOLLY, MARTIN C, ATTLABS Gesendet: Freitag, 27. M=E4rz 2009 00:36 An: Mary Barnes; Christer Holmberg; sip@ietf.org Betreff: Re: [Sip] New version of draft-holmberg-sip-keep Yes, we support this draft as a WG document. =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Mary Barnes Sent: Thursday, March 26, 2009 7:17 PM To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep =20 Hi folks, Christer has updated the document based on the action item from = Wednesday's SIP session (chaired by SIPPING chairs and modeled as the = proposed DISPATCH WG). If folks could please review the document and = raise any concerns on the document now, that would be appreciated. We = ask specifically for an answer to the question: Do you support the = document being adopted as a WG document in RAI (WG tbd)? A simple "yes" = is fine, however, if you don't think we should adopt this document, = could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holm= berg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-k= eep-04.txt = =20 tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer ------_=_NextPart_001_01C9AE97.EF42926F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of = draft-holmberg-sip-keep
"Yes"
We too.
 
Roland

Von: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN C,=20 ATTLABS
Gesendet: Freitag, 27. März 2009 = 00:36
An: Mary=20 Barnes; Christer Holmberg; sip@ietf.org
Betreff: Re: [Sip] New = version=20 of draft-holmberg-sip-keep

Yes,=20 we support this draft as a WG document.

 

From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Mary=20 Barnes
Sent: Thursday, March 26, 2009 7:17 PM
To: = Christer=20 Holmberg; sip@ietf.org
Subject: Re: [Sip] New version of=20 draft-holmberg-sip-keep

 

Hi=20 folks,

Christer has updated the document based on the action item = from=20 Wednesday's SIP session (chaired by SIPPING chairs and modeled as the = proposed=20 DISPATCH WG).  If folks could please review the document and raise = any=20 concerns on the document now, that would be appreciated. We ask = specifically for=20 an answer to the question:  Do you support the document being = adopted as a=20 WG document in RAI (WG tbd)?  A simple "yes" is fine, however, if = you don't=20 think we should adopt this document, could you please provide the=20 reason.

For your convenience, here's the link to the = document:
http://t= ools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And,=20 the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools= .ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.= org/id/draft-holmberg-sip-keep-04.txt
tinyurl:=20 http://tinyurl.com/dfyvxz

R= egards,
Mary
SIPPING=20 WG co-chair


-----Original Message-----
From: = sip-bounces@ietf.org=20 on behalf of Christer Holmberg
Sent: Thu 3/26/2009 12:41 PM
To:=20 sip@ietf.org
Subject: [Sip] New version of=20 draft-holmberg-sip-keep


Hi,

I've submitted a new = version (-04)=20 of the keep draft.

The requirement text is now alligned with the = text=20 shown on the slides
during the SFO SIP WG presentation.

There = are no=20 other changes in the document from the previous=20 version.

Regards,

Christer

------_=_NextPart_001_01C9AE97.EF42926F-- From shida@ntt-at.com Thu Mar 26 22:12:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475D83A6964 for ; Thu, 26 Mar 2009 22:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptNYtYmGEcBu for ; Thu, 26 Mar 2009 22:12:22 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.82.12]) by core3.amsl.com (Postfix) with SMTP id 26A423A67E6 for ; Thu, 26 Mar 2009 22:12:22 -0700 (PDT) Received: (qmail 7079 invoked from network); 27 Mar 2009 05:14:15 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway11.websitewelcome.com with SMTP; 27 Mar 2009 05:14:15 -0000 Received: from adsl-76-231-184-89.dsl.pltn13.sbcglobal.net ([76.231.184.89]:51557 helo=[192.168.1.168]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Ln4NG-0006FO-FV; Fri, 27 Mar 2009 00:13:00 -0500 Message-Id: <4D8385DA-E7BD-4F9B-8E27-6A3E4C0267B5@ntt-at.com> From: Shida Schubert To: Mary Barnes In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> Content-Type: multipart/alternative; boundary=Apple-Mail-5--21932887 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 22:13:08 -0700 References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.930.3) 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 Cc: "sip@ietf.org List" , Christer Holmberg Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 05:12:23 -0000 --Apple-Mail-5--21932887 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yes I support this work too. On 26-Mar-09, at 4:16 PM, Mary Barnes wrote: > Hi folks, > > Christer has updated the document based on the action item from > Wednesday's SIP session (chaired by SIPPING chairs and modeled as > the proposed DISPATCH WG). If folks could please review the > document and raise any concerns on the document now, that would be > appreciated. We ask specifically for an answer to the question: Do > you support the document being adopted as a WG document in RAI (WG > tbd)? A simple "yes" is fine, however, if you don't think we should > adopt this document, could you please provide the reason. > > For your convenience, here's the link to the document: > http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt > And, the diff: > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt > tinyurl: http://tinyurl.com/dfyvxz > > Regards, > Mary > SIPPING WG co-chair > > > -----Original Message----- > From: sip-bounces@ietf.org on behalf of Christer Holmberg > Sent: Thu 3/26/2009 12:41 PM > To: sip@ietf.org > Subject: [Sip] New version of draft-holmberg-sip-keep > > > Hi, > > I've submitted a new version (-04) of the keep draft. > > The requirement text is now alligned with the text shown on the slides > during the SFO SIP WG presentation. > > There are no other changes in the document from the previous version. > > Regards, > > Christer > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-5--21932887 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Yes I = support this work too.

On 26-Mar-09, at 4:16 PM, Mary = Barnes wrote:

Hi folks,

Christer has updated the document based on = the action item from Wednesday's SIP session (chaired by SIPPING chairs = and modeled as the proposed DISPATCH WG).  If folks could please = review the document and raise any concerns on the document now, that = would be appreciated. We ask specifically for an answer to the = question:  Do you support the document being adopted as a WG = document in RAI (WG tbd)?  A simple "yes" is fine, however, if you = don't think we should adopt this document, could you please provide the = reason.

For your convenience, here's the link to the = document:
http://to= ols.ietf.org/id/draft-holmberg-sip-keep-04.txt
And, the = diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.i= etf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org= /id/draft-holmberg-sip-keep-04.txt
tinyurl: http://tinyurl.com/dfyvxz
=
Regards,
Mary
SIPPING WG co-chair


= -----Original Message-----
From: sip-bounces@ietf.org on behalf = of Christer Holmberg
Sent: Thu 3/26/2009 12:41 PM
To: sip@ietf.org
Subject: [Sip] New = version of draft-holmberg-sip-keep


Hi,

I've = submitted a new version (-04) of the keep draft.

The = requirement text is now alligned with the text shown on the slides
= during the SFO SIP WG presentation.

There are no other changes = in the document from the previous version.

Regards,

= Christer

= _______________________________________________
Sip mailing list =  https://www.ietf.org/ma= ilman/listinfo/sip
This list is for NEW development of the core = SIP Protocol
Use sip-implementors@cs.colum= bia.edu for questions on current sip
Use sipping@ietf.org for new = developments on the application of = sip

= --Apple-Mail-5--21932887-- From sdoken@qualcomm.com Fri Mar 27 00:13:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778F53A63EC for ; Fri, 27 Mar 2009 00:13:14 -0700 (PDT) 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=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59DV-28Tfz46 for ; Fri, 27 Mar 2009 00:13:13 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0DCC93A69B9 for ; Fri, 27 Mar 2009 00:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1238138030; x=1269674030; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 Paul=20Kyzivat=20|CC:=20Dale=20Worley =20,=20SIP=20IETF=20, =0D=0A=20=20=20=20=20=20=20=20Brett=20Tate=0D=0A=09|Date:=20Fri,=2027=20Mar=202009=2000:13:47 =20-0700|Subject:=20RE:=20[Sip]=20Is=20REFER=20within=20d ialog=20part=20of=20INVITE=20or=09subscription=0D=0A=09us age?=20(was=20RE:=20SIP=20INFO)|Thread-Topic:=20[Sip]=20I s=20REFER=20within=20dialog=20part=20of=20INVITE=20or=09s ubscription=0D=0A=09usage?=20(was=20RE:=20SIP=20INFO) |Thread-Index:=20Acmsjutm+A75AfVXTp+uHyeyeoOKBwAjCTgg |Message-ID:=20|References:=20<24ACC38D-8B 7D-46E6-B767-73A33F6C9266@standardstrack.com>=0D=0A=09<49 C79CFD.1010408@cisco.com>=0D=0A=09<9B2A061A1137254BBE4F4B 2CD843646A10BFF48DF0@mbx02.citservers.local>=0D=0A=09<123 7853234.16613.41.camel@victoria-pingtel-com.us.nortel.com >=0D=0A=09<49C83831.7010102@cisco.com>=0D=0A=20=0D=0A=20<49C8F18D.1040800@cisco.com>|In-Reply-To: =20<49C8F18D.1040800@cisco.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5565"=3B=20a=3D"16644275"; bh=z6T+GXlaTMKWZL+bHLAapS9BEHT5zCghZcQddiFv/54=; b=L3NpjStOOUEI+k2m6R00RE+tkZ38IWQ83B6LFMefky8GYM+UPJ19kaWr rINsUCN6131kt9y+wDUJFLx9+ZEP1xuGp+4sXjxi4MOVq0UmSKKZyIAco M+D6QOsEiYWKGtLQkHKB7UUott9PQgfCUd9phYdP+FG8iwGFBiFbPUzqR U=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16644275" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2009 00:13:50 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R7Dn0L002584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Mar 2009 00:13:50 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R7DnEt028076 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Mar 2009 00:13:49 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Fri, 27 Mar 2009 00:13:48 -0700 From: "Doken, Serhad" To: Paul Kyzivat Date: Fri, 27 Mar 2009 00:13:47 -0700 Thread-Topic: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) Thread-Index: Acmsjutm+A75AfVXTp+uHyeyeoOKBwAjCTgg Message-ID: References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <49C8F18D.1040800@cisco.com> In-Reply-To: <49C8F18D.1040800@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 07:13:14 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, March 24, 2009 7:43 AM > To: Doken, Serhad > Cc: Dale Worley; SIP IETF; Brett Tate > Subject: Re: [Sip] Is REFER within dialog part of INVITE or > subscription usage? (was RE: SIP INFO) >=20 >=20 >=20 > Doken, Serhad wrote: >=20 > >> I guess the question is: would it be valid to send a REFER within an > >> existing dialog that had no INVITE usage? If it were valid, > presumably > > > > Yes, I think so. > > > > > >> it would have the same meaning as sending one outside a dialog, > except > >> that the resulting subscription would share the dialog. I expect > that > >> is > >> a usage it would be difficult to find in the wild. > > > > Consider a third party control application that forces an endpoint to > register : > > > > REFER sip:phone.doken.com SIP/2.0 > > Refer-To: > > > > that triggers a REG to the registrar as : > > > > REGISTER sip:serhad@doken.com SIP/2.0 >=20 > You are suggesting that first this 3pcc application sends a SUBSCRIBE > to > this UA, establishing a dialog. Then it sends a REFER within the > dialog, > asking the UA REGISTER? That then would presumably result in a > subscription to the refer event package sharing the dialog with the > prior subscription. I guess this is *possible*, though I don't know > *why* it would be done. What would the initial SUBSCRIBE be to, and how > would it be established before the UA has registered? 3rd party contact center desktop monitoring application is used by the supe= rvisor to see agent's activities. Thru a CTI <->SIP translator, it SUBs to = the agent's presence. Once the customer service agent comes in the morning = and turns his phone's status to Online(Open), app notices this and forces i= t to Register. At the end of the day when agent leaves, does the opposite a= nd de-registers it. Thus, it is made sure that they only get billed for the= time that agent was registered(online) by the service provider. >=20 > Are you aware of such usage in the wild? I have seen somewhat similar examples. If you are offering enough stimulus/= TARP money, wild frontiers will get closer. It's mostly used for Xfer however as you alluded to, REFER is implicit or a= mbiguous that it is open to be used as the Swiss knife if I wanted the othe= r side to do something for me. As long as the sender and receiver know/unde= rstand what is meant or the context(especially if they are from the same ve= ndor), everything is fine, if not misinterpretations may happen. >=20 > (Its incidental to this discussion, but REGISTER presents unique > challenges because of the way addressing works for it. Contrary to your > example above, we would typically expect that the To: would contain the > full URI, while the R-URI would only be sip:doken.com. This would You are right. Thanks, Serhad > require more special case processing.) >=20 > Thanks, > Paul From sdoken@qualcomm.com Fri Mar 27 00:13:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C513A68FB for ; Fri, 27 Mar 2009 00:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhcAPBT1BIUU for ; Fri, 27 Mar 2009 00:13:13 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id AC7AA3A6B51 for ; Fri, 27 Mar 2009 00:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1238138019; x=1269674019; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 aayush=20bhatnagar=20|CC:=20P aul=20Kyzivat=20,=20SIP=20IETF=20,=0D=0A=20=20=20=20=20=20=20=20Brett=20Tate=0D =0A=09|Date:=20Fri,=2027=20Mar=20200 9=2000:13:34=20-0700|Subject:=20RE:=20[Sip]=20Is=20REFER =20within=20dialog=20part=20of=20INVITE=20or=20subscripti on=0D=0A=20=09usage?=20(was=20RE:=20SIP=20INFO) |Thread-Topic:=20[Sip]=20Is=20REFER=20within=20dialog=20p art=20of=20INVITE=20or=20subscription=0D=0A=20=09usage? =20(was=20RE:=20SIP=20INFO)|Thread-Index:=20AcmsWTDtU8ORK 83tQP2HEPN2wmhhBgAuqCDQ|Message-ID:=20 |References:=20<24ACC38D-8B7D-46E6-B767-73A33F6C9266@stan dardstrack.com>=0D=0A=09=20<49C79CFD.1010408@cisco.com> =0D=0A=09=20<9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@m bx02.citservers.local>=0D=0A=09=20<1237853234.16613.41.ca mel@victoria-pingtel-com.us.nortel.com>=0D=0A=09=20<49C83 831.7010102@cisco.com>=0D=0A=09=20=0D=0A=09=20=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_ED88AAAE8B3D764B9FD8558DE1775B6913927 4F820NASANEXMB09na_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5565"=3B=20a=3D"16644274"; bh=ulQd+Mbj9Jim1aYwjMwA2FV4qT2lFIfb8+OpTZi4Bdg=; b=qTub2YTUkNmux+3otdAm8Cyd4gNzU76wfq9EWawRR6UJTYro8oC6heuQ dnwYIZ7fSABmdGSKvrgGsEDg68YlLvDpexoE2Lf3jxteDsJvo/FPmNzVB 78CzqMc1sBocOtgWycnMBvQYsRmQ353e2ON15OXIb0CReETqBylHXu903 U=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16644274" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2009 00:13:38 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R7Dco2016517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Mar 2009 00:13:38 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R7DbYc020368 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Mar 2009 00:13:37 -0700 (PDT) Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Fri, 27 Mar 2009 00:13:36 -0700 From: "Doken, Serhad" To: aayush bhatnagar Date: Fri, 27 Mar 2009 00:13:34 -0700 Thread-Topic: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) Thread-Index: AcmsWTDtU8ORK83tQP2HEPN2wmhhBgAuqCDQ Message-ID: References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.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: multipart/alternative; boundary="_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F820NASANEXMB09na_" MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 07:13:15 -0000 --_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F820NASANEXMB09na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps presence was not the best example there given what is supported tod= ay though that should not limit the imagination since new services/devices = pop up every day. Point is this can be enabled by the basic Sip building b= locks. Event=3Dkpml will do for a use case that an endpoint tells the server that = it wants the key presses to be monitored. I was making the case that SUB can be included in method parm of REFER. Serhad From: aayush bhatnagar [mailto:abhatnagar192006@gmail.com] Sent: Tuesday, March 24, 2009 1:19 AM To: Doken, Serhad Cc: Paul Kyzivat; SIP IETF; Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription us= age? (was RE: SIP INFO) >One can send a out of dialog, norefersub REFER and no dialog is establishe= d at the recipient. >Only an implicit subscription is created and a NTFY ma= y be sent or not sent at all. you are right. >It should be possible to do Refer-To: sip:serhad@doken.com;method=3DSUBSCRIBE?>Event=3Dpresence asking REFER receiver = to send me a SUBSCRIBE in order to find out about >my presence. In case the receiver is a server in the network, it must implement the role= of a PNA. If its an endpoint, it will subscribe only after approval of the= human user, else respond back with 400. I am not sure how many presence cl= ients support forced subscriptions like this. On Tue, Mar 24, 2009 at 1:01 PM, Doken, Serhad > wrote: > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounc= es@ietf.org] On Behalf Of > aayush bhatnagar > Sent: Monday, March 23, 2009 8:30 PM > To: Paul Kyzivat > Cc: SIP IETF; Brett Tate > Subject: Re: [Sip] Is REFER within dialog part of INVITE or > subscription usage? (was RE: SIP INFO) > > REFER if placed within the scope of the existing dialog usage of > INVITE will reuse its dialog usage, and create an implicit > subscription for the refer event package at the recipient. However, if > the recipient chooses to reject the in dialog REFER request, the > communication established by the INVITE should not be affected. Such a > rejection scenario implies that the call transfer failed..however the > existing active call should not be torn down. > > REFER if sent outside the scope of any exisiting dialog will behave as > a dialog creating request and will establish a subscription at the > recipient as described above. This subscription is only used to notify > the status of the sip session referral to the originator and is > seperate from any other subscribe usage that may have existed at the > recipient. One can send a out of dialog, norefersub REFER and no dialog is established= at the recipient. Only an implicit subscription is created and a NTFY may = be sent or not sent at all. > > As far as accessing the referred resource is concerned...using the > method parameter, it depends upon the business logic of the recipient > of the REFER request. You may send a REFER to a conferencing server > with a method INVITE to invite a user to join a conference. A method > parameter with the value BYE would imply removal from the conference > by the server and so on. > > I dont think you can include a SUBSCRIBE in the method parameter of > the REFER request. You have no way of telling the event package usage > of the subscription to the recipient, as the event header cannot be It should be possible to do Refer-To: sip:serhad@doken.com;method=3DSUBSCRIBE?Event=3Dpresence asking REFER receiver to= send me a SUBSCRIBE in order to find out about my presence. > included in the REFER request. Moreover, you can never be sure whether > the subscription usage is even applicable to the recipient or whether > the recipient even supports it. > > aayush > > On 3/24/09, Paul Kyzivat > = wrote: > > > > > > Dale Worley wrote: > >> On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote: > >>> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION > >>> usage, or neither? > >>> > >>> I'm asking mainly because of REFER 481 impacts; however the answer > >>> also has potential implications concerning draft-ietf-sip-info- > events. > >>> RFC 5057 appears to imply that it is part of the subscription > usage; > >>> however I'm not positive if my interpretation and/or RFC 5057 is > >>> correct. > >>> > >>> If REFER isn't considered part of the INVITE usage, how should > REFER > >>> 481 be interpreted? More specifically, should receiver of REFER > 481 > >>> send BYE? > >> > >> I would argue that the REFER is part of the INVITE usage, because > REFER > >> in that context is intimately related to the INVITE usage -- it is > >> intended to transfer the INVITE usage/dialog transferred to a > different > >> destination. > > > > Well, I guess there is that implied association. (Part of the "do > what > > *I* had in mind" approach that REFER has.) Since this was never > spelled > > out, it could also be simply "while this isn't part of an INVITE > usage, > > if there happens to be an INVITE usage, please refer that one." > > > > I guess the question is: would it be valid to send a REFER within an > > existing dialog that had no INVITE usage? If it were valid, > presumably > > it would have the same meaning as sending one outside a dialog, > except > > that the resulting subscription would share the dialog. I expect that > is > > a usage it would be difficult to find in the wild. > > > > Ah, but now I want to reconsider. Remember that REFER can take a > method > > name. So, rather than referring an INVITE, I could be referring > MESSAGE, > > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the > > association to the INVITE usage is probably meaningless. (Of course > its > > meaningful for BYE.) > > > >> And it seems quite safe that if the REFER receives a 481 response, > the > >> INVITE usage must not be functional any more, since the far end of > that > >> usage has denied that it can act on the REFER. > > > > IIRC, 5057 decided that each dialog usage must get its own 481 before > it > > goes away. I don't think there are any cases where a single 481 > response > > can make multiple usages go away. > > > > So the important question is whether the REFER is part of the INVITE > > usage and so its 481 takes down the INVITE usage or not. That gets > > especially interesting if the dialog already had both an INVITE > usage > > and a SUBSCRIBE usage. Does it make sense that the refer take down > the > > INVITE usage and leave up the SUBSCRIBE usage? > > > >> Now it's possible that the REFER, if it is successful, is the first > >> transaction of the subscription usage. But I don't think that has > any > >> paradoxical consequences, as by hypothesis, the REFER succeeded. > > > > Yeah, its already so weird, why not a little more weird? > > > > Also, I think it has recently been clarified that the 200 of a > SUBSCRIBE > > should not be considered to create a dialog - that its the NOTIFY > that > > creates the dialog. If so, then I suppose the same should be true of > REFER. > > > > Bottom line: I can live with it either way, but think it should be > > documented one way or the other. > > > > Thanks, > > Paul > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on t= he application of sip > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the= application of sip --_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F820NASANEXMB09na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Perhaps presence was not the best example there given what i= s supported today though that should not limit the imagination since new services/devices pop up every day. Point is  this can be enabled by th= e basic Sip building blocks.

 

Event=3Dkpml will do for a use case that an endpoint tells t= he server that it wants the key presses to be monitored.

 

I was making the case that SUB can be included in method par= m of REFER.

 

Serhad

 

From: aayush bhatna= gar [mailto:abhatnagar192006@gmail.com]
Sent: Tuesday, March 24, 2009 1:19 AM
To: Doken, Serhad
Cc: Paul Kyzivat; SIP IETF; Brett Tate
Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscrip= tion usage? (was RE: SIP INFO)

 

>One can send a out of dialog, norefersub REFER and= no dialog is established at the recipient. >Only an implicit subscription i= s created and a NTFY may be sent or not sent at all.

 

you are right. 

 

>It should be possible to do Refer-To: sip:serhad@doken.com;method=3DSU= BSCRIBE?>Event=3Dpresence asking REFER receiver to send me a SUBSCRIBE in order to find out about >= ;my presence.

 

In case the receiver is= a server in the network, it must implement the role of a PNA. If its an endpo= int, it will subscribe only after approval of the human user, else respond back = with 400. I am not sure how many presence clients support forced subscriptions l= ike this. 

On Tue, Mar 24, 2009 at 1:01 PM, Doken, Serhad <sdoken@qualcomm.com> wrote:=



> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] O= n Behalf Of

> aayush bhatnagar
> Sent: Monday, March 23, 2009 8:30 PM
> To: Paul Kyzivat
> Cc: SIP IETF; Brett Tate
> Subject: Re: [Sip] Is REFER within dialog part of INVITE or
> subscription usage? (was RE: SIP INFO)
>

> REFER if placed wi= thin the scope of the existing dialog usage of
> INVITE will reuse its dialog usage, and create an implicit
> subscription for the refer event package at the recipient. However, if=
> the recipient chooses to reject the in dialog REFER request, the
> communication established by the INVITE should not be affected. Such a=
> rejection scenario implies that the call transfer failed..however the<= br> > existing active call should not be torn down.
>
> REFER if sent outside the scope of any exisiting dialog will behave as=
> a dialog creating request and will establish a subscription at the
> recipient as described above. This subscription is only used to notify=
> the status of the sip session referral to the originator and is
> seperate from any other subscribe usage that may have existed at the > recipient.

One can send a out of dialog, norefersub REFER and no = dialog is established at the recipient. Only an implicit subscription is created a= nd a NTFY may be sent or not sent at all.


>
> As far as accessing the referred resource is concerned...using the
> method parameter, it depends upon the business logic of the recipient<= br> > of the REFER request. You may send a REFER to a conferencing server > with a method INVITE to invite a user to join a conference. A method > parameter with the value BYE would imply removal from the conference > by the server and so on.
>
> I dont think you can include a SUBSCRIBE in the method parameter of > the REFER request. You have no way of telling the event package usage<= br> > of the subscription to the recipient, as the event header cannot be

It should be possible to do Refer-To: sip:serhad@doken.com;method=3DSU= BSCRIBE?Event=3Dpresence asking REFER receiver to send me a SUBSCRIBE in order to find out about my presence.


> included in the REFER request. Moreover, you can never be sure whether=
> the subscription usage is even applicable to the recipient or whether<= br> > the recipient even supports it.
>
> aayush
>
> On 3/24/09, Paul Kyzivat <pky= zivat@cisco.com> wrote:
> >
> >
> > Dale Worley wrote:
> >> On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote:
> >>> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION
> >>> usage, or neither?
> >>>
> >>> I'm asking mainly because of REFER 481 impacts; however t= he answer
> >>> also has potential implications concerning draft-ietf-sip-info-
> events.
> >>> RFC 5057 appears to imply that it is part of the subscrip= tion
> usage;
> >>> however I'm not positive if my interpretation and/or RFC = 5057 is
> >>> correct.
> >>>
> >>> If REFER isn't considered part of the INVITE usage, how should
> REFER
> >>> 481 be interpreted?  More specifically, should recei= ver of REFER
> 481
> >>> send BYE?
> >>
> >> I would argue that the REFER is part of the INVITE usage, bec= ause
> REFER
> >> in that context is intimately related to the INVITE usage -- = it is
> >> intended to transfer the INVITE usage/dialog transferred to a=
> different
> >> destination.
> >
> > Well, I guess there is that implied association. (Part of the "do
> what
> > *I* had in mind" approach that REFER has.) Since this was ne= ver
> spelled
> > out, it could also be simply "while this isn't part of an IN= VITE
> usage,
> > if there happens to be an INVITE usage, please refer that one.&qu= ot;
> >
> > I guess the question is: would it be valid to send a REFER within= an
> > existing dialog that had no INVITE usage? If it were valid,
> presumably
> > it would have the same meaning as sending one outside a dialog, > except
> > that the resulting subscription would share the dialog. I expect = that
> is
> > a usage it would be difficult to find in the wild.
> >
> > Ah, but now I want to reconsider. Remember that REFER can take a<= br> > method
> > name. So, rather than referring an INVITE, I could be referring > MESSAGE,
> > OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, = the
> > association to the INVITE usage is probably meaningless. (Of cour= se
> its
> > meaningful for BYE.)
> >
> >> And it seems quite safe that if the REFER receives a 481 response,
> the
> >> INVITE usage must not be functional any more, since the far e= nd of
> that
> >> usage has denied that it can act on the REFER.
> >
> > IIRC, 5057 decided that each dialog usage must get its own 481 be= fore
> it
> > goes away. I don't think there are any cases where a single 481 > response
> > can make multiple usages go away.
> >
> > So the important question is whether the REFER is part of the INV= ITE
> > usage and so its 481 takes down the INVITE usage or not. That get= s
> > especially interesting if  the dialog already had both an IN= VITE
> usage
> > and a SUBSCRIBE usage. Does it make sense that the refer take dow= n
> the
> > INVITE usage and leave up the SUBSCRIBE usage?
> >
> >> Now it's possible that the REFER, if it is successful, is the first
> >> transaction of the subscription usage.  But I don't thin= k that has
> any
> >> paradoxical consequences, as by hypothesis, the REFER succeed= ed.
> >
> > Yeah, its already so weird, why not a little more weird?
> >
> > Also, I think it has recently been clarified that the 200 of a > SUBSCRIBE
> > should not be considered to create a dialog - that its the NOTIFY=
> that
> > creates the dialog. If so, then I suppose the same should be true= of
> REFER.
> >
> > Bottom line: I can live with it either way, but think it should b= e
> > documented one way or the other.
> >
> >     Thanks,
> >     Paul
> > _______________________________________________
> > Sip mailing list  https:= //www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-imple= mentors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for = new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implemento= rs@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

 

--_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F820NASANEXMB09na_-- From sdoken@qualcomm.com Fri Mar 27 00:13:28 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B8A28C150 for ; Fri, 27 Mar 2009 00:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.265 X-Spam-Level: X-Spam-Status: No, score=-105.265 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2pazQatD-PP for ; Fri, 27 Mar 2009 00:13:27 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 825383A6C23 for ; Fri, 27 Mar 2009 00:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1238138062; x=1269674062; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 "DRAGE,=20Keith=20(Keith)"=20, =0D=0A=20=20=20=20=20=20=20=20Mary=20Barnes=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Christe r=20Holmberg=20,=0D=0A=20 =20=20=20=20=20=20=20"sip@ietf.org"=20 |Date:=20Fri,=2027=20Mar=202009=2000:14:19=20-0700 |Subject:=20RE:=20New=20version=20of=20draft-holmberg-sip -keep|Thread-Topic:=20New=20version=20of=20draft-holmberg -sip-keep|Thread-Index:=20AcmuOhTsgZvUrNV7RDORHPJIBjZWIgA LU8c8AAwd+9AABPE4wA=3D=3D|Message-ID:=20 |References:=20=0D=0A=09<1ECE0EB50388174790 F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com>=0D=0A=20 <28B7C3AA2A7ABA4A841F11217ABE78D6757BE91E@FRMRSSXCHMBSB3. dc-m.alcatel-lucent.com>|In-Reply-To:=20<28B7C3AA2A7ABA4A 841F11217ABE78D6757BE91E@FRMRSSXCHMBSB3.dc-m.alcatel-luce nt.com>|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_ED88AAAE8B3D764B9FD8558DE1775B6913927 4F822NASANEXMB09na_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5565"=3B=20a=3D"16658949"; bh=+QCuIa3lHzwbBuh2T2/RFNrQ+F0JPgWpWzCZ78WmvRw=; b=NoKjw7XF3omeJcTXc4juzy8gVxamAYph/U7dJ2aauaKdhkE3Z//7XlPc d5o/8BJPzAJVZ6LnV2qcPNcEnVOEpccXxtQwKc6y+AgdGA9P1wgvKUDcL M1FAjET0n06w/rAsOdw6XH8JQQRdF7vN72julPOW9lqY0LbBDI/JGwDkm I=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16658949" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2009 00:14:21 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R7EL3v002611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Mar 2009 00:14:21 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2R7EKXO019992 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Mar 2009 00:14:20 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.109]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Fri, 27 Mar 2009 00:14:19 -0700 From: "Doken, Serhad" To: "DRAGE, Keith (Keith)" , Mary Barnes , Christer Holmberg , "sip@ietf.org" Date: Fri, 27 Mar 2009 00:14:19 -0700 Thread-Topic: New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8AAwd+9AABPE4wA== Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE91E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE91E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F822NASANEXMB09na_" MIME-Version: 1.0 Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 07:13:28 -0000 --_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F822NASANEXMB09na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ++ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of DRAGE= , Keith (Keith) Sent: Thursday, March 26, 2009 9:53 PM To: Mary Barnes; Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep As individual Support Keith ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary = Barnes Sent: Thursday, March 26, 2009 11:17 PM To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep Hi folks, Christer has updated the document based on the action item from Wednesday's= SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATC= H WG). If folks could please review the document and raise any concerns on= the document now, that would be appreciated. We ask specifically for an an= swer to the question: Do you support the document being adopted as a WG do= cument in RAI (WG tbd)? A simple "yes" is fine, however, if you don't thin= k we should adopt this document, could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holmbe= rg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-keep-= 04.txt tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer --_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F822NASANEXMB09na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of draft-holmberg-sip-keep

++

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of DRAG= E, Keith (Keith)
Sent: Thursday, March 26, 2009 9:53 PM
To: Mary Barnes; Christer Holmberg; sip@ietf.org
Subject: Re: [Sip] New version of draft-holmberg-sip-keep=

 

As individual

 

Support

 

Keith

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Thursday, March 26, 2009 11:17 PM
To: Christer Holmberg; sip@ietf.org
Subject: Re: [Sip] New version of draft-holmberg-sip-keep

Hi folks= ,

Christer has updated the document based on the action item from Wednesday's= SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATCH WG).  If folks could please review the document and raise any concerns= on the document now, that would be appreciated. We ask specifically for an ans= wer to the question:  Do you support the document being adopted as a WG document in RAI (WG tbd)?  A simple "yes" is fine, however, = if you don't think we should adopt this document, could you please provide the reason.

For your convenience, here's the link to the document:
http://= tools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And, the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.= org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/d= raft-holmberg-sip-keep-04.txt
tinyurl: http://tinyurl.com/dfyvxz

Regards,
Mary
SIPPING WG co-chair


-----Original Message-----
From: sip-bounces@ietf.org on behalf of Christer Holmberg
Sent: Thu 3/26/2009 12:41 PM
To: sip@ietf.org
Subject: [Sip] New version of draft-holmberg-sip-keep


Hi,

I've submitted a new version (-04) of the keep draft.

The requirement text is now alligned with the text shown on the slides
during the SFO SIP WG presentation.

There are no other changes in the document from the previous version.

Regards,

Christer

--_000_ED88AAAE8B3D764B9FD8558DE1775B69139274F822NASANEXMB09na_-- From marianne.mohali@orange-ftgroup.com Fri Mar 27 00:14:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C90B3A67D2 for ; Fri, 27 Mar 2009 00:14:09 -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.639, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gNHl-yNxMkJ for ; Fri, 27 Mar 2009 00:14:08 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 2696C3A68FB for ; Fri, 27 Mar 2009 00:14:07 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 08:14:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AEAB.B7B6B389" Date: Fri, 27 Mar 2009 08:14:47 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02606530619@ftrdmel2> In-Reply-To: <4D8385DA-E7BD-4F9B-8E27-6A3E4C0267B5@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: AcmumsPJV7yoCbgkTtePeMskvm+X+QAEOPpQ References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <4D8385DA-E7BD-4F9B-8E27-6A3E4C0267B5@ntt-at.com> From: To: , X-OriginalArrivalTime: 27 Mar 2009 07:14:50.0731 (UTC) FILETIME=[B80D9BB0:01C9AEAB] Cc: sip@ietf.org, christer.holmberg@ericsson.com Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 07:14:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AEAB.B7B6B389 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes ________________________________ De : sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] De la part de = Shida Schubert Envoy=E9 : jeudi 26 mars 2009 22:13 =C0 : Mary Barnes Cc : sip@ietf.org List; Christer Holmberg Objet : Re: [Sip] New version of draft-holmberg-sip-keep Yes I support this work too. On 26-Mar-09, at 4:16 PM, Mary Barnes wrote: Hi folks, =09 Christer has updated the document based on the action item from = Wednesday's SIP session (chaired by SIPPING chairs and modeled as the = proposed DISPATCH WG). If folks could please review the document and = raise any concerns on the document now, that would be appreciated. We = ask specifically for an answer to the question: Do you support the = document being adopted as a WG document in RAI (WG tbd)? A simple "yes" = is fine, however, if you don't think we should adopt this document, = could you please provide the reason. =09 For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: = http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holm= berg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-k= eep-04.txt tinyurl: http://tinyurl.com/dfyvxz =09 Regards, Mary SIPPING WG co-chair =09 =09 -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep =09 =09 Hi, =09 I've submitted a new version (-04) of the keep draft. =09 The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. =09 There are no other changes in the document from the previous version. =09 Regards, =09 Christer =09 =09 _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C9AEAB.B7B6B389 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes

De : sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] De la part de Shida=20 Schubert
Envoy=E9 : jeudi 26 mars 2009 = 22:13
=C0 :=20 Mary Barnes
Cc : sip@ietf.org List; Christer=20 Holmberg
Objet : Re: [Sip] New version of=20 draft-holmberg-sip-keep


Yes I support this work too.

On 26-Mar-09, at 4:16 PM, Mary Barnes wrote:

Hi folks,

Christer has updated the document = based on=20 the action item from Wednesday's SIP session (chaired by SIPPING = chairs and=20 modeled as the proposed DISPATCH WG).  If folks could please = review the=20 document and raise any concerns on the document now, that would be=20 appreciated. We ask specifically for an answer to the question:  = Do you=20 support the document being adopted as a WG document in RAI (WG = tbd)?  A=20 simple "yes" is fine, however, if you don't think we should adopt this = document, could you please provide the reason.

For your = convenience,=20 here's the link to the document:
http://t= ools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And,=20 the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tool= s.ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf= .org/id/draft-holmberg-sip-keep-04.txt
tinyurl:=20 http://tinyurl.com/dfyvxz

R= egards,
Mary
SIPPING=20 WG co-chair


-----Original Message-----
From: sip-bounces@ietf.org on = behalf of=20 Christer Holmberg
Sent: Thu 3/26/2009 12:41 PM
To: sip@ietf.org
Subject: [Sip] New = version of=20 draft-holmberg-sip-keep


Hi,

I've submitted a new = version=20 (-04) of the keep draft.

The requirement text is now alligned = with the=20 text shown on the slides
during the SFO SIP WG = presentation.

There=20 are no other changes in the document from the previous=20 = version.

Regards,

Christer

________= _______________________________________
Sip=20 mailing list  https://www.ietf.org/m= ailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip

------_=_NextPart_001_01C9AEAB.B7B6B389-- From pkyzivat@cisco.com Fri Mar 27 05:07:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCEDA28C0DF for ; Fri, 27 Mar 2009 05:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=3.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xxeZ9gKFWgS for ; Fri, 27 Mar 2009 05:07:04 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BDF8D3A68D1 for ; Fri, 27 Mar 2009 05:07:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,431,1233532800"; d="scan'208";a="147502025" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 27 Mar 2009 12:07:59 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2RC7wSd024171; Fri, 27 Mar 2009 08:07:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2RC7w1h012219; Fri, 27 Mar 2009 12:07:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 08:07:58 -0400 Received: from [10.86.251.174] ([10.86.251.174]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 08:07:58 -0400 Message-ID: <49CCC1A1.9040501@cisco.com> Date: Fri, 27 Mar 2009 08:08:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Doken, Serhad" References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <49C8F18D.1040800@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2009 12:07:58.0098 (UTC) FILETIME=[AAF0D720:01C9AED4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3372; t=1238155678; x=1239019678; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Is=20REFER=20within=20dialog=20 part=20of=20INVITE=20or=09subscription=09usage?=0A=20(was=20 RE=3A=20SIP=20INFO) |Sender:=20 |To:=20=22Doken,=20Serhad=22=20; bh=4MdYZ0oEU1x0ehpPbTVvXg9WnAVC8A2mHrr8G3xiGaE=; b=eIdve6bLSjm9Z8TB/Oyb4qRVgZ8TA8NfEvvc7pD1c5/P2BT3vsVAZVu7IV nIlNHSY24qmc7tpYY4UPVYvYhDoDVoNGFjaKK1ab8atzjoTuuju49HC98JXG Ay0Yf3t2IL; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 12:07:05 -0000 Doken, Serhad wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, March 24, 2009 7:43 AM >> To: Doken, Serhad >> Cc: Dale Worley; SIP IETF; Brett Tate >> Subject: Re: [Sip] Is REFER within dialog part of INVITE or >> subscription usage? (was RE: SIP INFO) >> >> >> >> Doken, Serhad wrote: >> >>>> I guess the question is: would it be valid to send a REFER within an >>>> existing dialog that had no INVITE usage? If it were valid, >> presumably >>> Yes, I think so. >>> >>> >>>> it would have the same meaning as sending one outside a dialog, >> except >>>> that the resulting subscription would share the dialog. I expect >> that >>>> is >>>> a usage it would be difficult to find in the wild. >>> Consider a third party control application that forces an endpoint to >> register : >>> REFER sip:phone.doken.com SIP/2.0 >>> Refer-To: >>> >>> that triggers a REG to the registrar as : >>> >>> REGISTER sip:serhad@doken.com SIP/2.0 >> You are suggesting that first this 3pcc application sends a SUBSCRIBE >> to >> this UA, establishing a dialog. Then it sends a REFER within the >> dialog, >> asking the UA REGISTER? That then would presumably result in a >> subscription to the refer event package sharing the dialog with the >> prior subscription. I guess this is *possible*, though I don't know >> *why* it would be done. What would the initial SUBSCRIBE be to, and how >> would it be established before the UA has registered? > > 3rd party contact center desktop monitoring application is used by the supervisor to see agent's activities. Thru a CTI <->SIP translator, it SUBs to the agent's presence. Once the customer service agent comes in the morning and turns his phone's status to Online(Open), app notices this and forces it to Register. At the end of the day when agent leaves, does the opposite and de-registers it. Thus, it is made sure that they only get billed for the time that agent was registered(online) by the service provider. I find this less than compelling. How does the monitoring application discover and address the UA to establish the subscription? If that was possible, then the UA must have a globally routable URI that is known to the application. And that could be used to send an out-of-dialog REFER. Thanks, Paul >> Are you aware of such usage in the wild? > > I have seen somewhat similar examples. If you are offering enough stimulus/TARP money, wild frontiers will get closer. > > It's mostly used for Xfer however as you alluded to, REFER is implicit or ambiguous that it is open to be used as the Swiss knife if I wanted the other side to do something for me. As long as the sender and receiver know/understand what is meant or the context(especially if they are from the same vendor), everything is fine, if not misinterpretations may happen. > >> (Its incidental to this discussion, but REGISTER presents unique >> challenges because of the way addressing works for it. Contrary to your >> example above, we would typically expect that the To: would contain the >> full URI, while the R-URI would only be sip:doken.com. This would > > You are right. > > Thanks, > Serhad > >> require more special case processing.) >> >> Thanks, >> Paul > From ietf.hanserik@gmail.com Fri Mar 27 05:32:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C913A6922 for ; Fri, 27 Mar 2009 05:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9Oy-nHRzd4v for ; Fri, 27 Mar 2009 05:32:46 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id A839B3A69C2 for ; Fri, 27 Mar 2009 05:32:43 -0700 (PDT) Received: by ewy9 with SMTP id 9so1029632ewy.37 for ; Fri, 27 Mar 2009 05:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p7NwqXlPuYY0YGUBIbFP1mWOHda5YCIXgOWh3TlJwhA=; b=sBKC/5K5IvnjCZz2mZL2p850gLO+7Gn9P82oyUe7fiwCcYFNoaGbvFIX0fh05i2Iiz KnRQ6ND/fPnMOg21lByjGX1V5/7SPaATeWDw9oDhEmHsnd5Rp2QrN5Fg9nV0Y/YpcKt+ KIgr46KHzEdTBC08AQyHmzB4ZgdOhWwZcI/ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TVrEedpqx11urbRFEeqILkzJLtp5ccFvs72qroI8yU1NrB7E2qiG61bBR0nzpgRXaB x87e1mPyf4d6bY47B7HMmNy2Wk30d4ORjFfwMbV5k35ILDWrdGzK+kzoT2L1nrIIpnps z/by9eBmdnPX9sXo08/nylaSNONNCMdLlqtXk= MIME-Version: 1.0 Received: by 10.210.35.5 with SMTP id i5mr1590557ebi.34.1238157217203; Fri, 27 Mar 2009 05:33:37 -0700 (PDT) In-Reply-To: <49CCC1A1.9040501@cisco.com> References: <24ACC38D-8B7D-46E6-B767-73A33F6C9266@standardstrack.com> <49C79CFD.1010408@cisco.com> <9B2A061A1137254BBE4F4B2CD843646A10BFF48DF0@mbx02.citservers.local> <1237853234.16613.41.camel@victoria-pingtel-com.us.nortel.com> <49C83831.7010102@cisco.com> <49C8F18D.1040800@cisco.com> <49CCC1A1.9040501@cisco.com> Date: Fri, 27 Mar 2009 13:33:36 +0100 Message-ID: <9ae56b1e0903270533tf8cbb4dh44fe66ef605be34c@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0015174c37701b880f046618f111 Cc: SIP IETF , Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 12:32:47 -0000 --0015174c37701b880f046618f111 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit That, AND why would you not use the OPEN line button to just REGISTER? And make the application be notified that the registration/deregistration happened. You could for example route the registrations through the application hosting proxy to the registrar. Or have like in IMS the possibility for the registrar to notify an application server upon registration of a particular user. Much simpler. /Hans Erik van Elburg On Fri, Mar 27, 2009 at 1:08 PM, Paul Kyzivat wrote: > You are suggesting that first this 3pcc application sends a SUBSCRIBE >>> to >>> this UA, establishing a dialog. Then it sends a REFER within the >>> dialog, >>> asking the UA REGISTER? That then would presumably result in a >>> subscription to the refer event package sharing the dialog with the >>> prior subscription. I guess this is *possible*, though I don't know >>> *why* it would be done. What would the initial SUBSCRIBE be to, and how >>> would it be established before the UA has registered? >>> >> >> 3rd party contact center desktop monitoring application is used by the >> supervisor to see agent's activities. Thru a CTI <->SIP translator, it SUBs >> to the agent's presence. Once the customer service agent comes in the >> morning and turns his phone's status to Online(Open), app notices this and >> forces it to Register. At the end of the day when agent leaves, does the >> opposite and de-registers it. Thus, it is made sure that they only get >> billed for the time that agent was registered(online) by the service >> provider. >> > > I find this less than compelling. How does the monitoring application > discover and address the UA to establish the subscription? If that was > possible, then the UA must have a globally routable URI that is known to the > application. And that could be used to send an out-of-dialog REFER. > > Thanks, > Paul --0015174c37701b880f046618f111 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That, AND why would you not use the OPEN line button to just REGISTER? And = make the application be notified that the registration/deregistration happe= ned. You could for example route the registrations through the application = hosting proxy to the registrar. Or have like in IMS the possibility for the= registrar to notify an application server upon registration of a particula= r user. Much simpler.

/Hans Erik van Elburg

On Fri, Mar 27, 2009 at 1:08 PM, Paul Kyziva= t <pkyzivat@cisc= o.com> wrote:
You are suggesting that first this 3pcc application sends a SUBSCRIBE
to
this UA, establishing a dialog. Then it sends a REFER within the
dialog,
asking the UA REGISTER? That then would presumably result in a
subscription to the refer event package sharing the dialog with the
prior subscription. I guess this is *possible*, though I don't know
*why* it would be done. What would the initial SUBSCRIBE be to, and how
would it be established before the UA has registered?

3rd party contact center desktop monitoring application is used by the supe= rvisor to see agent's activities. Thru a CTI <->SIP translator, i= t SUBs to the agent's presence. Once the customer service agent comes i= n the morning and turns his phone's status to Online(Open), app notices= this and forces it to Register. At the end of the day when agent leaves, d= oes the opposite and de-registers it. Thus, it is made sure that they only = get billed for the time that agent was registered(online) by the service pr= ovider.

I find this less than compelling. How does the monitoring application disco= ver and address the UA to establish the subscription? If that was possible,= then the UA must have a globally routable URI that is known to the applica= tion. And that could be used to send an out-of-dialog REFER.

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

--0015174c37701b880f046618f111-- From steve.norreys@bt.com Fri Mar 27 09:14:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A483A698D for ; Fri, 27 Mar 2009 09:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgN0ABTPEN4X for ; Fri, 27 Mar 2009 09:14:12 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id AD5403A68F5 for ; Fri, 27 Mar 2009 09:14:11 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 16:15:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AEF7.2FA1FC68" Date: Fri, 27 Mar 2009 16:15:03 -0000 Message-ID: <20B524BAC1567F48AE039F74BD294D190518E9DA@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8ACPsBeA= From: To: , , X-OriginalArrivalTime: 27 Mar 2009 16:15:04.0228 (UTC) FILETIME=[3000BE40:01C9AEF7] Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 16:14:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AEF7.2FA1FC68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 26 March 2009 23:17 To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep Hi folks, Christer has updated the document based on the action item from Wednesday's SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATCH WG). If folks could please review the document and raise any concerns on the document now, that would be appreciated. We ask specifically for an answer to the question: Do you support the document being adopted as a WG document in RAI (WG tbd)? A simple "yes" is fine, however, if you don't think we should adopt this document, could you please provide the reason. For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holm= b erg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-ke= e p-04.txt tinyurl: http://tinyurl.com/dfyvxz Regards, Mary SIPPING WG co-chair -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep Hi, I've submitted a new version (-04) of the keep draft. The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. There are no other changes in the document from the previous version. Regards, Christer ------_=_NextPart_001_01C9AEF7.2FA1FC68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of = draft-holmberg-sip-keep
Yes

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 26=20 March 2009 23:17
To: Christer Holmberg;=20 sip@ietf.org
Subject: Re: [Sip] New version of=20 draft-holmberg-sip-keep

Hi folks,

Christer has updated the document = based on the=20 action item from Wednesday's SIP session (chaired by SIPPING chairs and = modeled=20 as the proposed DISPATCH WG).  If folks could please review the = document=20 and raise any concerns on the document now, that would be appreciated. = We ask=20 specifically for an answer to the question:  Do you support the = document=20 being adopted as a WG document in RAI (WG tbd)?  A simple "yes" is = fine,=20 however, if you don't think we should adopt this document, could you = please=20 provide the reason.

For your convenience, here's the link to the=20 document:
http://t= ools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And,=20 the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tool= s.ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf= .org/id/draft-holmberg-sip-keep-04.txt
tinyurl:=20 http://tinyurl.com/dfyvxz

R= egards,
Mary
SIPPING=20 WG co-chair


-----Original Message-----
From: = sip-bounces@ietf.org=20 on behalf of Christer Holmberg
Sent: Thu 3/26/2009 12:41 PM
To:=20 sip@ietf.org
Subject: [Sip] New version of=20 draft-holmberg-sip-keep


Hi,

I've submitted a new = version (-04)=20 of the keep draft.

The requirement text is now alligned with the = text=20 shown on the slides
during the SFO SIP WG presentation.

There = are no=20 other changes in the document from the previous=20 version.

Regards,

Christer

= ------_=_NextPart_001_01C9AEF7.2FA1FC68-- From AUDET@nortel.com Fri Mar 27 09:27:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D4628C175 for ; Fri, 27 Mar 2009 09:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1y2qafq6HsEa for ; Fri, 27 Mar 2009 09:27:01 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E0B5228C174 for ; Fri, 27 Mar 2009 09:27:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2RGRNS13793; Fri, 27 Mar 2009 16:27:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AEF8.E70D25AF" Date: Fri, 27 Mar 2009 11:27:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D1B2D03@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8ACRfwxA= References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "Christer Holmberg" , Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 16:27:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AEF8.E70D25AF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable YES. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Barnes, Mary (RICH2:AR00) Sent: Thursday, March 26, 2009 16:17 To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep =09 =09 Hi folks, =09 Christer has updated the document based on the action item from = Wednesday's SIP session (chaired by SIPPING chairs and modeled as the = proposed DISPATCH WG). If folks could please review the document and = raise any concerns on the document now, that would be appreciated. We = ask specifically for an answer to the question: Do you support the = document being adopted as a WG document in RAI (WG tbd)? A simple "yes" = is fine, however, if you don't think we should adopt this document, = could you please provide the reason. =09 For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: = http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holm= berg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-k= eep-04.txt tinyurl: http://tinyurl.com/dfyvxz =09 Regards, Mary SIPPING WG co-chair =09 =09 -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep =09 =09 Hi, =09 I've submitted a new version (-04) of the keep draft. =09 The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. =09 There are no other changes in the document from the previous version. =09 Regards, =09 Christer =09 =09 ------_=_NextPart_001_01C9AEF8.E70D25AF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of = draft-holmberg-sip-keep
YES.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Barnes, Mary=20 (RICH2:AR00)
Sent: Thursday, March 26, 2009 = 16:17
To:=20 Christer Holmberg; sip@ietf.org
Subject: Re: [Sip] New = version of=20 draft-holmberg-sip-keep

Hi folks,

Christer has updated the document = based on=20 the action item from Wednesday's SIP session (chaired by SIPPING = chairs and=20 modeled as the proposed DISPATCH WG).  If folks could please = review the=20 document and raise any concerns on the document now, that would be=20 appreciated. We ask specifically for an answer to the question:  = Do you=20 support the document being adopted as a WG document in RAI (WG = tbd)?  A=20 simple "yes" is fine, however, if you don't think we should adopt this = document, could you please provide the reason.

For your = convenience,=20 here's the link to the document:
http://t= ools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And,=20 the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tool= s.ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf= .org/id/draft-holmberg-sip-keep-04.txt
tinyurl:=20 http://tinyurl.com/dfyvxz

R= egards,
Mary
SIPPING=20 WG co-chair


-----Original Message-----
From:=20 sip-bounces@ietf.org on behalf of Christer Holmberg
Sent: Thu = 3/26/2009=20 12:41 PM
To: sip@ietf.org
Subject: [Sip] New version of=20 draft-holmberg-sip-keep


Hi,

I've submitted a new = version=20 (-04) of the keep draft.

The requirement text is now alligned = with the=20 text shown on the slides
during the SFO SIP WG = presentation.

There=20 are no other changes in the document from the previous=20 = version.

Regards,

Christer

<= /BODY> ------_=_NextPart_001_01C9AEF8.E70D25AF-- From salvatore.loreto@ericsson.com Fri Mar 27 10:03:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334EE3A6CA0 for ; Fri, 27 Mar 2009 10:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_SE=0.35, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2adiegZoCKT for ; Fri, 27 Mar 2009 10:03:29 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0896B3A6C8C for ; Fri, 27 Mar 2009 10:03:29 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8045B21E53; Fri, 27 Mar 2009 17:55:46 +0100 (CET) X-AuditID: c1b4fb3c-acf5dbb000003f6e-30-49cd04edd47b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3006921E7E; Fri, 27 Mar 2009 17:55:09 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 17:49:28 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 17:49:28 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EA715245B; Fri, 27 Mar 2009 18:49:27 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AF260219E5; Fri, 27 Mar 2009 18:49:27 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AC6DF219D0; Fri, 27 Mar 2009 18:49:26 +0200 (EET) Message-ID: <49CD0395.2020103@ericsson.com> Date: Fri, 27 Mar 2009 18:49:25 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1D1B2D03@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D1B2D03@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 27 Mar 2009 16:49:28.0109 (UTC) FILETIME=[FE2BFDD0:01C9AEFB] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, Mary Barnes , Christer Holmberg Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 17:03:30 -0000 Yes > > ------------------------------------------------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On > Behalf Of *Barnes, Mary (RICH2:AR00) > *Sent:* Thursday, March 26, 2009 16:17 > *To:* Christer Holmberg; sip@ietf.org > *Subject:* Re: [Sip] New version of draft-holmberg-sip-keep > > Hi folks, > > Christer has updated the document based on the action item from > Wednesday's SIP session (chaired by SIPPING chairs and modeled as > the proposed DISPATCH WG). If folks could please review the > document and raise any concerns on the document now, that would be > appreciated. We ask specifically for an answer to the question: > Do you support the document being adopted as a WG document in RAI > (WG tbd)? A simple "yes" is fine, however, if you don't think we > should adopt this document, could you please provide the reason. > > For your convenience, here's the link to the document: > http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt > And, the diff: > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt > > tinyurl: http://tinyurl.com/dfyvxz > > Regards, > Mary > SIPPING WG co-chair > > > -----Original Message----- > From: sip-bounces@ietf.org on behalf of Christer Holmberg > Sent: Thu 3/26/2009 12:41 PM > To: sip@ietf.org > Subject: [Sip] New version of draft-holmberg-sip-keep > > > Hi, > > I've submitted a new version (-04) of the keep draft. > > The requirement text is now alligned with the text shown on the slides > during the SFO SIP WG presentation. > > There are no other changes in the document from the previous version. > > Regards, > > Christer > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From L.Liess@telekom.de Fri Mar 27 10:12:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2093A6C5E for ; Fri, 27 Mar 2009 10:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImY32jYg2-3b for ; Fri, 27 Mar 2009 10:12:39 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 440173A6968 for ; Fri, 27 Mar 2009 10:12:39 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 27 Mar 2009 18:13:32 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 18:13:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Mar 2009 18:13:29 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A002CA7355@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <49CC02F4.6070507@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 Thread-Index: AcmuYzsOrAj/+PMyS5iDoQU7It6ouAAk1yNw References: <49CA9943.1020808@cisco.com> <49CC02F4.6070507@iptel.org> From: To: , , X-OriginalArrivalTime: 27 Mar 2009 17:13:32.0080 (UTC) FILETIME=[5AD87B00:01C9AEFF] Cc: sip@ietf.org Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 17:12:41 -0000 Jiri, =20 I agree with you on the importance of the problem, but I don't agree with you that we can solve the problem by changing one of the protocol basics at this time, with millions of existing boxes, network boxes as well as end devices. Especially the end devices are critical. Most of them send today the IP-address in the call-ID. Customers often do not accept the upgrades. Some customers also have their own boxes. It will take at least 10 years until we can can rely on the secure call-id for dialog correlation. This is far too late. We also do not realy know which problems may occur if we change the protocol basics.=20 I support the session-ID troubleshooting. It works fine and it works now. For dialog matching we should work on a more general framework, e.g. context-id or something else. We can try secure call-id as a long term improvement of the protocol. But we have to make sure that we do not cause problems for the existing boxes and services which are up and running. =20 Laura =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jiri Kuthan > Sent: Thursday, March 26, 2009 11:34 PM > To: Hadriel Kaplan > Cc: IETF SIP List > Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 >=20 > First of all I think it is definitely worth trying. >=20 > Not being able to correlate dialogs through B2BUA is a big > operational problem. I'm not sure that this will get really > adopted (who knows what today's obfuscators choose to obfuscate > tomorrow...). However in hope for solving this problem, presence of > incentives for adoption and absence of any known harm it is > definitely worth doing. >=20 > Another idea how to accommodate receivers that are silly not > to be liberal is using a fake IP address (popular 0.0.0.0). > While not aesthetic at all, it could accommodate such receivers > (under assumption they assign no syntactical meaning to it) > and signal to B2BUA there is no disclosure of IP addresses. >=20 > OTOH it could be time too to abandon 2543 legacy. Supporting > strict routing and other ancient stuff like IP in callid does > not seem worth the trouble to me. >=20 > -jiri >=20 > Hadriel Kaplan wrote: > > Ooh, good point. Fair enough, I'll change that. > >=20 > > -hadriel > >=20 > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]=20 > On Behalf Of > >> Jonathan Rosenberg > >> Sent: Wednesday, March 25, 2009 4:51 PM > >> To: IETF SIP List > >> Subject: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 > >> > >> I didnt get a chance to say this at the mike. > >> > >> You *cannot* change the BNF for the call-id. If you did,=20 > you might end > >> up with the following problem: > >> > >> A new UA gets built, compliant to this update. It is one of these > >> 'aggressive parsing' UAs. It rejects any message which is=20 > not compliant > >> to the BNF. An older, normal RFC-3261 compliant UA sends a=20 > call-id which > >> includes the @-sign. > >> > >> According to the BNF of this updated 3261, and based on=20 > the strictness > >> of this aggressive-parsing UAs, it rejects that request as=20 > non-compliant. > >> > >> As such, you need to keep the BNF, but change the=20 > normative language > >> such that an endpoint MUST NOT include the [@ host] but=20 > MUST be prepared > >> to receive it. > >> > >> -Jonathan R. > >> > >> -- > >> Jonathan D. Rosenberg, Ph.D. 111 Wood=20 > Avenue South > >> Cisco Fellow Iselin, NJ 08830 > >> Cisco, Voice Technology Group > >> jdrosen@cisco.com > >> http://www.jdrosen.net PHONE:=20 > (408) 902-3084 > >> http://www.cisco.com > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From L.Liess@telekom.de Fri Mar 27 10:46:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4533A6C7B for ; Fri, 27 Mar 2009 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPDxKG6uLPpo for ; Fri, 27 Mar 2009 10:46:20 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 0C3DF3A6A4D for ; Fri, 27 Mar 2009 10:46:19 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 27 Mar 2009 18:47:13 +0100 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 18:47:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AF04.0E910FF3" Date: Fri, 27 Mar 2009 18:47:10 +0100 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A002CA7366@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <20B524BAC1567F48AE039F74BD294D190518E9DA@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: AcmuOhTsgZvUrNV7RDORHPJIBjZWIgALU8c8ACPsBeAAAzYt4A== References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <20B524BAC1567F48AE039F74BD294D190518E9DA@E03MVB1-UKBR.domain1.systemhost.net> From: To: X-OriginalArrivalTime: 27 Mar 2009 17:47:11.0960 (UTC) FILETIME=[0EC9B580:01C9AF04] Cc: sip@ietf.org, christer.holmberg@ericsson.com Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 17:46:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AF04.0E910FF3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable yes =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 26 March 2009 23:17 To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep =09 =09 Hi folks, =09 Christer has updated the document based on the action item from Wednesday's SIP session (chaired by SIPPING chairs and modeled as the proposed DISPATCH WG). If folks could please review the document and raise any concerns on the document now, that would be appreciated. We ask specifically for an answer to the question: Do you support the document being adopted as a WG document in RAI (WG tbd)? A simple "yes" is fine, however, if you don't think we should adopt this document, could you please provide the reason. =09 For your convenience, here's the link to the document: http://tools.ietf.org/id/draft-holmberg-sip-keep-04.txt And, the diff: =09 http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-holm= b erg-sip-keep-03.txt&url2=3Dhttp://tools.ietf.org/id/draft-holmberg-sip-ke= e p-04.txt tinyurl: http://tinyurl.com/dfyvxz =09 Regards, Mary SIPPING WG co-chair =09 =09 -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 3/26/2009 12:41 PM To: sip@ietf.org Subject: [Sip] New version of draft-holmberg-sip-keep =09 =09 Hi, =09 I've submitted a new version (-04) of the keep draft. =09 The requirement text is now alligned with the text shown on the slides during the SFO SIP WG presentation. =09 There are no other changes in the document from the previous version. =09 Regards, =09 Christer =09 =09 ------_=_NextPart_001_01C9AF04.0E910FF3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Sip] New version of = draft-holmberg-sip-keep
yes

 
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent:=20 26 March 2009 23:17
To: Christer Holmberg;=20 sip@ietf.org
Subject: Re: [Sip] New version of=20 draft-holmberg-sip-keep

Hi folks,

Christer has updated the document = based on=20 the action item from Wednesday's SIP session (chaired by SIPPING = chairs and=20 modeled as the proposed DISPATCH WG).  If folks could please = review the=20 document and raise any concerns on the document now, that would be=20 appreciated. We ask specifically for an answer to the question:  = Do you=20 support the document being adopted as a WG document in RAI (WG = tbd)?  A=20 simple "yes" is fine, however, if you don't think we should adopt this = document, could you please provide the reason.

For your = convenience,=20 here's the link to the document:
http://t= ools.ietf.org/id/draft-holmberg-sip-keep-04.txt
And,=20 the diff:
http://tools.ietf.org//rfcdiff?url1=3Dhttp://tool= s.ietf.org/id/draft-holmberg-sip-keep-03.txt&url2=3Dhttp://tools.ietf= .org/id/draft-holmberg-sip-keep-04.txt
tinyurl:=20 http://tinyurl.com/dfyvxz

R= egards,
Mary
SIPPING=20 WG co-chair


-----Original Message-----
From:=20 sip-bounces@ietf.org on behalf of Christer Holmberg
Sent: Thu = 3/26/2009=20 12:41 PM
To: sip@ietf.org
Subject: [Sip] New version of=20 draft-holmberg-sip-keep


Hi,

I've submitted a new = version=20 (-04) of the keep draft.

The requirement text is now alligned = with the=20 text shown on the slides
during the SFO SIP WG = presentation.

There=20 are no other changes in the document from the previous=20 = version.

Regards,

Christer

<= /BODY> ------_=_NextPart_001_01C9AF04.0E910FF3-- From adam@nostrum.com Fri Mar 27 13:19:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8170D3A6825 for ; Fri, 27 Mar 2009 13:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc-M0Eww9cRr for ; Fri, 27 Mar 2009 13:19:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5F1323A67E9 for ; Fri, 27 Mar 2009 13:19:05 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2RKJtCa024198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 15:19:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49CD34EB.6010605@nostrum.com> Date: Fri, 27 Mar 2009 13:19:55 -0700 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hadriel Kaplan References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9175/Fri Mar 27 10:17:42 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 20:19:06 -0000 Hadriel Kaplan wrote: > Sure, SBC's may not follow this draft. So? UA's and other devices may > not follow any given draft/RFC. But right now there's actually a > reasonably defendable rationale for why the Call-ID's should be > changed. I'm trying to get rid of that rationale. The owners of the > SBC's will then be able to tell their vendors "go do this draft", if > they find they need SIP extensions to work which rely on the Call-ID > not changing. The market will sort out if that's valuable or not. Which is why an informational draft explaining the problem is useful, while a normative document... not quite so much. Tell UACs: "If you include machine names in your Call-IDs, B2BUAs will have reason to change them." There's no MUST or MUST NOT here, just an explanation of rationale. Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do everyone a favor by not changing them, because it allows proper correlation of related transactions an dialogs." Again, no MUST; no MUST NOT. Just cause and effect. Then see if people want to play nice. The market will sort out if that's valuable or not. /a From drage@alcatel-lucent.com Fri Mar 27 18:53:39 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1663A6823 for ; Fri, 27 Mar 2009 18:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBxNKY+zE-OG for ; Fri, 27 Mar 2009 18:53:39 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id DA8603A67EC for ; Fri, 27 Mar 2009 18:53:38 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2S1sRJN004924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 28 Mar 2009 02:54:29 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 28 Mar 2009 02:54:27 +0100 From: "DRAGE, Keith (Keith)" To: "sip@ietf.org" Date: Sat, 28 Mar 2009 02:54:24 +0100 Thread-Topic: Completion of draft-ietf-sip-ua-privacy-06 Thread-Index: AcmvSB6pvyLF3HqUQdm0NfB4DhgNaA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BEAB7@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "draft-ietf-sip-ua-privacy@tools.ietf.org" Subject: [Sip] Completion of draft-ietf-sip-ua-privacy-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 01:53:39 -0000 (As WG chair) This document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-06.txt I am assuming we are pretty much done with this document and therefore will= proceed with writing up the publication request. If anyone thinks otherwise, now would be a very appropriate time to make th= at position known to the list. Expect some editorials as a result of me writing this up. regards Keith= From HKaplan@acmepacket.com Fri Mar 27 22:18:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B5A3A6866 for ; Fri, 27 Mar 2009 22:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmeHxskxH65S for ; Fri, 27 Mar 2009 22:18:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E7E373A6407 for ; Fri, 27 Mar 2009 22:18:29 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 28 Mar 2009 01:19:23 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 28 Mar 2009 01:19:23 -0400 From: Hadriel Kaplan To: Adam Roach Date: Sat, 28 Mar 2009 01:19:24 -0400 Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmvGXI8w+VjO+DqSnuY5iq1TGCQLwASd+Mw Message-ID: References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> <49CD34EB.6010605@nostrum.com> In-Reply-To: <49CD34EB.6010605@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 05:18:30 -0000 Yeah I've been thinking about what you said the other day about this, and I= think I understand your point, but I still think MUST's and an update to 3= 261 would be good, for the following reasons: 1) We really should want to change 3261 to say MUST NOT put an ip-address/h= ostname in the call-id. Really in 20/20 hindsight I don't think it should = have had one to begin with. 2) It's easier for customers to force vendors to do something if there's a = MUST statement, standards-track RFC, vs. an informational recommendation/sh= ould. 3) Endpoint UAC vendors should do it *before* getting deployed and being to= ld by customers to change after-wards. Specifically I'm thinking about ven= dors who don't attend IETF and aren't that up-to-speed on all the nuances a= nd such. An update to 3261 with normative mandatory language is clearer, I= think. -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Friday, March 27, 2009 4:20 PM >=20 > Which is why an informational draft explaining the problem is useful, > while a normative document... not quite so much. >=20 > Tell UACs: "If you include machine names in your Call-IDs, B2BUAs will > have reason to change them." There's no MUST or MUST NOT here, just an > explanation of rationale. >=20 > Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do everyone > a favor by not changing them, because it allows proper correlation of > related transactions an dialogs." Again, no MUST; no MUST NOT. Just > cause and effect. >=20 > Then see if people want to play nice. The market will sort out if that's > valuable or not. >=20 > /a From HKaplan@acmepacket.com Fri Mar 27 22:24:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E746B3A68EA for ; Fri, 27 Mar 2009 22:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr-U149R9rFe for ; Fri, 27 Mar 2009 22:24:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 83E283A68C7 for ; Fri, 27 Mar 2009 22:24:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 28 Mar 2009 01:25:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 28 Mar 2009 01:24:59 -0400 From: Hadriel Kaplan To: SIP Date: Sat, 28 Mar 2009 01:25:03 -0400 Thread-Topic: B2BUA's changing call-id's: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmvGXI8w+VjO+DqSnuY5iq1TGCQLwAS1T/w Message-ID: References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> <49CD34EB.6010605@nostrum.com> In-Reply-To: <49CD34EB.6010605@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Sip] B2BUA's changing call-id's: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 05:24:10 -0000 Howdy, In talking with some folks about this draft afterwards, I think some of the= consternation around the draft is due to the language around mandating B2B= UA's not to change the Call-ID. I thought it was clear that I only meant f= or the purposes of security/privacy, not for other purposes - in other word= s, if you have some reason you need to change the Call-ID other than privac= y, then the must-not-change doesn't apply. I think to alleviate the concern I'll just remove the language around that,= and change it to more of just a discussion for that topic - with no normat= ive requirements for B2BUA's, other than that if they do change the Call-ID= , they should act as a UAC and create one that doesn't contain an ip/host p= ortion. Would people prefer that? -hadriel From mdolly@att.com Sat Mar 28 09:27:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4973A6915 for ; Sat, 28 Mar 2009 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFMXh5LgWHOY for ; Sat, 28 Mar 2009 09:27:41 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id AC1323A6877 for ; Sat, 28 Mar 2009 09:27:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1238257716!30340538!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 5336 invoked from network); 28 Mar 2009 16:28:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-10.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2009 16:28:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2SGSa8U028575 for ; Sat, 28 Mar 2009 12:28:36 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2SGSXVS028572 for ; Sat, 28 Mar 2009 12:28:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Mar 2009 12:28:31 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BB3B8B@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmvGXI8w+VjO+DqSnuY5iq1TGCQLwASd+MwABezghA= References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com><49CD34EB.6010605@nostrum.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Hadriel Kaplan" , "Adam Roach" Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 16:27:42 -0000 I agree. Lack there of, only means the IETF does not want an interoperable solution -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Saturday, March 28, 2009 1:19 AM To: Adam Roach Cc: SIP Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Yeah I've been thinking about what you said the other day about this, and I think I understand your point, but I still think MUST's and an update to 3261 would be good, for the following reasons: 1) We really should want to change 3261 to say MUST NOT put an ip-address/hostname in the call-id. Really in 20/20 hindsight I don't think it should have had one to begin with. 2) It's easier for customers to force vendors to do something if there's a MUST statement, standards-track RFC, vs. an informational recommendation/should. 3) Endpoint UAC vendors should do it *before* getting deployed and being told by customers to change after-wards. Specifically I'm thinking about vendors who don't attend IETF and aren't that up-to-speed on all the nuances and such. An update to 3261 with normative mandatory language is clearer, I think. -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Friday, March 27, 2009 4:20 PM >=20 > Which is why an informational draft explaining the problem is useful, > while a normative document... not quite so much. >=20 > Tell UACs: "If you include machine names in your Call-IDs, B2BUAs will > have reason to change them." There's no MUST or MUST NOT here, just an > explanation of rationale. >=20 > Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do everyone > a favor by not changing them, because it allows proper correlation of > related transactions an dialogs." Again, no MUST; no MUST NOT. Just > cause and effect. >=20 > Then see if people want to play nice. The market will sort out if that's > valuable or not. >=20 > /a _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mdolly@att.com Sat Mar 28 12:26:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6205F3A69AA; Sat, 28 Mar 2009 12:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba7942c1CWLG; Sat, 28 Mar 2009 12:26:40 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 967573A68F1; Sat, 28 Mar 2009 12:26:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-161.messagelabs.com!1238268455!14552735!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22468 invoked from network); 28 Mar 2009 19:27:35 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-161.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2009 19:27:35 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2SJRZi9026126; Sat, 28 Mar 2009 15:27:35 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2SJRT5s026095; Sat, 28 Mar 2009 15:27:29 -0400 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: Sat, 28 Mar 2009 15:27:29 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD45C2@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Geo URI and privacy URI Thread-Index: Acmv0fXYUCga5gtYQXKTQR4Fsa+kVQACUXmP From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: geopriv@ietf.org, jmorris-lists@cdt.org Subject: Re: [Sip] [Geopriv] Geo URI and privacy URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 19:26:42 -0000 UHJvZmVzc29yLA0KDQpZb3VyIGNvbW1lbnRzIGF0IHRoZSBtaWtlIHdlcmUgb3V0IG9mIGxpbmUs IHNvOg0KSSBjaGFsbGVuZ2UgeW91IGFuZCB5b3VyIDMgYmVzdCBraXNzIGFzcyBncmFkIHN0dWRl bnRzIHRvIGEgZGViYXRlIG9uIHJlYWxpdHkNCg0KSSBkbyByZXNwZWN0IHlvdS4NCg0KQ2hlZXJz LA0KDQpNYXJ0aW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogZ2VvcHJp di1ib3VuY2VzQGlldGYub3JnIDxnZW9wcml2LWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogQWxpc3Nh IENvb3BlciA8YWNvb3BlckBjZHQub3JnPg0KQ2M6ICdHRU9QUklWJyA8Z2VvcHJpdkBpZXRmLm9y Zz47IEpvaG4gTW9ycmlzIDxqbW9ycmlzLWxpc3RzQGNkdC5vcmc+DQpTZW50OiBTYXQgTWFyIDI4 IDE0OjIwOjU0IDIwMDkNClN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gR2VvIFVSSSBhbmQgcHJpdmFj eSBVUkkNCg0KQnV0IHRoZSBJRVRGIGlzIGFuIGVuZ2luZWVyaW5nIG9yZ2FuaXphdGlvbiwgbm90 IGEgcG9saXRpY2FsIGxvYmJ5aW5nICANCm9yZ2FuaXphdGlvbiwgc28gcHJhY3RpY2FsaXR5IG1h dHRlcnMuIEFzIEkndmUgcG9pbnRlZCBvdXQsIGEgc3RyaWN0ICANCmludGVycHJldGF0aW9uIG9m IHRoZSByZXRlbnRpb24gcG9saWN5IG1lYW5zIHRoYXQgb25seSBubyBsb2dnaW5nIGF0ICANCmFs bCBpcyBwb3NzaWJsZSwgc2luY2UgeW91IGNhbid0IHJlYXNvbmFibHkgcHVyZ2UgbG9ncyBhdCBk aWZmZXJlbnQgIA0KdGltZSBpbnRlcnZhbHMuIEl0J3MgYSBiaXQgbXVjaCB0byBleHBlY3QgYSBj b21wYW55IHRvIGNvbXBsZXRlbHkgcmUtIA0KYXJjaGl0ZWN0IHRoZWlyIHdlYiBzZXJ2ZXIsIGlm IHRoZSBhbHRlcm5hdGl2ZSBpcyB0byBpZ25vcmUgR0VPUFJJVi4gIA0KSSdkIGJlIHJlYWxseSBz dXJwcmlzZWQgaWYgYW55IGNvbXBhbnkgaW4gdGhlIGxvY2F0aW9uIHNwYWNlIHRoaW5rcyAgDQph Ym91dCBHRU9QUklWIGF0IGFsbC4uLg0KDQpJdCdzIHByZXR0eSBjbGVhciB0aGF0LCBhZnRlciA2 IHllYXJzLCB3ZSd2ZSBoYWQgbWluaW1hbCBpbXBhY3QgaW4gdGhlICANCnBpZWNlcyB0aGF0IHJl cXVpcmUgbG9jYXRpb24gcHJpdmFjeSwgc28gaXQgbWlnaHQgYmUgdGltZSB0byBhc2sgd2h5LiAg DQpJJ20gYWxsIGZvciB0aGUgZ29hbHMgb2YgZW5zdXJpbmcgcHJpdmFjeSwgYnV0IHJlbHlpbmcg b24gImV2ZXJ5Ym9keSAgDQpzaG91bGQgYmUgZG9pbmcgaXQgdGhlIHdheSB3ZSB3YW50IHRvIiBp cyBub3QgYSByb2FkIHRvIHN1Y2Nlc3MuIFRoZXJlICANCmlzIG5vdGhpbmcgbWFnaWMgYWJvdXQg dGhlIHBvbGljeSBwcmltaXRpdmVzIHRoYXQgd2UgY29va2VkIHVwIGluIHRoZSAgDQplYXJseSBH RU9QUklWIGRheXM7IGdpdmVuIHRoZWlyIGxhY2sgb2YgaW1wYWN0LCBpdCBtaWdodCBiZSB1c2Vm dWwgdG8gIA0KY29uc2lkZXIgaWRlYXMgdGhhdCBhY2hpZXZlIHByaXZhY3kgZ29hbHMsIGJ1dCBt b3JlIGNsb3NlbHkgcmVmbGVjdCAgDQpob3cgcmVhbCBuZXR3b3JrIHNlcnZpY2VzIHdvcmssIGFz IG9wcG9zZWQgdG8gZXhwZWN0aW5nIGV2ZXJ5b25lIHRvICANCmNoYW5nZS4NCg0KQXMgZGVmaW5l ZCBjdXJyZW50bHksIGxvZ2dpbmcgaGFzIHRvIGJlIHNlZW4gYXMgcmV0ZW50aW9uLCBzbyB3ZSAg DQplaXRoZXIgbmVlZCB0byBzcGVjaWZ5IHRoYXQgaXQgc29tZWhvdyBkb2Vzbid0IGFwcGx5IGFz IGxvbmcgYXMgdGhlICANCnNpdGUgaGFzIGEgbG9nZ2luZyBwb2xpY3kgc3RhdGVkIChvciBzb21l IG90aGVyIHJlYXNvbmFibGUgIA0KZGVmaW5pdGlvbiksIG9yIGV4cGVjdCB0byBiZSBpZ25vcmVk Lg0KDQpIZW5uaW5nDQoNCk9uIE1hciAyOCwgMjAwOSwgYXQgMToyMiBQTSwgQWxpc3NhIENvb3Bl ciB3cm90ZToNCg0KPiBJIG1pZ2h0IGJlIGFib3V0IHRvIGdldCB0b28gcGhpbG9zb3BoaWNhbCBo ZXJlLCBidXQuLi4NCj4NCj4gSW4gc29tZSBzZW5zZSB0aGUgZW50aXJlIEdlb3ByaXYgcHJpdmFj eSBhcmNoaXRlY3R1cmUgY291bGQgYmUgIA0KPiBjb25zaWRlcmVkIGEgIm5vbi1zdGFydGVyIiBm b3IgdGhlIHNhbWUgcmVhc29uIHlvdSBzdWdnZXN0IGJlbG93OiAgDQo+IGl0J3MgbWVhbnQgdG8g ZW5jb3VyYWdlIGxvY2F0aW9uIHJlY2lwaWVudHMgdG8gY2hhbmdlIHRoZWlyIGN1cnJlbnQgIA0K PiBiZWhhdmlvci4gSWYgaXQgZGlkbid0IHJlcXVpcmUgYmVoYXZpb3IgY2hhbmdlLCBpdCB3b3Vs ZG4ndCBoYXZlIGFueSAgDQo+IHV0aWxpdHkuDQo+DQo+IEFnYWluLCBJIHRoaW5rIHJldGVudGlv bi1leHBpcmVzIGhhcyB2YWx1ZSBldmVuIGlmIGFsbCB0aGF0IHJlc3VsdHMgIA0KPiBmcm9tIGl0 IGlzIHRoYXQgYSByZWNpcGllbnQgdGhpbmtzIHR3aWNlIGFib3V0IGl0cyBsb2dnaW5nIHBvbGlj eSwgIA0KPiBvciBjbGFyaWZpZXMgaXRzIGRpc2Nsb3N1cmVzIGFib3V0IGl0cyBsb2dnaW5nIHBv bGljeSwgb3IgcmVhbGl6ZXMgIA0KPiB0aGF0IHBlb3BsZSBjYXJlIGFib3V0IGl0cyBsb2dnaW5n IHBvbGljeS4gSU1PLCBkZWZpbmluZyBhIHN0cmljdCAgDQo+IHNlbWFudGljIHRoYXQgcmVzdWx0 cyBpbiB0aGlzIGtpbmQgb2YgcmVhY3Rpb24gaXMgcHJlZmVyYWJsZSB0byAgDQo+IGNyZWF0aW5n IGEgbG9vcGhvbGUgaW4gdGhlIHNlbWFudGljIHRoYXQgY291bGQgcG90ZW50aWFsbHkgc3dhbGxv dyAgDQo+IGFsbCBvZiBpdHMgdmFsdWUuDQo+DQo+IE9uIE1hciAyNiwgMjAwOSwgYXQgNjoxMiBQ TSwgSGVubmluZyBTY2h1bHpyaW5uZSB3cm90ZToNCj4NCj4+IEknbSBzb3JyeSwgYnV0IGFmdGVy IDYgeWVhcnMgd2UncmUgbm8gY2xvc2VyIHRvIHRoaXMgaGFwcGVuaW5nLiAgDQo+PiBIb3dldmVy LCBhbnl0aGluZyB0aGF0IHJlcXVpcmVzIHJ1bm5pbmcgbm9uLXN0YW5kYXJkIHdlYiBzZXR1cHMg IA0KPj4gc2VlbXMgbGlrZSBhIG5vbi1zdGFydGVyLiBObyB3b25kZXIgdGhhdCBXM0MgZG9lc24n dCB0YWtlIEdFT1BSSVYgIA0KPj4gc2VyaW91c2x5Li4uDQo+Pg0KPj4gSGVubmluZw0KPj4NCj4+ IE9uIE1hciAyNiwgMjAwOSwgYXQgNjowNSBQTSwgSm9obiBNb3JyaXMgd3JvdGU6DQo+Pg0KPj4+ ICsxIHRvIEFsaXNzYSAocGVyaGFwcyBub3QgYSBzdXJwcmlzZSkuLi4gIGJ1dCBmb3IgaGlzdG9y aWNhbCAgDQo+Pj4gaW50ZXJlc3QsIEkgaGF2ZSBwYXN0ZWQgYmVsb3cgZXhjZXJwdHMgZnJvbSB0 aHJlZSAyMDAzIGUtbWFpbHMgaW4gIA0KPj4+IHdoaWNoIEhlbm5pbmcgYW5kIEkgZGlzY3Vzc2Vk IHRoaXMgc2FtZSB0b3BpYy4uLi4gIEpvaG4NCj4+Pg0KPj4+IEF0IDExOjAxIEFNIC0wNTAwIDEx LzExLzAzLCBIZW5uaW5nIFNjaHVsenJpbm5lIHdyb3RlOg0KPj4+PiBEYXRlOiBUdWUsIDExIE5v diAyMDAzIDExOjAxOjEzIC0wNTAwDQo+Pj4+IEZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgPGhn c0Bjcy5jb2x1bWJpYS5lZHU+DQo+Pj4+IFRvOiAiJ2dlb3ByaXZAaWV0Zi5vcmcnIiA8Z2VvcHJp dkBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogW0dlb3ByaXZdIFF1ZXN0aW9ucyBvbiBwaWRmLWxv DQo+Pj4+DQo+Pj4+IEFmdGVyIGFub3RoZXIgcmVhZGluZyBhbmQgc29tZSBoYWxsd2F5IGRpc2N1 c3Npb25zLCBhIGZldyAgDQo+Pj4+IHF1ZXN0aW9ucyBvbiBQSURGLUxPOg0KPj4+PiA8c25pcD4N Cj4+Pj4gMykgUmV0ZW50aW9uDQo+Pj4+DQo+Pj4+IE5vcm1hbCBvcGVyYXRpbmcgcHJvY2VkdXJl IGlzIHRoYXQgZGF0YWJhc2VzIGFyZSBiYWNrZWQgdXAuIEFtIEkgIA0KPj4+PiBsaWFibGUgaWYg YSBsb2NhdGlvbiBvYmplY3QgYWNjaWRlbnRhbGx5IG1ha2VzIGl0IG9udG8gdGhlIGJhY2t1cCAg DQo+Pj4+IHRhcGU/IChFeGFtcGxlOiByZXRlbnRpb24gaXMgMjQgaG91cnM7IExPIGFycml2ZXMg YXQgOCBwbTsgYmFja3VwICANCj4+Pj4gaXMgcnVuIGF0IG1pZG5pZ2h0LiBJIGNhbid0IHRlbGwg dGhlIGJhY2t1cCByb3V0aW5lIHRvIG5vdCBiYWNrdXAgIA0KPj4+PiB0aGF0IGVudHJ5LikNCj4+ Pj4NCj4+Pj4gV29yZGVkIGluIGl0cyBjdXJyZW50IHZhZ3VlbmVzcywgSSdtIGFmcmFpZCB0aGF0 IGFueSBsYXJnZSBlbnRpdHkgIA0KPj4+PiB3aG8gaGFzIGFueSBleHBvc3VyZSBhdCBhbGwgd291 bGQgYmUgZm9vbGlzaCB0byBhY2NlcHQgYW55IG9iamVjdCAgDQo+Pj4+IHRoYXQgaW4gYW55IHdh eSByZXN0cmljdHMgcmV0ZW50aW9uIGFuZCBkaXN0cmlidXRpb24uDQo+Pj4+DQo+Pj4+IEhlbm5p bmcNCj4+Pg0KPj4+IEF0IDEyOjM0IFBNIC0wNjAwIDExLzExLzAzLCBKb2huIE1vcnJpcyB3cm90 ZToNCj4+Pj4gRGF0ZTogVHVlLCAxMSBOb3YgMjAwMyAxMjozNDozMiAtMDYwMA0KPj4+PiBUbzog SGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNvbHVtYmlhLmVkdT4NCj4+Pj4gRnJvbTogSm9o biBNb3JyaXMgPGptb3JyaXNAY2R0Lm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFtHZW9wcml2XSBR dWVzdGlvbnMgb24gcGlkZi1sbw0KPj4+PiBDYzogIidnZW9wcml2QGlldGYub3JnJyIgPGdlb3By aXZAaWV0Zi5vcmc+DQo+Pj4+DQo+Pj4+IEhlbm5pbmcsIHlvdSB3b24ndCBiZSBoYXBweSB3aXRo IGhvdyBJIHdvdWxkIGFuc3dlciB0aGVzZSAgDQo+Pj4+IHF1ZXN0aW9ucy4gU2VlIGlubGluZS4g IEpvaG4NCj4+PiA8c25pcD4NCj4+Pj4+IDMpIFJldGVudGlvbg0KPj4+Pj4NCj4+Pj4+IE5vcm1h bCBvcGVyYXRpbmcgcHJvY2VkdXJlIGlzIHRoYXQgZGF0YWJhc2VzIGFyZSBiYWNrZWQgdXAuIEFt IEkgIA0KPj4+Pj4gbGlhYmxlIGlmIGEgbG9jYXRpb24gb2JqZWN0IGFjY2lkZW50YWxseSBtYWtl cyBpdCBvbnRvIHRoZSAgDQo+Pj4+PiBiYWNrdXAgdGFwZT8gKEV4YW1wbGU6IHJldGVudGlvbiBp cyAyNCBob3VyczsgTE8gYXJyaXZlcyBhdCA4ICANCj4+Pj4+IHBtOyBiYWNrdXAgaXMgcnVuIGF0 IG1pZG5pZ2h0LiBJIGNhbid0IHRlbGwgdGhlIGJhY2t1cCByb3V0aW5lICANCj4+Pj4+IHRvIG5v dCBiYWNrdXAgdGhhdCBlbnRyeS4pDQo+Pj4+Pg0KPj4+Pj4gV29yZGVkIGluIGl0cyBjdXJyZW50 IHZhZ3VlbmVzcywgSSdtIGFmcmFpZCB0aGF0IGFueSBsYXJnZSAgDQo+Pj4+PiBlbnRpdHkgd2hv IGhhcyBhbnkgZXhwb3N1cmUgYXQgYWxsIHdvdWxkIGJlIGZvb2xpc2ggdG8gYWNjZXB0ICANCj4+ Pj4+IGFueSBvYmplY3QgdGhhdCBpbiBhbnkgd2F5IHJlc3RyaWN0cyByZXRlbnRpb24gYW5kIGRp c3RyaWJ1dGlvbi4NCj4+Pj4NCj4+Pj4gTXkgYW5zd2VyIGlzIHRoYXQgYmlnIGVudGl0aWVzIHdp bGwgaGF2ZSB0byBjb3BlLiAgSW4gdGhlIFUuUy4gYXQgIA0KPj4+PiBsZWFzdCwgd2UgaGF2ZSBu b3QgeWV0IHJlc29sdmVkIHRoZSB0cmFpbiB3cmVjayB0aGF0IG9jY3VycyAgDQo+Pj4+IGJldHdl ZW4gcHJpdmFjeSBhbmQgcm91dGluZSBiYWNrdXAgdGFwZXMuICBJZiB0aGUgaW5mbyBpcyBpbiBh ICANCj4+Pj4gYmFja3VwIHRhcGUsIGl0IGNhbiBiZSBvYnRhaW5lZCB0aHJvdWdoIHN1YnBvZW5h LCBsYXcgZW5mb3JjZW1lbnQgIA0KPj4+PiByZXF1ZXN0LCBldGMuDQo+Pj4+DQo+Pj4+IEFuZCB5 ZXMsIEkgZG8gdGhpbmsgdGhhdCBjb21wYW5pZXMgYXJlIG1vdmluZyB0b3dhcmQgYSBtb3JlICAN Cj4+Pj4gY29uc2lkZXJlZCBiYWNrdXAgc3RyYXRlZ3kgdGhhdCB0YWtlcyBwcml2YWN5IGFuZCBv dGhlciBsZWdhbCAgDQo+Pj4+IG9ibGlnYXRpb25zIGludG8gYWNjb3VudC4gIEl0IHdpbGwgYmUg YSBzbG93IHRyYW5zaXN0aW9uLCBidXQgSSAgDQo+Pj4+IHRoaW5rIGl0IHdpbGwgaGFwcGVuLg0K Pj4+Pg0KPj4+PiBTbyBhbnkgZW50aXR5IGNvbmNlcm5lZCBhYm91dCB0aGlzIHR5cGUgb2YgZXhw b3N1cmUgc2hvdWxkIGRlY2lkZSAgDQo+Pj4+IHRoYXQgY2VydGFpbiBpbmZvcm1hdGlvbiBzaG91 bGQgc2ltcGx5IG5vdCBiZSByZXRhaW5lZCBpbiAgDQo+Pj4+IGRhdGFiYXNlcyB0aGF0IGFyZSBy b3V0aW5lbHkgYmFja2VkIHVwLiAgSSBzdHJvbmdseSBkbyBub3QgdGhpbmsgIA0KPj4+PiB3ZSBz aG91bGQgYWxsb3cgZ2VvcHJpdiB0byBzYXkgImRvIG5vdCByZXRhaW4gdGhlIGluZm8gbG9uZ2Vy ICANCj4+Pj4gdGhhbiB0aGUgcnVsZSBwZXJtaXRzIChleGNlcHQgcm91dGluZSBiYWNrdXBzIGRv bid0IGNvdW50KS4iDQo+Pj4+DQo+Pj4+PiBIZW5uaW5nDQo+Pj4+DQo+Pj4+IEpvaG4NCj4+Pg0K Pj4+IEF0IDI6NTYgUE0gLTA1MDAgMTEvMTEvMDMsIEhlbm5pbmcgU2NodWx6cmlubmUgd3JvdGU6 DQo+Pj4+IERhdGU6IFR1ZSwgMTEgTm92IDIwMDMgMTQ6NTY6NTggLTA1MDANCj4+Pj4gRnJvbTog SGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNvbHVtYmlhLmVkdT4NCj4+Pj4gVG86IEpvaG4g TW9ycmlzIDxqbW9ycmlzQGNkdC5vcmc+DQo+Pj4+IENjOiAiJ2dlb3ByaXZAaWV0Zi5vcmcnIiA8 Z2VvcHJpdkBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFtHZW9wcml2XSBRdWVzdGlvbnMg b24gcGlkZi1sbw0KPj4+Pg0KPj4+PiBKb2huIE1vcnJpcyB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhl bm5pbmcsIHlvdSB3b24ndCBiZSBoYXBweSB3aXRoIGhvdyBJIHdvdWxkIGFuc3dlciB0aGVzZSAg DQo+Pj4+PiBxdWVzdGlvbnMuIFNlZSBpbmxpbmUuICBKb2huDQo+Pj4+DQo+Pj4+IEknbSBhY3R1 YWxseSBoYXBweSB3aXRoICphbnkqIGNvbnNpc3RlbnQgYW5kIGltcGxlbWVudGFibGUgIA0KPj4+ PiBhbnN3ZXIuIEknbSBtb3N0bHkgY29uY2VybmVkIHRoYXQgaW1wbGVtZW50b3JzIGFyZSBnaXZl biAgDQo+Pj4+IGluc3VmZmljaWVudCBndWlkYW5jZSBpbiB0aGUgc3BlYy4NCj4+Pj4NCj4+PiA8 c25pcD4NCj4+Pj4+IE15IGFuc3dlciBpcyB0aGF0IGJpZyBlbnRpdGllcyB3aWxsIGhhdmUgdG8g Y29wZS4gIEluIHRoZSBVLlMuICANCj4+Pj4+IGF0IGxlYXN0LCB3ZSBoYXZlIG5vdCB5ZXQgcmVz b2x2ZWQgdGhlIHRyYWluIHdyZWNrIHRoYXQgb2NjdXJzICANCj4+Pj4+IGJldHdlZW4gcHJpdmFj eSBhbmQgcm91dGluZSBiYWNrdXAgdGFwZXMuICBJZiB0aGUgaW5mbyBpcyBpbiBhICANCj4+Pj4+ IGJhY2t1cCB0YXBlLCBpdCBjYW4gYmUgb2J0YWluZWQgdGhyb3VnaCBzdWJwb2VuYSwgbGF3ICAN Cj4+Pj4+IGVuZm9yY2VtZW50IHJlcXVlc3QsIGV0Yy4NCj4+Pj4+DQo+Pj4+PiBBbmQgeWVzLCBJ IGRvIHRoaW5rIHRoYXQgY29tcGFuaWVzIGFyZSBtb3ZpbmcgdG93YXJkIGEgbW9yZSAgDQo+Pj4+ PiBjb25zaWRlcmVkIGJhY2t1cCBzdHJhdGVneSB0aGF0IHRha2VzIHByaXZhY3kgYW5kIG90aGVy IGxlZ2FsICANCj4+Pj4+IG9ibGlnYXRpb25zIGludG8gYWNjb3VudC4gIEl0IHdpbGwgYmUgYSBz bG93IHRyYW5zaXN0aW9uLCBidXQgSSAgDQo+Pj4+PiB0aGluayBpdCB3aWxsIGhhcHBlbi4NCj4+ Pj4+DQo+Pj4+PiBTbyBhbnkgZW50aXR5IGNvbmNlcm5lZCBhYm91dCB0aGlzIHR5cGUgb2YgZXhw b3N1cmUgc2hvdWxkICANCj4+Pj4+IGRlY2lkZSB0aGF0IGNlcnRhaW4gaW5mb3JtYXRpb24gc2hv dWxkIHNpbXBseSBub3QgYmUgcmV0YWluZWQgaW4gIA0KPj4+Pj4gZGF0YWJhc2VzIHRoYXQgYXJl IHJvdXRpbmVseSBiYWNrZWQgdXAuICBJIHN0cm9uZ2x5IGRvIG5vdCB0aGluayAgDQo+Pj4+PiB3 ZSBzaG91bGQgYWxsb3cgZ2VvcHJpdiB0byBzYXkgImRvIG5vdCByZXRhaW4gdGhlIGluZm8gbG9u Z2VyICANCj4+Pj4+IHRoYW4gdGhlIHJ1bGUgcGVybWl0cyAoZXhjZXB0IHJvdXRpbmUgYmFja3Vw cyBkb24ndCBjb3VudCkuIg0KPj4+Pg0KPj4+PiBBcyBsb25nIGFzIHdlIHNheSAidGhpcyBpbmNs dWRlcyBiYWNrdXAgbWVkaWEiLCBJJ20gZmluZSAtIEknbSAgDQo+Pj4+IGp1c3QgZm9yIGNsYXJp dHkuIFdlIGNhbid0IHJlbW92ZSBldmVyeSBhbWJpZ3VpdHksIGJ1dCB0aGF0J3Mgbm8gIA0KPj4+ PiBleGN1c2Ugbm90IHRvIGJlIHByZWNpc2Ugd2hlcmUgd2UgY2FuLg0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gR2VvcHJpdiBtYWlsaW5n IGxpc3QNCj4+PiBHZW9wcml2QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9nZW9wcml2DQo+Pj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4+IEdl b3ByaXZAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Z2VvcHJpdg0KPg0KPiAtLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IEFsaXNzYSBDb29wZXINCj4gQ2hpZWYgQ29tcHV0ZXIgU2NpZW50 aXN0DQo+IENlbnRlciBmb3IgRGVtb2NyYWN5IGFuZCBUZWNobm9sb2d5DQo+IDIwMiA2MzcgOTgw MCB4MTEwDQo+IGFjb29wZXJAY2R0Lm9yZw0KPiBodHRwOi8vd3d3LmNkdC5vcmcvDQo+DQo+DQo+ DQo+DQo+DQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpHZW9wcml2IG1haWxpbmcgbGlzdA0KR2VvcHJpdkBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2DQo= From jiri@iptel.org Sat Mar 28 14:02:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE233A68D8 for ; Sat, 28 Mar 2009 14:02:37 -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.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iylsJqF3iE-u for ; Sat, 28 Mar 2009 14:02:37 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 05B5C3A68A1 for ; Sat, 28 Mar 2009 14:02:37 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 2F8ED180FD7B; Sat, 28 Mar 2009 22:03:31 +0100 (CET) Message-ID: <49CE8255.4000103@iptel.org> Date: Sat, 28 Mar 2009 21:02:29 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "sip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Francois Audet Subject: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 21:02:38 -0000 As we were running out of time in the meeting, I wanted to follow up on an argument which Francois has made: RFC 4474 works if the identity provider and verifiers are "next to each other", thus we have no problem with this RFC. /* hope I didn't misinterpret, let me know should that be the case */ I'm worried this is only a wishful thinking. While perfectly logical, still even in such constrained setups some bizzar ALGs do in my experience appear in the middle, change SDP and make thus the identity worthless. I think the bottom line is the protocol is not really end-to-end. It makes quite some assumptions about the quality of underlying network (particularly about not changing SDPs) as opposed to trying to deal with lack of it. In fact, SDP payloads are changed at quite a number of devices: proxy servers, B2BUAs, SBCs, you name it. Assuming there is nothing in the way which won't change SDP is just NOT ROBUST. Other way to look at it is it is function overloading. You ask for identity and get message integrity -- consequently when the latter fails, the former, which you really initially wanted, fails too. ekr's argument is certainly right that a message of certain origin but uncertain content is close to worthless. OTOH, the particular piece, IP address and port numbers in SDP are certainly not to be covered by a message integrity checks. In fact, for accepting calls based on who is calling, as a minimalistic application example, one does not need message integrity. In conclusion, I do not think that RFC4474 can be of any help (other than in controlled environments which beats its purpose) as long as IP/port in SDP are message-integrity-protected. -jiri From jiri@iptel.org Sat Mar 28 17:55:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535703A6863 for ; Sat, 28 Mar 2009 17:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-1.246, BAYES_00=-2.599, FRT_BELOW2=2.154, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDNT3wUHwjK8 for ; Sat, 28 Mar 2009 17:55:24 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 9F8AF3A65A5 for ; Sat, 28 Mar 2009 17:55:23 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 804271810C13; Sun, 29 Mar 2009 01:56:16 +0100 (CET) Message-ID: <49CEC72F.8060600@iptel.org> Date: Sun, 29 Mar 2009 01:56:15 +0100 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: L.Liess@telekom.de References: <49CA9943.1020808@cisco.com> <49CC02F4.6070507@iptel.org> <40FB0FFB97588246A1BEFB05759DC8A002CA7355@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A002CA7355@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 00:55:25 -0000 Interestingly I made a measurement which supports your argument. In short, a vast majority of SIP traffic going through iptel.org has IP address in it. Details of the measurement follow bellow for those interested in details (including links to colorful non-ASCII graphs ;-)). Key characteristics of the iptel.org SIP service is high variance in type of UAs using it. As for the backwards-compatibility argument, I guess that it will take same long time to get UAs do session-id, so IMO an improvement is only possible under an assumption that network-asserted session-id is easier to introduce than UA-asserted, right? That appears meaningful to me. -jiri (hoping for better life for unfortunate ones, who have chosen to operate callid-mangling B2BUAs and RFC-2543 clients without upgrade strategy ;-)) Measurement Details -------------------- a) types of UA for a pie-chart see: http://www.iptel.org/~jiri/etc/ua-breakdown.png (picture to big to be attached, sorry) It is saying that there are 162 diffent types of User Agents for 1131 users. Apart from the most popular UA types seen in the graph, the greatest variety occurs in the "other devices" chunk representing 150+ User Agent Types. In summary I think the selection of UAs is quite representative. b) callid stats I pulled about 18 minutes of SIP traffic at about 0.5 Mbps (including layer-2 headers; resulting in about 65e3 packets totaling to 35e6 bytes of SIP data, avg SIP packet size 540 bytes) and postprocessed it as follows: # IP addres in grep -v is an availabaility checker -- to be excluded ngrep -d any -W byline port 5060| grep -i Call-ID|grep -v "213.192.59.93"|sort -u >/tmp/callid2 # number of callids captured in the sample: 4345 tlb1:~# wc /tmp/callid2 4345 8733 184947 /tmp/callid2 # number of @IP callids: 3695 (85%) tlb1:~# egrep "@[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" /tmp/callid2|wc 3695 7433 152577 # number of callids w/o @: 470 (11%) tlb1:~# egrep -v "@" /tmp/callid2|wc 470 940 23053 # numver of callids with @ and some non-nummerical stuff after it (domain name typically) tlb1:~# egrep "@[^0-9]" /tmp/callid2|wc 149 298 8220 # number of "natted callids" tlb1:~# egrep "@(10|192\.168|172\.(16|17|18|19|2[0-9]|30|31))\." /tmp/callid2|wc 1092 2184 47063 c) measurement mistakes: a and b have been measured independently, it is possible but unlikely that the statements in b related to a different set of UAs featuring a different variance. This likelihood of such circumstances to occur doesn't seem very high to me. b) has been measured on an off-the shelf PC attached to the same Ethernet swtich at iptel.org's load-balancer --it is possible that such a PC could have missed some IP packets. If so, I assume it has done so on a fair basis which does not impact the CallId assertion. L.Liess@telekom.de wrote: > Jiri, > I agree with you on the im portance of the problem, but I don't agree > with you that we can solve the problem by changing one of the protocol > basics at this time, with millions of existing boxes, network boxes as > well as end devices. Especially the end devices are critical. Most of > them send today the IP-address in the call-ID. Customers often do not > accept the upgrades. Some customers also have their own boxes. It will > take at least 10 years until we can can rely on the secure call-id for > dialog correlation. This is far too late. We also do not realy know > which problems may occur if we change the protocol basics. > > I support the session-ID troubleshooting. It works fine and it works > now. For dialog matching we should work on a more general framework, > e.g. context-id or something else. > > We can try secure call-id as a long term improvement of the protocol. > But we have to make sure that we do not cause problems for the existing > boxes and services which are up and running. > > Laura > > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Jiri Kuthan >> Sent: Thursday, March 26, 2009 11:34 PM >> To: Hadriel Kaplan >> Cc: IETF SIP List >> Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 >> >> First of all I think it is definitely worth trying. >> >> Not being able to correlate dialogs through B2BUA is a big >> operational problem. I'm not sure that this will get really >> adopted (who knows what today's obfuscators choose to obfuscate >> tomorrow...). However in hope for solving this problem, presence of >> incentives for adoption and absence of any known harm it is >> definitely worth doing. >> >> Another idea how to accommodate receivers that are silly not >> to be liberal is using a fake IP address (popular 0.0.0.0). >> While not aesthetic at all, it could accommodate such receivers >> (under assumption they assign no syntactical meaning to it) >> and signal to B2BUA there is no disclosure of IP addresses. >> >> OTOH it could be time too to abandon 2543 legacy. Supporting >> strict routing and other ancient stuff like IP in callid does >> not seem worth the trouble to me. >> >> -jiri >> >> Hadriel Kaplan wrote: >>> Ooh, good point. Fair enough, I'll change that. >>> >>> -hadriel >>> >>>> -----Original Message----- >>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] >> On Behalf Of >>>> Jonathan Rosenberg >>>> Sent: Wednesday, March 25, 2009 4:51 PM >>>> To: IETF SIP List >>>> Subject: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 >>>> >>>> I didnt get a chance to say this at the mike. >>>> >>>> You *cannot* change the BNF for the call-id. If you did, >> you might end >>>> up with the following problem: >>>> >>>> A new UA gets built, compliant to this update. It is one of these >>>> 'aggressive parsing' UAs. It rejects any message which is >> not compliant >>>> to the BNF. An older, normal RFC-3261 compliant UA sends a >> call-id which >>>> includes the @-sign. >>>> >>>> According to the BNF of this updated 3261, and based on >> the strictness >>>> of this aggressive-parsing UAs, it rejects that request as >> non-compliant. >>>> As such, you need to keep the BNF, but change the >> normative language >>>> such that an endpoint MUST NOT include the [@ host] but >> MUST be prepared >>>> to receive it. >>>> >>>> -Jonathan R. >>>> >>>> -- >>>> Jonathan D. Rosenberg, Ph.D. 111 Wood >> Avenue South >>>> Cisco Fellow Iselin, NJ 08830 >>>> Cisco, Voice Technology Group >>>> jdrosen@cisco.com >>>> http://www.jdrosen.net PHONE: >> (408) 902-3084 >>>> http://www.cisco.com >>>> _______________________________________________ >>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > From AUDET@nortel.com Sat Mar 28 21:32:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9D43A6B54 for ; Sat, 28 Mar 2009 21:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnqBDLPrIPWq for ; Sat, 28 Mar 2009 21:32:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B173F3A69B8 for ; Sat, 28 Mar 2009 21:32:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2T4XLK27361; Sun, 29 Mar 2009 04:33:21 GMT 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: Sat, 28 Mar 2009 23:33:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> In-Reply-To: <49CE8255.4000103@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: francois' comments and why RFC4474 not used in the field Thread-Index: Acmv6Kjgt6akHoX1Qne8dHV+sVecewAPBmEg References: <49CE8255.4000103@iptel.org> From: "Francois Audet" To: "Jiri Kuthan" , Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 04:32:30 -0000 I think our views are not that appart. See belows. =20 > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org]=20 > Sent: Saturday, March 28, 2009 13:02 > To: sip@ietf.org > Cc: Audet, Francois (SC100:3055) > Subject: francois' comments and why RFC4474 not used in the field >=20 > As we were running out of time in the meeting, I wanted to=20 > follow up on an argument which Francois has made: RFC 4474=20 > works if the identity provider and verifiers are "next to=20 > each other", thus we have no problem with this RFC. >=20 > /* hope I didn't misinterpret, let me know should that be the case */ First part is currect, but I didn't say "thus we have no problem with this RFC." As you say, it only works if the identity provider and the verifier are "next to each other". A federation of Enterprises for example. Or = between service providers. However, one of the most predominant model today doesn't work like this. A domain is often relying on a third party, a "service provider". So it's really not "end-to-end". That was the point I was trying to = make. RFC 4474 appears to work fine for end-to-end identity: unfortunately, many deployment models (perhaps the majority) and in fact, not = end-to-end, but mediated. In a typical scenario, each end would have it's own "service provider", so 2 intermediaries. > I'm worried this is only a wishful thinking. While perfectly=20 > logical, still even in such constrained setups some bizzar=20 > ALGs do in my experience appear in the middle, change SDP and=20 > make thus the identity worthless. Yes, I agree 4474 doesn't work if there are intermidiaries. > I think the bottom line is the protocol is not really end-to-end. EXACTLY! > It makes quite some assumptions about the quality of=20 > underlying network (particularly about not changing SDPs) as=20 > opposed to trying to deal with lack of it. In fact, SDP=20 > payloads are changed at quite a number of devices: proxy=20 > servers, B2BUAs, SBCs, you name it. Assuming there is nothing=20 > in the way which won't change SDP is just NOT ROBUST. >=20 > Other way to look at it is it is function overloading. You=20 > ask for identity and get message integrity -- consequently=20 > when the latter fails, the former, which you really initially=20 > wanted, fails too. ekr's argument is certainly right that a=20 > message of certain origin but uncertain content is close to worthless. > OTOH, the particular piece, IP address and port numbers in=20 > SDP are certainly not to be covered by a message integrity checks. > In fact, for accepting calls based on who is calling, as a=20 > minimalistic application example, one does not need message=20 > integrity. >=20 > In conclusion, I do not think that RFC4474 can be of any help=20 > (other than in controlled environments which beats its=20 > purpose) as long as IP/port in SDP are message-integrity-protected. Here is what I think: RFC 4474 can work in the following situations: 1 - Enterprise-to-Enterprise: i.e., the network as a dumb pipe. The = enterprises have their own SBCs modifying SIP/SDP (or they can use ICE). 2 - Subscriber on Service provider A to Subscriber on service provider = B:=20 i.e., the "domain" for the first subscriber is actually that of the = subscriber. This can work for "residential users" and small enterprises. 3 - Any permutation of the above. In all those cases, there is effectively end-to-end identity. RFC 4474 does NOT work if it's not end-to-end. For example, if=20 the "Enterprise" has it's own domain, but it relies on it's=20 service provider to perform a number of functions. NAT traversal, topology hiding, etc. So, what can we do? I see 2 possibilities: 1 - Make it end-to-end. This means tackling one by one the problem = areas. Use TURN/ICE instead for relying on SDP payload manipulation. Use Call-ID and Contact headers that don't reveal topology, etc. 2 - Create a non end-to-end Identity assertion mechanism that is = different from RFC 4474 and more secure than P-Asserted-Identity. I have a=20 feeling that it won't be trivial. We may have to define the=20 trust relationship between the ends and the intermediaries.=20 What I was trying to say in the meeting is that for "end-to-end identity", 4474 appears to work. But if the problem we are trying to solve is NOT end-to-end identity, but strong mediated identity, then, let's just say so. It's just a DIFFERENT problem to solve. From dwing@cisco.com Sat Mar 28 22:30:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248A93A6A69 for ; Sat, 28 Mar 2009 22:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.259 X-Spam-Level: X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLOChYUAdbOb for ; Sat, 28 Mar 2009 22:30:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 53EF13A67AA for ; Sat, 28 Mar 2009 22:30:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,440,1233532800"; d="scan'208";a="163242771" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2009 05:31:51 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2T5VoRh018921; Sat, 28 Mar 2009 22:31:50 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2T5Voj6009389; Sun, 29 Mar 2009 05:31:50 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Jiri Kuthan'" , References: <49CE8255.4000103@iptel.org> <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> Date: Sat, 28 Mar 2009 22:31:50 -0700 Message-ID: <000a01c9b02f$a9316d30$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acmv6Kjgt6akHoX1Qne8dHV+sVecewAPBmEgAAKlRNA= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=394; t=1238304710; x=1239168710; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=/Yqh+tjhlUArPpI0DsZTVGc5ChY7RJeZaMVdU88mW8c=; b=dXok8h2H4zwARYJZKghMrh5HiRlVivGRismZJc50Ut3JHVMCTJ2HSy9ao4 tQngz9xR2X3dSRuBv99WTqPucDvmQp9H4Zf/3Ks9GyX3tF2Obo6v5nlsvu0P 4g9rTjr4HR; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 05:30:57 -0000 > However, one of the most predominant model today doesn't work > like this. > A domain is often relying on a third party, a "service provider". I observed Hadriel's presentation from the very back of the room. My interpretation is that we lack consensus that there are intermediate service providers. Until consensus on that point is reached everything else is for naught. -d From theo@crazygreek.co.uk Sun Mar 29 01:50:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4113A6ABC for ; Sun, 29 Mar 2009 01:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wSUJyJ8n1Js for ; Sun, 29 Mar 2009 01:50:05 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with SMTP id ED9EC3A6870 for ; Sun, 29 Mar 2009 01:50:02 -0700 (PDT) Received: from source ([72.14.220.153]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSc82c/nvHCPd51Pr9Q2kriM4TjKAigCc@postini.com; Sun, 29 Mar 2009 01:51:00 PDT Received: by fg-out-1718.google.com with SMTP id d23so247540fga.16 for ; Sun, 29 Mar 2009 01:50:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> <49CD34EB.6010605@nostrum.com> Date: Sun, 29 Mar 2009 09:49:13 +0100 Received: by 10.86.94.11 with SMTP id r11mr3373829fgb.53.1238316658782; Sun, 29 Mar 2009 01:50:58 -0700 (PDT) Message-ID: <167dfb9b0903290149l459219eaw109ce767911d4f71@mail.gmail.com> From: Theo Zourzouvillys To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP Subject: Re: [Sip] B2BUA's changing call-id's: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 08:50:06 -0000 On Sat, Mar 28, 2009 at 6:25 AM, Hadriel Kaplan wrote: > Would people prefer that? yup. Also: [OPEN ISSUE: should we make this a fixed format, defined randomization mechanism to avoid detecting the vendor type from the Call-ID format?] How about defining it to be a v5 uuid (rfc4122), which: - is well defined (including generating) in RFC 4122 - has many libraries for generating and parsing - a v5 uuid can be detected (by looking at bits 4-7 == 0101) and thus knows if it's secure - is "almost" unique across a four dimensional space-time continuum - certainly a _very_ low chance of any collision, even when we're communicating with alpha centauri over SIP/2.0. ~ Theo Sent from: Bicester Oxfordshire United Kingdom. From theo@crazygreek.co.uk Sun Mar 29 04:41:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F41F3A67F9 for ; Sun, 29 Mar 2009 04:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOMAPxF3zCOY for ; Sun, 29 Mar 2009 04:41:30 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with SMTP id 08C573A692F for ; Sun, 29 Mar 2009 04:41:30 -0700 (PDT) Received: from source ([72.14.220.158]) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSc9eom+0QcUsdeT8yaPjW+jBH3GMk3Wn@postini.com; Sun, 29 Mar 2009 04:42:27 PDT Received: by fg-out-1718.google.com with SMTP id 16so608264fgg.19 for ; Sun, 29 Mar 2009 04:42:26 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02B4FEEA@gaalpa1msgusr7e.ugd.att.com> References: <49C507BB.9010804@cisco.com> <1237955188.22543.30.camel@victoria-pingtel-com.us.nortel.com> <1238014787.22565.12.camel@victoria-pingtel-com.us.nortel.com> <4ff4e7370903251440l6e57f4ecp99a4f7bafcb0c873@mail.gmail.com> <40FB0FFB97588246A1BEFB05759DC8A002CA6CBD@S4DE9JSAANI.ost.t-com.de> <14C85D6CCBE92743AF33663BF5D24EBA02B4FEEA@gaalpa1msgusr7e.ugd.att.com> Date: Sun, 29 Mar 2009 12:42:10 +0100 Received: by 10.86.65.9 with SMTP id n9mr3418381fga.55.1238326946221; Sun, 29 Mar 2009 04:42:26 -0700 (PDT) Message-ID: <167dfb9b0903290442y2539c4fci8466cd1070cb7a2e@mail.gmail.com> From: Theo Zourzouvillys To: "DOLLY, MARTIN C, ATTLABS" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, L.Liess@telekom.de Subject: Re: [Sip] draft-kaplan-sip-session-id-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 11:41:31 -0000 On Thu, Mar 26, 2009 at 7:06 PM, DOLLY, MARTIN C, ATTLABS wrote: > We support this draft as well I also support this draft. ~ Theo Sent from: Bicester Oxfordshire United Kingdom. From theo@crazygreek.co.uk Sun Mar 29 04:58:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283773A68DF for ; Sun, 29 Mar 2009 04:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B98m00R1nVYX for ; Sun, 29 Mar 2009 04:58:22 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with SMTP id 098653A6403 for ; Sun, 29 Mar 2009 04:58:21 -0700 (PDT) Received: from source ([72.14.220.152]) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSc9ilv0au1+KMrPaZqL3DBJwXweSofe2@postini.com; Sun, 29 Mar 2009 04:59:19 PDT Received: by fg-out-1718.google.com with SMTP id 19so663163fgg.10 for ; Sun, 29 Mar 2009 04:59:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <49CEC72F.8060600@iptel.org> References: <49CA9943.1020808@cisco.com> <49CC02F4.6070507@iptel.org> <40FB0FFB97588246A1BEFB05759DC8A002CA7355@S4DE9JSAANI.ost.t-com.de> <49CEC72F.8060600@iptel.org> Date: Sun, 29 Mar 2009 12:59:03 +0100 Received: by 10.86.49.13 with SMTP id w13mr3400372fgw.76.1238327958229; Sun, 29 Mar 2009 04:59:18 -0700 (PDT) Message-ID: <167dfb9b0903290459u6df35044o320c13582d660424@mail.gmail.com> From: Theo Zourzouvillys To: Jiri Kuthan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, L.Liess@telekom.de Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 11:58:23 -0000 On Sun, Mar 29, 2009 at 1:56 AM, Jiri Kuthan wrote: > Interestingly I made a measurement which supports your argument. > In short, a vast majority of SIP traffic going through iptel.org > has IP address in it. Yup, i have come to the same conclusion with our customers, too. ~ Theo From jiri@iptel.org Sun Mar 29 06:37:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982173A692A for ; Sun, 29 Mar 2009 06:37:11 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kQxHw+gr8oe for ; Sun, 29 Mar 2009 06:37:10 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 3976F3A6923 for ; Sun, 29 Mar 2009 06:37:10 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id E4ABA181294A; Sun, 29 Mar 2009 15:38:04 +0200 (CEST) Message-ID: <49CF79BC.6030408@iptel.org> Date: Sun, 29 Mar 2009 15:38:04 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francois Audet References: <49CE8255.4000103@iptel.org> <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 13:37:11 -0000 Francois Audet wrote: > I think our views are not that appart. > > See belows. > >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Sent: Saturday, March 28, 2009 13:02 >> To: sip@ietf.org >> Cc: Audet, Francois (SC100:3055) >> Subject: francois' comments and why RFC4474 not used in the field >> >> As we were running out of time in the meeting, I wanted to >> follow up on an argument which Francois has made: RFC 4474 >> works if the identity provider and verifiers are "next to >> each other", thus we have no problem with this RFC. >> >> /* hope I didn't misinterpret, let me know should that be the case */ > > First part is currect, but I didn't say "thus we have no problem with > this RFC." > > As you say, it only works if the identity provider and the verifier are > "next to each other". A federation of Enterprises for example. Or between > service providers. > > However, one of the most predominant model today doesn't work like this. > A domain is often relying on a third party, a "service provider". > > So it's really not "end-to-end". That was the point I was trying to make. > > RFC 4474 appears to work fine for end-to-end identity: unfortunately, > many deployment models (perhaps the majority) and in fact, not end-to-end, > but mediated. In a typical scenario, each end would have it's own > "service provider", so 2 intermediaries. > >> I'm worried this is only a wishful thinking. While perfectly >> logical, still even in such constrained setups some bizzar >> ALGs do in my experience appear in the middle, change SDP and >> make thus the identity worthless. > > Yes, I agree 4474 doesn't work if there are intermidiaries. > >> I think the bottom line is the protocol is not really end-to-end. > > EXACTLY! > > >> It makes quite some assumptions about the quality of >> underlying network (particularly about not changing SDPs) as >> opposed to trying to deal with lack of it. In fact, SDP >> payloads are changed at quite a number of devices: proxy >> servers, B2BUAs, SBCs, you name it. Assuming there is nothing >> in the way which won't change SDP is just NOT ROBUST. >> >> Other way to look at it is it is function overloading. You >> ask for identity and get message integrity -- consequently >> when the latter fails, the former, which you really initially >> wanted, fails too. ekr's argument is certainly right that a >> message of certain origin but uncertain content is close to worthless. >> OTOH, the particular piece, IP address and port numbers in >> SDP are certainly not to be covered by a message integrity checks. >> In fact, for accepting calls based on who is calling, as a >> minimalistic application example, one does not need message >> integrity. >> >> In conclusion, I do not think that RFC4474 can be of any help >> (other than in controlled environments which beats its >> purpose) as long as IP/port in SDP are message-integrity-protected. Thanks for the clarifications. I think we are on the same page then. > > Here is what I think: > > RFC 4474 can work in the following situations: > > 1 - Enterprise-to-Enterprise: i.e., the network as a dumb pipe. The enterprises > have their own SBCs modifying SIP/SDP (or they can use ICE). > > 2 - Subscriber on Service provider A to Subscriber on service provider B: > i.e., the "domain" for the first subscriber is actually that of the subscriber. > This can work for "residential users" and small enterprises. > > 3 - Any permutation of the above. > > In all those cases, there is effectively end-to-end > > RFC 4474 does NOT work if it's not end-to-end. For example, if > the "Enterprise" has it's own domain, but it relies on it's > service provider to perform a number of functions. NAT traversal, > topology hiding, etc. > > So, what can we do? I see 2 possibilities: > > 1 - Make it end-to-end. This means tackling one by one the problem areas. > Use TURN/ICE instead for relying on SDP payload manipulation. Use > Call-ID and Contact headers that don't reveal topology, etc. > > 2 - Create a non end-to-end Identity assertion mechanism that is different > from RFC 4474 and more secure than P-Asserted-Identity. I have a > feeling that it won't be trivial. We may have to define the > trust relationship between the ends and the intermediaries. > > What I was trying to say in the meeting is that for "end-to-end > identity", 4474 appears to work. But if the problem we are trying to > solve is NOT end-to-end identity, but strong mediated identity, then, > let's just say so. It's just a DIFFERENT problem to solve. Well, I'm afraid that 1 is too complicated to work. Bringing TURN/ICE to work is already quite an enterprise, and as much success I wish to it, I would be careful and avoid dependency on it (which is generally a good protocol design practice anyhow). 2 is then probably the safer direction to me. The point is really that RFC4474 is not having as broad applicability as we have hoped, and leaving SIP without Identity is going to be real-time irritating, compared to convenience of Email's off-line irritation. Some of the RFC 4474 applicability limitations could be lifted by reducing its integrity protection scope. I'm not sure how popular will it be then (some have had different opinions on adoptability of things relying on CA) but it seems worth trying. I would not dare to restrain ourselves to fixing RFC4474 though. I'm very much in favor of testing other alternatives. IETF has had a very successful tradition of testing several approaches. A more ellaborated email on the topic was BTW recently written by Dave Crocker: http://www.ietf.org/mail-archive/web/mmox/current/msg01233.html Obviously DERIVE (or perhaps non-SIP based reverse verifications) appears a feasible alternative to me (because easy to deploy and offering incentives to do so), but given the interest it is quite certain there will be more different alternatives. -jiri From jiri@iptel.org Sun Mar 29 06:52:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6EE3A6A86 for ; Sun, 29 Mar 2009 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSVIwM79arfm for ; Sun, 29 Mar 2009 06:52:30 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E8F933A67F7 for ; Sun, 29 Mar 2009 06:52:29 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 075571812958; Sun, 29 Mar 2009 15:53:24 +0200 (CEST) Message-ID: <49CF7D54.6010002@iptel.org> Date: Sun, 29 Mar 2009 15:53:24 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dan Wing References: <49CE8255.4000103@iptel.org> <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> <000a01c9b02f$a9316d30$c4f0200a@cisco.com> In-Reply-To: <000a01c9b02f$a9316d30$c4f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, 'Francois Audet' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 13:52:30 -0000 Dan Wing wrote: >> However, one of the most predominant model today doesn't work >> like this. >> A domain is often relying on a third party, a "service provider". > > I observed Hadriel's presentation from the very back of the > room. My interpretation is that we lack consensus that there > are intermediate service providers. > > Until consensus on that point is reached everything else is > for naught. I'm worried that "intermediate service providers" is a sort of scenario which is underplaying the RFC4474 flaw. The key problem is that RFC4474 is not robust. It ties likely-to-fail integrity to identity, resulting in identity broken. Integrity is likely to fail, because regardless how close the assertion party is to the verification party, some sort of SDP-changer will be there. Maybe "intermediate service provider" or an ALG. One can argue that ALG has nothing to do there (quite rightfully so) but relying on such not to be there is just way too brittle. So I don't think the problem is we are missing a definition of intermediate service provider. I think we are missing identity vehicles that have robustness to overcome all sorts of middleboxes. -jiri > > -d > From dean.willis@softarmor.com Sun Mar 29 20:52:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D97B3A6CF2 for ; Sun, 29 Mar 2009 20:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvfhpsHejDKC for ; Sun, 29 Mar 2009 20:52:56 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 994763A6A55 for ; Sun, 29 Mar 2009 20:52:56 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2U3rmEb001956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 29 Mar 2009 22:53:50 -0500 Message-Id: <81881C2E-C631-4F46-A506-C984248337DC@softarmor.com> From: Dean Willis To: Mary Barnes In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 22:53:42 -0500 References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: sip@ietf.org, Christer Holmberg Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 03:52:57 -0000 On Mar 26, 2009, at 6:16 PM, Mary Barnes wrote: > Hi folks, > > Christer has updated the document based on the action item from > Wednesday's SIP session (chaired by SIPPING chairs and modeled as > the proposed DISPATCH WG). If folks could please review the > document and raise any concerns on the document now, that would be > appreciated. We ask specifically for an answer to the question: Do > you support the document being adopted as a WG document in RAI (WG > tbd)? A simple "yes" is fine, however, if you don't think we should > adopt this document, could you please provide the reason. > > > So, given the outpouring of support, should we pull back the draft- ietf-sip-outbound and re-write it to refer to the keepalive mechanism of this draft instead of containing similar but not identical text? -- Dean From dean.willis@softarmor.com Sun Mar 29 20:54:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533D73A6CFE for ; Sun, 29 Mar 2009 20:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orNQe6Kczbuc for ; Sun, 29 Mar 2009 20:54:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 80FBD3A6A55 for ; Sun, 29 Mar 2009 20:54:50 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2U3tiCe001995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 29 Mar 2009 22:55:46 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 22:55:39 -0500 References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> <49CD34EB.6010605@nostrum.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP , Adam Roach Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 03:54:51 -0000 On Mar 28, 2009, at 12:19 AM, Hadriel Kaplan wrote: > > Yeah I've been thinking about what you said the other day about > this, and I think I understand your point, but I still think MUST's > and an update to 3261 would be good, for the following reasons: > > 1) We really should want to change 3261 to say MUST NOT put an ip- > address/hostname in the call-id. Really in 20/20 hindsight I don't > think it should have had one to begin with. > > 2) It's easier for customers to force vendors to do something if > there's a MUST statement, standards-track RFC, vs. an informational > recommendation/should. > > 3) Endpoint UAC vendors should do it *before* getting deployed and > being told by customers to change after-wards. Specifically I'm > thinking about vendors who don't attend IETF and aren't that up-to- > speed on all the nuances and such. An update to 3261 with normative > mandatory language is clearer, I think. > I find myself in agreement with all three arguments here. -- Dean From dean.willis@softarmor.com Sun Mar 29 21:07:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF653A6CBC for ; Sun, 29 Mar 2009 21:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40CjaMjr-ykd for ; Sun, 29 Mar 2009 21:07:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id BEC653A6A7C for ; Sun, 29 Mar 2009 21:07:53 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2U48mC4002058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 29 Mar 2009 23:08:50 -0500 Message-Id: <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> From: Dean Willis To: Jiri Kuthan , Jon Peterson In-Reply-To: <49CE8255.4000103@iptel.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 23:08:43 -0500 References: <49CE8255.4000103@iptel.org> X-Mailer: Apple Mail (2.930.3) Cc: SIP List , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 04:07:55 -0000 On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: > > > I'm worried this is only a wishful thinking. While perfectly > logical, still even in such constrained setups some bizzar > ALGs do in my experience appear in the middle, change SDP > and make thus the identity worthless. If they change the SDP, they've changed the identity assertion. They need to re-assert. There might reasonably be a need to have a stack of assertions with diffs, so one could go back and see the original SDP, with its original key fingerprint and original verifiable signature, but just changing stuff and pretending the associated identity assertion hasn't changed is fundamentally bogus. The MAIN reason, it seems to me, to want to change the SDP (and especially the key fingerprint) undetectably is to enable intercept (lawful or otherwise) without detectability. That just won't do. Perhaps we only need are two different identity assertions; one on the original SDP with fingerprint, and one on whatever has resulted post- modification by the MITM attackers. Intermediate manipulations by yet more MITN attackers might well be worthless. Let's put it another way: One of the very important things that RFC 4474 does is protect the DTLS/SRTP key fingerprint. Arguably, its protection of the other stuff in the SDP, such as the port numbers and IP addresses used for media, is just a side effect. Of course, changing the codec (transcoding) is going to break DTLS/SRTP quite horribly, so the codec information might as well be protected by Identity. Would we be willing to accept a model where the fingerprint is preserved across SBCs but the IP address/port number information is not? I'm not saying that would be easy to produce; it would seem to require a very complex modification to RFC 4474's handling of SDP, or complementary fundamental changes to RFC 4474 and the DTLS draft family. But would it get us past this this stone wall? If not, why not? And you're going to have to convince me that you're not just building a phone-tapper protocol here . . . -- Dean From dwing@cisco.com Sun Mar 29 22:29:07 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581653A6B18 for ; Sun, 29 Mar 2009 22:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMWpMz5BHC3y for ; Sun, 29 Mar 2009 22:29:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 236823A6807 for ; Sun, 29 Mar 2009 22:29:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,444,1233532800"; d="scan'208";a="163505970" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 30 Mar 2009 05:30:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2U5U3Mv019419; Sun, 29 Mar 2009 22:30:03 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2U5U3s4020826; Mon, 30 Mar 2009 05:30:03 GMT From: "Dan Wing" To: "'Dean Willis'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> Date: Sun, 29 Mar 2009 22:30:03 -0700 Message-ID: <00ae01c9b0f8$940e6880$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acmw7UsSvMMgwgyWQKWdBjMdMGoX6wACYN4A In-Reply-To: <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4483; t=1238391003; x=1239255003; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=ysmccWlF4z/UdFRBLYvkKYSpH4FkWamWVe/QBy4tebc=; b=DLLsdZImzPH8MABlE1TNhjGSpaXsfKSpggJhezuQP0e8JZVVxpGe2MW7XW +p/JDgAOOmDaOp1uTUGYycAsOTSXNJy2S7VFCTjo509KlzCueZqaaotUGS/8 Mkkd6i/aBf; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'SIP List' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 05:29:07 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Sunday, March 29, 2009 9:09 PM > To: Jiri Kuthan; Jon Peterson > Cc: SIP List; Francois Audet > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: > > > > > > > I'm worried this is only a wishful thinking. While perfectly > > logical, still even in such constrained setups some bizzar > > ALGs do in my experience appear in the middle, change SDP > > and make thus the identity worthless. > > > If they change the SDP, they've changed the identity > assertion. They > need to re-assert. There might reasonably be a need to have a > stack of > assertions with diffs, so one could go back and see the > original SDP, > with its original key fingerprint and original verifiable signature, > but just changing stuff and pretending the associated identity > assertion hasn't changed is fundamentally bogus. > > The MAIN reason, it seems to me, to want to change the SDP (and > especially the key fingerprint) undetectably is to enable intercept > (lawful or otherwise) without detectability. That just won't do. > > Perhaps we only need are two different identity assertions; > one on the > original SDP with fingerprint, and one on whatever has resulted post- > modification by the MITM attackers. Intermediate > manipulations by yet > more MITN attackers might well be worthless. > > Let's put it another way: One of the very important things that RFC > 4474 does is protect the DTLS/SRTP key fingerprint. Arguably, its > protection of the other stuff in the SDP, such as the port > numbers and > IP addresses used for media, is just a side effect. Of course, > changing the codec (transcoding) is going to break DTLS/SRTP quite > horribly, so the codec information might as well be protected by > Identity. > > Would we be willing to accept a model where the fingerprint is > preserved across SBCs but the IP address/port number information is > not? I'm not saying that would be easy to produce; it would seem to > require a very complex modification to RFC 4474's handling of > SDP, or > complementary fundamental changes to RFC 4474 and the DTLS draft > family. But would it get us past this this stone wall? It would not get us past this stone wall, because this very idea was already proposed and already rejected, http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4.2 The reasons for the rejection, as I recall, were along the lines of "we don't want to require SRTP to provide identity". That argument is countered with the ICE technique in Section 4.3 of the same draft; we could change that from ICE to something else that does not overload ICE semantics of course. Other reasons included "but SBCs might [destroy | modify | manipulate]" the messages. The counter argument to that is that the operators of SBCs have an incentive to allow identity through (namely, so that people will accept incoming SIP calls), very much like the long distance phone companies in the 1980's added echo cancellation tone detectors (because it was something needed by the end users). Other arguments questioned how non-Invite requests would get protection (also answered in that same draft). It is not a lack of solutions in this space. It is a lack of participation by interested parties and an unwillingness to admit that voice networks are using SBCs -- as if SBCs operated by service providers are as real as the tooth fairy or Santa Claus. > If not, why not? And you're going to have to convince me that you're > not just building a phone-tapper protocol here . . . Strong identity makes it *harder* to build a phone-tapping system. This hop-by-hop signing thing that you are describing above, and Jon described at the microphone, is transitive trust with extra CPU horsepower and something you could fight better in a lawsuit when you learned that a service provider lied. I don't see a service provider getting very interested in the additional capex, opex, and business risk of doing such signing, especially compared to the three proposals on the table which require the service provider do _no_ signing and no stronger attestation than today (same business risk as today). -d From HKaplan@acmepacket.com Sun Mar 29 22:50:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5233A6918 for ; Sun, 29 Mar 2009 22:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xpz-iCzkxDVs for ; Sun, 29 Mar 2009 22:50:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 555D13A6403 for ; Sun, 29 Mar 2009 22:50:01 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 30 Mar 2009 01:50:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 30 Mar 2009 01:50:57 -0400 From: Hadriel Kaplan To: Dean Willis , Jiri Kuthan , Jon Peterson Date: Mon, 30 Mar 2009 01:50:56 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmw7VMtPulbVZSGQiaFV+A4z0eh/gAC5p9w Message-ID: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> In-Reply-To: <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP List , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 05:50:02 -0000 What is it in the SDP that you feel is integral to the identity of the send= er of the request? If I send an offer-less Invite and sign it with rfc4474= does it not confirm my identity, because there was no SDP? Clearly it wou= ld indicate that the signed sender did not send SDP, so it prevents a MITM = from inserting one, but does it actually let a MITM change the Identity of = the sender of the request if it inserts one? You say below that one of the important properties is that it protects the = dtls-srtp fingerprint, presumably because that allows it to tie the identit= y of the sender of the SIP request to the identity of the media. Every dra= ft proposal thus far to do rfc4474 differently has included the ability to = sign that fingerprint, specifically for that purpose. The question is whet= her the IP-Addr/port of the media is itself integral to the identity of the= sender, or not. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Monday, March 30, 2009 12:09 AM >=20 > On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: >=20 > > I'm worried this is only a wishful thinking. While perfectly > > logical, still even in such constrained setups some bizzar > > ALGs do in my experience appear in the middle, change SDP > > and make thus the identity worthless. >=20 >=20 > If they change the SDP, they've changed the identity assertion. They > need to re-assert. There might reasonably be a need to have a stack of > assertions with diffs, so one could go back and see the original SDP, > with its original key fingerprint and original verifiable signature, > but just changing stuff and pretending the associated identity > assertion hasn't changed is fundamentally bogus. >=20 > The MAIN reason, it seems to me, to want to change the SDP (and > especially the key fingerprint) undetectably is to enable intercept > (lawful or otherwise) without detectability. That just won't do. >=20 > Perhaps we only need are two different identity assertions; one on the > original SDP with fingerprint, and one on whatever has resulted post- > modification by the MITM attackers. Intermediate manipulations by yet > more MITN attackers might well be worthless. >=20 > Let's put it another way: One of the very important things that RFC > 4474 does is protect the DTLS/SRTP key fingerprint. Arguably, its > protection of the other stuff in the SDP, such as the port numbers and > IP addresses used for media, is just a side effect. Of course, > changing the codec (transcoding) is going to break DTLS/SRTP quite > horribly, so the codec information might as well be protected by > Identity. >=20 > Would we be willing to accept a model where the fingerprint is > preserved across SBCs but the IP address/port number information is > not? I'm not saying that would be easy to produce; it would seem to > require a very complex modification to RFC 4474's handling of SDP, or > complementary fundamental changes to RFC 4474 and the DTLS draft > family. But would it get us past this this stone wall? >=20 > If not, why not? And you're going to have to convince me that you're > not just building a phone-tapper protocol here . . . >=20 > -- > Dean >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From HKaplan@acmepacket.com Sun Mar 29 22:59:17 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6333A6C6E for ; Sun, 29 Mar 2009 22:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxHC7-cCsC0U for ; Sun, 29 Mar 2009 22:59:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3311D3A67E6 for ; Sun, 29 Mar 2009 22:59:13 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 30 Mar 2009 02:00:09 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 30 Mar 2009 02:00:09 -0400 From: Hadriel Kaplan To: Dean Willis , Jiri Kuthan , Jon Peterson Date: Mon, 30 Mar 2009 02:00:11 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmw7VMtPulbVZSGQiaFV+A4z0eh/gADi0Gw Message-ID: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> In-Reply-To: <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP List , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 05:59:18 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Monday, March 30, 2009 12:09 AM >=20 > The MAIN reason, it seems to me, to want to change the SDP (and > especially the key fingerprint) undetectably is to enable intercept > (lawful or otherwise) without detectability. That just won't do. No, that's not at all the main reason. RFC4474 is already not end-to-end. = It's signed by a middlebox in the originating domain, and verified by a mi= ddlebox in the terminating domain. There is ample opportunity to change th= e SDP at either of those domains to perform lawful intercept.=20 The main reason to change SDP is to steer the media, for numerous reasons. -hadriel From christer.holmberg@ericsson.com Mon Mar 30 07:18:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460AB3A6CE9 for ; Mon, 30 Mar 2009 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a53tmPzj3EAP for ; Mon, 30 Mar 2009 07:18:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 37EB128C0F8 for ; Mon, 30 Mar 2009 07:18:52 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E8DD3200F9; Mon, 30 Mar 2009 16:19:48 +0200 (CEST) X-AuditID: c1b4fb3e-affbdbb000006d6d-0f-49d0d504c387 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CE68B203BF; Mon, 30 Mar 2009 16:19:48 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 16:17:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Mar 2009 16:17:41 +0200 Message-ID: In-Reply-To: <81881C2E-C631-4F46-A506-C984248337DC@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: Acmw6ySu5OqHZ/O8R3ipnGWtP4yRkgAGF7pQ References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <81881C2E-C631-4F46-A506-C984248337DC@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Mary Barnes" X-OriginalArrivalTime: 30 Mar 2009 14:17:42.0835 (UTC) FILETIME=[4A3EB030:01C9B142] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 14:18:53 -0000 Hi, Personally I have nothing against moving the keep-alive mechanism to draft-keep, and I guess most people agree it is how it should have been done. However, we have previously agreed not to do it, so I hope we will not spend lots of time to discuss it again. Regards, Christer -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Monday, March 30, 2009 4:54 AM To: Mary Barnes Cc: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] New version of draft-holmberg-sip-keep On Mar 26, 2009, at 6:16 PM, Mary Barnes wrote: > Hi folks, > > Christer has updated the document based on the action item from=20 > Wednesday's SIP session (chaired by SIPPING chairs and modeled as the=20 > proposed DISPATCH WG). If folks could please review the document and=20 > raise any concerns on the document now, that would be appreciated. We=20 > ask specifically for an answer to the question: Do you support the=20 > document being adopted as a WG document in RAI (WG tbd)? A simple=20 > "yes" is fine, however, if you don't think we should adopt this=20 > document, could you please provide the reason. > > > So, given the outpouring of support, should we pull back the draft- ietf-sip-outbound and re-write it to refer to the keepalive mechanism of this draft instead of containing similar but not identical text? -- Dean From AUDET@nortel.com Mon Mar 30 08:32:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C3A3A6C56 for ; Mon, 30 Mar 2009 08:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZxfJb9qAP+g for ; Mon, 30 Mar 2009 08:32:22 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id AFF753A6C43 for ; Mon, 30 Mar 2009 08:32:21 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2UFWia13940; Mon, 30 Mar 2009 15:32:44 GMT 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: Mon, 30 Mar 2009 10:32:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D203A69@zrc2hxm0.corp.nortel.com> In-Reply-To: <49CF79BC.6030408@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: francois' comments and why RFC4474 not used in the field Thread-Index: Acmwc5+b2JtlPutTTdq/t7Xzj141MwA2NoSA References: <49CE8255.4000103@iptel.org> <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> <49CF79BC.6030408@iptel.org> From: "Francois Audet" To: "Jiri Kuthan" Cc: sip@ietf.org Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 15:32:22 -0000 =20 > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org]=20 > Sent: Sunday, March 29, 2009 06:38 > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org > Subject: Re: francois' comments and why RFC4474 not used in the field >=20 > > So, what can we do? I see 2 possibilities: > >=20 > > 1 - Make it end-to-end. This means tackling one by one the=20 > problem areas. > > Use TURN/ICE instead for relying on SDP payload=20 > manipulation. Use > > Call-ID and Contact headers that don't reveal topology, etc. > >=20 > > 2 - Create a non end-to-end Identity assertion mechanism=20 > that is different > > from RFC 4474 and more secure than P-Asserted-Identity.=20 > I have a=20 > > feeling that it won't be trivial. We may have to define the=20 > > trust relationship between the ends and the intermediaries.=20 > >=20 > > What I was trying to say in the meeting is that for "end-to-end=20 > > identity", 4474 appears to work. But if the problem we are=20 > trying to=20 > > solve is NOT end-to-end identity, but strong mediated=20 > identity, then,=20 > > let's just say so. It's just a DIFFERENT problem to solve. >=20 > Well, I'm afraid that 1 is too complicated to work. Bringing=20 > TURN/ICE to work is already quite an enterprise, and as much=20 > success I wish to it, I would be careful and avoid dependency=20 > on it (which is generally a good protocol design practice anyhow). >=20 > 2 is then probably the safer direction to me. The point is really that > RFC4474 is not having as broad applicability as we have=20 > hoped, and leaving SIP without Identity is going to be=20 > real-time irritating, compared to convenience of Email's=20 > off-line irritation. 1 is definitively difficult to implement. However, I'm quite afraid that 2 is actually worst... =20 > Some of the RFC 4474 applicability limitations could be=20 > lifted by reducing its integrity protection scope. I'm not=20 > sure how popular will it be then (some have had different=20 > opinions on adoptability of things relying on CA) but it =20 > seems worth trying. My fear is that by doing so, we will not do something that will be substantially better than P-Asserted-Identity. But like you said, it may be worth trying. From AUDET@nortel.com Mon Mar 30 08:47:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61043A6A7F for ; Mon, 30 Mar 2009 08:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve7Hi10ZQQSB for ; Mon, 30 Mar 2009 08:47:04 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DBD513A6A47 for ; Mon, 30 Mar 2009 08:47:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2UFlQa17050; Mon, 30 Mar 2009 15:47:27 GMT 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: Mon, 30 Mar 2009 10:46:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D267BF0@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmw7VMtPulbVZSGQiaFV+A4z0eh/gADi0GwABSfnOA= References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Dean Willis" , "Jiri Kuthan" , "Jon Peterson" Cc: SIP List Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 15:47:04 -0000 =20 > No, that's not at all the main reason. RFC4474 is already=20 > not end-to-end. It's signed by a middlebox in the=20 > originating domain, and verified by a middlebox in the=20 > terminating domain. There is ample opportunity to change the=20 > SDP at either of those domains to perform lawful intercept.=20 End-to-end means from end domain to end domain. So 4474 is end-to-end. Again, if enterprise A wants to talk to enterprise B, without some service provider spying or redirecting media for their own potentially nefarious purposes, then 4474 is a perfect way to ensure that you are talking to who you think you are talking to. The fact that these enterprise may or may not be using their own SBCs to deal with NAT traversal and topology hiding is not relevant. > The main reason to change SDP is to steer the media, for=20 > numerous reasons. It should be up to the Enterprise to decide if it is willing to deal with a man-in-the-middle. If it does not, then it can use 4474. If it does, then it's not end-to-end security. This is probably acceptable to many enterprises, provided that they can trust their service provider. So again, perhaps what we need is a non end-to-end secure identity. Perhaps something that requires a broker/service provider. From pkyzivat@cisco.com Mon Mar 30 09:53:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5665428C116 for ; Mon, 30 Mar 2009 09:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1FRDMPHnPUI for ; Mon, 30 Mar 2009 09:53:51 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3AE6928C10D for ; Mon, 30 Mar 2009 09:53:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,447,1233532800"; d="scan'208";a="148255924" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2009 16:54:49 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2UGsnpt005631; Mon, 30 Mar 2009 09:54:49 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UGsjPM003119; Mon, 30 Mar 2009 16:54:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 12:54:47 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 12:54:47 -0400 Message-ID: <49D0F957.7070001@cisco.com> Date: Mon, 30 Mar 2009 12:54:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hadriel Kaplan References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> <49CD34EB.6010605@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2009 16:54:47.0258 (UTC) FILETIME=[3BA383A0:01C9B158] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2308; t=1238432089; x=1239296089; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20I-D=20Inaction=3A=20draft-kapla n-sip-secure-call-id-00.txt |Sender:=20; bh=7LgxeifmJ6fW+pRt2yI4+rk+PGgS2jGq6ryMJuKfGY8=; b=pdOnGRKIRexZYmt/XLXGfib8W35dG5dfCVe7/sMtjLGUSSvNmLH+We0lDo dxh0x8plbQoXziHcKgqldchvSg4APi5kYifxSImcvUmxAFvEH/vLW2vQO7HZ 2sItV/I80j; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP , Adam Roach Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 16:53:55 -0000 Hadriel, I understand your logic. BUT are we agreed that we should be making non-backward-compatible normative changes to 3261 (or any of the key RFCs) for reasons other than correcting out and out errors and ambiguities? Seems like that is the start of SIP/3.0. Paul Hadriel Kaplan wrote: > Yeah I've been thinking about what you said the other day about this, and I think I understand your point, but I still think MUST's and an update to 3261 would be good, for the following reasons: > > 1) We really should want to change 3261 to say MUST NOT put an ip-address/hostname in the call-id. Really in 20/20 hindsight I don't think it should have had one to begin with. > > 2) It's easier for customers to force vendors to do something if there's a MUST statement, standards-track RFC, vs. an informational recommendation/should. > > 3) Endpoint UAC vendors should do it *before* getting deployed and being told by customers to change after-wards. Specifically I'm thinking about vendors who don't attend IETF and aren't that up-to-speed on all the nuances and such. An update to 3261 with normative mandatory language is clearer, I think. > > -hadriel > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Friday, March 27, 2009 4:20 PM >> >> Which is why an informational draft explaining the problem is useful, >> while a normative document... not quite so much. >> >> Tell UACs: "If you include machine names in your Call-IDs, B2BUAs will >> have reason to change them." There's no MUST or MUST NOT here, just an >> explanation of rationale. >> >> Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do everyone >> a favor by not changing them, because it allows proper correlation of >> related transactions an dialogs." Again, no MUST; no MUST NOT. Just >> cause and effect. >> >> Then see if people want to play nice. The market will sort out if that's >> valuable or not. >> >> /a > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From HKaplan@acmepacket.com Mon Mar 30 10:01:41 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF84E3A6D48 for ; Mon, 30 Mar 2009 10:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoDAjSm874v1 for ; Mon, 30 Mar 2009 10:01:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 887AF3A6B28 for ; Mon, 30 Mar 2009 10:01:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 30 Mar 2009 13:02:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 30 Mar 2009 13:02:37 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 30 Mar 2009 13:02:37 -0400 Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmxWESe1/9y5kbRRGG42jTMCHPisAAADHzQ Message-ID: References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> <49CD34EB.6010605@nostrum.com> <49D0F957.7070001@cisco.com> In-Reply-To: <49D0F957.7070001@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP , Adam Roach Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 17:01:41 -0000 What's non-backward-compatible about it? The text would say a UAC should g= enerate a call-id without the IP/host (which is completely in-line with 326= 1), and that a UAS must continue to accept a call-id with ip/host. I'll remove the ABNF change piece since people are worried that may affect = backwards compatibility, due to a future strict-compliance parser checking = for this update's ABNF and rejecting legacy 3261 ABNF. So this update woul= d only affect the normative text and not the ABNF. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, March 30, 2009 12:55 PM > To: Hadriel Kaplan > Cc: Adam Roach; SIP > Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt >=20 > Hadriel, >=20 > I understand your logic. BUT are we agreed that we should be making > non-backward-compatible normative changes to 3261 (or any of the key > RFCs) for reasons other than correcting out and out errors and > ambiguities? Seems like that is the start of SIP/3.0. >=20 > Paul >=20 > Hadriel Kaplan wrote: > > Yeah I've been thinking about what you said the other day about this, > and I think I understand your point, but I still think MUST's and an > update to 3261 would be good, for the following reasons: > > > > 1) We really should want to change 3261 to say MUST NOT put an ip- > address/hostname in the call-id. Really in 20/20 hindsight I don't think > it should have had one to begin with. > > > > 2) It's easier for customers to force vendors to do something if there'= s > a MUST statement, standards-track RFC, vs. an informational > recommendation/should. > > > > 3) Endpoint UAC vendors should do it *before* getting deployed and bein= g > told by customers to change after-wards. Specifically I'm thinking about > vendors who don't attend IETF and aren't that up-to-speed on all the > nuances and such. An update to 3261 with normative mandatory language is > clearer, I think. > > > > -hadriel > > > > > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@nostrum.com] > >> Sent: Friday, March 27, 2009 4:20 PM > >> > >> Which is why an informational draft explaining the problem is useful, > >> while a normative document... not quite so much. > >> > >> Tell UACs: "If you include machine names in your Call-IDs, B2BUAs will > >> have reason to change them." There's no MUST or MUST NOT here, just an > >> explanation of rationale. > >> > >> Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do > everyone > >> a favor by not changing them, because it allows proper correlation of > >> related transactions an dialogs." Again, no MUST; no MUST NOT. Just > >> cause and effect. > >> > >> Then see if people want to play nice. The market will sort out if > that's > >> valuable or not. > >> > >> /a > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > From AUDET@nortel.com Mon Mar 30 10:09:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D751B3A68DC for ; Mon, 30 Mar 2009 10:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZPuOvllUrh7 for ; Mon, 30 Mar 2009 10:09:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BCCEF28C0FC for ; Mon, 30 Mar 2009 10:09:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2UHA6n00018; Mon, 30 Mar 2009 17:10:06 GMT 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: Mon, 30 Mar 2009 12:09:54 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D267EBE@zrc2hxm0.corp.nortel.com> In-Reply-To: <81881C2E-C631-4F46-A506-C984248337DC@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of draft-holmberg-sip-keep Thread-Index: Acmw6zKd0889sHT5RxuRDPO+WEUpCAAbiqdQ References: <1ECE0EB50388174790F9694F77522CCF1BF5FDAD@zrc2hxm0.corp.nortel.com> <81881C2E-C631-4F46-A506-C984248337DC@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Mary Barnes" Cc: sip@ietf.org, Cullen Jennings , Christer Holmberg Subject: Re: [Sip] New version of draft-holmberg-sip-keep X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 17:09:16 -0000 Dean,=20 There is no reason to do so. There is no "similar but not identical text" in draft-keep. Draft-keep only defines a parameter that allows the usage of the keep-alive defined in draft-ietf-sip-outbound, outside of the context of the registration procedures of draft-ietf-sip-outbound.=20 Currently, the two drafts are carefully choregraphed to be consistent. I don't want to undo this at the last minute. Note that some other drafts in the queue are dependent on=20 draft-ietf-outbound (e.g., draft-ietf-sip-sips). I really don't want us to undo our work for no good reason. I would recommend moving draft-keep swiftly to WG document. I believe it should rapidly move into last call. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Dean Willis > Sent: Sunday, March 29, 2009 20:54 > To: Barnes, Mary (RICH2:AR00) > Cc: sip@ietf.org; Christer Holmberg > Subject: Re: [Sip] New version of draft-holmberg-sip-keep >=20 >=20 > On Mar 26, 2009, at 6:16 PM, Mary Barnes wrote: >=20 > > Hi folks, > > > > Christer has updated the document based on the action item from=20 > > Wednesday's SIP session (chaired by SIPPING chairs and=20 > modeled as the=20 > > proposed DISPATCH WG). If folks could please review the=20 > document and=20 > > raise any concerns on the document now, that would be=20 > appreciated. We=20 > > ask specifically for an answer to the question: Do you support the=20 > > document being adopted as a WG document in RAI (WG tbd)? A simple=20 > > "yes" is fine, however, if you don't think we should adopt this=20 > > document, could you please provide the reason. > > > > > > >=20 > So, given the outpouring of support, should we pull back the=20 > draft- ietf-sip-outbound and re-write it to refer to the=20 > keepalive mechanism of this draft instead of containing=20 > similar but not identical text? >=20 > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From victor.pascual.avila@gmail.com Mon Mar 30 10:17:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815FF3A6C7E for ; Mon, 30 Mar 2009 10:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZYIi1wf1BPe for ; Mon, 30 Mar 2009 10:17:21 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 631F73A6C62 for ; Mon, 30 Mar 2009 10:17:17 -0700 (PDT) Received: by ewy9 with SMTP id 9so2174586ewy.37 for ; Mon, 30 Mar 2009 10:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3bYdbN5vwet+P3yw6LSqbLHm73Ijfu3ttT6A1EsZe6U=; b=P26PS7kzyh3IPV8aSfPXA/F8fi9dUrzFYAiPkpeNJ+jQr7i+BcmkUtj963S8bUMdq3 2p4mrWWYvckGPPlOBGaixg9cZizxTHr9CA+ayUy4LB4np+LT/LyS6U/TGBhkG2k3RyEC ZyyQb27/ftO7n2qVAn/S0OPMTfE9FuFa9JfME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dETSw4KDRTwKBJJuiVoJQ2r1UUSA+akFoUePHAjXRIXSGykJFCuzujGQZTXsxl0oay GChx0xkLEJX/PquMnHX6/nO8RpKSc2o9HKszqFRRhkUhHllyhLds+ZgrhUY0nMyLLWV/ EekFEAVIjLHxzdstCDOIp89IVX5Iyu4+cVBP8= MIME-Version: 1.0 Received: by 10.210.127.13 with SMTP id z13mr2758545ebc.91.1238433494727; Mon, 30 Mar 2009 10:18:14 -0700 (PDT) In-Reply-To: <49CEC72F.8060600@iptel.org> References: <49CA9943.1020808@cisco.com> <49CC02F4.6070507@iptel.org> <40FB0FFB97588246A1BEFB05759DC8A002CA7355@S4DE9JSAANI.ost.t-com.de> <49CEC72F.8060600@iptel.org> Date: Mon, 30 Mar 2009 19:18:14 +0200 Message-ID: <618e24240903301018t3ee2c9dcp5276e2a70aec6dea@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Jiri Kuthan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 17:17:22 -0000 On Sun, Mar 29, 2009 at 2:56 AM, Jiri Kuthan wrote: (snip) > As for the backwards-compatibility argument, I guess that it will > take same long time to get UAs do session-id, so IMO an improvement > is only possible under an assumption that network-asserted session-id > is easier to introduce than UA-asserted, right? That appears > meaningful to me. I'm still worried about out-of-dialog messages referencing to Call-ID values. It sounds like "you break it, you fix it". --=20 Victor Pascual =C3=81vila From dean.willis@softarmor.com Mon Mar 30 11:17:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEE93A6CA3 for ; Mon, 30 Mar 2009 11:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWV7PAGbAlSY for ; Mon, 30 Mar 2009 11:17:37 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E994F3A6D54 for ; Mon, 30 Mar 2009 11:17:36 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2UIIT0L007185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2009 13:18:30 -0500 Message-Id: <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 13:18:23 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 18:17:37 -0000 On Mar 30, 2009, at 1:00 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >> Of Dean >> Willis >> Sent: Monday, March 30, 2009 12:09 AM >> >> The MAIN reason, it seems to me, to want to change the SDP (and >> especially the key fingerprint) undetectably is to enable intercept >> (lawful or otherwise) without detectability. That just won't do. > > No, that's not at all the main reason. RFC4474 is already not end- > to-end. It's signed by a middlebox in the originating domain, and > verified by a middlebox in the terminating domain. There is ample > opportunity to change the SDP at either of those domains to perform > lawful intercept. RFC 4474 can be used end to end. It all depends on which cert is used to sign the identity, where that signing occurs, and where it gets checked. For stupid legacy phones, it can be signed and checked at middleboxes operating under some level of transitive trust. For smarter devices, it happens in the endpoint. Signing and checking at the endpoint, coupled with the DTLS fingerprint check. enables end-to-end verification of media integrity and privacy. Once you start ripping these signatures out in the middle of the network and replacing them, we have lost this absolutely critical property. If transit providers even think it MIGHT be reasonable to rip out the signatures, then we have lost the key functionality. Removing signatures MUST BE FORBIDDEN. Adding new ones might be ok. I might be willing to compromise on the mechanism (I've already proposed several potential approaches to doing so), but I'm unwilling to compromise on the fundamental requirement for this end-to-end applicability. -- Dean From jiri@iptel.org Mon Mar 30 11:24:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B964C3A69D1 for ; Mon, 30 Mar 2009 11:24:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBmYwCvd+CQQ for ; Mon, 30 Mar 2009 11:24:39 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 84A273A695C for ; Mon, 30 Mar 2009 11:24:39 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id C58651818096; Mon, 30 Mar 2009 20:25:35 +0200 (CEST) Message-ID: <49D0FA87.8030407@iptel.org> Date: Mon, 30 Mar 2009 18:59:51 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dean Willis References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> In-Reply-To: <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 18:24:40 -0000 Dean Willis wrote: > > On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: > >> >> >> I'm worried this is only a wishful thinking. While perfectly >> logical, still even in such constrained setups some bizzar >> ALGs do in my experience appear in the middle, change SDP >> and make thus the identity worthless. > > > If they change the SDP, they've changed the identity assertion. They > need to re-assert. There might reasonably be a need to have a stack of > assertions with diffs, so one could go back and see the original SDP, > with its original key fingerprint and original verifiable signature, but > just changing stuff and pretending the associated identity assertion > hasn't changed is fundamentally bogus. Hi Dean, My argument has been that including SDP's IP address and port numbers in message integrity check is not an identity assertion, but a protocol shortcoming (certainly well-meant, but making things hard to deploy). I really think that identity and integrity of SDP are two different things. Or do you think that these elements somehow belong to identity assertion? > > The MAIN reason, it seems to me, to want to change the SDP (and > especially the key fingerprint) undetectably is to enable intercept > (lawful or otherwise) without detectability. That just won't do. In the field, the desire to change SDP I have witnessed is due to NATs. We don't have TURN & ICE in the field and I'm quite worried that very few care today. In fact, SDP rewriting has been in use for so long, that I consider TURN's success chances very marginal. Other I have witnessed is transcoding. To make it clear: I'm not opposed to all sorts of integrity protection. I'm just worried that if we try to solve identity in a single package with integrity of ever changing SDP, we will unlikely succeed. > > Perhaps we only need are two different identity assertions; one on the > original SDP with fingerprint, and one on whatever has resulted > post-modification by the MITM attackers. Intermediate manipulations by > yet more MITN attackers might well be worthless. > > Let's put it another way: One of the very important things that RFC 4474 > does is protect the DTLS/SRTP key fingerprint. Arguably, its protection > of the other stuff in the SDP, such as the port numbers and IP addresses > used for media, is just a side effect. Of course, changing the codec > (transcoding) is going to break DTLS/SRTP quite horribly, so the codec > information might as well be protected by Identity. > > Would we be willing to accept a model where the fingerprint is preserved > across SBCs but the IP address/port number information is not? I'm not > saying that would be easy to produce; it would seem to require a very > complex modification to RFC 4474's handling of SDP, or complementary > fundamental changes to RFC 4474 and the DTLS draft family. But would it > get us past this this stone wall? Logically yes, integrity of some pieces that are known not to be useful to be rewritten would be ok. The practicability is of course another question, on which many may have different opinions. Should mine be asked, I would be in favor of using confidentiality protocols that do not have dependencies in general, and dependencies on protocols with unenforceable identity in particular: zRTP. > > If not, why not? And you're going to have to convince me that you're not > just building a phone-tapper protocol here . . . I haven't been working on a phone-tapper, even though a media-relay or transcoder could be labeled so for marketing purposes :-) zRTP actually makes it gracefuly through media relay while confidentiality remains preserved. -jiri > > -- > Dean > From jiri@iptel.org Mon Mar 30 11:24:47 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC743A6CBA for ; Mon, 30 Mar 2009 11:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOylz63ftpr9 for ; Mon, 30 Mar 2009 11:24:47 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id B29E73A6CB3 for ; Mon, 30 Mar 2009 11:24:46 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 1401018180A3; Mon, 30 Mar 2009 20:25:41 +0200 (CEST) Message-ID: <49D10281.5040007@iptel.org> Date: Mon, 30 Mar 2009 19:33:53 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francois Audet References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D267BF0@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D267BF0@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , Jon Peterson , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 18:24:47 -0000 Francois Audet wrote: > >> No, that's not at all the main reason. RFC4474 is already >> not end-to-end. It's signed by a middlebox in the >> originating domain, and verified by a middlebox in the >> terminating domain. There is ample opportunity to change the >> SDP at either of those domains to perform lawful intercept. > > End-to-end means from end domain to end domain. So 4474 is > end-to-end. > > Again, if enterprise A wants to talk to enterprise B, without > some service provider spying or redirecting media for their > own potentially nefarious purposes, then 4474 is a perfect > way to ensure that you are talking to who you think you are > talking to. > > The fact that these enterprise may or may not be using their > own SBCs to deal with NAT traversal and topology hiding is > not relevant. > >> The main reason to change SDP is to steer the media, for >> numerous reasons. > > It should be up to the Enterprise to decide if it is willing > to deal with a man-in-the-middle. If it does not, then it > can use 4474. > > If it does, then it's not end-to-end security. This is probably > acceptable to many enterprises, provided that they can trust > their service provider. > > So again, perhaps what we need is a non end-to-end secure identity. > Perhaps something that requires a broker/service provider. I think that there is a lot of confusion around putting together identity and integrity. It is not that I must have one for the other. I can have identity without integrity of SDP and still be in position to accept/decline a call based on who is calling me. If I'm worried about media confidentiality, I can add zRTP. As long as identity remains clearly separated from other stuff, we can do quite some things. Most of the confusion seems to come from packaging it with other functionalities. 4474 without integrity of the IP:port in SDP would work, DERIVE (as e2e representaive) would work, certainly many other things as well. Let's face it, integrity of whole SDP payload is illusive and any functionality relying upon it undeployable. -jiri > From dean.willis@softarmor.com Mon Mar 30 11:26:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D0D3A6898 for ; Mon, 30 Mar 2009 11:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HKKCGOdgzzR for ; Mon, 30 Mar 2009 11:26:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 823CD3A6B42 for ; Mon, 30 Mar 2009 11:26:42 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2UIRbEF007319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2009 13:27:39 -0500 Message-Id: From: Dean Willis To: Dan Wing In-Reply-To: <00ae01c9b0f8$940e6880$c4f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 13:27:32 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <00ae01c9b0f8$940e6880$c4f0200a@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'SIP List' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 18:26:43 -0000 On Mar 30, 2009, at 12:30 AM, Dan Wing wrote: >> >> Would we be willing to accept a model where the fingerprint is >> preserved across SBCs but the IP address/port number information is >> not? I'm not saying that would be easy to produce; it would seem to >> require a very complex modification to RFC 4474's handling of >> SDP, or >> complementary fundamental changes to RFC 4474 and the DTLS draft >> family. But would it get us past this this stone wall? > > It would not get us past this stone wall, because this very idea > was already proposed and already rejected, > http://tools.ietf.org/html/draft-wing-sip-identity- > media-02#section-4.2 I'm hoping that we've developed a broader understanding of the problem since the last time this was circulated, > The reasons for the rejection, as I recall, were along the lines of > "we > don't want to require SRTP to provide identity". That argument is > countered with the ICE technique in Section 4.3 of the same draft; > we could change that from ICE to something else that does not > overload ICE semantics of course. Other reasons included "but SBCs > might [destroy | modify | manipulate]" the messages. The counter > argument to that is that the operators of SBCs have an incentive > to allow identity through (namely, so that people will accept > incoming SIP calls), very much like the long distance phone > companies in the 1980's added echo cancellation tone detectors > (because it was something needed by the end users). Other arguments > questioned how non-Invite requests would get protection (also > answered in that same draft). Given that a clever on-path attacker could disrupt "identity" without changing the port/address presentation, I fail to see how protecting them proves anything. > It is not a lack of solutions in this space. It is a lack of > participation by interested parties and an unwillingness to admit > that voice networks are using SBCs -- as if SBCs operated by service > providers are as real as the tooth fairy or Santa Claus. > >> If not, why not? And you're going to have to convince me that you're >> not just building a phone-tapper protocol here . . . > > Strong identity makes it *harder* to build a phone-tapping system. > This > hop-by-hop signing thing that you are describing above, and Jon > described at > the microphone, is transitive trust with extra CPU horsepower and > something > you could fight better in a lawsuit when you learned that a service > provider > lied. I don't see a service provider getting very interested in the > additional capex, opex, and business risk of doing such signing, > especially > compared to the three proposals on the table which require the service > provider do _no_ signing and no stronger attestation than today > (same business > risk as today). You misunderstand the hop-by-hop signing approach I described. By adding signatures, rather than replacing them, the original media and DTLS key identifier properties are preserved. The stack of signatures and new SDPs provide an audit chain for figuring out what happened and for a basis of transitive trust where end-to-end trust is not existent, but do not impede the ability for end-to-end when the endpoints have that capability. -- Dean From dean.willis@softarmor.com Mon Mar 30 11:28:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D703A6D50 for ; Mon, 30 Mar 2009 11:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHoZ9w8gNpuM for ; Mon, 30 Mar 2009 11:28:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id BD90A3A6C9B for ; Mon, 30 Mar 2009 11:28:47 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2UITf7T007336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2009 13:29:43 -0500 Message-Id: <9DFD5C6B-F15E-493E-AE4F-CA591A289758@softarmor.com> From: Dean Willis To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D267BF0@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 13:29:35 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D267BF0@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP List , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 18:28:48 -0000 On Mar 30, 2009, at 10:46 AM, Francois Audet wrote: > >> No, that's not at all the main reason. RFC4474 is already >> not end-to-end. It's signed by a middlebox in the >> originating domain, and verified by a middlebox in the >> terminating domain. There is ample opportunity to change the >> SDP at either of those domains to perform lawful intercept. > > End-to-end means from end domain to end domain. So 4474 is > end-to-end. RFC 4474 can also be used user-agent to user-agent, phone to phone. > > So again, perhaps what we need is a non end-to-end secure identity. > Perhaps something that requires a broker/service provider. How is this not P-Asserted-Identity? What real property does such an identity assertion have that PAID lacks? -- Dean From dean.willis@softarmor.com Mon Mar 30 11:39:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D3B3A6D53 for ; Mon, 30 Mar 2009 11:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEDxbdy46oVy for ; Mon, 30 Mar 2009 11:39:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9B20D3A69BC for ; Mon, 30 Mar 2009 11:39:47 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2UIehGn007422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2009 13:40:44 -0500 Message-Id: <99040E46-0547-4D31-B283-A955332DBD2E@softarmor.com> From: Dean Willis To: Jiri Kuthan In-Reply-To: <49D0FA87.8030407@iptel.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 13:40:38 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> X-Mailer: Apple Mail (2.930.3) Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 18:39:48 -0000 On Mar 30, 2009, at 11:59 AM, Jiri Kuthan wrote: > Dean Willis wrote: >> On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: >>> >>> >>> I'm worried this is only a wishful thinking. While perfectly >>> logical, still even in such constrained setups some bizzar >>> ALGs do in my experience appear in the middle, change SDP >>> and make thus the identity worthless. >> If they change the SDP, they've changed the identity assertion. >> They need to re-assert. There might reasonably be a need to have a >> stack of assertions with diffs, so one could go back and see the >> original SDP, with its original key fingerprint and original >> verifiable signature, but just changing stuff and pretending the >> associated identity assertion hasn't changed is fundamentally bogus. > > My argument has been that including SDP's IP address and port numbers > in message integrity check is not an identity assertion, but a > protocol > shortcoming (certainly well-meant, but making things hard to deploy). > I really think that identity and integrity of SDP are two different > things. > > Or do you think that these elements somehow belong to identity > assertion? The argument has been made that these elements might provide additional clues to identity. For example, if I see something that is coming from what I know is your IP address, and see that it was signed by your proxy, whose cert I trust, I might be inclined to believe this assertion more than I would believe it if the source address were coming from a node that had a reverse record in alqueda,org. In the absence of a DTLS or zRTP protection of the media path, I'd be likely to give fairly heavy weighting to this IP address comparison, even though we know it's not 100% it is MUCH better than nothing. Of course, I'd rather have an identity mechanism that actually works with DTLS than one than doesn't but "works just a little" for unprotected media. So personally, I'd be willing to give up signing of IP address/port numbers when a media key fingerprint is present. But if there's no media key fingerprint in the signaling (or in the protocol, as zRTP), then I want to see the address and port numbers included. -- Dean From AUDET@nortel.com Mon Mar 30 11:43:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794CC3A6A3C for ; Mon, 30 Mar 2009 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eifE1CZqihgS for ; Mon, 30 Mar 2009 11:43:21 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 890313A69BC for ; Mon, 30 Mar 2009 11:43:21 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n2UIiFn02187; Mon, 30 Mar 2009 18:44:15 GMT 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: Mon, 30 Mar 2009 13:44:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D268195@zrc2hxm0.corp.nortel.com> In-Reply-To: <49D10281.5040007@iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmxZQDXYs04i7dlT6GXoXli9B6o4gAAMFVw References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D267BF0@zrc2hxm0.corp.nortel.com> <49D10281.5040007@iptel.org> From: "Francois Audet" To: "Jiri Kuthan" Cc: SIP List , Jon Peterson , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 18:43:22 -0000 =20 > I think that there is a lot of confusion around putting=20 > together identity and integrity. It is not that I must have=20 > one for the other. > I can have identity without integrity of SDP and still be in=20 > position to accept/decline a call based on who is calling me.=20 > If I'm worried about media confidentiality, I can add zRTP. If relying on dead-beat end-users for enforcing security, then sure, you can use ZRTP. Those end-users are the same guys who keep clicking accept anytime theirs browsers tell them the certificate is invalid. When the private conversations unlawfully recorded gets leaked, or when somebody impersonates an important person, the individual who=20 gets fired is the IT guy who recommended using ZRTP. Anyways, I digress. I think the argument for the proponents of RFC 4474 is that you can not separate identity from media security. If 4474 allows for intercepting the media, than the identity of the interlocutor is wrong. What you are arguing for is a mechanism that asserts the identity of the sender of the signalling only (SIP), and not the media. Perhaps this what we need. I believe that the current DTLS proposal actually relies on 4474 for the fingerprinting. I guess we would need something else. It's almost as if we would need something like 4474 between originating domain and Service Provider, and then 4474 again between Service = provider and destination domain. From apike3@csc.com Mon Mar 30 12:08:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8C73A6A3C for ; Mon, 30 Mar 2009 12:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.06 X-Spam-Level: X-Spam-Status: No, score=-5.06 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6WMBLmFcWwO for ; Mon, 30 Mar 2009 12:08:24 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by core3.amsl.com (Postfix) with ESMTP id 60A2E3A67CF for ; Mon, 30 Mar 2009 12:08:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-5.tower-85.messagelabs.com!1238440158!40898763!3 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 13935 invoked from network); 30 Mar 2009 19:09:19 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-5.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Mar 2009 19:09:19 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2UJ9ISA031524; Mon, 30 Mar 2009 15:09:19 -0400 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> , <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> MIME-Version: 1.0 From: Anthony D Pike To: Dean Willis Message-ID: Date: Mon, 30 Mar 2009 15:09:16 -0400 X-Mailer: Lotus Domino Web Server Release 8.0.1 February 07, 2008 X-MIMETrack: Serialize by Notes Server on AMER-ML20/SRV/CSC(Release 8.0.1|February 07, 2008) at 03/30/2009 15:09:16, Serialize complete at 03/30/2009 15:09:16, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 03/30/2009 03:11:29 PM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:08:25 -0000 inline

This is a PRIVATE messag= e. If you are not the intended recipient, please delete without copying and= kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardles= s of content, this e-mail shall not operate to bind CSC to any order or oth= er contract unless pursuant to explicit written agreement or government ini= tiative expressly permitting the use of e-mail for such purpose. =E2=80=A2 

-----sip-bounces@ietf.org wrote: -----

To: Hadriel Kaplan &= lt;HKaplan@acmepacket.com>
From: Dean Willis <dean.willis@softarmo= r.com>
Sent by: sip-bounces@ietf.org
Date: 03/30/2009 02:18PM
c= c: SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>, = Jon Peterson <jon.peterson@neustar.biz>
Subject: Re: [Sip] francoi= s' comments and why RFC4474 not used in the field


On Mar 30, 2009, = at 1:00 AM, Hadriel Kaplan wrote:

>
>
>> -----Orig= inal Message-----
>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf  
>> Of Dean
>> Willis
>> Sent: Mond= ay, March 30, 2009 12:09 AM
>>
>> The MAIN reason, it see= ms to me, to want to change the SDP (and
>> especially the key fin= gerprint) undetectably is to enable intercept
>> (lawful or otherw= ise) without detectability. That just won't do.
>
> No, that's = not at all the main reason.  RFC4474 is already not end-
> to-e= nd.  It's signed by a middlebox in the originating domain, and  <= BR>> verified by a middlebox in the terminating domain.  There is a= mple  
> opportunity to change the SDP at either of those domain= s to perform  
> lawful intercept.

RFC 4474 can be used e= nd to end. It all depends on which cert is used  
to sign the ident= ity, where that signing occurs, and where it gets  
checked. For st= upid legacy phones, it can be signed and checked at  
middleboxes o= perating under some level of transitive trust. For  
smarter device= s, it happens in the endpoint.

Signing and checking at the endpoint,= coupled with the DTLS  
fingerprint check. enables end-to-end veri= fication of media integrity  
and privacy. Once you start ripping t= hese signatures out in the middle  
of the network and replacing th= em, we have lost this absolutely  
critical property. If transit pr= oviders even think it MIGHT be  
reasonable to rip out the signatur= es, then we have lost the key  
functionality. Removing signatures = MUST BE FORBIDDEN. Adding new ones  
might be ok.

I am = 100% in agreement with this normative text above. I also believe that Bot= h the Signalling and Media need to be asserted ( this is not th= e case in 4474), the mechanism is TBD, but I believe this should be a req= uirement. Think of your children I have a 5 year old girl growing up in a= next generation environment, if Identity is not completely solved in the= next few years, then shame on us for not helping to protect the next gen= eration! My 0.02c worth.

I might be willing to compromise on the m= echanism (I've already  
proposed several potential approaches to d= oing so), but I'm unwilling  
to compromise on the fundamental requ= irement for this end-to-end  
applicability.

--
Dean
= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sip m= ailing list  https://www.ietf.org/mailman/listinfo/sip
This list is = for NEW development of the core SIP Protocol
Use sip-implementors@cs.col= umbia.edu for questions on current sip
Use sipping@ietf.org for new deve= lopments on the application of sip


= From Adam.Uzelac@globalcrossing.com Mon Mar 30 12:24:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9503A6AA1 for ; Mon, 30 Mar 2009 12:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joq26u-N9wTc for ; Mon, 30 Mar 2009 12:24:17 -0700 (PDT) Received: from mailsrv.ams.gblxint.com (unknown-141-roc.globalcrossing.com [209.130.177.141]) by core3.amsl.com (Postfix) with ESMTP id 598093A6898 for ; Mon, 30 Mar 2009 12:24:17 -0700 (PDT) Received: from w3uspdyvs212.ams.gblxint.com (w3uspdyvs212.ams.gblxint.com [10.60.54.213]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 14D6CE8B51; Mon, 30 Mar 2009 15:25:13 -0400 (EDT) Received: from w3uspdyvs240.ams.gblxint.com ([10.60.54.201]) by w3uspdyvs212.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 15:25:12 -0400 Received: from EVS20.ams.gblxint.com ([10.60.53.123]) by w3uspdyvs240.ams.gblxint.com ([10.60.54.201]) with mapi; Mon, 30 Mar 2009 15:25:12 -0400 From: "Uzelac, Adam" To: Jiri Kuthan , Dean Willis Date: Mon, 30 Mar 2009 15:25:11 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmxZV6LnjdMuoyeRx6fDdQr9RxC8gAB011A Message-ID: <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> In-Reply-To: <49D0FA87.8030407@iptel.org> 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-OriginalArrivalTime: 30 Mar 2009 19:25:12.0926 (UTC) FILETIME=[3F5B27E0:01C9B16D] Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:24:18 -0000 Francois has said it, and so has Jiri. =20 " I think that there is a lot of confusion around putting together identity= and integrity."=20 " I really think that identity and integrity of SDP are two different thing= s." Put me down as +1 The need is IDENTITY first and foremost. Adam From dean.willis@softarmor.com Mon Mar 30 12:48:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DAB3A6D0C for ; Mon, 30 Mar 2009 12:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vuPtvycw9c4 for ; Mon, 30 Mar 2009 12:48:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CE6433A6968 for ; Mon, 30 Mar 2009 12:48:03 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2UJmss4007888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2009 14:48:56 -0500 Message-Id: <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> From: Dean Willis To: "Uzelac, Adam" In-Reply-To: <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 14:48:49 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP List Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:48:04 -0000 On Mar 30, 2009, at 2:25 PM, Uzelac, Adam wrote: > > > The need is IDENTITY first and foremost. Is that signaling identity, or media identity, or both? Is either useful alone? I'm thinking that a lot of people are demanding signaling identity without media identity, and haven't really thought about the consequences of that decision because they grew up with a telephone system that essentially lacks the distinction. -- Dean From dwing@cisco.com Mon Mar 30 12:50:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0B73A6846 for ; Mon, 30 Mar 2009 12:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlpPuziny0zh for ; Mon, 30 Mar 2009 12:50:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CDA863A6D48 for ; Mon, 30 Mar 2009 12:50:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,448,1233532800"; d="scan'208";a="276891306" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 19:51:27 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2UJpRtQ010343; Mon, 30 Mar 2009 12:51:27 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2UJpQKO029701; Mon, 30 Mar 2009 19:51:27 GMT From: "Dan Wing" To: "'Dean Willis'" References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <00ae01c9b0f8$940e6880$c4f0200a@cisco.com> Date: Mon, 30 Mar 2009 12:51:26 -0700 Message-ID: <029d01c9b170$e9adba20$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmxZTXZDRIRvJuPQhm1Gzh78S4BDAAC37uw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1511; t=1238442687; x=1239306687; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=q4SeuDQD+p1mQwtajX+WuCzCoOdJBFNjrrKCc7UdUPc=; b=DSOHbz6FtipMxXlB9B9BBu/c3Td8B4fLaB8r+OPJOioo6pAr12VYeN03IL BDIRAaCEjCAUhwoWii7qJ5KyyTUXiDAFxbM2vbIJGZ8tzn1hP1DA2jYoheGz rSOdYLInfg; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'SIP List' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:50:42 -0000 > > Strong identity makes it *harder* to build a phone-tapping > system. > > This > > hop-by-hop signing thing that you are describing above, and Jon > > described at > > the microphone, is transitive trust with extra CPU horsepower and > > something > > you could fight better in a lawsuit when you learned that a > service > > provider > > lied. I don't see a service provider getting very interested in the > > additional capex, opex, and business risk of doing such signing, > > especially > > compared to the three proposals on the table which require > the service > > provider do _no_ signing and no stronger attestation than today > > (same business > > risk as today). > > > You misunderstand the hop-by-hop signing approach I described. By > adding signatures, rather than replacing them, the original > media and > DTLS key identifier properties are preserved. The stack of > signatures > and new SDPs provide an audit chain for figuring out what > happened and > for a basis of transitive trust where end-to-end trust is not > existent, but do not impede the ability for end-to-end when the > endpoints have that capability. You are right, I had misunderstood. Your proposal is different from the proposal that Jon described at the microphone. However, it would disclose the entire path which SP's appear reluctant to do -- else they would not remove Via headers (I understand most SPs, using SBCs, remove Via headers). -d From michael@voip.co.uk Mon Mar 30 13:00:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689DF3A6C2A for ; Mon, 30 Mar 2009 13:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIzo+q+zmlB2 for ; Mon, 30 Mar 2009 13:00:37 -0700 (PDT) Received: from voip.co.uk (smtp.sov.voip.co.uk [80.249.108.49]) by core3.amsl.com (Postfix) with ESMTP id 93FC83A691B for ; Mon, 30 Mar 2009 13:00:37 -0700 (PDT) Message-ID: <49D12514.3040403@voip.co.uk> Date: Mon, 30 Mar 2009 21:01:24 +0100 From: Michael Procter User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Dean Willis References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> In-Reply-To: <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:00:38 -0000 Dean Willis wrote: > On Mar 30, 2009, at 2:25 PM, Uzelac, Adam wrote: >> The need is IDENTITY first and foremost. > > Is that signaling identity, or media identity, or both? > > Is either useful alone? I think it is at least a bit useful. If Alice calls Bob, Bob can ensure that the signalling for the call originated from Alice. He can't assert that the media is to/from Alice yet, but it is a start. More usefully, if Eve calls Bob, Bob can see that it isn't Alice. A positive result from signalling-only identity isn't as useful as you might hope. But a negative result is still interesting. Is that enough of a solution to still be useful? There are still several holes in it, but it is better than we have at present. > I'm thinking that a lot of people are demanding signaling identity > without media identity, and haven't really thought about the > consequences of that decision because they grew up with a telephone > system that essentially lacks the distinction. Indeed. Michael From pkyzivat@cisco.com Mon Mar 30 13:47:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8F93A6D92 for ; Mon, 30 Mar 2009 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.936 X-Spam-Level: X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hveZpSyFv1dr for ; Mon, 30 Mar 2009 13:47:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 627F43A6D20 for ; Mon, 30 Mar 2009 13:47:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,448,1233532800"; d="scan'208";a="276924365" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 20:48:35 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2UKmZEj004426; Mon, 30 Mar 2009 13:48:35 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2UKmQRj015395; Mon, 30 Mar 2009 20:48:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 16:48:30 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 16:48:29 -0400 Message-ID: <49D1301C.1060001@cisco.com> Date: Mon, 30 Mar 2009 16:48:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hadriel Kaplan References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> <49CD34EB.6010605@nostrum.com> <49D0F957.7070001@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2009 20:48:29.0901 (UTC) FILETIME=[E1C907D0:01C9B178] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3394; t=1238446115; x=1239310115; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20I-D=20Inaction=3A=20draft-kapla n-sip-secure-call-id-00.txt |Sender:=20; bh=E+vtnin+D/mlQcrly1xC9xySrgXqAg0nNSmmYltYY8Y=; b=AjM1kVz8KG0e5z7647WP7EerSLR6IfReLcQGC9Pa6Mk1mXIfjkmaGlpKFz XROwxEgSCdPyM5GQP0gqUv4tpQGrE1Jzv1VmfZm6aHrBaWMxUUxENaLxPtqH fR5Gjo1Hli; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIP , Adam Roach Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:47:38 -0000 Hadriel Kaplan wrote: > What's non-backward-compatible about it? The text would say a UAC should generate a call-id without the IP/host (which is completely in-line with 3261), and that a UAS must continue to accept a call-id with ip/host. OK. I thought you were proposing to go further. What you say above here seems fine. (But of course some won't implement SHOULD either.) Thanks, Paul > I'll remove the ABNF change piece since people are worried that may affect backwards compatibility, due to a future strict-compliance parser checking for this update's ABNF and rejecting legacy 3261 ABNF. So this update would only affect the normative text and not the ABNF. > > -hadriel > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, March 30, 2009 12:55 PM >> To: Hadriel Kaplan >> Cc: Adam Roach; SIP >> Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt >> >> Hadriel, >> >> I understand your logic. BUT are we agreed that we should be making >> non-backward-compatible normative changes to 3261 (or any of the key >> RFCs) for reasons other than correcting out and out errors and >> ambiguities? Seems like that is the start of SIP/3.0. >> >> Paul >> >> Hadriel Kaplan wrote: >>> Yeah I've been thinking about what you said the other day about this, >> and I think I understand your point, but I still think MUST's and an >> update to 3261 would be good, for the following reasons: >>> 1) We really should want to change 3261 to say MUST NOT put an ip- >> address/hostname in the call-id. Really in 20/20 hindsight I don't think >> it should have had one to begin with. >>> 2) It's easier for customers to force vendors to do something if there's >> a MUST statement, standards-track RFC, vs. an informational >> recommendation/should. >>> 3) Endpoint UAC vendors should do it *before* getting deployed and being >> told by customers to change after-wards. Specifically I'm thinking about >> vendors who don't attend IETF and aren't that up-to-speed on all the >> nuances and such. An update to 3261 with normative mandatory language is >> clearer, I think. >>> -hadriel >>> >>> >>>> -----Original Message----- >>>> From: Adam Roach [mailto:adam@nostrum.com] >>>> Sent: Friday, March 27, 2009 4:20 PM >>>> >>>> Which is why an informational draft explaining the problem is useful, >>>> while a normative document... not quite so much. >>>> >>>> Tell UACs: "If you include machine names in your Call-IDs, B2BUAs will >>>> have reason to change them." There's no MUST or MUST NOT here, just an >>>> explanation of rationale. >>>> >>>> Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do >> everyone >>>> a favor by not changing them, because it allows proper correlation of >>>> related transactions an dialogs." Again, no MUST; no MUST NOT. Just >>>> cause and effect. >>>> >>>> Then see if people want to play nice. The market will sort out if >> that's >>>> valuable or not. >>>> >>>> /a >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > From john.elwell@siemens-enterprise.com Mon Mar 30 13:54:58 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899EA28C127 for ; Mon, 30 Mar 2009 13:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx1kycFY2q7M for ; Mon, 30 Mar 2009 13:54:53 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1B2F53A6A36 for ; Mon, 30 Mar 2009 13:54:53 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHC0014T7H229@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Mar 2009 21:55:50 +0100 (BST) Date: Mon, 30 Mar 2009 21:55:50 +0100 From: "Elwell, John" In-reply-to: <49CE8255.4000103@iptel.org> To: Jiri Kuthan , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B5146C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmv6LKaGBfPxw0RTBedFfXPlLF1YwBjBe0g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49CE8255.4000103@iptel.org> Cc: Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:54:58 -0000 Jiri,=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jiri Kuthan > Sent: 28 March 2009 20:02 > To: sip@ietf.org > Cc: Francois Audet > Subject: [Sip] francois' comments and why RFC4474 not used in=20 > the field >=20 > As we were running out of time in the meeting, I wanted to > follow up on an argument which Francois has made: RFC 4474 > works if the identity provider and verifiers are "next to > each other", thus we have no problem with this RFC. >=20 > /* hope I didn't misinterpret, let me know should that be > the case */ >=20 > I'm worried this is only a wishful thinking. While perfectly > logical, still even in such constrained setups some bizzar > ALGs do in my experience appear in the middle, change SDP > and make thus the identity worthless. >=20 > I think the bottom line is the protocol is not really end-to-end. > It makes quite some assumptions about the quality of underlying > network (particularly about not changing SDPs) as opposed to > trying to deal with lack of it. In fact, SDP payloads are > changed at quite a number of devices: proxy servers, B2BUAs, > SBCs, you name it. Assuming there is nothing in the way > which won't change SDP is just NOT ROBUST. >=20 > Other way to look at it is it is function overloading. You ask > for identity and get message integrity -- consequently when > the latter fails, the former, which you really initially wanted, > fails too. ekr's argument is certainly right that a message > of certain origin but uncertain content is close to worthless. > OTOH, the particular piece, IP address and port numbers in SDP > are certainly not to be covered by a message integrity checks. > In fact, for accepting calls based on who is calling, as > a minimalistic application example, one does not need > message integrity. >=20 > In conclusion, I do not think that RFC4474 can be of any help > (other than in controlled environments which beats its purpose) > as long as IP/port in SDP are message-integrity-protected. [JRE] Exactly. Moreover, when media are secured by some means (SRTP in the case of RTP) and if SDP contains a fingerprint of the certificate used to secure the media, there is absolutely no need to sign the IP address/port. They can quite happily change without impacting the security of media. Of course, if media isn't secured, it is a slightly different matter, but I doubt that signing the IP address and port really buys us much. So you might as well not include IP address and port in the signature, and if they are changed by intermediate SBCs, no problem. John From john.elwell@siemens-enterprise.com Mon Mar 30 13:55:34 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023A83A6C9B for ; Mon, 30 Mar 2009 13:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjpAiLpSHpH8 for ; Mon, 30 Mar 2009 13:55:32 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7E0973A6A53 for ; Mon, 30 Mar 2009 13:55:32 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHC0015D7I629@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Mar 2009 21:56:30 +0100 (BST) Date: Mon, 30 Mar 2009 21:56:30 +0100 From: "Elwell, John" In-reply-to: <49CF79BC.6030408@iptel.org> To: Jiri Kuthan , Francois Audet Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B5146D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmwc6I30YlQCCiARfC67N0FVdChCABAplfg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49CE8255.4000103@iptel.org> <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> <49CF79BC.6030408@iptel.org> Cc: sip@ietf.org Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:55:34 -0000 Jiri,=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jiri Kuthan > Sent: 29 March 2009 14:38 > To: Francois Audet > Cc: sip@ietf.org > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > Francois Audet wrote: > > I think our views are not that appart. > >=20 > > See belows. =20 > >=20 > >> -----Original Message----- > >> From: Jiri Kuthan [mailto:jiri@iptel.org]=20 > >> Sent: Saturday, March 28, 2009 13:02 > >> To: sip@ietf.org > >> Cc: Audet, Francois (SC100:3055) > >> Subject: francois' comments and why RFC4474 not used in the field > >> > >> As we were running out of time in the meeting, I wanted to=20 > >> follow up on an argument which Francois has made: RFC 4474=20 > >> works if the identity provider and verifiers are "next to=20 > >> each other", thus we have no problem with this RFC. > >> > >> /* hope I didn't misinterpret, let me know should that be=20 > the case */ > >=20 > > First part is currect, but I didn't say "thus we have no=20 > problem with > > this RFC." > >=20 > > As you say, it only works if the identity provider and the=20 > verifier are > > "next to each other". A federation of Enterprises for=20 > example. Or between > > service providers. > >=20 > > However, one of the most predominant model today doesn't=20 > work like this. > > A domain is often relying on a third party, a "service provider". > >=20 > > So it's really not "end-to-end". That was the point I was=20 > trying to make. > >=20 > > RFC 4474 appears to work fine for end-to-end identity:=20 > unfortunately, > > many deployment models (perhaps the majority) and in fact,=20 > not end-to-end, > > but mediated. In a typical scenario, each end would have it's own > > "service provider", so 2 intermediaries. > >=20 > >> I'm worried this is only a wishful thinking. While perfectly=20 > >> logical, still even in such constrained setups some bizzar=20 > >> ALGs do in my experience appear in the middle, change SDP and=20 > >> make thus the identity worthless. > >=20 > > Yes, I agree 4474 doesn't work if there are intermidiaries. > >=20 > >> I think the bottom line is the protocol is not really end-to-end. > >=20 > > EXACTLY! > >=20 > >=20 > >> It makes quite some assumptions about the quality of=20 > >> underlying network (particularly about not changing SDPs) as=20 > >> opposed to trying to deal with lack of it. In fact, SDP=20 > >> payloads are changed at quite a number of devices: proxy=20 > >> servers, B2BUAs, SBCs, you name it. Assuming there is nothing=20 > >> in the way which won't change SDP is just NOT ROBUST. > >> > >> Other way to look at it is it is function overloading. You=20 > >> ask for identity and get message integrity -- consequently=20 > >> when the latter fails, the former, which you really initially=20 > >> wanted, fails too. ekr's argument is certainly right that a=20 > >> message of certain origin but uncertain content is close=20 > to worthless. > >> OTOH, the particular piece, IP address and port numbers in=20 > >> SDP are certainly not to be covered by a message integrity checks. > >> In fact, for accepting calls based on who is calling, as a=20 > >> minimalistic application example, one does not need message=20 > >> integrity. > >> > >> In conclusion, I do not think that RFC4474 can be of any help=20 > >> (other than in controlled environments which beats its=20 > >> purpose) as long as IP/port in SDP are message-integrity-protected. >=20 > Thanks for the clarifications. I think we are on the same page then. >=20 > >=20 > > Here is what I think: > >=20 > > RFC 4474 can work in the following situations: > >=20 > > 1 - Enterprise-to-Enterprise: i.e., the network as a dumb=20 > pipe. The enterprises > > have their own SBCs modifying SIP/SDP (or they can use ICE). > >=20 > > 2 - Subscriber on Service provider A to Subscriber on=20 > service provider B:=20 > > i.e., the "domain" for the first subscriber is actually=20 > that of the subscriber. > > This can work for "residential users" and small enterprises. > >=20 > > 3 - Any permutation of the above. > >=20 > > In all those cases, there is effectively end-to-end > >=20 > > RFC 4474 does NOT work if it's not end-to-end. For example, if=20 > > the "Enterprise" has it's own domain, but it relies on it's=20 > > service provider to perform a number of functions. NAT traversal, > > topology hiding, etc. > >=20 > > So, what can we do? I see 2 possibilities: > >=20 > > 1 - Make it end-to-end. This means tackling one by one the=20 > problem areas. > > Use TURN/ICE instead for relying on SDP payload=20 > manipulation. Use > > Call-ID and Contact headers that don't reveal topology, etc. > >=20 > > 2 - Create a non end-to-end Identity assertion mechanism=20 > that is different > > from RFC 4474 and more secure than P-Asserted-Identity.=20 > I have a=20 > > feeling that it won't be trivial. We may have to define the=20 > > trust relationship between the ends and the intermediaries.=20 > >=20 > > What I was trying to say in the meeting is that for "end-to-end > > identity", 4474 appears to work. But if the problem we are trying to > > solve is NOT end-to-end identity, but strong mediated=20 > identity, then, > > let's just say so. It's just a DIFFERENT problem to solve. >=20 > Well, I'm afraid that 1 is too complicated to work. Bringing=20 > TURN/ICE to > work is already quite an enterprise, and as much success I wish to it, > I would be careful and avoid dependency on it (which is generally > a good protocol design practice anyhow). >=20 > 2 is then probably the safer direction to me. The point is really that > RFC4474 is not having as broad applicability as we have hoped, and > leaving SIP without Identity is going to be real-time irritating, > compared to convenience of Email's off-line irritation. >=20 > Some of the RFC 4474 applicability limitations could be lifted by > reducing its integrity protection scope. I'm not sure how popular > will it be then (some have had different opinions on adoptability > of things relying on CA) but it seems worth trying. >=20 > I would not dare to restrain ourselves to fixing RFC4474 though. > I'm very much in favor of testing other alternatives. IETF has > had a very successful tradition of testing several approaches. > A more ellaborated email on the topic was BTW recently written > by Dave Crocker:=20 > http://www.ietf.org/mail-archive/web/mmox/current/msg01233.html >=20 > Obviously DERIVE (or perhaps non-SIP based reverse verifications) > appears a feasible alternative to me (because easy to deploy and > offering incentives to do so), but given the interest it is quite > certain there will be more different alternatives. [JRE] I am open to such alternative suggestions. I think the problem with DERIVE was that it still was impacted by the idiosyncrasies of SIP, i.e., B2BUAs and backwards compatibility with UACs. Perhaps we need a non-SIP-based solution. John From john.elwell@siemens-enterprise.com Mon Mar 30 13:56:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91923A69C3 for ; Mon, 30 Mar 2009 13:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoOSu0YKlM3y for ; Mon, 30 Mar 2009 13:56:11 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id E0ACE3A6846 for ; Mon, 30 Mar 2009 13:56:10 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHC0015Q7J829@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Mar 2009 21:57:08 +0100 (BST) Date: Mon, 30 Mar 2009 21:57:08 +0100 From: "Elwell, John" In-reply-to: <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> To: Dean Willis , Hadriel Kaplan Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B5146E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmxY/59M92iYkhETeilQNhKZzRRVAAE7ULA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:56:11 -0000 Dean,=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Dean Willis > Sent: 30 March 2009 19:18 > To: Hadriel Kaplan > Cc: SIP List; Francois Audet; Jon Peterson > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > On Mar 30, 2009, at 1:00 AM, Hadriel Kaplan wrote: >=20 > > > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]=20 > On Behalf =20 > >> Of Dean > >> Willis > >> Sent: Monday, March 30, 2009 12:09 AM > >> > >> The MAIN reason, it seems to me, to want to change the SDP (and > >> especially the key fingerprint) undetectably is to enable intercept > >> (lawful or otherwise) without detectability. That just won't do. > > > > No, that's not at all the main reason. RFC4474 is already not end-=20 > > to-end. It's signed by a middlebox in the originating domain, and =20 > > verified by a middlebox in the terminating domain. There is ample =20 > > opportunity to change the SDP at either of those domains to=20 > perform =20 > > lawful intercept. >=20 > RFC 4474 can be used end to end. It all depends on which cert=20 > is used =20 > to sign the identity, where that signing occurs, and where it gets =20 > checked. For stupid legacy phones, it can be signed and checked at =20 > middleboxes operating under some level of transitive trust. For =20 > smarter devices, it happens in the endpoint. >=20 > Signing and checking at the endpoint, coupled with the DTLS =20 > fingerprint check. enables end-to-end verification of media=20 > integrity =20 > and privacy. Once you start ripping these signatures out in=20 > the middle =20 > of the network and replacing them, we have lost this absolutely =20 > critical property. If transit providers even think it MIGHT be =20 > reasonable to rip out the signatures, then we have lost the key =20 > functionality. Removing signatures MUST BE FORBIDDEN. Adding=20 > new ones =20 > might be ok. >=20 > I might be willing to compromise on the mechanism (I've already =20 > proposed several potential approaches to doing so), but I'm=20 > unwilling =20 > to compromise on the fundamental requirement for this end-to-end =20 > applicability. [JRE] Yes, that is a positive feature of RFC 4474, the fact that it can be used end-to-end, end-domain-to-end-domain, or even end-domain-to-end or end-to-end-domain. In other words, the authentication and verification functions can be in the endpoint or an end domain intermediary. John >=20 > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From john.elwell@siemens-enterprise.com Mon Mar 30 13:56:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAEF228C13B for ; Mon, 30 Mar 2009 13:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB+NRJ4ZGyFJ for ; Mon, 30 Mar 2009 13:56:42 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 60A5F28C11E for ; Mon, 30 Mar 2009 13:56:42 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHC001657K429@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Mar 2009 21:57:40 +0100 (BST) Date: Mon, 30 Mar 2009 21:57:40 +0100 From: "Elwell, John" In-reply-to: <49D0FA87.8030407@iptel.org> To: Jiri Kuthan , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B5146F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmxZPYlGXyg9QiRSlC+/niE5fm7XwAE3x5Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:56:43 -0000 Jiri,=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jiri Kuthan > Sent: 30 March 2009 18:00 > To: Dean Willis > Cc: SIP List; Francois Audet; Jon Peterson > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 > Dean Willis wrote: > >=20 > > On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: > >=20 > >> > >> > >> I'm worried this is only a wishful thinking. While perfectly > >> logical, still even in such constrained setups some bizzar > >> ALGs do in my experience appear in the middle, change SDP > >> and make thus the identity worthless. > >=20 > >=20 > > If they change the SDP, they've changed the identity=20 > assertion. They=20 > > need to re-assert. There might reasonably be a need to have=20 > a stack of=20 > > assertions with diffs, so one could go back and see the=20 > original SDP,=20 > > with its original key fingerprint and original verifiable=20 > signature, but=20 > > just changing stuff and pretending the associated identity=20 > assertion=20 > > hasn't changed is fundamentally bogus. >=20 > Hi Dean, >=20 > My argument has been that including SDP's IP address and port numbers > in message integrity check is not an identity assertion, but=20 > a protocol > shortcoming (certainly well-meant, but making things hard to deploy). > I really think that identity and integrity of SDP are two=20 > different things. >=20 > Or do you think that these elements somehow belong to=20 > identity assertion? >=20 > >=20 > > The MAIN reason, it seems to me, to want to change the SDP (and=20 > > especially the key fingerprint) undetectably is to enable intercept=20 > > (lawful or otherwise) without detectability. That just won't do. >=20 > In the field, the desire to change SDP I have witnessed is=20 > due to NATs. > We don't have TURN & ICE in the field and I'm quite worried that very > few care today. In fact, SDP rewriting has been in use for so=20 > long, that > I consider TURN's success chances very marginal. Other I have=20 > witnessed > is transcoding. >=20 > To make it clear: I'm not opposed to all sorts of integrity=20 > protection. > I'm just worried that if we try to solve identity in a single package > with integrity of ever changing SDP, we will unlikely succeed. >=20 > >=20 > > Perhaps we only need are two different identity assertions;=20 > one on the=20 > > original SDP with fingerprint, and one on whatever has resulted=20 > > post-modification by the MITM attackers. Intermediate=20 > manipulations by=20 > > yet more MITN attackers might well be worthless. > >=20 > > Let's put it another way: One of the very important things=20 > that RFC 4474=20 > > does is protect the DTLS/SRTP key fingerprint. Arguably,=20 > its protection=20 > > of the other stuff in the SDP, such as the port numbers and=20 > IP addresses=20 > > used for media, is just a side effect. Of course, changing=20 > the codec=20 > > (transcoding) is going to break DTLS/SRTP quite horribly,=20 > so the codec=20 > > information might as well be protected by Identity. > >=20 > > Would we be willing to accept a model where the fingerprint=20 > is preserved=20 > > across SBCs but the IP address/port number information is=20 > not? I'm not=20 > > saying that would be easy to produce; it would seem to=20 > require a very=20 > > complex modification to RFC 4474's handling of SDP, or=20 > complementary=20 > > fundamental changes to RFC 4474 and the DTLS draft family.=20 > But would it=20 > > get us past this this stone wall? >=20 > Logically yes, integrity of some pieces that are known not to=20 > be useful > to be rewritten would be ok. >=20 > The practicability is of course another question, on which=20 > many may have > different opinions. Should mine be asked, I would be in favor of using > confidentiality protocols that do not have dependencies in general, > and dependencies on protocols with unenforceable identity in=20 > particular: > zRTP. >=20 > >=20 > > If not, why not? And you're going to have to convince me=20 > that you're not=20 > > just building a phone-tapper protocol here . . . >=20 > I haven't been working on a phone-tapper, even though a media-relay or > transcoder could be labeled so for marketing purposes :-)=20 > zRTP actually > makes it gracefuly through media relay while confidentiality remains > preserved. [JRE] I am concerned about more than just confidentiality of media. I believe integrity protection (of certain data) and authentication are also important. There is only limited value on agreeing an encryption key with an unknown entity. John >=20 > -jiri >=20 > >=20 > > --=20 > > Dean > >=20 >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From jdrosen@cisco.com Mon Mar 30 14:24:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903A228C134 for ; Mon, 30 Mar 2009 14:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZQ+n695bu0z for ; Mon, 30 Mar 2009 14:24:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9E4933A6A34 for ; Mon, 30 Mar 2009 14:24:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,448,1233532800"; d="scan'208";a="276944210" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 21:25:46 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2ULPk8b021099; Mon, 30 Mar 2009 14:25:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2ULPkm2027851; Mon, 30 Mar 2009 21:25:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 14:25:45 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 14:25:45 -0700 Message-ID: <49D138D8.1040308@cisco.com> Date: Mon, 30 Mar 2009 17:25:44 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> In-Reply-To: <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2009 21:25:45.0590 (UTC) FILETIME=[165C1960:01C9B17E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1272; t=1238448346; x=1239312346; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=bcL4gSjJYMLd//53mnblecT8LtB37G7mzyvPJnsblrY=; b=W5YIhIDghOcsFDvgykCqXSsRrt8oBtvhZ9TipGJePJAtJcUJ/QKRqUR1c6 zHBlDvJ520THQQ4JZSdZwAzJPhLX2KnJ7D8iaibNk4TGAMpv580dLYsncjFh h4vFI8QYQm; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 21:24:48 -0000 inline: Dean Willis wrote: > > On Mar 30, 2009, at 2:25 PM, Uzelac, Adam wrote: >> >> >> The need is IDENTITY first and foremost. > > Is that signaling identity, or media identity, or both? > > Is either useful alone? > > I'm thinking that a lot of people are demanding signaling identity > without media identity, and haven't really thought about the > consequences of that decision because they grew up with a telephone > system that essentially lacks the distinction. From an end user perspective, I would assert that the most important thing is probably the media. If the callerID says, "this is bob", what is important to the user, is that when I pick up the phone and start talking, it will be Bob who hears me, and Bob that I hear. Consider this litmus test: If the signaling actually came from Mary (perhaps as a third party), but the media goes/comes to/from Bob, who should appear on the caller ID? I say - Bob. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From jiri@iptel.org Mon Mar 30 16:47:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB87D3A6B81 for ; Mon, 30 Mar 2009 16:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSi1yPawN7kO for ; Mon, 30 Mar 2009 16:47:16 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id C46AF3A6B65 for ; Mon, 30 Mar 2009 16:47:15 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 75DBC1810C53; Tue, 31 Mar 2009 01:48:11 +0200 (CEST) Message-ID: <49D15A3A.5030000@iptel.org> Date: Tue, 31 Mar 2009 01:48:10 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dean Willis References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <99040E46-0547-4D31-B283-A955332DBD2E@softarmor.com> In-Reply-To: <99040E46-0547-4D31-B283-A955332DBD2E@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 23:47:17 -0000 Dean Willis wrote: > > On Mar 30, 2009, at 11:59 AM, Jiri Kuthan wrote: > >> Dean Willis wrote: >>> On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: >>>> >>>> >>>> I'm worried this is only a wishful thinking. While perfectly >>>> logical, still even in such constrained setups some bizzar >>>> ALGs do in my experience appear in the middle, change SDP >>>> and make thus the identity worthless. >>> If they change the SDP, they've changed the identity assertion. They >>> need to re-assert. There might reasonably be a need to have a stack >>> of assertions with diffs, so one could go back and see the original >>> SDP, with its original key fingerprint and original verifiable >>> signature, but just changing stuff and pretending the associated >>> identity assertion hasn't changed is fundamentally bogus. >> >> My argument has been that including SDP's IP address and port numbers >> in message integrity check is not an identity assertion, but a protocol >> shortcoming (certainly well-meant, but making things hard to deploy). >> I really think that identity and integrity of SDP are two different >> things. >> >> Or do you think that these elements somehow belong to identity assertion? > > The argument has been made that these elements might provide additional > clues to identity. For example, if I see something that is coming from > what I know is your IP address, and see that it was signed by your > proxy, whose cert I trust, I might be inclined to believe this assertion > more than I would believe it if the source address were coming from a > node that had a reverse record in alqueda,org. > > In the absence of a DTLS or zRTP protection of the media path, I'd be > likely to give fairly heavy weighting to this IP address comparison, > even though we know it's not 100% it is MUCH better than nothing. > > Of course, I'd rather have an identity mechanism that actually works > with DTLS than one than doesn't but "works just a little" for > unprotected media. > > So personally, I'd be willing to give up signing of IP address/port > numbers when a media key fingerprint is present. But if there's no media > key fingerprint in the signaling (or in the protocol, as zRTP), then I > want to see the address and port numbers included. I perfectly agree with the suggestion "relax about changed IP/port in SDP if media secured". -jiri > > -- > Dean > From jiri@iptel.org Mon Mar 30 16:54:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694363A6BB9 for ; Mon, 30 Mar 2009 16:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWTe98LuTK4Y for ; Mon, 30 Mar 2009 16:54:43 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 46E473A69B3 for ; Mon, 30 Mar 2009 16:54:43 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 467191810C40; Tue, 31 Mar 2009 01:55:40 +0200 (CEST) Message-ID: <49D15BFB.5050606@iptel.org> Date: Tue, 31 Mar 2009 01:55:39 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francois Audet References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D267BF0@zrc2hxm0.corp.nortel.com> <49D10281.5040007@iptel.org> <1ECE0EB50388174790F9694F77522CCF1D268195@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D268195@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , Jon Peterson , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 23:54:44 -0000 Francois Audet wrote: > >> I think that there is a lot of confusion around putting >> together identity and integrity. It is not that I must have >> one for the other. >> I can have identity without integrity of SDP and still be in >> position to accept/decline a call based on who is calling me. >> If I'm worried about media confidentiality, I can add zRTP. > > If relying on dead-beat end-users for enforcing security, then > sure, you can use ZRTP. Those end-users are the same guys who > keep clicking accept anytime theirs browsers tell them the certificate > is invalid. > > When the private conversations unlawfully recorded gets leaked, > or when somebody impersonates an important person, the individual who > gets fired is the IT guy who recommended using ZRTP. > > Anyways, I digress. > > I think the argument for the proponents of RFC 4474 is that > you can not separate identity from media security. If 4474 > allows for intercepting the media, than the identity of the > interlocutor is wrong. That's indeed the argument. In other words, how can be message of certain origin valuable if of uncertain content. Are you sure to whom you are sending your RTP packets to? (Ironic answer: with 99% probability to your enterprise's ALG ;-)) The argument is valid, but unfortunately I believe SDP rewriting is here to stay, in places we have not anticipated. These SDP rewriters render the extra security value much less useful then we have hoped for. > > What you are arguing for is a mechanism that asserts the > identity of the sender of the signalling only (SIP), and not the > media. Yes. > > Perhaps this what we need. I believe that the current DTLS proposal > actually relies on 4474 for the fingerprinting. I guess we would > need something else. That's indeed a problem. Could be addressed by DTLS doing it somewhere else or 4474 changed to cover less. -jiri > > It's almost as if we would need something like 4474 between originating > domain and Service Provider, and then 4474 again between Service provider > and destination domain. > From jiri@iptel.org Mon Mar 30 16:57:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175E63A6B67 for ; Mon, 30 Mar 2009 16:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoG6g-vIx9-Q for ; Mon, 30 Mar 2009 16:57:35 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 460B43A6C6D for ; Mon, 30 Mar 2009 16:57:35 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 8D27B1810C40; Tue, 31 Mar 2009 01:58:32 +0200 (CEST) Message-ID: <49D15CA8.6060601@iptel.org> Date: Tue, 31 Mar 2009 01:58:32 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Elwell, John" References: <49CE8255.4000103@iptel.org> <0D5F89FAC29E2C41B98A6A762007F5D001B5146C@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001B5146C@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 23:57:36 -0000 Elwell, John wrote: >> In conclusion, I do not think that RFC4474 can be of any help >> (other than in controlled environments which beats its purpose) >> as long as IP/port in SDP are message-integrity-protected. > [JRE] Exactly. Moreover, when media are secured by some means (SRTP in > the case of RTP) and if SDP contains a fingerprint of the certificate > used to secure the media, there is absolutely no need to sign the IP > address/port. They can quite happily change without impacting the > security of media. Of course, if media isn't secured, it is a slightly > different matter, but I doubt that signing the IP address and port > really buys us much. So you might as well not include IP address and > port in the signature, and if they are changed by intermediate SBCs, no > problem. > > John > Yes, that's the point. -jiri From jiri@iptel.org Mon Mar 30 17:07:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE223A69B3 for ; Mon, 30 Mar 2009 17:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN+upxy-52xk for ; Mon, 30 Mar 2009 17:07:24 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id C27C23A68DF for ; Mon, 30 Mar 2009 17:07:24 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id EA3AC1810C51; Tue, 31 Mar 2009 02:08:21 +0200 (CEST) Message-ID: <49D15EF5.7080908@iptel.org> Date: Tue, 31 Mar 2009 02:08:21 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Elwell, John" References: <49CE8255.4000103@iptel.org> <1ECE0EB50388174790F9694F77522CCF1D203370@zrc2hxm0.corp.nortel.com> <49CF79BC.6030408@iptel.org> <0D5F89FAC29E2C41B98A6A762007F5D001B5146D@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001B5146D@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 00:07:25 -0000 Elwell, John wrote: >> Obviously DERIVE (or perhaps non-SIP based reverse verifications) >> appears a feasible alternative to me (because easy to deploy and >> offering incentives to do so), but given the interest it is quite >> certain there will be more different alternatives. > [JRE] I am open to such alternative suggestions. I think the problem > with DERIVE was that it still was impacted by the idiosyncrasies of SIP, > i.e., B2BUAs and backwards compatibility with UACs. Perhaps we need a > non-SIP-based solution. > > John Hi John, that may be very well true, in the end SIP is quite complex nowadays and overloading it with more stuff may make things possibly worse. I'm just wondering what folks thing about reverse verification per DNS. While not providing such a good granularity as SIP does, there is still some better-than-nothing value in it. What I find appealing about it is there is some prior experience (our domain for example is using SPF). Also, identity established via DNS is not worthless -- changing DNS names to change identity is associated with some prohibitive cost. Any other ideas? -jiri From jiri@iptel.org Mon Mar 30 18:02:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE7F3A6845 for ; Mon, 30 Mar 2009 18:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGXueFpvejzg for ; Mon, 30 Mar 2009 18:02:35 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id ADACF3A685E for ; Mon, 30 Mar 2009 18:02:35 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id BDB2F1810C51; Tue, 31 Mar 2009 03:03:31 +0200 (CEST) Message-ID: <49D16BE1.3060307@iptel.org> Date: Tue, 31 Mar 2009 03:03:29 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jonathan Rosenberg References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> In-Reply-To: <49D138D8.1040308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , "Uzelac, Adam" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 01:02:36 -0000 Jonathan Rosenberg wrote: > inline: > > Dean Willis wrote: >> >> On Mar 30, 2009, at 2:25 PM, Uzelac, Adam wrote: >>> >>> >>> The need is IDENTITY first and foremost. >> >> Is that signaling identity, or media identity, or both? >> >> Is either useful alone? >> >> I'm thinking that a lot of people are demanding signaling identity >> without media identity, and haven't really thought about the >> consequences of that decision because they grew up with a telephone >> system that essentially lacks the distinction. > > From an end user perspective, I would assert that the most important > thing is probably the media. If the callerID says, "this is bob", what > is important to the user, is that when I pick up the phone and start > talking, it will be Bob who hears me, and Bob that I hear. > > Consider this litmus test: > > If the signaling actually came from Mary (perhaps as a third party), but > the media goes/comes to/from Bob, who should appear on the caller ID? I > say - Bob. There is a timing aspect in favor of placing identity in signaling -- I would like to know whose call is ringing before I answer (if I do). -jiri > > -Jonathan R. > > > From jdrosen@cisco.com Mon Mar 30 19:11:54 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A664A3A6B1E for ; Mon, 30 Mar 2009 19:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcLoWn1vY0O1 for ; Mon, 30 Mar 2009 19:11:53 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AED5C3A6A89 for ; Mon, 30 Mar 2009 19:11:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,449,1233532800"; d="scan'208";a="148661423" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 31 Mar 2009 02:12:50 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2V2Cop6007590; Mon, 30 Mar 2009 19:12:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2V2CoNA020491; Tue, 31 Mar 2009 02:12:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 19:12:50 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 19:12:49 -0700 Message-ID: <49D17C20.8050907@cisco.com> Date: Mon, 30 Mar 2009 22:12:48 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jiri Kuthan References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> In-Reply-To: <49D16BE1.3060307@iptel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2009 02:12:49.0862 (UTC) FILETIME=[30D36E60:01C9B1A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1181; t=1238465570; x=1239329570; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=L70OaaHRpPki8RUAlk6zetFV1sGlS+IRqKg6OQgdbGY=; b=puGU1rttIuIj1EnlzmPuUojvCL3aiHaS0nvzNalxXvFWLwjtRattdZHVta vn06JlH9uo8qO2+GGHunjgfN7XnDVE/6IbDYeIeVxcKygMwCl8tEhQPS20jI wTZQ6uOdCg; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIP List , "Uzelac, Adam" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 02:11:54 -0000 inline: Jiri Kuthan wrote: >> From an end user perspective, I would assert that the most important >> thing is probably the media. If the callerID says, "this is bob", what >> is important to the user, is that when I pick up the phone and start >> talking, it will be Bob who hears me, and Bob that I hear. >> >> Consider this litmus test: >> >> If the signaling actually came from Mary (perhaps as a third party), >> but the media goes/comes to/from Bob, who should appear on the caller >> ID? I say - Bob. > > There is a timing aspect in favor of placing identity in signaling -- > I would like to know whose call is ringing before I answer (if I do). You can still have that. Just don't ring the phone until early media has been exchanged and verified. Indeed if you were doing an ICE-style thing per Dan's draft, you'd get that for free. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From AUDET@nortel.com Mon Mar 30 19:52:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261953A6C71 for ; Mon, 30 Mar 2009 19:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.457 X-Spam-Level: X-Spam-Status: No, score=-4.457 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSAgvyVx-d+u for ; Mon, 30 Mar 2009 19:52:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 309523A6B68 for ; Mon, 30 Mar 2009 19:52:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n2V2qe006445; Tue, 31 Mar 2009 02:52:41 GMT Received: from 47.102.153.123 ([47.102.153.123]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 Mar 2009 02:53:11 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 30 Mar 2009 19:53:07 -0700 From: "Francois Audet" To: Jonathan Rosenberg , Jiri Kuthan , Dan WING Message-ID: Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmxq9GNyI2jCsJzRPmmW+i4vP5uBQ== In-Reply-To: <49D17C20.8050907@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: SIP IETF , "Uzelac, Adam" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 02:52:29 -0000 For everybody's reference, can you point to Dan's draft? On Mar30 2009 19:12 , "Jonathan Rosenberg" wrote: > inline: > > Jiri Kuthan wrote: > > >>> From an end user perspective, I would assert that the most important >>> thing is probably the media. If the callerID says, "this is bob", what >>> is important to the user, is that when I pick up the phone and start >>> talking, it will be Bob who hears me, and Bob that I hear. >>> >>> Consider this litmus test: >>> >>> If the signaling actually came from Mary (perhaps as a third party), >>> but the media goes/comes to/from Bob, who should appear on the caller >>> ID? I say - Bob. >> >> There is a timing aspect in favor of placing identity in signaling -- >> I would like to know whose call is ringing before I answer (if I do). > > You can still have that. Just don't ring the phone until early media has > been exchanged and verified. Indeed if you were doing an ICE-style thing > per Dan's draft, you'd get that for free. > > -Jonathan R. > > From jiri@iptel.org Mon Mar 30 20:19:47 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25B73A68B6 for ; Mon, 30 Mar 2009 20:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BJ6qPJGEEXt for ; Mon, 30 Mar 2009 20:19:47 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 1000C3A67D8 for ; Mon, 30 Mar 2009 20:19:47 -0700 (PDT) Received: from jiri-kuthans-macbook-pro-8.local (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id F305A1812D35; Tue, 31 Mar 2009 05:20:42 +0200 (CEST) Message-ID: <49D18C0A.2070908@iptel.org> Date: Tue, 31 Mar 2009 05:20:42 +0200 From: Jiri Kuthan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jonathan Rosenberg References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> <49D17C20.8050907@cisco.com> In-Reply-To: <49D17C20.8050907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIP List , "Uzelac, Adam" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 03:19:48 -0000 Jonathan Rosenberg wrote: > inline: > > Jiri Kuthan wrote: > > >>> From an end user perspective, I would assert that the most important >>> thing is probably the media. If the callerID says, "this is bob", >>> what is important to the user, is that when I pick up the phone and >>> start talking, it will be Bob who hears me, and Bob that I hear. >>> >>> Consider this litmus test: >>> >>> If the signaling actually came from Mary (perhaps as a third party), >>> but the media goes/comes to/from Bob, who should appear on the caller >>> ID? I say - Bob. >> >> There is a timing aspect in favor of placing identity in signaling -- >> I would like to know whose call is ringing before I answer (if I do). > > You can still have that. Just don't ring the phone until early media has > been exchanged and verified. Indeed if you were doing an ICE-style thing > per Dan's draft, you'd get that for free. Hi Jonathan, Ok, that's feasible in a sense. And there is certain beauty in getting the security attributes associated with RTP packets, to which they belong. (I like this about zRTP). A particular example where this would perform well is today's PSTN directory service, which connects me to the final recipient, while still the directory's service phone number appears on my phone. (well, with connected identity one could actually handle it using signaling too...) What I'm anxious of is the idea of to do "x" you also have to do "y" which you need for "z" anyhow -- doesn't that impair the feasibility? Could not we find something that is just as easy as to do "x" do "x"? -jiri From dean.willis@softarmor.com Mon Mar 30 21:06:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D033A69F2 for ; Mon, 30 Mar 2009 21:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Qu-lRDq+v0 for ; Mon, 30 Mar 2009 21:06:56 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 415243A67D8 for ; Mon, 30 Mar 2009 21:06:56 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2V47o0O011237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2009 23:07:51 -0500 Message-Id: From: Dean Willis To: Jiri Kuthan In-Reply-To: <49D16BE1.3060307@iptel.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 23:07:44 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> X-Mailer: Apple Mail (2.930.3) Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 04:06:57 -0000 On Mar 30, 2009, at 8:03 PM, Jiri Kuthan wrote: > > There is a timing aspect in favor of placing identity in signaling -- > I would like to know whose call is ringing before I answer (if I do). So, we need identity in signaling, we need identity in media, and we need the two identity expressions to match. That's what we get with RFC 4474 and DTLS/SRTP. Why were we trying to change it to protect something else? -- Dean From dwing@cisco.com Mon Mar 30 21:14:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0723A69F2 for ; Mon, 30 Mar 2009 21:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k-CvfPq3FXt for ; Mon, 30 Mar 2009 21:14:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D21AD3A6966 for ; Mon, 30 Mar 2009 21:14:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,450,1233532800"; d="scan'208";a="164114610" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2009 04:15:49 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2V4FnoB011180; Mon, 30 Mar 2009 21:15:49 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2V4Fnhe008800; Tue, 31 Mar 2009 04:15:49 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Jonathan Rosenberg'" , "'Jiri Kuthan'" References: <49D17C20.8050907@cisco.com> Date: Mon, 30 Mar 2009 21:15:49 -0700 Message-ID: <042901c9b1b7$5f923a40$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acmxq9GNyI2jCsJzRPmmW+i4vP5uBQAC0NBQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1713; t=1238472949; x=1239336949; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=Fup1+Bs91vRx+6nnfOwK3dvZ7xy108IG4lgWBHwNHNY=; b=aLPfbTbQTjPphGdCgxICm0KIIzTRvvKOsVZqrlZSwH4EZnRBBD4f9nTBGy m4M4LEAuWNm4FuY7LcO+KjSY50ybievFWREkh9h7ZgtcPJaCVxyFDTHbM4YR ABgBCZDSbL; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'SIP IETF' , "'Uzelac, Adam'" , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 04:14:51 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, March 30, 2009 7:53 PM > To: Jonathan Rosenberg; Jiri Kuthan; Dan WING > Cc: SIP IETF; Uzelac, Adam; Dean Willis > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > For everybody's reference, can you point to Dan's draft? It is http://tools.ietf.org/html/draft-wing-sip-identity-media-02 other proposals in the same sphere, http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00 http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 -d > On Mar30 2009 19:12 , "Jonathan Rosenberg" wrote: > > > inline: > > > > Jiri Kuthan wrote: > > > > > >>> From an end user perspective, I would assert that the > most important > >>> thing is probably the media. If the callerID says, "this > is bob", what > >>> is important to the user, is that when I pick up the > phone and start > >>> talking, it will be Bob who hears me, and Bob that I hear. > >>> > >>> Consider this litmus test: > >>> > >>> If the signaling actually came from Mary (perhaps as a > third party), > >>> but the media goes/comes to/from Bob, who should appear > on the caller > >>> ID? I say - Bob. > >> > >> There is a timing aspect in favor of placing identity in > signaling -- > >> I would like to know whose call is ringing before I answer > (if I do). > > > > You can still have that. Just don't ring the phone until > early media has > > been exchanged and verified. Indeed if you were doing an > ICE-style thing > > per Dan's draft, you'd get that for free. > > > > -Jonathan R. > > > > > From apike3@csc.com Mon Mar 30 21:38:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959B23A6880 for ; Mon, 30 Mar 2009 21:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.055 X-Spam-Level: X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woIueWm6EDSa for ; Mon, 30 Mar 2009 21:38:35 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by core3.amsl.com (Postfix) with ESMTP id 948743A6859 for ; Mon, 30 Mar 2009 21:38:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: apike3@csc.com X-Msg-Ref: server-7.tower-86.messagelabs.com!1238474312!6632309!15 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 6021 invoked from network); 31 Mar 2009 04:39:33 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-7.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Mar 2009 04:39:33 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2V4cWmC018922; Tue, 31 Mar 2009 00:39:29 -0400 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <042901c9b1b7$5f923a40$c4f0200a@cisco.com> References: <49D17C20.8050907@cisco.com> , <042901c9b1b7$5f923a40$c4f0200a@cisco.com> MIME-Version: 1.0 From: Anthony D Pike To: "Dan Wing" Message-ID: Date: Tue, 31 Mar 2009 00:39:24 -0400 X-Mailer: Lotus Domino Web Server Release 8.0.1 February 07, 2008 X-MIMETrack: Serialize by Notes Server on AMER-ML20/SRV/CSC(Release 8.0.1|February 07, 2008) at 03/31/2009 00:39:24, Serialize complete at 03/31/2009 00:39:24, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 03/31/2009 12:41:39 AM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "'Uzelac, Adam'" , 'SIP IETF' , 'Francois Audet' , 'Dean Willis' Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 04:38:36 -0000 This general approach looks interesting I need time to digest the Kapl= an doc.

This is a PRIVATE message. I= f you are not the intended recipient, please delete without copying and kin= dly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of= content, this e-mail shall not operate to bind CSC to any order or other c= ontract unless pursuant to explicit written agreement or government initiat= ive expressly permitting the use of e-mail for such purpose. =E2=80=A2 = From ietf.hanserik@gmail.com Tue Mar 31 00:48:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8616D3A67B2 for ; Tue, 31 Mar 2009 00:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yigbzHbJG2J for ; Tue, 31 Mar 2009 00:48:09 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id DC2F63A6358 for ; Tue, 31 Mar 2009 00:48:08 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so579910eyf.31 for ; Tue, 31 Mar 2009 00:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mD1L8UXa8Ec/8VZEIAA0Cki4hxt4UeFfAIg2YOQy4U0=; b=Gw7Lbh2t4Sqsm7Cr3pbONTvHWd3AhJyiMSaxnWNMa3VACpH5eIy8NAcpCb+u1gWoKk hWz2GyJk6rfM6IMK2OKyQraKEAqxQaHnClVLhSa/8QwknIrh4kvhsesCqjl9lk0QF8od h8WDdT7uKUZuw0LTCehFsjs/YRSilAT8rB0Q8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e5fseKiQ6py8qmaMNhasXrkZbC0sH9fUrqC+buvhqQ8qEzNVNJb0FpMEEMyo/njJt2 qfuO2E9GNEPuBYpShkdXhEn6mWoJKGl5/ooUg3KCXu+fz/WC4RPd7K1oWQEYbHA6a/51 0T1nQ8BN6moMBDkYxl/oCsQbDJrqTGinrBezU= MIME-Version: 1.0 Received: by 10.216.49.209 with SMTP id x59mr1915450web.195.1238485746795; Tue, 31 Mar 2009 00:49:06 -0700 (PDT) In-Reply-To: <49D17C20.8050907@cisco.com> References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> <49D17C20.8050907@cisco.com> Date: Tue, 31 Mar 2009 09:49:06 +0200 Message-ID: <9ae56b1e0903310049x54945239q5e576f48075932f7@mail.gmail.com> From: Hans Erik van Elburg To: Jonathan Rosenberg Content-Type: multipart/alternative; boundary=001485f27f5eff46a80466656ead Cc: SIP List , "Uzelac, Adam" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 07:48:10 -0000 --001485f27f5eff46a80466656ead Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This litmus test seems to mixup presentation with Identity. All identity presentation services I know of are based on signaled identity. Of course a more advanced identity presentation service can be devised that also incorporates media identity. But this can become quite complicated, imagine 1 session containing multiple media streams coming from different entities, what do I present? Or will this not be allowed anymore? The first thing I would be interested in is who is trying to setup a session with me, and if I trust that someone. If I have more stringent requirements also on the media integrity then I need something additional. /Hans Erik van Elburg On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg wrote: > inline: > > Jiri Kuthan wrote: > > > From an end user perspective, I would assert that the most important >>> thing is probably the media. If the callerID says, "this is bob", what is >>> important to the user, is that when I pick up the phone and start talking, >>> it will be Bob who hears me, and Bob that I hear. >>> >>> Consider this litmus test: >>> >>> If the signaling actually came from Mary (perhaps as a third party), but >>> the media goes/comes to/from Bob, who should appear on the caller ID? I say >>> - Bob. >>> >> >> There is a timing aspect in favor of placing identity in signaling -- >> I would like to know whose call is ringing before I answer (if I do). >> > > You can still have that. Just don't ring the phone until early media has > been exchanged and verified. Indeed if you were doing an ICE-style thing per > Dan's draft, you'd get that for free. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --001485f27f5eff46a80466656ead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This litmus test seems to mixup presentation with Identity.

All iden= tity presentation services I know of are based on signaled identity. Of cou= rse a more advanced identity presentation service can be devised that also = incorporates media identity. But this can become quite complicated, imagine= 1 session containing multiple media streams coming from different entities= , what do I present?=A0 Or will this not be allowed anymore?

The first thing I would be interested in is who is trying to setup a se= ssion with me, and if I trust that someone. If I have more stringent requir= ements also on the media integrity then I need something additional.

/Hans Erik van Elburg


On Tue, Mar 31, 2009 at 4:12 AM, Jonatha= n Rosenberg <jdro= sen@cisco.com> wrote:
inline:


Jiri Kuthan wrote:


=A0From an end user perspective, I would assert that the most important thi= ng is probably the media. If the callerID says, "this is bob", wh= at is important to the user, is that when I pick up the phone and start tal= king, it will be Bob who hears me, and Bob that I hear.

Consider this litmus test:

If the signaling actually came from Mary (perhaps as a third party), but th= e media goes/comes to/from Bob, who should appear on the caller ID? I say -= Bob.

There is a timing aspect in favor of placing identity in signaling --
I would like to know whose call is ringing before I answer (if I do).

You can still have that. Just don't ring the phone until early media ha= s been exchanged and verified. Indeed if you were doing an ICE-style thing = per Dan's draft, you'd get that for free.


-Jonathan R.



--
Jonathan D. Rosenberg, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 111 Wood A= venue South
Cisco Fellow =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Iselin, NJ 08830
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PHONE: (408) 902-3084<= br> http://www.cisco.com=
_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use s= ip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org<= /a> for new developments on the application of sip

--001485f27f5eff46a80466656ead-- From john.elwell@siemens-enterprise.com Tue Mar 31 02:05:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0DB3A682E for ; Tue, 31 Mar 2009 02:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALhYw5XSoxBE for ; Tue, 31 Mar 2009 02:05:21 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id E2D6D3A686D for ; Tue, 31 Mar 2009 02:05:20 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KHD00LCU5AHMP@siemenscomms.co.uk> for sip@ietf.org; Tue, 31 Mar 2009 10:06:18 +0100 (BST) Date: Tue, 31 Mar 2009 10:06:16 +0100 From: "Elwell, John" In-reply-to: <9ae56b1e0903310049x54945239q5e576f48075932f7@mail.gmail.com> To: Hans Erik van Elburg , Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B51585@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C9B1DF.F35B4505" Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmx1TfVtZ8JFMvCQQOpqsgDNwZ3zwACpjyQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> <49D17C20.8050907@cisco.com> <9ae56b1e0903310049x54945239q5e576f48075932f7@mail.gmail.com> Cc: SIP List , "Uzelac, Adam" , Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 09:05:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B1DF.F35B4505 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hans Erik, =20 I think the issue is to verify that the media is to/from the same user as the signalling. I agree it would be complex if we were dealing with different users. =20 John ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 31 March 2009 08:49 To: Jonathan Rosenberg Cc: SIP List; Uzelac, Adam; Dean Willis Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field =09 =09 This litmus test seems to mixup presentation with Identity. =09 All identity presentation services I know of are based on signaled identity. Of course a more advanced identity presentation service can be devised that also incorporates media identity. But this can become quite complicated, imagine 1 session containing multiple media streams coming from different entities, what do I present? Or will this not be allowed anymore? =09 The first thing I would be interested in is who is trying to setup a session with me, and if I trust that someone. If I have more stringent requirements also on the media integrity then I need something additional.=20 =09 /Hans Erik van Elburg =09 =09 =09 On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg wrote: =09 inline:=20 Jiri Kuthan wrote: =09 =09 =09 From an end user perspective, I would assert that the most important thing is probably the media. If the callerID says, "this is bob", what is important to the user, is that when I pick up the phone and start talking, it will be Bob who hears me, and Bob that I hear. =09 Consider this litmus test: =09 If the signaling actually came from Mary (perhaps as a third party), but the media goes/comes to/from Bob, who should appear on the caller ID? I say - Bob. =09 There is a timing aspect in favor of placing identity in signaling -- I would like to know whose call is ringing before I answer (if I do). =09 You can still have that. Just don't ring the phone until early media has been exchanged and verified. Indeed if you were doing an ICE-style thing per Dan's draft, you'd get that for free.=20 -Jonathan R. =09 =09 =09 --=20 Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ =09 Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C9B1DF.F35B4505 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hans Erik,
 
I think the issue is to verify that the media is to/from = the same=20 user as the signalling. I agree it would be complex if we were dealing = with=20 different users.
 
John

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Hans Erik van=20 Elburg
Sent: 31 March 2009 08:49
To: Jonathan=20 Rosenberg
Cc: SIP List; Uzelac, Adam; Dean = Willis
Subject:=20 Re: [Sip] francois' comments and why RFC4474 not used in the=20 field

This litmus test seems to mixup presentation with=20 Identity.

All identity presentation services I know of are = based on=20 signaled identity. Of course a more advanced identity presentation = service can=20 be devised that also incorporates media identity. But this can become = quite=20 complicated, imagine 1 session containing multiple media streams = coming from=20 different entities, what do I present?  Or will this not be = allowed=20 anymore?

The first thing I would be interested in is who is = trying to=20 setup a session with me, and if I trust that someone. If I have more = stringent=20 requirements also on the media integrity then I need something = additional.=20

/Hans Erik van Elburg


On Tue, Mar 31, 2009 at 4:12 AM, Jonathan = Rosenberg=20 <jdrosen@cisco.com> = wrote:
inline:


Jiri Kuthan wrote:


 From=20 an end user perspective, I would assert that the most important = thing is=20 probably the media. If the callerID says, "this is bob", what is = important to the user, is that when I pick up the phone and = start=20 talking, it will be Bob who hears me, and Bob that I=20 hear.

Consider this litmus test:

If the signaling = actually=20 came from Mary (perhaps as a third party), but the media = goes/comes=20 to/from Bob, who should appear on the caller ID? I say -=20 Bob.

There is a timing aspect in favor of = placing=20 identity in signaling --
I would like to know whose call is = ringing=20 before I answer (if I do).

You can still = have=20 that. Just don't ring the phone until early media has been exchanged = and=20 verified. Indeed if you were doing an ICE-style thing per Dan's = draft, you'd=20 get that for free.


-Jonathan R.



--
Jonathan = D.=20 Rosenberg, Ph.D.               =  =20   111 Wood Avenue South
Cisco Fellow       =  =20                   =    =20     Iselin, NJ 08830
Cisco, Voice Technology = Group
jdrosen@cisco.com
http://www.jdrosen.net=20                   =    =20   PHONE: (408) 902-3084
http://www.cisco.com
_____________________________= __________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This = list is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions = on current=20 sip
Use sipping@ietf.org for new developments on the = application=20 of = sip

------_=_NextPart_001_01C9B1DF.F35B4505-- From victor.pascual.avila@gmail.com Tue Mar 31 03:05:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3909A3A6B29 for ; Tue, 31 Mar 2009 03:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGGSoG5VEntM for ; Tue, 31 Mar 2009 03:05:55 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 0ECED3A6885 for ; Tue, 31 Mar 2009 03:05:54 -0700 (PDT) Received: by ewy9 with SMTP id 9so2464058ewy.37 for ; Tue, 31 Mar 2009 03:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+dDVg9vKUxzWUkTsTyLArkUUSpDlaw3lZM8DTLz1aSc=; b=v3H6fwQ5ob4lITCVs2bvfRBm6x67VtL8rvHF2lr19tuoK2VETroiPNIELytsqgHzEo +rUnMd8e7gKpN0HTs7u5CvOIJCGIKh9iNWpvrHlkzMRn/HfOD7SC9rFQkCFGRVdBh42c 1RvmpIfMnsS7HPURrNymiJyV+DONDVhE+Tqsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OIf+4zK8aR6+TjtOheBzXfKZp9EEsG2/4f72kd0ybS4zINyDOcjG1dlNDN57O7HaHi hE+QYgKn4tTZccztwdlU4CxJFw5a32tzQYhNN5jHdOsrmOTzQCdmANU0yWZh1v8Un01f wmjZrm0qYd+Qwr9c3+VyYNM/DJQIMUgNlBSqs= MIME-Version: 1.0 Received: by 10.210.29.11 with SMTP id c11mr4917805ebc.20.1238494013400; Tue, 31 Mar 2009 03:06:53 -0700 (PDT) Date: Tue, 31 Mar 2009 12:06:52 +0200 Message-ID: <618e24240903310306k61cefe0cwb71848b3d78a7e50@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Jonathan Rosenberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: SIP List Subject: [Sip] Media vs Signaling identity (was Re: francois' comments and why RFC4474 not used in the field) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 10:05:56 -0000 On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg wro= te: > inline: > > Jiri Kuthan wrote: > > >>> =C2=A0From an end user perspective, I would assert that the most import= ant >>> thing is probably the media. If the callerID says, "this is bob", what = is >>> important to the user, is that when I pick up the phone and start talki= ng, >>> it will be Bob who hears me, and Bob that I hear. >>> >>> Consider this litmus test: >>> >>> If the signaling actually came from Mary (perhaps as a third party), bu= t >>> the media goes/comes to/from Bob, who should appear on the caller ID? I= say >>> - Bob. >> >> There is a timing aspect in favor of placing identity in signaling -- >> I would like to know whose call is ringing before I answer (if I do). > > You can still have that. Just don't ring the phone until early media has > been exchanged and verified. Indeed if you were doing an ICE-style thing = per > Dan's draft, you'd get that for free. Are we restricting the identity assertion to telephony-like sessions? IMHO, identity assertion should also work for the following scenarios (among others): -rfc3725, figure 1, message 1 (INVITE no SDP): Upon receipt of the initial INVITE (note there's no session description at all), "A" decides to authorize or reject the call based on the delivered identifier. -rfc3428, figure 1, message 2 (F2): "user2" decides to answer or ignore the message based on the delivered identifier. -rfc3515, example 4.1, message 1 (F1): "agent B" decides to accept or reject the refer based on the delivered identifier -Any other application based on white/black lists (where the identity verification must happen before accepting a request). While "signaling identity" seems to be a common denominator, I'm not sure about the role of "media identity" in the above listed scenarios. Any clarification will be appreciated. Cheers, --=20 Victor Pascual =C3=81vila From HKaplan@acmepacket.com Tue Mar 31 05:54:44 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0F73A6D3C for ; Tue, 31 Mar 2009 05:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBpBKO8xmt0n for ; Tue, 31 Mar 2009 05:54:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 06B2F3A68BE for ; Tue, 31 Mar 2009 05:54:43 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 31 Mar 2009 08:55:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Mar 2009 08:55:42 -0400 From: Hadriel Kaplan To: Jonathan Rosenberg , Dean Willis Date: Tue, 31 Mar 2009 08:55:41 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmxfiY9TQZG7GG7ThCjX7m5PVB2tQABRp0Q Message-ID: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> In-Reply-To: <49D138D8.1040308@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 12:54:44 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Monday, March 30, 2009 5:26 PM >=20 > Consider this litmus test: > If the signaling actually came from Mary (perhaps as a third party), but > the media goes/comes to/from Bob, who should appear on the caller ID? I > say - Bob. So what does 10.0.200.6:45001 mean to you? Bob or Mary? And since the SDP only indicates where to send your media to, not where it = comes from, what does it mean to you to get a session request where the cal= ler asks you to send media to 10.0.200.6:45001, but it can come from anywhe= re? The thing is an IP:port is NOT an Identity. It's not a secure assertion of= anything. Signing it doesn't *prove* anything. It neither prevents media= spoofing injection nor interception. It's only the signing of the dtls fi= ngerprint by binding it to the signaling identity that provides strong "med= ia" identity. -hadriel From HKaplan@acmepacket.com Tue Mar 31 06:01:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085DB3A6BFF for ; Tue, 31 Mar 2009 06:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8BAp6IZmIT0 for ; Tue, 31 Mar 2009 06:01:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2332A3A681F for ; Tue, 31 Mar 2009 06:01:34 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 31 Mar 2009 09:02:32 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Mar 2009 09:02:29 -0400 From: Hadriel Kaplan To: Dean Willis , Jiri Kuthan Date: Tue, 31 Mar 2009 09:02:25 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: Acmxtkdj0x8p6SA5RAOyy/7Cp1CWiwASf4JQ Message-ID: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 13:01:35 -0000 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dea= n > Willis > Sent: Tuesday, March 31, 2009 12:08 AM >=20 > So, we need identity in signaling, we need identity in media, and we > need the two identity expressions to match. >=20 > That's what we get with RFC 4474 and DTLS/SRTP. >=20 > Why were we trying to change it to protect something else? Well, for one, you can get identity in signaling and identity in media usin= g DTLS/SRTP *without* using RFC-4474 as currently defined. We're trying to= get it to NOT protect things that don't need to be protected for identity = to be attained. -hadriel From christer.holmberg@ericsson.com Tue Mar 31 06:12:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598703A69E3 for ; Tue, 31 Mar 2009 06:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.797 X-Spam-Level: X-Spam-Status: No, score=-5.797 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaQqRFwoykoV for ; Tue, 31 Mar 2009 06:12:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0EEB93A68F0 for ; Tue, 31 Mar 2009 06:12:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0DD2F188549; Tue, 31 Mar 2009 14:38:00 +0200 (CEST) X-AuditID: c1b4fb3e-aa7b2bb000006d6d-51-49d20ea7c835 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B2497160010; Tue, 31 Mar 2009 14:37:59 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 14:22:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 14:22:03 +0200 Message-ID: In-Reply-To: <49D1301C.1060001@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt Thread-Index: AcmxeQd8rLqqw73NRwiV6du/cPARtAAgiqtA References: <1237953559.22543.6.camel@victoria-pingtel-com.us.nortel.com> <49CD34EB.6010605@nostrum.com><49D0F957.7070001@cisco.com> <49D1301C.1060001@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Hadriel Kaplan" X-OriginalArrivalTime: 31 Mar 2009 12:22:04.0867 (UTC) FILETIME=[4D4E8930:01C9B1FB] X-Brightmail-Tracker: AAAAAA== Cc: SIP , Adam Roach Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 13:12:15 -0000 Hi, I think Hadriel's proposal is fine. Regards, Christer=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 30. maaliskuuta 2009 23:48 > To: Hadriel Kaplan > Cc: SIP; Adam Roach > Subject: Re: [Sip] I-D Inaction:=20 > draft-kaplan-sip-secure-call-id-00.txt >=20 >=20 >=20 > Hadriel Kaplan wrote: > > What's non-backward-compatible about it? The text would=20 > say a UAC should generate a call-id without the IP/host=20 > (which is completely in-line with 3261), and that a UAS must=20 > continue to accept a call-id with ip/host. >=20 > OK. I thought you were proposing to go further. >=20 > What you say above here seems fine. (But of course some won't=20 > implement SHOULD either.) >=20 > Thanks, > Paul >=20 > > I'll remove the ABNF change piece since people are worried=20 > that may affect backwards compatibility, due to a future=20 > strict-compliance parser checking for this update's ABNF and=20 > rejecting legacy 3261 ABNF. So this update would only affect=20 > the normative text and not the ABNF. > >=20 > > -hadriel > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, March 30, 2009 12:55 PM > >> To: Hadriel Kaplan > >> Cc: Adam Roach; SIP > >> Subject: Re: [Sip] I-D Inaction:=20 > >> draft-kaplan-sip-secure-call-id-00.txt > >> > >> Hadriel, > >> > >> I understand your logic. BUT are we agreed that we should=20 > be making=20 > >> non-backward-compatible normative changes to 3261 (or any=20 > of the key > >> RFCs) for reasons other than correcting out and out errors and=20 > >> ambiguities? Seems like that is the start of SIP/3.0. > >> > >> Paul > >> > >> Hadriel Kaplan wrote: > >>> Yeah I've been thinking about what you said the other day about=20 > >>> this, > >> and I think I understand your point, but I still think=20 > MUST's and an=20 > >> update to 3261 would be good, for the following reasons: > >>> 1) We really should want to change 3261 to say MUST NOT put an ip- > >> address/hostname in the call-id. Really in 20/20=20 > hindsight I don't=20 > >> think it should have had one to begin with. > >>> 2) It's easier for customers to force vendors to do something if=20 > >>> there's > >> a MUST statement, standards-track RFC, vs. an informational=20 > >> recommendation/should. > >>> 3) Endpoint UAC vendors should do it *before* getting=20 > deployed and=20 > >>> being > >> told by customers to change after-wards. Specifically I'm=20 > thinking=20 > >> about vendors who don't attend IETF and aren't that up-to-speed on=20 > >> all the nuances and such. An update to 3261 with=20 > normative mandatory=20 > >> language is clearer, I think. > >>> -hadriel > >>> > >>> > >>>> -----Original Message----- > >>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>> Sent: Friday, March 27, 2009 4:20 PM > >>>> > >>>> Which is why an informational draft explaining the problem is=20 > >>>> useful, while a normative document... not quite so much. > >>>> > >>>> Tell UACs: "If you include machine names in your=20 > Call-IDs, B2BUAs=20 > >>>> will have reason to change them." There's no MUST or=20 > MUST NOT here,=20 > >>>> just an explanation of rationale. > >>>> > >>>> Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do > >> everyone > >>>> a favor by not changing them, because it allows proper=20 > correlation=20 > >>>> of related transactions an dialogs." Again, no MUST; no=20 > MUST NOT.=20 > >>>> Just cause and effect. > >>>> > >>>> Then see if people want to play nice. The market will sort out if > >> that's > >>>> valuable or not. > >>>> > >>>> /a > >>> _______________________________________________ > >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 From pkyzivat@cisco.com Tue Mar 31 06:14:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890863A679C for ; Tue, 31 Mar 2009 06:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmzRDS9ZTq2a for ; Tue, 31 Mar 2009 06:14:08 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BA3123A67FC for ; Tue, 31 Mar 2009 06:14:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,453,1233532800"; d="scan'208";a="164307258" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2009 13:15:07 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2VDF75p003608; Tue, 31 Mar 2009 09:15:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2VDF796021403; Tue, 31 Mar 2009 13:15:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 09:15:07 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 09:15:06 -0400 Message-ID: <49D21757.4090900@cisco.com> Date: Tue, 31 Mar 2009 09:15:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2009 13:15:06.0779 (UTC) FILETIME=[B5DFC6B0:01C9B202] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1906; t=1238505307; x=1239369307; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20 |To:=20Dean=20Willis=20; bh=Oku2VNqlsEDoFyWeybmEpVaG1IpLgxFrnNg0mJw3qmk=; b=F2ta0BGRVLsvwcxVrZLb28hHvfc6u5R4rvo0u9YClhBVMNc2Vk1MTpCHue uFePXku0vZUJ+2gz4+FZRK7jr5XnglTqOW+vqfD53q9yWYNrTrqn02KaMAL2 FeNGEA2RXl; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 13:14:09 -0000 Hans beat me to it with his reply - if there is more than one media stream (e.g. audio/video), and they come from different sources, then what to you display? Dean says these and the signaling identity should match. Modulo the problems we are trying to solve with intermediaries, that will be the situation in the majority of cases. But the general case is: - one, none, or maybe more than one, identity for the signaling - one, none, (or maybe more than one?), identity for each media stream With that jumble of stuff you need to decide what to present to the user. If all are the same then no problem. If you have a UI that permits display of them all, then no problem. (Except user confusion.) But if there is disagreement among the sources and you can only present one, then do you: pick one, or pick none? At the moment that seems to be a common case. We may be able to get some sort of identity for one of these, but can't verify that it applies to all (where "all" usually means signaling + audio) and we can at most display one. Thanks, Paul Dean Willis wrote: > > On Mar 30, 2009, at 8:03 PM, Jiri Kuthan wrote: >> >> There is a timing aspect in favor of placing identity in signaling -- >> I would like to know whose call is ringing before I answer (if I do). > > So, we need identity in signaling, we need identity in media, and we > need the two identity expressions to match. > > That's what we get with RFC 4474 and DTLS/SRTP. > > Why were we trying to change it to protect something else? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From HKaplan@acmepacket.com Tue Mar 31 06:26:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BABA28C11E for ; Tue, 31 Mar 2009 06:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12MYPMq7giiV for ; Tue, 31 Mar 2009 06:26:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1476D28C118 for ; Tue, 31 Mar 2009 06:26:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 31 Mar 2009 09:27:52 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Mar 2009 09:27:51 -0400 From: Hadriel Kaplan To: Dean Willis Date: Tue, 31 Mar 2009 09:27:50 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmxZAJoNdevhMAuSGyfg0FeqAQLEwAnRPzw Message-ID: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> In-Reply-To: <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List , Francois Audet , SIP, Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 13:26:59 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, March 30, 2009 2:18 PM > To: Hadriel Kaplan >=20 > RFC 4474 can be used end to end. It all depends on which cert is used > to sign the identity, where that signing occurs, and where it gets > checked. For stupid legacy phones, it can be signed and checked at > middleboxes operating under some level of transitive trust. For > smarter devices, it happens in the endpoint. Ummm.... nafaik. If your AoR is of the form user@domain.com, then even if = your UA endpoint has a cert and signs the request, any middlebox which has = a cert for "domain.com", or "*.domain.com", can willy-nilly replace your si= gnature and do lawful interception. =20 > Signing and checking at the endpoint, coupled with the DTLS > fingerprint check. enables end-to-end verification of media integrity > and privacy. Once you start ripping these signatures out in the middle > of the network and replacing them, we have lost this absolutely > critical property. If transit providers even think it MIGHT be > reasonable to rip out the signatures, then we have lost the key > functionality. Removing signatures MUST BE FORBIDDEN. Adding new ones > might be ok. I don't think anyone wants to remove signatures. (of course mandating they= don't get removed is like mandating to set the evil bit if you're bad :) -hadriel From HKaplan@acmepacket.com Tue Mar 31 07:26:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD2C3A69F8 for ; Tue, 31 Mar 2009 07:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK1Ibnrjjf+a for ; Tue, 31 Mar 2009 07:26:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EED243A6A07 for ; Tue, 31 Mar 2009 07:26:03 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 31 Mar 2009 10:27:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Mar 2009 10:27:01 -0400 From: Hadriel Kaplan To: SIP List Date: Tue, 31 Mar 2009 10:26:51 -0400 Thread-Topic: secure-call-id vs. session-id Thread-Index: AcmyDLvC0gBteK6ySpexQVS0H8pDeQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Sip] secure-call-id vs. session-id X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 14:26:05 -0000 Howdy, Several people asked me after the meeting about why we would need a session= -id if people just implemented secure-call-id. Clearly I didn't articulate= it well enough, so here goes another try... ISTM, there are numerous "types" of B2BUA's in the World. Some of those B2= BUA's replace the Call-ID for a single reason: security/privacy, because th= e Call-ID had an IP/host in it. For example SBC's are of such a type, typi= cally. Using a secure-call-id should remove the incentive they have for re= placing it, which will improve scenarios for dialog-matching in out-of-dial= og requests. =20 There are also other B2BUA types, which replace the Call-ID for different r= easons. IP-PBX's, App-Servers, SoftSwitches, etc., I would put in that cam= p. I don't know why they replace the Call-ID, but clearly their designers = feel they need to. It may just be for strict compliance with RFC-3261, whi= ch may well be the right thing to do for their case. I believe the designe= rs of those devices fully expect that the out-of-dialog request reaches the= m, and that it's their Call-ID that is in it. They just didn't expect *oth= er* B2BUA's to be in the path, such as SBC's. So the secure-call-id is to provide a better path forward for B2BAU's which= only change the call-id for the privacy reason. =20 For troubleshooting purposes, however, that's not enough. People want to c= orrelate the session as it crosses as many B2BUA's as possible in their log= s/monitoring-equipment, and thus the session-id draft. -hadriel From L.Liess@telekom.de Tue Mar 31 08:07:46 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9C128C103 for ; Tue, 31 Mar 2009 08:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKTtrYYeyrrz for ; Tue, 31 Mar 2009 08:07:45 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 4D3243A6D7A for ; Tue, 31 Mar 2009 08:07:44 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 31 Mar 2009 17:08:24 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 17:08:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 17:08:22 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A002CD83CC@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Sip] secure-call-id vs. session-id thread-index: AcmyDLvC0gBteK6ySpexQVS0H8pDeQAAUPxg References: From: To: , X-OriginalArrivalTime: 31 Mar 2009 15:08:23.0969 (UTC) FILETIME=[8950A910:01C9B212] Subject: Re: [Sip] secure-call-id vs. session-id X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 15:07:46 -0000 Another reason for the session-ID is that, different from the secure-call-id, the mechanism does not rely on the end devices.=20 So service providers=20 - can use it as soon as they implement it within their B2BUAs directly connected to end devices and=20 - can use it for tracing some kind of attacks (we do not expect that people to upgrade their end devices soon) Laura=20 =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: Tuesday, March 31, 2009 4:27 PM > To: SIP List > Subject: [Sip] secure-call-id vs. session-id >=20 > Howdy, > Several people asked me after the meeting about why we would=20 > need a session-id if people just implemented secure-call-id. =20 > Clearly I didn't articulate it well enough, so here goes=20 > another try... >=20 > ISTM, there are numerous "types" of B2BUA's in the World. =20 > Some of those B2BUA's replace the Call-ID for a single=20 > reason: security/privacy, because the Call-ID had an IP/host=20 > in it. For example SBC's are of such a type, typically. =20 > Using a secure-call-id should remove the incentive they have=20 > for replacing it, which will improve scenarios for=20 > dialog-matching in out-of-dialog requests. =20 >=20 > There are also other B2BUA types, which replace the Call-ID=20 > for different reasons. IP-PBX's, App-Servers, SoftSwitches,=20 > etc., I would put in that camp. I don't know why they=20 > replace the Call-ID, but clearly their designers feel they=20 > need to. It may just be for strict compliance with RFC-3261,=20 > which may well be the right thing to do for their case. I=20 > believe the designers of those devices fully expect that the=20 > out-of-dialog request reaches them, and that it's their=20 > Call-ID that is in it. They just didn't expect *other*=20 > B2BUA's to be in the path, such as SBC's. >=20 > So the secure-call-id is to provide a better path forward for=20 > B2BAU's which only change the call-id for the privacy reason. =20 >=20 > For troubleshooting purposes, however, that's not enough. =20 > People want to correlate the session as it crosses as many=20 > B2BUA's as possible in their logs/monitoring-equipment, and=20 > thus the session-id draft. >=20 > -hadriel >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 From dean.willis@softarmor.com Tue Mar 31 09:40:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404143A6D71 for ; Tue, 31 Mar 2009 09:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjfJsTjMH5Bi for ; Tue, 31 Mar 2009 09:40:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6D3983A6837 for ; Tue, 31 Mar 2009 09:40:21 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2VGfHPB016523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Mar 2009 11:41:18 -0500 Message-Id: <0740D592-CA27-442D-AA00-59E7391DA570@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 11:41:11 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP List Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 16:40:22 -0000 On Mar 31, 2009, at 7:55 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Jonathan Rosenberg >> Sent: Monday, March 30, 2009 5:26 PM >> >> Consider this litmus test: >> If the signaling actually came from Mary (perhaps as a third >> party), but >> the media goes/comes to/from Bob, who should appear on the caller >> ID? I >> say - Bob. > > So what does 10.0.200.6:45001 mean to you? Bob or Mary? It means "Not Dean's home phone, which I know uses a 192 address . . ." If I knew Bob and Mary well, I might have a clue there too. Not perfect, but better than nothing. Enough better than nothing to bother with? I don't know. I'd like to hear Jon's take on that. -- Dean From dean.willis@softarmor.com Tue Mar 31 09:42:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6813E28C171 for ; Tue, 31 Mar 2009 09:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKcaoUUFYEkC for ; Tue, 31 Mar 2009 09:42:04 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8EBC228C167 for ; Tue, 31 Mar 2009 09:42:04 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2VGgwuC016545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Mar 2009 11:43:00 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 11:42:53 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> X-Mailer: Apple Mail (2.930.3) Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 16:42:05 -0000 On Mar 31, 2009, at 8:02 AM, Hadriel Kaplan wrote: > > Well, for one, you can get identity in signaling and identity in > media using DTLS/SRTP *without* using RFC-4474 as currently > defined. We're trying to get it to NOT protect things that don't > need to be protected for identity to be attained. umm, I believe RFC 4474 is what correlates the identity-in-media with the identity-in-signaling. The media identity expression is not particularly useful without its correlation to signaling and thence to a "human readable" identity expression. -- Dean From HKaplan@acmepacket.com Tue Mar 31 09:50:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24ABD28C177 for ; Tue, 31 Mar 2009 09:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmn9otStlCqF for ; Tue, 31 Mar 2009 09:50:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3F8C428C170 for ; Tue, 31 Mar 2009 09:50:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 31 Mar 2009 12:51:56 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Mar 2009 12:51:53 -0400 From: Hadriel Kaplan To: Dean Willis Date: Tue, 31 Mar 2009 12:51:35 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmyH9MxCjSz9x+IS3y7wABKVNwupQAAD0oA Message-ID: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <49D0FA87.8030407@iptel.org> <278488ECD81E6A42A7289E84524D2A25AC381539@EVS20.ams.gblxint.com> <0C80EA9A-C947-4DD9-9D8D-015531B15BFD@softarmor.com> <49D138D8.1040308@cisco.com> <49D16BE1.3060307@iptel.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIP List , "Uzelac, Adam" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 16:50:59 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 31, 2009 12:43 PM > To: Hadriel Kaplan >=20 > On Mar 31, 2009, at 8:02 AM, Hadriel Kaplan wrote: >=20 > > Well, for one, you can get identity in signaling and identity in > > media using DTLS/SRTP *without* using RFC-4474 as currently > > defined. We're trying to get it to NOT protect things that don't > > need to be protected for identity to be attained. >=20 > umm, I believe RFC 4474 is what correlates the identity-in-media with > the identity-in-signaling. The media identity expression is not > particularly useful without its correlation to signaling and thence to > a "human readable" identity expression. Right, sorry I should have been clearer. You had said: > That's what we get with RFC 4474 and DTLS/SRTP. > Why were we trying to change it to protect something else? I meant we don't have to use 4474 in particular to accomplish the same goal= - for example, any one of the other proposals thus far provide you that sa= me binding. Just because 4474 gets you that binding, doesn't mean another = mechanism can't, nor that changing what 4474 protects removes that binding.= We're trying to protect only what actually needs to be protected to get y= ou that binding. -hadriel From dean.willis@softarmor.com Tue Mar 31 09:51:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665783A6DA1 for ; Tue, 31 Mar 2009 09:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaEK2YI0+t+M for ; Tue, 31 Mar 2009 09:51:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6AC613A6894 for ; Tue, 31 Mar 2009 09:51:54 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n2VGqo0x016628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Mar 2009 11:52:51 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 11:52:45 -0500 References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: SIP List , Francois Audet , Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 16:51:55 -0000 On Mar 31, 2009, at 8:27 AM, Hadriel Kaplan wrote: >> >> RFC 4474 can be used end to end. It all depends on which cert is used >> to sign the identity, where that signing occurs, and where it gets >> checked. For stupid legacy phones, it can be signed and checked at >> middleboxes operating under some level of transitive trust. For >> smarter devices, it happens in the endpoint. > > Ummm.... nafaik. If your AoR is of the form user@domain.com, then > even if your UA endpoint has a cert and signs the request, any > middlebox which has a cert for "domain.com", or "*.domain.com", can > willy-nilly replace your signature and do lawful interception. Not quite. Here's how I understand it to work: If the signing cert is user@domain.com instead of domain.com, then the middlebox would need to work with a CA to mint a cert having that full name. A more typical scenario would have the middlebox use a cert with name "domain.com". The verifying node can tell the difference. But even better, with RFC 4474 I might have a connection to AT&T. I might use this connection to send a call with an Identity header for "dean.willis@softarmor.com ". If you have any relationship with me at all, you know AT&T isn't likely to have the private key for the softarmor.com CA certificate or for my private certificate issued by that CA. So AT&T isn't a MITM attacker in this scenario. Of course, if AT&T's accursed SBC strips off my RFC 4474 Identity header and inserts their own useless declamation asserting some bogus phone number then my assertion is useless, we could have a MITM, and I'm changing carriers. -- dean From HKaplan@acmepacket.com Tue Mar 31 10:14:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E6F3A68BA for ; Tue, 31 Mar 2009 10:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eNW7Hdfr1C9 for ; Tue, 31 Mar 2009 10:14:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 587933A69F3 for ; Tue, 31 Mar 2009 10:14:18 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 31 Mar 2009 13:15:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Mar 2009 13:15:13 -0400 From: Hadriel Kaplan To: Dean Willis Date: Tue, 31 Mar 2009 13:14:56 -0400 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmyISPIGCpci0ccQ8CSBIoQ6Z9dVwAACCWA Message-ID: References: <49CE8255.4000103@iptel.org> <2D5213D9-E6A2-4E76-9C85-6A2955CB7E62@softarmor.com> <0C5FC0C7-6EF1-4CCA-8FB8-D82E4B546E1B@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: List , Francois Audet , SIP, Jon Peterson Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 17:14:19 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 31, 2009 12:53 PM >=20 > Here's how I understand it to work: >=20 > If the signing cert is user@domain.com instead of domain.com, then the > middlebox would need to work with a CA to mint a cert having that full > name. A more typical scenario would have the middlebox use a cert with > name "domain.com". The verifying node can tell the difference. Not as I read 4474. The verifier will be getting a From AoR of user@domain= .com, and a cert for domain.com. That passes the verification check. The = verifier had no idea that the original cert was for "user@domain.com", beca= use it won't be downloading that cert, because the Identity-Info header wou= ld have been changed to point to the domain-wide cert, and the signature wo= uld have been recalculated using the domain-wide cert. (assuming a middlebo= x in the domain wanted to do this) Again, this isn't really a problem - presumably you trust your own domain. = I was just pointing out that the protected portion of this is domain-to-do= main, not end-to-end. Most people are fine with that, as am I. -hadriel From jdrosen@cisco.com Tue Mar 31 10:33:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536F83A6825 for ; Tue, 31 Mar 2009 10:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiPX0NoYE7t9 for ; Tue, 31 Mar 2009 10:33:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2962F3A6DAD for ; Tue, 31 Mar 2009 10:33:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,303,1235952000"; d="scan'208";a="277527442" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2009 17:31:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2VHVpMG003010; Tue, 31 Mar 2009 10:31:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2VHVpq7029943; Tue, 31 Mar 2009 17:31:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 10:31:51 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 10:31:50 -0700 Message-ID: <49D25386.40805@cisco.com> Date: Tue, 31 Mar 2009 13:31:50 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?UTF-8?B?VmljdG9yIFBhc2N1YWwgw4F2aWxh?= References: <618e24240903310306k61cefe0cwb71848b3d78a7e50@mail.gmail.com> In-Reply-To: <618e24240903310306k61cefe0cwb71848b3d78a7e50@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 31 Mar 2009 17:31:51.0014 (UTC) FILETIME=[93838060:01C9B226] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3226; t=1238520711; x=1239384711; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Media=20vs=20Signaling=20identity=20(wa s=20Re=3A=20[Sip]=20francois'=20comments=0A=20and=20why=20=0 9RFC4474=20not=20used=20in=20the=20field) |Sender:=20; bh=vJclpONsIuPlNRzeLGnRiAP9x3rW+v4/Knf1eV3/g/o=; b=ja6p+lMRfMXiLeTXlXhGEsYi0/KlCF9g6ulEjLfr1OLFpVkLqWHz2sYc7y h5TTYW9ZFpAUWKrsZl+K9x8AFQ3k3HpQGLM21PL6g2qYC6aLr33G3pslMHwa gfZ2EudHfw; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIP List Subject: Re: [Sip] Media vs Signaling identity (was Re: francois' comments and why RFC4474 not used in the field) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 17:33:15 -0000 inline: Victor Pascual Ávila wrote: > On Tue, Mar 31, 2009 at 4:12 AM, Jonathan Rosenberg wrote: >> inline: >> >> Jiri Kuthan wrote: >> >> >>>> From an end user perspective, I would assert that the most important >>>> thing is probably the media. If the callerID says, "this is bob", what is >>>> important to the user, is that when I pick up the phone and start talking, >>>> it will be Bob who hears me, and Bob that I hear. >>>> >>>> Consider this litmus test: >>>> >>>> If the signaling actually came from Mary (perhaps as a third party), but >>>> the media goes/comes to/from Bob, who should appear on the caller ID? I say >>>> - Bob. >>> There is a timing aspect in favor of placing identity in signaling -- >>> I would like to know whose call is ringing before I answer (if I do). >> You can still have that. Just don't ring the phone until early media has >> been exchanged and verified. Indeed if you were doing an ICE-style thing per >> Dan's draft, you'd get that for free. > > Are we restricting the identity assertion to telephony-like sessions? > > IMHO, identity assertion should also work for the following scenarios > (among others): > > -rfc3725, figure 1, message 1 (INVITE no SDP): Upon receipt of the > initial INVITE (note there's no session description at all), "A" > decides to authorize or reject the call based on the delivered > identifier. The identity is delivered via the signaling; you just need the media to verify it. This then enables a 'trust but verify model' - an attacker might get that initial call in but will be immediately detected and rejected when their media comes through. > > -rfc3428, figure 1, message 2 (F2): "user2" decides to answer or > ignore the message based on the delivered identifier. Its not obvious to me at this point, that we should be using exactly the same solution for MESSAGE as INVITE-based media sessions. The general idea with 'media' is that the media stream itself - the true user content - is what we are binding the identity to. User content is more difficult to modify because it is detectable by the user's themselves and disrupts the user's perception of the service. In the case of MESSAGE, it would be the content of the MESSAGE that we'd correlate the identity with. In that way, it doesn't matter what manipulations were made on any other aspect of the MESSAGE, but as long as the content is not manipulated - the identity matches. For MSRP, something akin to DTLS-SRTP could be done, since its a media stream like RTP. > > -rfc3515, example 4.1, message 1 (F1): "agent B" decides to accept or > reject the refer based on the delivered identifier This one is tricky. Arguably the thing that represents the 'user content' and should be immutable is the Refer-To URI, but I have no doubt that b2bua muck with that header too. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From fluffy@cisco.com Tue Mar 31 15:30:50 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30DB33A6997 for ; Tue, 31 Mar 2009 15:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.628 X-Spam-Level: X-Spam-Status: No, score=-106.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia04HzMDaI-U for ; Tue, 31 Mar 2009 15:30:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 62F263A6869 for ; Tue, 31 Mar 2009 15:30:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,304,1235952000"; d="scan'208";a="277700318" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2009 22:31:49 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2VMVn5H025865; Tue, 31 Mar 2009 15:31:49 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2VMVmAq009087; Tue, 31 Mar 2009 22:31:48 GMT From: Cullen Jennings To: Jiri Kuthan In-Reply-To: <49CE8255.4000103@iptel.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <49CE8255.4000103@iptel.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 16:31:47 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=940; t=1238538709; x=1239402709; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=5w3JOKDeo+eiBS5xrcVwuOGbCayXPVXKNf0asMdmnyQ=; b=op4qAQe2nNvlcgQtAClrW7tz/oO1ixgapBUIgayfrqGWlVV77i/RlfV+v5 mCJDn55fwqBCJ2i6pSyLzGVbrpdPvKWNXi5usXk8Dq4IXtUZsohpPKcYBiZr 82JvuDfD3H; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "sip@ietf.org" , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 22:30:50 -0000 On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > > I'm worried this is only a wishful thinking. While perfectly > logical, still even in such constrained setups some bizzar > ALGs do in my experience appear in the middle, change SDP > and make thus the identity worthless. The thing I keep asking is can we make a list of reason why SDP and headers get changes and in what scenarios they do this. I think it will be hard to sort how to fix this without being clear what needs to be fixed. For example, one of the things we might want to say is something like: the Phone is behind a NAT and connects to it's proxy / registrar for its' domain. That proxy/b2bua whatever mucks with IP/ports in the SDP for NAT traversal. Then we could ask if 4474 is broken in this case or not and what might be a good way of solving the problem of having UAs behind NATs. Cullen From drage@alcatel-lucent.com Tue Mar 31 18:00:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16B23A68FB for ; Tue, 31 Mar 2009 18:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2HIcBD4IkJn for ; Tue, 31 Mar 2009 18:00:26 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id B373B3A6888 for ; Tue, 31 Mar 2009 18:00:25 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3110tOl002443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Apr 2009 03:00:55 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 1 Apr 2009 03:00:54 +0200 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , Jiri Kuthan Date: Wed, 1 Apr 2009 03:00:54 +0200 Thread-Topic: [Sip] francois' comments and why RFC4474 not used in the field Thread-Index: AcmyUII0Ne7AdCx/QGiiwLyrB2auUgAFIu4g Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49CE8255.4000103@iptel.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "sip@ietf.org" , Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 01:00:26 -0000 Cullen wrote: > The thing I keep asking is can we make a list of reason why=20 > SDP and headers get changes and in what scenarios they do=20 > this. I think it will be hard to sort how to fix this without=20 > being clear what needs to be fixed. > =20 Isn't that the function of the text that was placed in section 8 of http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 If it is not, then what do you think is missing. regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Cullen Jennings > Sent: Tuesday, March 31, 2009 11:32 PM > To: Jiri Kuthan > Cc: sip@ietf.org; Francois Audet > Subject: Re: [Sip] francois' comments and why RFC4474 not=20 > used in the field >=20 >=20 > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: >=20 > > > > I'm worried this is only a wishful thinking. While=20 > perfectly logical,=20 > > still even in such constrained setups some bizzar ALGs do in my=20 > > experience appear in the middle, change SDP and make thus=20 > the identity=20 > > worthless. >=20 > The thing I keep asking is can we make a list of reason why=20 > SDP and headers get changes and in what scenarios they do=20 > this. I think it will be hard to sort how to fix this without=20 > being clear what needs to be fixed. >=20 > For example, one of the things we might want to say is=20 > something like: =20 > the Phone is behind a NAT and connects to it's proxy /=20 > registrar for its' domain. That proxy/b2bua whatever mucks=20 > with IP/ports in the SDP for NAT traversal. Then we could ask=20 > if 4474 is broken in this case or not and what might be a=20 > good way of solving the problem of having UAs behind NATs. >=20 > Cullen >=20 > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip > = From fluffy@cisco.com Tue Mar 31 18:23:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC50A3A68AB for ; Tue, 31 Mar 2009 18:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI5i1z3+ren1 for ; Tue, 31 Mar 2009 18:23:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C2C4A3A6878 for ; Tue, 31 Mar 2009 18:23:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,304,1235952000"; d="scan'208";a="149186197" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2009 01:24:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n311OARd022512; Tue, 31 Mar 2009 18:24:10 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n311O8ER026353; Wed, 1 Apr 2009 01:24:09 GMT From: Cullen Jennings To: "DRAGE, Keith (Keith)" In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-Id: <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 19:24:08 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3365; t=1238549050; x=1239413050; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20francois'=20comments=20and=20wh y=20RFC4474=20not=20used=20in=20the=20field |Sender:=20; bh=Y/QZJumqN5TplOhJRFR2BBa0nf9/RaVcTHtYYc84vzA=; b=EpCJSqdstyi3NqFyzf2fSsk5ICQNkavV5RTOG0xGHu1agbiHL0H9vY24lB Any1gxYW4nnEgLjW47Gp1kFV3gsOaOMyUIbPa1x7RPE46uL2ZbBhKy+mxTq0 6IyPE30iOG; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, Francois Audet Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 01:23:12 -0000 In all of section 8, the only reason I find of why things are changed is "For media steering purposes, B2BUAs in intermediate domains need to modify the IP address c-lines and the port in m-lines." Even this one line leaves me confused about what intermediate domains are in the deployment cases where this happens and if we are talking about email style address or e.164 style addresses. What an example is of a deployment where things like this happen and why the middle (not the end domains) do the media steering. When I ask this of example people give me, if often turns out what is really wanted is not media steering but the middle to be able to hide the fact that they actually delivered the call to a third provider for PSTN termination. Pretend 4474 does not even exist for a minute. I don't think it is unrealizable of me to ask what the problem is we are trying to solve. Saying 4474 is does not solve the problem may or may not be true but we are unlikely to have a good conversation about about what we should do until we understand what we are trying to accomplish. On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote: > Cullen wrote: > > > The thing I keep asking is can we make a list of reason why > > SDP and headers get changes and in what scenarios they do > > this. I think it will be hard to sort how to fix this without > > being clear what needs to be fixed. > > > > Isn't that the function of the text that was placed in section 8 of > > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > If it is not, then what do you think is missing. > > regards > > Keith > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Cullen Jennings > > Sent: Tuesday, March 31, 2009 11:32 PM > > To: Jiri Kuthan > > Cc: sip@ietf.org; Francois Audet > > Subject: Re: [Sip] francois' comments and why RFC4474 not > > used in the field > > > > > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > > > > > > > > I'm worried this is only a wishful thinking. While > > perfectly logical, > > > still even in such constrained setups some bizzar ALGs do in my > > > experience appear in the middle, change SDP and make thus > > the identity > > > worthless. > > > > The thing I keep asking is can we make a list of reason why > > SDP and headers get changes and in what scenarios they do > > this. I think it will be hard to sort how to fix this without > > being clear what needs to be fixed. > > > > For example, one of the things we might want to say is > > something like: > > the Phone is behind a NAT and connects to it's proxy / > > registrar for its' domain. That proxy/b2bua whatever mucks > > with IP/ports in the SDP for NAT traversal. Then we could ask > > if 4474 is broken in this case or not and what might be a > > good way of solving the problem of having UAs behind NATs. > > > > Cullen > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > From Martin.Thomson@andrew.com Tue Mar 31 20:02:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2BC3A687F for ; Tue, 31 Mar 2009 20:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+yVApoCCSjk for ; Tue, 31 Mar 2009 20:02:55 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 243933A659C for ; Tue, 31 Mar 2009 20:02:55 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_31_22_24_03 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 31 Mar 2009 22:24:03 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 22:03:49 -0500 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, 31 Mar 2009 22:03:45 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-sip-location-conveyance-13 Thread-Index: AcmydnjE5N9iFoomQHuBbrN8XhDGTw== From: "Thomson, Martin" To: , "Brian Rosen" X-OriginalArrivalTime: 01 Apr 2009 03:03:49.0177 (UTC) FILETIME=[7ABB9A90:01C9B276] Cc: sip@ietf.org Subject: [Sip] WGLC comments on draft-ietf-sip-location-conveyance-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 03:02:56 -0000 SSd2ZSBpbmNsdWRlZCBteSBsYXN0IGNhbGwgY29tbWVudHMgb24gc2lwLWxvY2F0aW9uLWNvbnZl eWFuY2UuICBVbmZvcnR1bmF0ZWx5LCB0aGlzIGlzIGEgbGVuZ3RoeSBlbWFpbC4NCg0KVGhlIGJ1 bGsgb2YgbXkgY29tbWVudHMgYXJlIG1pbm9yLiAgVGhlIGFic3RyYWN0LCB3aGljaCBpcyBxdWl0 ZSBjb25jaXNlLCBiZWxpZXMgdGhlIGVub3Jtb3VzIHNpemUgb2YgdGhpcyBkb2N1bWVudC4gIEks IGxpa2UgSGFubmVzIGJlZm9yZSBtZSwgYmVsaWV2ZSB0aGF0IHRoaXMgY291bGQgYmUgd3JpdHRl biBmb3IgbW9yZSBzdWNjaW5jdGx5IHRoYW4gaXQgaXMuDQoNCkhvd2V2ZXIsIEkgYW0gYWxzbyBv ZiB0aGUgb3BpbmlvbiB0aGF0IHdlJ3ZlIGJlZW4gc2l0dGluZyBvbiB0aGlzIGRvY3VtZW50IGZv ciB0b28gbG9uZy4gIFBlcmhhcHMgdGhpcyBkb2N1bWVudCBleGVtcGxpZmllcyB0aGUgUkFJIHdv ZXMuICBJdCBuZWVkcyB0byBiZSBwdWJsaXNoZWQsIGFuZCBJIGhhdmUgdmVyeSBmZXcgc3Vic3Rh bnRpYWwgY29uY2VybnMgd2l0aCB0aGUgdGVjaG5pY2FsIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50 LiAgQXQgdGhpcyBzdGFnZSwgSSB3b3VsZCByYXRoZXIgaGF2ZSBhIHBvb3IgZG9jdW1lbnQgcHVi bGlzaGVkIHRoYW4gaGF2ZSB0byB3YWl0IGFub3RoZXIgeWVhciBmb3IgYSBnb29kIGRvY3VtZW50 Lg0KDQpIb3dldmVyLCB0aGUgaXRlbXMgSSd2ZSBpZGVudGlmaWVkIGFzIGlzc3VlcyBuZWVkIHRv IGJlIGFkZHJlc3NlZC4NCg0KPT1Jc3N1ZTogQXJ0aWN1bGF0ZSBHZW9sb2NhdGlvbiBoZWFkZXIg c2VtYW50aWNzDQoNClRoZSBtb3N0IGltcG9ydGFudCB0aGluZyB0aGF0IHRoaXMgZG9jdW1lbnQg bmVlZHMgdG8gZGVmaW5lIGlzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIEdlb2xvY2F0aW9uIGhlYWRl ci4gIFNlY3Rpb24gMyBnZXRzIHN0cmFpZ2h0IGludG8gdGhlICJob3ciLCBidXQgbmV2ZXIgYWN0 dWFsbHkgY2xlYXJseSBzdGF0ZXMgd2hhdCB0aGUgaGVhZGVyIG1lYW5zLiAgQSBVQSBpcyBzdXBw b3NlZCB0byBpbmZlciBfc29tZXRoaW5nXyBmcm9tIHRoZSBwcmVzZW5jZSBvZiBhIEdlb2xvY2F0 aW9uIGhlYWRlci4gIFRoZSBzZW1hbnRpY3MgYXJlIHVuc3RhdGVkLCB3aGljaCBjb3VsZCBsZWFk IHRvIGNvbmZ1c2lvbi4gIA0KDQpUaGUgcHJvYmxlbSBpcyBjb21wb3VuZGVkIGluIFNlY3Rpb24g Ni4xIHdoZW4gdGhlIGRvY3VtZW50IHRhbGtzIGFib3V0IGxvY2F0aW9uIGluZm9ybWF0aW9uIGZv ciBtdWx0aXBsZSB0YXJnZXRzIGluIHRoZSBvbmUgcmVxdWVzdC4NCg0KVGV4dCBhbG9uZyB0aGUg bGluZXMgb2YgdGhlIGZvbGxvd2luZyBpcyBuZWNlc3Nhcnk6DQoNCiAgIlRoZSBHZW9sb2NhdGlv biBoZWFkZXIgaW5kaWNhdGVzIGEgcmVzb3VyY2UgdGhhdCBpbmNsdWRlcyB0aGUgcGh5c2ljYWwg bG9jYXRpb24gb2YgdGhlIFVBIGluZGljYXRlZCBpbiB0aGUgRnJvbTogaGVhZGVyIG9mIHRoZSBt ZXNzYWdlLiINCg0KT2YgY291cnNlLCB0aGlzIHN0YXRlbWVudCBpcyBib3RoIGluY29ycmVjdCBh bmQgaW5jb21wbGV0ZS4gIFlvdSBuZWVkIHRvIGNvbnNpZGVyIGVhY2ggb2YgdGhlIFNJUCByZXF1 ZXN0cyB0byBhcnJpdmUgYXQgYSBnZW5lcmFsIGZyYW1ld29yayBmb3IgdW5kZXJzdGFuZGluZyB0 aGUgc2VtYW50aWNzIG9mIHRoZSBoZWFkZXIuICBBcyBpdCBzdGFuZHMsIHRoZSBkb2N1bWVudCBw cm92aWRlcyBubyBiYXNpcyBmb3IgZGV0ZXJtaW5pbmcgd2hhdCB0aGUgc2VtYW50aWNzIG9mIHRo ZSBoZWFkZXIgYXJlIGluLCBmb3IgaW5zdGFuY2UsIGFuIElORk8gcmVxdWVzdC4NCg0KRnVydGhl ciB0byB0aGlzLCB0aGUgdXNlIG9mIEdlb2xvY2F0aW9uIGluIGEgTk9USUZZIHJlcXVlc3QgbmVl ZHMgdG8gYmUgbWFkZSB2ZXJ5IGNsZWFyLiAgTk9USUZZIGluIHByZXNlbmNlIGhhcyB3ZWxsIGVz dGFibGlzaGVkIHNlbWFudGljcy4gIEluIG1hbnkgcmVzcGVjdHMsIEdlb2xvY2F0aW9uIGlzIG5v dCBuZWNlc3NhcnkgZm9yIE5PVElGWSwgcGFydGljdWxhcmx5IGlmIGl0IG1lYW5zIHRoYXQgdGhl cmUgYXJlIHNwZWNpYWwgY2FzZXMgcmVxdWlyZWQgaW4gZXN0YWJsaXNoaW5nIGEgY29tbW9uIHNl bWFudGljIGZvciB0aGUgaGVhZGVyLg0KDQpPbiB0aGUgc2FtZSBpc3N1ZSwgdGhlIGZvbGxvd2lu ZyBzdGF0ZW1lbnQgY291bGQgYmUgYWRkcmVzc2VkIGZvciBQVUJMSVNILCBidXQgaXMgYXZvaWRl ZCB3aXRoIHNvbWUgZGVjaWRlZGx5IHdlYXNlbGx5IHdvcmRzOg0KDQogICBEaXNjdXNzaW5nIGxv Y2F0aW9uIHVzaW5nIHRoZSBQVUJMSVNIIHJlcXVlc3QgaXMgb3V0IG9mIHNjb3BlDQogICBmb3Ig dGhpcyBkb2N1bWVudCBzaW5jZSBpdCBpcyBwYXJ0IG9mIFByZXNlbmNlLCB0aGVyZWZvcmUsIGZv cg0KICAgY29tcGxldGVuZXNzLCBUYWJsZSAxIHNob3dzIFBVQkxJU0ggaXMgdG8gc3VwcG9ydCBM b2NhdGlvbg0KICAgQ29udmV5YW5jZSB2aWEgdGhpcyBleHRlbnNpb24sIGJ1dCBpcyBub3QgZGlz Y3Vzc2VkIGZ1cnRoZXIuDQoNCkZ1cnRoZXIgcmVsYXRlZCwgSSB0aGluayB0aGF0IHRoZXJlIGFy ZSB1bnN0YXRlZCBhc3N1bXB0aW9ucyBhYm91dCB1c2Ugb2YgdGhlIGVudGl0eSBhdHRyaWJ1dGUg b2YgdGhlIFBJREYgZG9jdW1lbnQuICBJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBhcHByb3ByaWF0 ZWx5IGNvbnNpZGVycyB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgUElERiBjb3VsZCBjb250YWlu IGFuIHVubGlua2VkIHBzZXVkb255bToNCg0KICAgSG93ZXZlciwgaWYgbG9jYXRpb24gaXMgYWxy ZWFkeSBpbiBhIFNJUCByZXF1ZXN0LCBhIFNJUCBzZXJ2ZXINCiAgIFNIT1VMRCBOT1QgYWRkIGFu b3RoZXIgTGJ5UiB0aGF0IGlkZW50aWZpZXMgdGhlIHNhbWUgdGFyZ2V0IGluIHRoZQ0KICAgUElE Ri1MTyAoaW4gdGhlIDxkbTpkZXZpY2UgaWQ+IGVsZW1lbnQpIHRvIHRoZSBzYW1lIHJlcXVlc3Qu ICBUaGlzDQogICB3aWxsIGxpa2VseSBjYXVzZSBjb25mdXNpb24gYXQgdGhlIExvY2F0aW9uIFJl Y2lwaWVudCBhcyB0byB3aGljaCB0bw0KICAgdXNlLg0KDQpJIGhhdmUgYmVlbiBvcGVyYXRpbmcg b24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgYmluZGluZyBvZiBsb2NhdGlvbiB0byBpZGVudGl0 eSB3YXMgZG9uZSBpbiBTSVAuICBJIGNhbiBmb2xsb3cgdXAgd2l0aCB1c2UgY2FzZXMgYW5kIGlu Y2x1ZGUgbW9yZSBkaXNjdXNzaW9uIGFzIG5lY2Vzc2FyeS4NCg0KPT1Jc3N1ZTogV2hhdCBkb2Vz IEdlb2xvY2F0aW9uLUVycm9yIDUwMCBtZWFuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGVy cm9yIGNvZGUuDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCBJIGNvdWxkIHN1Y2Nlc3NmdWxseSBkaXN0 aW5ndWlzaCB0aGlzIGZyb20gMVhYIGVycm9ycywgZGVzcGl0ZSB0aGUgZG9jdW1lbnQgY2xhaW1p bmcgdGhhdCB0aGUgZGlmZmVyZW5jZSBpcyBzaW1wbGUgKGFub3RoZXIgdmFsdWUganVkZ2VtZW50 KS4gIEl0IGFsbW9zdCBzZWVtcyBsaWtlIGEgNFhYLg0KDQo9PUlzc3VlOiBQcm94eSBpbnNlcnRp b24NCg0KSSdkIGxpa2UgdG8gc2VlIHRoZSBkb2N1bWVudCBhbnN3ZXIgdGhpcyBxdWVzdGlvbjog IElmIGEgVUFDIGRvZXNuJ3QgdW5kZXJzdGFuZCB0aGlzIGRvY3VtZW50IGFuZCB0aGUgcHJveHkg aW5zZXJ0cyBsb2NhdGlvbiBmb3IgaXQsIHdoYXQgYmVoYXZpb3VyIGlzIGV4cGVjdGVkIGZyb20g Ym90aCBwcm94eSBhbmQgVUFDIGlmIGEgNDI0IHJlc3BvbnNlIGlzIHJlY2VpdmVkPw0KDQpUaGUg cHJveHkgY29uc3VtZXMgdGhlIEdlb2xvY2F0aW9uLUVycm9yIGhlYWRlciBhbmQgZGV0ZXJtaW5l cyB0aGF0IGl0IG5lZWRzIHRvIHNlbmQgYWdhaW4gLSBidXQgaG93IGRvZXMgaXQgZG8gdGhpcz8g IERvZXMgaXQgYWx0ZXIgdGhlIGVycm9yIGNvZGUgdG8gZm9yY2UgdGhlIFVBQyB0byByZS1zZW5k IHRoZSBmYWlsZWQgcmVxdWVzdD8gIElmIHNvLCBob3cgZG9lcyBpdCBkZXRlcm1pbmUgdGhhdCBs b2NhdGlvbiBpcyBuZWVkZWQgaW4gdGhlIHN1YnNlcXVlbnQgcmVxdWVzdD8gIE9yLCBkb2VzIHRo aXMgc2NlbmFyaW8gYWx3YXlzIHJlc3VsdCBpbiBmYWlsdXJlPw0KDQo9PU1pbm9yIFRlY2huaWNh bCBOaXRzDQoNClBsZWFzZSByZWZlcmVuY2UgUkZDIDM5ODYgZm9yIFVSSSBBQk5GLiAgTm90ZSBh bHNvIHRoYXQgYWxsIHNwZWNpZmljIFVSSSBBQk5GIGlzIGEgc3Vic2V0IG9mIHRoZSAzOTg2IEFC TkYsIHNvIHNpcC1VUkksIHNpcHMtVVJJLCBwcmVzLVVSSSBhbmQgY2lkLXVybCBhcmUgcmVkdW5k YW50ICh5ZXMsIHRoaXMgY29tbWVudCBoYXMgYmVlbiBtYWRlIGFuZCBpZ25vcmVkIHByZXZpb3Vz bHkpLg0KDQpXaGF0IGJlbmVmaXQgZG9lcyB0aGUgZm9sbG93aW5nIHJlc3RyaWN0aW9uIHByb3Zp ZGU/DQoJDQogICBQbGFjZW1lbnQgb2YgdGhlICJyb3V0aW5nLWFsbG93ZWQiIHBhcmFtZXRlciwg d2hlbg0KICAgcHJlc2VudCwgTVVTVCBiZSB0aGUgbGFzdCBoZWFkZXIgdmFsdWUgaW4gdGhlIEdl b2xvY2F0aW9uIGhlYWRlci4NCg0KUmVxdWlyaW5nIHBvc2l0aW9uYWwgc2lnbmlmaWNhbmNlIG9u IGhlYWRlciBwYXJhbWV0ZXJzIG9ubHkgbGVhZHMgdG8gbW9yZSBjb21wbGljYXRlZCBpbXBsZW1l bnRhdGlvbnMuICBJZiBsb2NhdGlvbiBjYW4gYmUgaW5zZXJ0ZWQgYWxvbmcgdGhlIHBhdGgsIGFu ZCB0aGF0IGluc2VydGlvbiBtdXN0IGJlIGF0IHRoZSBlbmQsIGluc2VydGlvbiBpcyBxdWlja2Vy IHdpdGhvdXQgaGF2aW5nIHRvIGZpcnN0IHJlbW92ZSB0aGlzIHBhcmFtZXRlciBhbmQgcmUtYWRk IGl0IGFmdGVyLg0KDQpBbHNvIG9uICJyb3V0aW5nLWFsbG93ZWQiLCB3aHkgaXMgcHJlc2VuY2Ug b3IgYWJzZW5jZSBvZiB0aGUgdGFnIHVzZWQgdG8gaW5kaWNhdGUgeWVzIGFuZCBubywgcmF0aGVy IHRoYW4gcmVxdWlyaW5nIHZhbHVlcz8NCg0KQXZvaWQgbWFraW5nIHZhbHVlLWp1ZGdlbWVudHMs IHN1Y2ggYXM6DQoNCiAgICMxIC0gU0lQIFNlcnZlcnMgYXJlIG5vdCB0aGUgYmVzdCBTaWdodGVy cw0KDQpTdWdnZXN0IGNoYW5naW5nIHRoZSBHZW9sb2NhdGlvbi1FcnJvciAiY29kZSIgcGFyYW1l dGVyIHRvIGJlICJ0ZXh0IiB0byBtYWtlIGl0cyB1c2FnZSBjbGVhcmVyLiAgV2hhdCBhYm91dCBp MThuIGNvbmNlcm5zIG9uIHRoaXMgcGFyYW1ldGVyOyBkb2VzIGl0IG5lZWQgbGFuZ3VhZ2UgdGFn cz8NCg0KSSBkb24ndCBoYXZlIGEgbWVhbnMgb2YgaW50ZXJwcmV0aW5nIFRhYmxlIDEgYW5kIFRh YmxlIDIuICBUaGVyZSBpcyBubyBsZWdlbmQgaW4gUkZDIDMyNjEuICBJIGFwb2xvZ2lzZSBmb3Ig c2luZ2xpbmcgdGhpcyBkb2N1bWVudCBvdXQsIGJ1dCBJIGdlbmVyYWxseSBkb24ndCBkaWcgaW50 byBTSVAgSS1EcyBpbiBhbnkgZ3JlYXQgZGVwdGguICBObyBkb3VidCB0aGVyZSBpcyBzb21lIHVu c3RhdGVkIGNvbnZlbnRpb24gdGhhdCBpcyB3aWRlbHkgdW5kZXJzdG9vZC4NCg0KVGhlIGV4YW1w bGVzIHN0aWxsIGRvbid0IGNvbmZvcm0gdG8gUkZDIDU0OTEuDQoNClNlY3Rpb24gNi4xOiBhcyBl c3RhYmxpc2hlZCBpbiBnZW9wcml2LWxieXItcmVxdWlyZW1lbnRzLCBhbiBMUyBpcyB0aGUgZW50 aXR5IHRoYXQgc2VydmVzIGEgbG9jYXRpb24gVVJJLiAgRm9sbG93aW5nIG9uIGZyb20gdGhhdCwg dGhlIExvY2F0aW9uIEdlbmVyYXRvciBpc24ndCBpbnZvbHZlZCBpbiBjb250cm9sIG9mIGFueSBz b3J0Lg0KDQpJIGNhbid0IHNlZSBob3cgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgbWFrZXMgc2Vu c2U6DQoNCiAgIFVzZSBvZiBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZXMgaXMgaW5hcHByb3ByaWF0 ZSBmb3IgdXNlIGluDQogICBwcm90ZWN0aW5nIGEgUElERiwgYXMgdGhlIHNlbmRlciBkb2VzIG5v dCBoYXZlIGEgc2VjdXJlIGlkZW50aXR5IG9mDQogICB0aGUgcmVjaXBpZW50Lg0KDQpVc2UgKG9y IG5vdCkgb2Ygc2VsZi1zaWduZWQgY2VydGlmaWNhdGVzIGdlbmVyYWxseSBsZWFkcyB0byBpc3N1 ZXMgcmVnYXJkaW5nIHRydXN0IGFuY2hvcnMsIHNvIHRoaXMgc3RhdGVtZW50IGFsbW9zdCBtYWtl cyBzZW5zZS4gIEhvd2V2ZXIsIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHByb3RlY3Rpb24gaXMg YmVpbmcgc291Z2h0IGhlcmUuICANCg0KSWYgdGhpcyBzdGF0ZW1lbnQgaXMgaW50ZW5kZWQgdG8g YWRkcmVzcyB0aGUgaXNzdWUgd2hlcmUgdGhlIFVBQyBkb2Vzbid0IGtub3cgdGhlIHVsdGltYXRl IHJlY2lwaWVudCBvZiB0aGUgcmVxdWVzdCwgdGhlbiB0aGUgaXNzdWUgaXMgZGlmZmVyZW50LiAg SW4gdGhpcyBjYXNlLCB0aGUgaXNzdWUgaXMgcmVsYXRlcyB0byB3aGV0aGVyIGRhdGEgY2FuIGJl IGVuY3J5cHRlZCBmb3IgdGhlIHJlY2lwaWVudC4NCg0KSSBkb24ndCB0aGluayB0aGF0IDIxMTkg bGFuZ3VhZ2UgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50Og0KDQog ICBUaGUgVUFTIGlzIG5vdCBSRVFVSVJFRCB0byBkZXJlZmVyZW5jZSB0aGUgTGJ5UiBpZg0KICAg aXQgZG9lcyBub3Qgd2FudCB0byAoYnkgY29uZmlndXJhdGlvbiBvciB1c2VyIGNob2ljZSkuDQoN ClRoZSBzYW1lIGdvZXMgZm9yIHRoZSBzdGF0ZW1lbnQgdGhhdCBmb2xsb3cgdGhpcy4NCg0KSXMg dGhpcyBhIHJlY29tbWVuZGF0aW9uIGJ5IHN0ZWFsdGg/DQoNCiAgIFRoaXMgZG9jdW1lbnQgZ2l2 ZXMgbm8gZ3VpZGFuY2Ugd2hpY2ggU0lQDQogICByZXF1ZXN0IHRvIHVzZSwgYnV0IFNJUCBNRVNT QUdFIGlzIGEgdmlhYmxlIGNob2ljZS4NCg0KSWYgTUVTU0FHRSBpcyB0aGUgcmlnaHQgd2F5IHRv IGluZGljYXRlIGxvY2F0aW9uLCB0aGVuIHNheSBpdC4gIE9yLCBkb24ndCBtYWtlIGFueSByZWNv bW1lbmRhdGlvbi4NCg0KT24gbXVsdGlwbGUgbG9jYXRpb25zOg0KDQogICBUaGlzIGRvY3VtZW50 IHNheXMgbm90aGluZyBhYm91dCB3aGF0IGEgTG9jYXRpb24gUmVjaXBpZW50IGRvZXMgd2l0aA0K ICAgbW9yZSB0aGFuIG9uZSAnZ29vZCcgbG9jYXRpb25WYWx1ZSBpbiBhIHJlcXVlc3QgKGkuZS4s IHdoaWNoIHRvDQogICBjaG9vc2UgdG8gdXNlKS4gIFRoaXMgc2NlbmFyaW8gTUFZIGJlIGFkZHJl c3NlZCBpbiBhIGZ1dHVyZSBlZmZvcnQuDQoNClRoaXMgaXNuJ3QgYSBoYXJkIHByb2JsZW0gdG8g c29sdmUuICBJIGRvbid0IHNlZSBhIG5lZWQgdG8gZGVmZXIgdGhpcyBkZWNpc2lvbi4gIFBpY2sg YW4gYW5zd2VyLiAgSWYgaXQgdHVybnMgb3V0IHRvIGJlIHRoZSB3cm9uZyBvbmUsIHRoZW4gdGhh dCdzIG9rLCB0aGUgZnV0dXJlIGVmZm9ydCBjYW4gZml4IGl0LiAgQmV0dGVyIHRvIHBpY2sgb25l IGFuZCBiZSB3cm9uZyB0aGFuIGxlYXZlIGl0IHVuc3BlY2lmaWVkIHNvIHRoYXQgd2UgZ2V0IGlu dGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMuDQoNCk9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgU0lQIGlz IHRoZSBvbmx5IGRlcmVmZXJlbmNlIHByb3RvY29sOg0KDQogICBBIHByb3h5IHdpc2hpbmcgdG8g ZGVyZWZlcmVuY2UgYW4gTGJ5UiBVUkkgY29udGFpbmVkIGluIGEgcmVjZWl2ZWQNCiAgIHJlcXVl c3Qgd2lsbCB1c2UgdGhlICdwcmVzZW5jZScgZXZlbnQgcGFja2FnZSBpbiBhIFNVQlNDUklCRSBy ZXF1ZXN0DQogICB0byB0aGUgVVJJLg0KDQpXaXRoIHN0YXRlbWVudHMgbGlrZSB0aGlzLCB0aGVy ZSBpcyBsaXR0bGUgcG9pbnQgaW4gYWxsb3dpbmcgb3RoZXIgcHJvdG9jb2xzLg0KDQpTZWN0aW9u IDYuMy4yIHJlZmVycyB0byBhIHByb3h5IGJlaW5nIHN1YmplY3QgdG8gYWxsIHRoZSBydWxlcyBv ZiBhIFVBUywgYW5kIHRoZW4gcmVmZXJlbmNlcyA2LjIuMSwgd2hpY2ggZGlzY3Vzc2VzIGdlb2xv Y2F0aW9uLWVycm9yIGdlbmVyYXRpb246DQoNCiAgIEZvciBwcm94aWVzIHRoYXQgcmVjZWl2ZSBh IFNJUCByZXF1ZXN0IHRoYXQgY29udGFpbnMgYSBsb2NhdGlvbg0KICAgZXJyb3IsIGVpdGhlciBp biBhIGNvbnRhaW5lZCBtZXNzYWdlIGJvZHkgb3IgYWZ0ZXIgdGhlIHByb3h5IGRvZXMgYQ0KICAg ZGVyZWZlcmVuY2Ugb2YgdGhlIExieVIgVVJJLCBhbGwgdGhlIHJ1bGVzIGFwcGxpY2FibGUgdG8g YSBVQVMgYXBwbHkNCiAgIGhlcmUgIChzZWUgU2VjdGlvbiA2LjIuMS4pLCBzaW5jZSBpbiB0aGlz IGNhc2UsIHRoZSBwcm94eSBpcw0KICAgY29uc2lkZXJlZCBhIExvY2F0aW9uIFJlY2lwaWVudC4g VGhlcmVmb3JlLCB0aGVyZSBpcyBubyByZWFzb24gdG8NCiAgIHJlc3RhdGUgdGhlbSBoZXJlLCBh bmQgcG90ZW50aWFsbHkgaGF2ZSB0aGUgdHdvIHNlY3Rpb25zIGJlDQogICBpbmNvbnNpc3RlbnQu DQoNClRoaXMgaXMgY29uZnVzaW5nLiAgRG9lcyB0aGlzIHJlbGF0ZSB0byBwcm9jZXNzaW5nIG9m IHRoZSByZXF1ZXN0PyAgR2VuZXJhdGlvbiBvZiB0aGUgZXJyb3IgKGFzIGltcGxpZWQgYnkgdGhl IHJlZmVyZW5jZSkuICBPciBpcyB0aGlzIGEgcHJpdmFjeSB0aGluZyAoaW1wbGllZCBieSB0aGUg dXNlIG9mIHRoZSBHRU9QUklWIHRlcm0gb2YgTG9jYXRpb24gUmVjaXBpZW50KT8gIElmIGl0IGRv ZXMgcmVsYXRlIHRvIGNvbnN1bXB0aW9uIG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uIGFuZCBnZW5l cmF0aW9uIG9mIDQyNCBvciBHZW9sb2NhdGlvbi1FcnJvciBoZWFkZXJzLCB0aGVuIGl0IG1pZ2h0 IG1ha2Ugc2Vuc2UgdG8gcHV0IGFsbCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhpcyBiZWhhdmlv dXIgaW4gYSBzZXBhcmF0ZSBzZWN0aW9uLg0KDQpUaGUgbGFyZ2UgcGFyYWdyYXBoIG9uIFNlY3Rp b24gOCBQYWdlIDM4IHNlZW1zIHRvIGJlIGEgcmVoYXNoIG9mIHRoZSBpc3N1ZXMgZGlzY3Vzc2Vk IGluIGRyYWZ0LWlldGYtZ2VvcHJpdi1zaXAtbG8tcmV0cmFuc21pc3Npb24gYW5kIGRyYWZ0LWll dGYtZ2VvcHJpdi1sYnlyLXJlcXVpcmVtZW50cy4gIEFzIGl0IHN0YW5kcywgdGhlIGRpc2N1c3Np b24gb24gdGhlIGRpZmZpY3VsdGllcyBhc3NvY2lhdGVkIHdpdGggZGVwbG95aW5nIGF1dGhlbnRp Y2F0aW9uIGFyZSBpbnRlcmVzdGluZywgYmlhc2VkIGFuZCBub3QgcmVsZXZhbnQgZm9yIHRoaXMg ZG9jdW1lbnQuICBCZXR0ZXIgdG8gYWRkIGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIGFuZCBi ZSBkb25lLg0KDQpTbWFsbCBjaGFuZ2UgdG8gdGhlIGZvbGxvd2luZyB0byBhbGxvdyBmb3IgZGlm ZmVyZW50IGF1dGhvcml6YXRpb24gbW9kZWxzOg0KDQogICBBY2NvcmRpbmdseSwgcG9zc2Vzc2lv biBvZiB0aGUgcmVmZXJlbmNlIHNob3VsZCBiZSBjb25zaWRlcmVkDQogICBlcXVpdmFsZW50IHRv IHBvc3Nlc3Npb24gb2YgdGhlIHZhbHVlLCBhbmQgdGhlIHJlZmVyZW5jZSBzaG91bGQgYmUNCiAg IHRyZWF0ZWQgd2l0aCB0aGUgc2FtZSBkZWdyZWUgb2YgY2FyZSBhcyB0aGUgdmFsdWUuICANCg0K cy9BY2NvcmRpbmdseS9Vbmxlc3MgYSBsb2NhdGlvbiByZWZlcmVuY2UgaXMga25vd24gdG8gYmUg cHVibGljLw0KDQo9PUVkaXRvcmlhbA0KDQpUaGlzIGRvY3VtZW50IHVzZXMgYW5kIGludmVudHMg dGVybWlub2xvZ3kgdGhhdCBpcyBpbmNvbnNpc3RlbnQgd2l0aCBHRU9QUklWIGRvY3VtZW50cy4N Cg0KVGhpcyBpcyBhIGRpZmZpY3VsdCBkb2N1bWVudCB0byByZWFkIGFuZCByZXZpZXcuICBUaGUg bG9uZ2VyIHNlY3Rpb25zIGxhY2sgc3RydWN0dXJlIGFuZCB1c2UgdmVyeSBsb25nIHBhcmFncmFw aHMgd2l0aCBsb3RzIG9mIHN5bWJvbHMsIHRlcm1pbm9sb2d5IGFuZCBwYXJlbnRoZXRpY2FsIHN0 YXRlbWVudHMuICANCg0KQXZvaWQgdXNpbmcgQUJORiBuYW1lcyBpbiB0ZXh0IHdoZXJlIEVuZ2xp c2ggd291bGQgc3VmZmljZS4gIFRoZSB3ZWFrbmVzcyBpbiB1c2luZyB0aGlzIGFwcHJvYWNoIGlz IHJldmVhbGVkIHdoZW4geW91IHBsdXJhbGlzZSB0aGVzZS4gIGxvY2F0aW9uVmFsdWUgYW5kIGxv Y2F0aW9uRXJyb3JWYWx1ZSBhcmUgdXNlZCBleHRlbnNpdmVseSBpbiB0aGlzIG1hbm5lci4NCg0K UGFnZSA4OiB3aGF0IG1ha2VzIHRoZSBoZWFkZXIgcGFyYW1ldGVycyAiaW5kZXBlbmRlbnQiPyAg QSByb2d1aXNoIGRpc3Bvc2l0aW9uIHdpdGggYSBuYXR1cmFsIGRpc3Jlc3BlY3QgZm9yIGF1dGhv cml0eT8NCg0KU29tZSBzZWN0aW9ucyBjb3VsZCByZWFsbHkgYmVuZWZpdCBmcm9tIHN1Yi1zZWN0 aW9ucy4gIFRoZSBjdXJyZW50IGRvY3VtZW50IGhhcyBhIHN0cmVhbS1vZi1jb25zY2lvdXNuZXNz IHF1YWxpdHkgdGhhdCBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gcXVpY2tseSBmaW5kIHJlbGV2YW50 IHRleHQuICBBdCBhIG1pbmltdW0sIHN1Yi1zZWN0aW9ucyBmb3IgZWFjaCBoZWFkZXIgcGFyYW1l dGVyIHdvdWxkIGJlIGEgZ3JlYXQgaGVscC4NCg0KQSBkZWdyZWUgb2YgYmlhcyBpcyBzaG93biBp biBTZWN0aW9uIDYuMSwgYXZvaWRpbmcgbWVudGlvbiBvZiBIRUxELiAgSSdtIGRlbW9uc3RyYXRp bmcgbXkgb3duIGJpYXMgYnkgbWFraW5nIHRoZSBjb21tZW50LCBidXQgSSBkb24ndCB0aGluayB0 aGF0IHRoZSBjb21tZW50IGlzIGFueSBsZXNzIHZhbGlkIGZvciBpdC4NCg0KU2VjdGlvbiA1LjEg Y29udGFpbnMgdGV4dCBhYm91dCBsb2NhdGlvbiBieSByZWZlcmVuY2UgdGhhdCBpcyByZWR1bmRh bnQgZ2l2ZW4gdGhlIHN1YmplY3Qgb2YgU2VjdGlvbiA1LjIuDQoNCi0tTWFydGluDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBm b3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxl Z2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklm IHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIN CmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1 c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== From dean.willis@softarmor.com Tue Mar 31 23:51:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976133A6B4F for ; Tue, 31 Mar 2009 23:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCMKgiLgAGsQ for ; Tue, 31 Mar 2009 23:51:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AEA5C3A6860 for ; Tue, 31 Mar 2009 23:51:54 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n316qpoY021095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2009 01:52:52 -0500 Message-Id: From: Dean Willis To: Cullen Jennings In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 01:52:46 -0500 References: <49CE8255.4000103@iptel.org> X-Mailer: Apple Mail (2.930.3) Cc: SIP List Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 06:51:55 -0000 On Mar 31, 2009, at 5:31 PM, Cullen Jennings wrote: > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote: > >> >> I'm worried this is only a wishful thinking. While perfectly >> logical, still even in such constrained setups some bizzar >> ALGs do in my experience appear in the middle, change SDP >> and make thus the identity worthless. > > The thing I keep asking is can we make a list of reason why SDP and > headers get changes and in what scenarios they do this. I think it > will be hard to sort how to fix this without being clear what needs > to be fixed. > > For example, one of the things we might want to say is something > like: the Phone is behind a NAT and connects to it's proxy / > registrar for its' domain. That proxy/b2bua whatever mucks with IP/ > ports in the SDP for NAT traversal. Then we could ask if 4474 is > broken in this case or not and what might be a good way of solving > the problem of having UAs behind NATs. > You seem to be trying to construct an argument for "why 4474 isn't broken" based on being able to transform every use case where RFC 4474 breaks to one where it doesn't, generally by mandating a different approach to solving problems (TURN vs, SDP fixup, for example). You seem to expect this to prove that RFC 4474 is fine as-is, needing no modification to its A/M signing. It might be useful to counter this with "If RFC 4474 isn't broken, why isn't it being deployed?" I expect that the answer is "because users currently expect to correct their topological issues using SBCs instead of the tools that work with 4474. You might not think they have legitimate reasons for doing it this way, but the fact remains -- that's how they do it. Technically correct or not, ordering this to flow out is likely to give you wet feet. -- Dean From dean.willis@softarmor.com Tue Mar 31 23:57:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A483A6BDE for ; Tue, 31 Mar 2009 23:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6VCpLdT1-hq for ; Tue, 31 Mar 2009 23:57:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E90F43A6BD6 for ; Tue, 31 Mar 2009 23:57:23 -0700 (PDT) Received: from [192.168.2.100] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n316wIhp021172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2009 01:58:19 -0500 Message-Id: <45D4E875-7EFC-4C32-BED8-AEC8A68D2506@softarmor.com> From: Dean Willis To: Cullen Jennings In-Reply-To: <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 01:58:12 -0500 References: <49CE8255.4000103@iptel.org> <28B7C3AA2A7ABA4A841F11217ABE78D6758061B5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <64F3519A-B08B-4D63-A93D-7B8587D66FE7@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: sip@ietf.org, Francois Audet , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 06:57:24 -0000 On Mar 31, 2009, at 8:24 PM, Cullen Jennings wrote: > > In all of section 8, the only reason I find of why things are > changed is > > "For media steering purposes, B2BUAs in intermediate domains need to > modify the IP address c-lines and the port in m-lines." > Even this one line leaves me confused about what intermediate > domains are in the deployment cases where this happens and if we are > talking about email style address or e.164 style addresses. What an > example is of a deployment where things like this happen and why the > middle (not the end domains) do the media steering. When I ask this > of example people give me, if often turns out what is really wanted > is not media steering but the middle to be able to hide the fact > that they actually delivered the call to a third provider for PSTN > termination. > I'll agree that topology hiding is a use case for port/address obfuscation that results in RFC 4474 not working, thereby preventing DTLS/SRTP key fingerprinting when topology-hiding occurs. Design alternatives include tunnels and STUN relays combined with header obfuscation and UA support for selective obfuscation for the offer. While these sorts of triggerworks might work, they're a lot more complex than just editing the SDP. -- Dean