From sip-bounces@ietf.org Tue Apr 1 09:30:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EFA28C4B6; Tue, 1 Apr 2008 09:30:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FA528C467 for ; Tue, 1 Apr 2008 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=1.493, 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 7cjw+oJkPyAT for ; Tue, 1 Apr 2008 09:30:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2359428C4B8 for ; Tue, 1 Apr 2008 09:30:19 -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 m31GUBT09403; Tue, 1 Apr 2008 16:30:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 11:30:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15DAC007@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AACyBNEAAGWVBQ References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> From: "Francois Audet" To: "Mary Barnes" , "Hans Erik van Elburg" , "Juha Heinanen" , "Christer Holmberg" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The biggest problems with History-Info (IMHO) are: - It is written so that the UAC may generate the first History-Info entry or (more typically), it's proxy will. Creates some confusion on who does what. - It's optional - The number of entries can be pruned by proxies, making the content unreliable. - The last hop (i.e., replacing with contact) is not made obvious in the list (the whole point of this discussion). - People have used it as a replacement to diversion-header, i.e., to map to ISDN redirection number information. <--- This is the biggest problem All of those could be solve by a -bis. (There are also a few minor mistakes in some of the flows). > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Tuesday, April 01, 2008 06:28 > To: Hans Erik van Elburg; Audet, Francois (SC100:3055); Juha > Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > The proper use of History-Info isn't rocket science, but it > does require careful reading of the spec and proper > implementation (i.e., I agree if you don't implement the spec > properly, then it is a mess but that can be the case for any > spec that isn't implemented properly). There are some > inaccuracies in one of Dale's examples on forking that makes > it look far more error prone and problematic than it should > be. I'll respond separately with details. > > Mary. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: Tuesday, April 01, 2008 3:07 AM > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > The point is that History-Info does not solve the problem so > something new is needed anyway. > > And proper use of History-Info is rocket science as Dale has shown. > > /Hans Erik > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: Tuesday, April 01, 2008 2:16 AM > To: Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > There are existing implementations of History-Info in the field. > > It's not rocket science. > > And I don't see why introducing something else will be > simpler. It will just be extra complexity. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Juha Heinanen > > Sent: Saturday, March 29, 2008 05:48 > > To: Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > Christer Holmberg writes: > > > > > However, I still fail to understand how Target would be more > > "complex" > > > than e.g. History-Info. > > > > christer, > > > > ANY solution for anything must be MUCH simpler than history-info, > > which is far too complex by itself. > > > > i haven't seen anyone fully implement history-info and most likely > > that is because of its complexity. if you are now going to invent > > some other mechanism that is as complex or even more > complex, it has > > no change in real world. > > > > i therefore suggest that h-i is deprecated and a replaced > by a simpler > > > mechanism. > > > > -- juha > > _______________________________________________ > > 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 > _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 1 11:12:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BA03A6C05; Tue, 1 Apr 2008 11:12:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B9D28C120 for ; Tue, 1 Apr 2008 11:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U7dmnqejiwn for ; Tue, 1 Apr 2008 11:12:14 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 0BC8B3A6A62 for ; Tue, 1 Apr 2008 11:12:13 -0700 (PDT) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 29160799; Tue, 01 Apr 2008 18:12:11 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> From: Dan York Date: Tue, 1 Apr 2008 14:12:07 -0400 To: Hadriel Kaplan X-Mailer: Apple Mail (2.753) Cc: "sip@ietf.org" , Bob Penfield Subject: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1905679208==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1905679208== Content-Type: multipart/alternative; boundary=Apple-Mail-28--1014422403 --Apple-Mail-28--1014422403 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hadriel, Nice piece of work that you and Bob did! I laughed quite a good bit throughout. Thanks for injecting some humor here, Dan On Apr 1, 2008, at 3:15 AM, Hadriel Kaplan wrote: > Greetings, > Given today's relative importance in history - being the date Swiss > farmers had their largest spaghetti crop harvest, Sweden introduced > color television, the USSR connected Kremvax to Usenet, the Alabama > state government changed the value of Pi to 3.0, and much more - we > took it upon ourselves to write up and submit a new Internet-Draft > for an update to RFC 3261 (and a bunch of other RFCs): P2P2PSIP, > a.k.a. SIP v4.0. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt > > Abstract: > This document defines a new and improved version of SIP, which > tastes great and is less filling than the previous SIP. This draft > updates all previous and future RFCs related to SIP in SIPPING, > SIMPLE, MMUSIC, BEHAVE, and so on. > > -hadriel > p.s. I apologize for the length of it - it was only 41 pages long > originally, but my co-author demanded it be expanded to 42 pages > (for obvious reasons), and thus it's a bit bloated. > > _______________________________________________ > 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 -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free --Apple-Mail-28--1014422403 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hadriel,

Nice piece of work that you and Bob did! =A0 = I laughed quite a good bit throughout.=A0

Thanks = for injecting some humor here,
Dan

On = Apr 1, 2008, at 3:15 AM, Hadriel Kaplan wrote:
Greetings,
Given today's = relative importance in history - being the date Swiss farmers had their = largest spaghetti crop harvest, Sweden introduced color television, the = USSR connected Kremvax to Usenet, the Alabama state government changed = the value of Pi to 3.0, and much more - we took it upon ourselves to = write up and submit a new Internet-Draft for an update to RFC 3261 (and = a bunch of other RFCs): P2P2PSIP, a.k.a. SIP v4.0.

A URL = for this Internet-Draft is:

Abstract:
This document = defines a new and improved version of SIP, which tastes great and is = less filling than the previous SIP.=A0= This draft updates all previous and future RFCs related to SIP = in SIPPING, SIMPLE, MMUSIC, BEHAVE, and so on.

p.s. I apologize for the length = of it - it was only 41 pages long originally, but my co-author demanded = it be expanded to 42 pages (for obvious reasons), and thus it's a bit = bloated.

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
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Build voice applications based on open = standards.




=

= --Apple-Mail-28--1014422403-- --===============1905679208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1905679208==-- From sip-bounces@ietf.org Tue Apr 1 11:19:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF58928C1D4; Tue, 1 Apr 2008 11:19:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E2C3A6A94 for ; Tue, 1 Apr 2008 11:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.973, 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 T3Z50h3zaZqS for ; Tue, 1 Apr 2008 11:19:09 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id B3B473A68A4 for ; Tue, 1 Apr 2008 11:19:09 -0700 (PDT) Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id E4D284006D; Tue, 1 Apr 2008 12:18:15 -0600 (MDT) Message-ID: <47F27C8C.9070806@stpeter.im> Date: Tue, 01 Apr 2008 12:18:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Dan York References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> In-Reply-To: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> Cc: "sip@ietf.org" , Bob Penfield Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1798467659==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1798467659== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060807030205070303060804" This is a cryptographically signed message in MIME format. --------------ms060807030205070303060804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm waiting for v6 myself... Dan York wrote: > Hadriel, > > Nice piece of work that you and Bob did! I laughed quite a good bit > throughout. > > Thanks for injecting some humor here, > Dan > > On Apr 1, 2008, at 3:15 AM, Hadriel Kaplan wrote: > >> Greetings, >> Given today's relative importance in history - being the date Swiss >> farmers had their largest spaghetti crop harvest, Sweden introduced >> color television, the USSR connected Kremvax to Usenet, the Alabama >> state government changed the value of Pi to 3.0, and much more - we >> took it upon ourselves to write up and submit a new Internet-Draft for >> an update to RFC 3261 (and a bunch of other RFCs): P2P2PSIP, a.k.a. >> SIP v4.0. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt >> >> Abstract: >> This document defines a new and improved version of SIP, which tastes >> great and is less filling than the previous SIP. This draft updates >> all previous and future RFCs related to SIP in SIPPING, SIMPLE, >> MMUSIC, BEHAVE, and so on. >> >> -hadriel >> p.s. I apologize for the length of it - it was only 41 pages long >> originally, but my co-author demanded it be expanded to 42 pages (for >> obvious reasons), and thus it's a bit bloated. >> >> _______________________________________________ >> 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 --------------ms060807030205070303060804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA0MDExODE4NTJaMCMGCSqG SIb3DQEJBDEWBBSfeUV3yg+IMmZ++o0nXVPoX8QzkjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQBqiD3mgIxsBfi8CFkmlWiTwcy3KtNNt0Aj6HU4KDUvEcq+r2wa1VEdnZ6GYE6weYvTX++l OkIp2SXCief0WxKAZn6roilxon1jlhrqU7cp0TB/My2sXlZkLrPEyAVyajFYOXSR+oVzzoaS Clheax1qOOo2Eott6qREUXb+uR2oQcf+L2BCeTLyhn6hqGW+yR1kjQrkqleVMF56YlZ6U6bV 9TFAK6uwPHk2W+OOh0b3R/AwXw16F3o19CEsKnoq8K0wtaW7wREMaj2XreVVPfzEZcczTaFb yH+siEzQmm9D172iEoCT837bEG2CLJxbL+fYNuAsDU4syj1i+dDXfMbiAAAAAAAA --------------ms060807030205070303060804-- --===============1798467659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1798467659==-- From sip-bounces@ietf.org Tue Apr 1 11:29:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C885E28C498; Tue, 1 Apr 2008 11:29:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE2B28C4F0 for ; Tue, 1 Apr 2008 11:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.032 X-Spam-Level: X-Spam-Status: No, score=-4.032 tagged_above=-999 required=5 tests=[AWL=2.567, 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 8O5AJaSPd9Ar for ; Tue, 1 Apr 2008 11:29:03 -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 F32A528C498 for ; Tue, 1 Apr 2008 11:29:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,588,1199682000"; d="scan'208";a="3713949" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Apr 2008 14:29:01 -0400 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 m31IT1HZ006635; Tue, 1 Apr 2008 14:29:01 -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 m31IT1mZ018823; Tue, 1 Apr 2008 18:29:01 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, 1 Apr 2008 14:29:01 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 14:29:00 -0400 Message-ID: <47F27F03.20703@cisco.com> Date: Tue, 01 Apr 2008 14:29:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dan York References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> In-Reply-To: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> X-OriginalArrivalTime: 01 Apr 2008 18:29:00.0857 (UTC) FILETIME=[417F0290:01C89426] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2647; t=1207074541; x=1207938541; 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]=20Enjoyable=20read...=20Re=3A=20I -D=20Action=3A=09draft-kaplan-sip-four-oh-00.txt |Sender:=20 |To:=20Dan=20York=20; bh=J1Iu/u4boCAbAfQFZxDqtzRt8hlnRQidovTndPgCDCE=; b=iDcybKQ98eqsRXhXY6Kznji/rfsdQqME6mEJS0fo6d1HQPCHSPV5kPSVAD TmwOXL3S6Y+BqsjAB+c08k5iQWv+IT6n5aaDCFQ5v/T/o6vtvV9ZERn5uxum frm1z0pydA; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org" , Bob Penfield Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org humor? I'm looking forward to cleaning up the details and getting this approved. Its about time we moved on. Paul Dan York wrote: > Hadriel, > > Nice piece of work that you and Bob did! I laughed quite a good bit > throughout. > > Thanks for injecting some humor here, > Dan > > On Apr 1, 2008, at 3:15 AM, Hadriel Kaplan wrote: >> Greetings, >> Given today's relative importance in history - being the date Swiss >> farmers had their largest spaghetti crop harvest, Sweden introduced >> color television, the USSR connected Kremvax to Usenet, the Alabama >> state government changed the value of Pi to 3.0, and much more - we >> took it upon ourselves to write up and submit a new Internet-Draft for >> an update to RFC 3261 (and a bunch of other RFCs): P2P2PSIP, a.k.a. >> SIP v4.0. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt >> >> Abstract: >> This document defines a new and improved version of SIP, which tastes >> great and is less filling than the previous SIP. This draft updates >> all previous and future RFCs related to SIP in SIPPING, SIMPLE, >> MMUSIC, BEHAVE, and so on. >> >> -hadriel >> p.s. I apologize for the length of it - it was only 41 pages long >> originally, but my co-author demanded it be expanded to 42 pages (for >> obvious reasons), and thus it's a bit bloated. >> >> _______________________________________________ >> 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 > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 sip-bounces@ietf.org Tue Apr 1 12:32:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EEE628C1CB; Tue, 1 Apr 2008 12:32:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F1C3A6BC8 for ; Tue, 1 Apr 2008 12:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=0.935, 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 FvYV4YTQF4td for ; Tue, 1 Apr 2008 12:32:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5C9FF28C38A for ; Tue, 1 Apr 2008 12:31:54 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m31JVm2Q009412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Apr 2008 14:31:49 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <47F27F03.20703@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 14:31:42 -0500 References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> <47F27F03.20703@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP List Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 1, 2008, at 1:29 PM, Paul Kyzivat wrote: > humor? > > I'm looking forward to cleaning up the details and getting this > approved. Its about time we moved on. > That's the scary part. The draft is completely implementable. I'm pretty sure it wouldn't even work all that badly, especially if we cut down a bit on the BRIMSTONE spamming. -- 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 sip-bounces@ietf.org Tue Apr 1 12:48:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432133A6F2D; Tue, 1 Apr 2008 12:48:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C5A3A6D41 for ; Tue, 1 Apr 2008 12:48:49 -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 5UWL6d5iOhIp for ; Tue, 1 Apr 2008 12:48:42 -0700 (PDT) Received: from cg.towfiq.com (mailbox.nextfort.com [207.38.48.6]) by core3.amsl.com (Postfix) with ESMTP id CF26128C5D9 for ; Tue, 1 Apr 2008 12:45:59 -0700 (PDT) Received: from [72.211.213.26] (account bayan@towfiq.com HELO [192.168.1.105]) by cg.towfiq.com (CommuniGate Pro SMTP 5.1.12) with ESMTPSA id 365985; Tue, 01 Apr 2008 12:45:58 -0700 Message-Id: <8C26F57F-276D-4401-9EA2-D948A8509BDD@towfiq.com> From: Bayan Towfiq To: Dean Willis In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 12:45:58 -0700 References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> <47F27F03.20703@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP List , Paul Kyzivat Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks Hadriel, I'm looking forward to it too! We'll get rid of the tel: confusion and the sipss: would finally solve secure SIP by providing end-to-end-TO-END security. I love it! hahaha -- Bayan Towfiq On Apr 1, 2008, at 12:31 PM, Dean Willis wrote: > > On Apr 1, 2008, at 1:29 PM, Paul Kyzivat wrote: >> humor? >> >> I'm looking forward to cleaning up the details and getting this >> approved. Its about time we moved on. >> > > That's the scary part. The draft is completely implementable. I'm > pretty sure it wouldn't even work all that badly, especially if we cut > down a bit on the BRIMSTONE spamming. > > -- > 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 _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 1 12:52:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE553A6ED9; Tue, 1 Apr 2008 12:52:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576393A6E37 for ; Tue, 1 Apr 2008 12:52:53 -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 vJUlDKXwiK2y for ; Tue, 1 Apr 2008 12:52:52 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 21FB33A6ED9 for ; Tue, 1 Apr 2008 12:52:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: sam.ganesan@motorola.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1207079561!5402413!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 11227 invoked from network); 1 Apr 2008 19:52:41 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-15.tower-153.messagelabs.com with SMTP; 1 Apr 2008 19:52:41 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m31JqexK016753 for ; Tue, 1 Apr 2008 12:52:41 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m31Jqd80020917 for ; Tue, 1 Apr 2008 14:52:39 -0500 (CDT) Received: from de01exm62.ds.mot.com (de01exm62.am.mot.com [10.176.8.107]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m31Jqcbl020899 for ; Tue, 1 Apr 2008 14:52:38 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 15:52:36 -0400 Message-ID: <0A7B3E4DF2B4484F933C26AE3DF6F74E03C00798@de01exm62.ds.mot.com> In-Reply-To: <47F27F03.20703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Enjoyable read... Re: I-DAction: draft-kaplan-sip-four-oh-00.txt thread-index: AciUJlgr0X7OTBGYTyOBfnMNHXZgQAAC5AIQ References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> <47F27F03.20703@cisco.com> From: "Ganesan Sam-W00184" To: "Paul Kyzivat" , "Dan York" X-CFilter-Loop: Reflected Cc: sip@ietf.org, Bob Penfield Subject: Re: [Sip] Enjoyable read... Re: I-DAction: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Count me in!!! Sam -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, April 01, 2008 2:29 PM To: Dan York Cc: sip@ietf.org; Bob Penfield Subject: Re: [Sip] Enjoyable read... Re: I-DAction: draft-kaplan-sip-four-oh-00.txt humor? I'm looking forward to cleaning up the details and getting this approved. Its about time we moved on. Paul Dan York wrote: > Hadriel, > > Nice piece of work that you and Bob did! I laughed quite a good bit > throughout. > > Thanks for injecting some humor here, > Dan > > On Apr 1, 2008, at 3:15 AM, Hadriel Kaplan wrote: >> Greetings, >> Given today's relative importance in history - being the date Swiss >> farmers had their largest spaghetti crop harvest, Sweden introduced >> color television, the USSR connected Kremvax to Usenet, the Alabama >> state government changed the value of Pi to 3.0, and much more - we >> took it upon ourselves to write up and submit a new Internet-Draft >> for an update to RFC 3261 (and a bunch of other RFCs): P2P2PSIP, a.k.a. >> SIP v4.0. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt >> >> Abstract: >> This document defines a new and improved version of SIP, which tastes >> great and is less filling than the previous SIP. This draft updates >> all previous and future RFCs related to SIP in SIPPING, SIMPLE, >> MMUSIC, BEHAVE, and so on. >> >> -hadriel >> p.s. I apologize for the length of it - it was only 41 pages long >> originally, but my co-author demanded it be expanded to 42 pages (for >> obvious reasons), and thus it's a bit bloated. >> >> _______________________________________________ >> 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 > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > 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 sip-bounces@ietf.org Tue Apr 1 13:01:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D073A6D98; Tue, 1 Apr 2008 13:01:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A4C3A6E9E for ; Tue, 1 Apr 2008 13:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.243 X-Spam-Level: X-Spam-Status: No, score=-4.243 tagged_above=-999 required=5 tests=[AWL=2.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 KdDudMdawwpy for ; Tue, 1 Apr 2008 13:01:02 -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 2223B3A6A14 for ; Tue, 1 Apr 2008 13:01:02 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2008 13:01:01 -0700 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 m31K11JP004830; Tue, 1 Apr 2008 13:01:01 -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 m31K11tr009304; Tue, 1 Apr 2008 20:01:01 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); Tue, 1 Apr 2008 13:00:58 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.146.228]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 13:00:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Apr 2008 15:00:56 -0500 To: Paul Kyzivat , Dan York From: "James M. Polk" In-Reply-To: <47F27F03.20703@cisco.com> References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> <47F27F03.20703@cisco.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 01 Apr 2008 20:00:58.0363 (UTC) FILETIME=[1A2F9CB0:01C89433] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3420; t=1207080061; x=1207944061; 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:=20Re=3A=20[Sip]=20Enjoyable=20read...=20Re=3A=20I -D=0A=20=20Action=3A=09draft-kaplan-sip-four-oh-00.txt |Sender:=20; bh=2yRmLV7/Q4QQiOLILFPbe4nAiaqKbWbSDwokO7j/3/E=; b=Jn+88H0rQyHzoNZbOxYgIq1uhomaOUdcltYpRwj6f1AGSoTaRJd52yW3ug sZ51Vil5GLzRACVgI7hiU9HapYEA/c6vqv2oe6IJsZ3y4ZlmdLZhLJ2iSkaG 6jxqd4GVNc; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "sip@ietf.org" , Bob Penfield Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 01:29 PM 4/1/2008, Paul Kyzivat wrote: >humor? > >I'm looking forward to cleaning up the details and getting this >approved. Its about time we moved on. last nit - it needs to explicitly deprecate all currently standardized headers by name (not just whimically mention "all others present and future are no good anymore") to reduce the last bits of potential confusion by readers - and I think this doc is done. Who's gonna call for consensus on it? > Paul > >Dan York wrote: > > Hadriel, > > > > Nice piece of work that you and Bob did! I laughed quite a good bit > > throughout. > > > > Thanks for injecting some humor here, > > Dan > > > > On Apr 1, 2008, at 3:15 AM, Hadriel Kaplan wrote: > >> Greetings, > >> Given today's relative importance in history - being the date Swiss > >> farmers had their largest spaghetti crop harvest, Sweden introduced > >> color television, the USSR connected Kremvax to Usenet, the Alabama > >> state government changed the value of Pi to 3.0, and much more - we > >> took it upon ourselves to write up and submit a new Internet-Draft for > >> an update to RFC 3261 (and a bunch of other RFCs): P2P2PSIP, a.k.a. > >> SIP v4.0. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt > >> > >> Abstract: > >> This document defines a new and improved version of SIP, which tastes > >> great and is less filling than the previous SIP. This draft updates > >> all previous and future RFCs related to SIP in SIPPING, SIMPLE, > >> MMUSIC, BEHAVE, and so on. > >> > >> -hadriel > >> p.s. I apologize for the length of it - it was only 41 pages long > >> originally, but my co-author demanded it be expanded to 42 pages (for > >> obvious reasons), and thus it's a bit bloated. > >> > >> _______________________________________________ > >> 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 > > > > -- > > Dan York, CISSP, Director of Emerging Communication Technology > > Office of the CTO Voxeo Corporation dyork@voxeo.com > > > > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > > > Build voice applications based on open standards. > > Find out how at http://www.voxeo.com/free > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 sip-bounces@ietf.org Tue Apr 1 13:28:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4E73A6EED; Tue, 1 Apr 2008 13:28:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C12128C113 for ; Tue, 1 Apr 2008 13:28:21 -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 3iNrlkDfg5+o for ; Tue, 1 Apr 2008 13:28:20 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 93FA93A6EA2 for ; Tue, 1 Apr 2008 13:28:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: sam.ganesan@motorola.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1207081690!5937431!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 31233 invoked from network); 1 Apr 2008 20:28:11 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-8.tower-153.messagelabs.com with SMTP; 1 Apr 2008 20:28:11 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m31KSAUD022769 for ; Tue, 1 Apr 2008 13:28:10 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m31KS9mZ028885 for ; Tue, 1 Apr 2008 15:28:10 -0500 (CDT) Received: from de01exm62.ds.mot.com (de01exm62.am.mot.com [10.176.8.107]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m31KS8BJ028871 for ; Tue, 1 Apr 2008 15:28:09 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 16:28:07 -0400 Message-ID: <0A7B3E4DF2B4484F933C26AE3DF6F74E03C007DD@de01exm62.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt thread-index: AciUMzoj2QmTnlfWQ+2ytlFguauphAAA3StA References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com><47F27F03.20703@cisco.com> From: "Ganesan Sam-W00184" To: , "Dean Willis" X-CFilter-Loop: Reflected Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Agenda time in Dublin..... !!!! Sam -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, April 01, 2008 4:01 PM To: Paul Kyzivat; Dan York Cc: sip@ietf.org; Bob Penfield Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt At 01:29 PM 4/1/2008, Paul Kyzivat wrote: >humor? > >I'm looking forward to cleaning up the details and getting this >approved. Its about time we moved on. last nit - it needs to explicitly deprecate all currently standardized headers by name (not just whimically mention "all others present and future are no good anymore") to reduce the last bits of potential confusion by readers - and I think this doc is done. Who's gonna call for consensus on it? > Paul > >Dan York wrote: > > Hadriel, > > > > Nice piece of work that you and Bob did! I laughed quite a good bit > > throughout. > > > > Thanks for injecting some humor here, Dan > > > > On Apr 1, 2008, at 3:15 AM, Hadriel Kaplan wrote: > >> Greetings, > >> Given today's relative importance in history - being the date Swiss > >> farmers had their largest spaghetti crop harvest, Sweden introduced > >> color television, the USSR connected Kremvax to Usenet, the Alabama > >> state government changed the value of Pi to 3.0, and much more - we > >> took it upon ourselves to write up and submit a new Internet-Draft > >> for an update to RFC 3261 (and a bunch of other RFCs): P2P2PSIP, a.k.a. > >> SIP v4.0. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt > >> > >> Abstract: > >> This document defines a new and improved version of SIP, which > >> tastes great and is less filling than the previous SIP. This draft > >> updates all previous and future RFCs related to SIP in SIPPING, > >> SIMPLE, MMUSIC, BEHAVE, and so on. > >> > >> -hadriel > >> p.s. I apologize for the length of it - it was only 41 pages long > >> originally, but my co-author demanded it be expanded to 42 pages > >> (for obvious reasons), and thus it's a bit bloated. > >> > >> _______________________________________________ > >> 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 > > > > -- > > Dan York, CISSP, Director of Emerging Communication Technology > > Office of the CTO Voxeo Corporation dyork@voxeo.com > > > > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > > > Build voice applications based on open standards. > > Find out how at http://www.voxeo.com/free > > > > > > > > > > > > > > -------------------------------------------------------------------- > > ---- > > > > _______________________________________________ > > 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 _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 1 18:19:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C233A6973; Tue, 1 Apr 2008 18:19:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECFE3A6973 for ; Tue, 1 Apr 2008 18:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AZ8MMSGhnol for ; Tue, 1 Apr 2008 18:19:20 -0700 (PDT) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 612413A67B1 for ; Tue, 1 Apr 2008 18:19:20 -0700 (PDT) Received: from rshockeyPC (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m321IFoZ006232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2008 17:18:17 -0800 From: "Richard Shockey" To: "'Dean Willis'" , "'Paul Kyzivat'" References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> <47F27F03.20703@cisco.com> In-Reply-To: Date: Tue, 1 Apr 2008 21:19:01 -0400 Message-ID: <041a01c8945f$8a3767f0$9ea637d0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciULw1xQLAqVmnUQIiH/8mXwLcAAQAL/JqA Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: 'SIP List' Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I was particularly impressed by the explicit support for RFC 3093 http://www.ietf.org/rfc/rfc3093.txt We've needed this for a long time. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Tuesday, April 01, 2008 3:32 PM > To: Paul Kyzivat > Cc: SIP List > Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip- > four-oh-00.txt > > > On Apr 1, 2008, at 1:29 PM, Paul Kyzivat wrote: > > humor? > > > > I'm looking forward to cleaning up the details and getting this > > approved. Its about time we moved on. > > > > That's the scary part. The draft is completely implementable. I'm > pretty sure it wouldn't even work all that badly, especially if we cut > down a bit on the BRIMSTONE spamming. > > -- > 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 _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 1 18:53:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E15728C0E9; Tue, 1 Apr 2008 18:53:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14243A6945; Tue, 1 Apr 2008 18:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, 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 vszwBI922c2x; Tue, 1 Apr 2008 18:53:33 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 0E0BA3A69F4; Tue, 1 Apr 2008 18:53:32 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-18-109.dsl.rcsntx.swbell.net [68.94.18.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m321rPYl007541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2008 20:53:30 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> From: Ben Campbell To: jari.urpalainen@nokia.com Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 20:53:25 -0500 X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I have reviewed draft-ietf-sip-xcapevent-01 for WGLC, and have some comments. Apologies in advance for getting this in late. General: While I do not have many major technical concerns, I think the presentation could use some work. I share Miguel's concern that the organization of section 4.1 needs work. More specifics below: Specific Comments: Section 4.1 Paragraph 2 (editorial): "Once these nodes will be created, the notification bodies will indicate their content." I find this sentence confusing. I suggest something like "If this node is later created, the notification body will indicate its content." Section 4.4, paragraph 1(clarity): "The usage of hierarchical lists and references, etc. can thus be omitted." You say that the usage of hierarchical lists and references can be omitted. Are they actually being forbidden in this context, or do you just mean to say that they are optional? If features of the resource list format are forbidden, then this draft needs normative language saying explicitly what is not to be used. If you just mean to say that they are optional, what are the interoperability issues if one device chooses to use them but the peer does not understand them? "As it is anticipated that the XCAP server will be collocated with the SIP notifier, the subscriber MAY use relative XCAP URIs." Is it the authors' intention to require this collocation? That seems to be an architectural consequence of allowing relative URIs, unless we assert that if an implementation is architected differently, it is up to the implementation to be able to dereference relative URIs. Paragraph 2(editorial): "If no Accept header is specified to a SUBSCRIBE request, the NOTIFY messages will also contain bodies in this MIME type." I am confused by the word "also" in this context--does this imply that the body in this MIME type is in addition to some other body? I think you just mean to say that the default is xcap-diff+xml if the Accept header is ommitted, but the wording is confusing. Section 4.7, first paragraph(clarity): "Once there are superfluous resource selections in the requested URI list, the notifier SHOULD NOT provide overlapping similar responses for these resources." The sentence is confusing. "Once there are..." implies that there _will_ eventually be superfuous resource selections. I think you mean to say "If there are..." "Only the resources where the authenticated user has read privilege, will be included in the XCAP-Diff format." That seems like a normative statement that needs normative language. The last half of the paragraph is hard to follow, as it intermingles three distinct ideas each worthy of its own paragraph. That is, 1) Subscriber must have read permissions to see things, 2) Subscriptions to elements that don't exist yet are still kept in case the element is created in the future, and 3) What happens if the subscriber switches event parameters in a re-subscribe. Also, have we thought about the performance and DoS implications of requiring the notifier to keep subscription state for elements that may or may not exist at some point in the future? I'm not saying there is a problem, but it raises a warning flag to me. I'm willing to believe it is okay, but it might be worth some text explaining that. Paragraph 3 (clarity): I'm not sure what the MUST applies to here--are you saying that the server MUST check for the condition you list as an example, or simply that, if the notifier chooses not to send XML-Patch-Ops patches for reasons of local policy, it MUST fall back to xcap-patching mode? Also, I suggest reversing the order of paragraphs 3 and 4, as 4 introduces the general principle, and 3 is more about corner cases. Paragraph 5 (clarity): "RFC 3265 [RFC3265] proposes utilization of a "version" attribute information to state deltas in chapter 4.4. Partial-PIDF-Notify [I-D.ietf-simple-partial-notify] requires that notifiers will not send a new request to the same dialog unless a successful response (200 OK) has been received for the last request. The latter applies also to this "xcap-diff" event package." This is confusing--you mention the version attribute but don't seem to indicate its use here. Why mention it at all, except maybe in a paragraph explaining why it wasn't chosen? OTOH, you do require the partial-pidf-notify approach--this needs some normative language, unless it is elsewhere and I missed it. section 4.8, paragraph 1 (editorial/clarity): " However, once all atomic XCAP modifications are indicated with both previous and new ETags of each resource, it is easy to chain the modification list for a document and possibly omit some of the patches based on the received ETag (with HTTP) of a document." s/"once all"/"since all" "After that the subscriber MAY send a re-subscription to start the diff "aggregation" on the server." Does this mean to imply the subscriber cannot start out with aggregation turned on? (I think this may be another case of presenting the edge case without presenting the primary use case first.) Paragraph 2: (substantive) You cannot safely use non-sequential CSeq to detect missing NOTIFY requests. For example, if the NOTIFY request is challenged by an intervening proxy, the subscriber will see non-sequential CSeq values. It may be unusual for NOTIFY to get challenged, but unless we forbid it, then we cannot depend on CSeq for this purpose. Paragraph 3 (editorial/clarity): "...look Section 5.1 of [I-D.ietf-simple-xml-patch-ops]..." s/look/see "It is hardly reasonable to signal this error to the notifier even if the error exists in the notifier process." I think there is an implication here that should be stated explicitly, that is, the subscriber does not send a non-2XX response to a NOTIFY because of an inability to apply the patch. Section 4.10 (substantive) It's not clear to me how this interacts with the "aggregation" mechanism. In particular, if the notifier has more than one change in the 5 second window, but the subscriber did not allow aggregation, how is it handled? Section 5, figure 3 (clarity): It would be nice to see this in context of an actual NOTIFY. Section 6, 2nd paragraph (nit): There is no need for a bullet list if it contains only one bullet. Section 7, Security Considerations (substantive) I think we need more here. What sort of authentication is adequate (particularly for authenticating the notifier.) Does the potential sensitive content create any need for privacy and integrity protection beyond that generically needed for SIP-Events? _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 1 19:06:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B5E28C120; Tue, 1 Apr 2008 19:06:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDAC3A6D09; Tue, 1 Apr 2008 19:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.649, 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 5jFuIWLrzn9b; Tue, 1 Apr 2008 19:06:22 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id B45C03A6945; Tue, 1 Apr 2008 19:06:21 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-18-109.dsl.rcsntx.swbell.net [68.94.18.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m3224sjQ008787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2008 21:04:58 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <4B6E5040-A282-4557-8C9B-07D442AB4EC7@estacado.net> From: Ben Campbell To: jari.urpalainen@nokia.com, jdrosen@cisco.com Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 21:04:53 -0500 X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: [Sip] WGLC review of draft-ietf-simple-xcap-diff-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org (cross posting to SIP at request of SIMPLE chairs.) Hi, I just completed a slightly belated WGLC review of draft-ietf-simple- xcap-diff-08. Caveat 1: I am absolutely the worst person in the IETF to review XML schema definitions. I hope someone who actually understands those is reviewing this draft. Caveat 2: This draft is only useful if it advances in lockstep with the xcapevent draft in SIP. IMHO, If that draft gets significant revisions as a result of the WGLC, this draft should probably wait with it, as substantive changes there could conceivable have impact here. Other than those caveats, I think this draft is ready to progress. Thanks! Ben. _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 1 22:10:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92CC43A69E5; Tue, 1 Apr 2008 22:10:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C863A69E5 for ; Tue, 1 Apr 2008 22:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=4.476, 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 496J82lw1ibw for ; Tue, 1 Apr 2008 22:10:39 -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 2C96D3A69E2 for ; Tue, 1 Apr 2008 22:10:39 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2008 22:10:38 -0700 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 m325Acm7027088; Tue, 1 Apr 2008 22:10:38 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m325AbB5011137; Wed, 2 Apr 2008 05:10:38 GMT From: Cullen Jennings To: Avasarala Ranjit-A20990 In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B05485CBC@ZMY16EXM66.ds.mot.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <750BBC72E178114F9DC4872EBFF29A5B05485CBC@ZMY16EXM66.ds.mot.com> Message-Id: <97138EB6-2EBB-434F-BB9D-8E5AC5C72745@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 22:10:19 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=569; t=1207113038; x=1207977038; 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]=20Status=20of=20draft-levy-sip-di version-08 |Sender:=20; bh=1vI734WzIQCvGgYz2zxNynR8loZtPPFBPjtdySlOwOY=; b=WdErOqoNnVYfMpdvXQGq+LQw7MkdLR/ARNICXhddVUf7XRtSbduVi+qFPy WyETQJnYMGIYaV/CUFyTETVMKnyhRowF4nXA2QgmM5Mu4D/ezgcPhdkJhwRW G3tsZCRnA0; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP List Subject: Re: [Sip] Status of draft-levy-sip-diversion-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Mar 5, 2008, at 1:06 AM, Avasarala Ranjit-A20990 wrote: > Hi all > > What is the current status of this draft? Some of the functionality was satisfied by RFC 4458. This draft is not longer being advanced. > > > > Regards > Ranjit > _______________________________________________ > 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 sip-bounces@ietf.org Tue Apr 1 23:53:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1213A68F2; Tue, 1 Apr 2008 23:53:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE063A6831 for ; Tue, 1 Apr 2008 23:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m960c5KaGlX for ; Tue, 1 Apr 2008 23:53:23 -0700 (PDT) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id B867328C4DE for ; Tue, 1 Apr 2008 23:52:42 -0700 (PDT) Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 08:52:40 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 08:52:40 +0200 Received: from [10.229.8.125] ([10.229.8.125]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 08:52:39 +0200 Message-ID: <47F34951.2010808@telecomitalia.it> Date: Wed, 02 Apr 2008 10:52:33 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: X-Enigmail-Version: 0.95.0 X-OriginalArrivalTime: 02 Apr 2008 06:52:39.0512 (UTC) FILETIME=[24497580:01C8948E] Cc: "sip@ietf.org" , Bob Penfield Subject: Re: [Sip] I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2104887474==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2104887474== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080904050307050803000805" This is a cryptographically signed message in MIME format. --------------ms080904050307050803000805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hadriel Kaplan wrote: > p.s. I apologize for the length of it - it was only 41 pages long originally, but my co-author demanded it be expanded to 42 pages (for obvious reasons), and thus it's a bit bloated. Now I'm sure: this is the answer! Lovely :-) -- Ciao, Enrico --------------ms080904050307050803000805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyOTEzMDExOVoX DTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilXiec5xWsN2DuaGvHSz4IeWJlPiP7z UnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hjh1LTYcF1WnggMZoaH/ktb6dMCHvO oYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HYLIQxqyORJ+snLSmiA7xLX1L5Gy+t W950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzclaS0SWzKMeHg3sjdI2tKxuf3eBb0v1 +XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY78X26J2y3N61DoZHYwYyNowIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCn ZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78ZIxGWKphMQ/iAAb0tuW+VdrAZpih a7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeDWCgiCKwRRemFHM1G7lWtKt6tHrfe +BCmVslPGk2aphSk2KBAFbgCiTCCAzswggKkoAMCAQICEB5MAA0NQwlT3ufR7UBbG7gwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA4MDMyOTEzMDExOVoXDTA5MDMyOTEzMDExOVowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscB8QkU/epro6Z59GpYTko0wKy8RkilX iec5xWsN2DuaGvHSz4IeWJlPiP7zUnHHF5c/51wH6PzFyhq+OZjTP50NZLyh5VBfOuyjf6Hj h1LTYcF1WnggMZoaH/ktb6dMCHvOoYCzR0J1ZtfBGmz7XuHUDiuTnbo0A16F685nBAkBh4HY LIQxqyORJ+snLSmiA7xLX1L5Gy+tW950fMs9Z3SpSQM37AMSS2S2ooZB9cotvJAgmauWzcla S0SWzKMeHg3sjdI2tKxuf3eBb0v1+XnOjz1YLyzmJjSrDwdwUarSjx8EhD9kBHdYSWxBCEY7 8X26J2y3N61DoZHYwYyNowIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQCnZkvJXyvhUJf6wectMCJ83wWcBrWW6GbDZYzCwErd8X78 ZIxGWKphMQ/iAAb0tuW+VdrAZpiha7yRIE0DMkQiKNR9v1dszgIEVO+7ebe4l02T537gZAeD WCgiCKwRRemFHM1G7lWtKt6tHrfe+BCmVslPGk2aphSk2KBAFbgCiTCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQHkwADQ1DCVPe59HtQFsbuDAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA0MDIwODUyMzNaMCMG CSqGSIb3DQEJBDEWBBT75c/sRbOu+Yat7GemoizatCTUzDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhAeTAANDUMJU97n0e1AWxu4MA0GCSqGSIb3DQEBAQUABIIBAFrXPAeSw8cO 2bscNYbkZShBz+RmXpNhegevF+78cdPvd6AzDU/KrBeY8M5zp7+rLmeLwL5jKtH2+j96F9f2 dKh+6Qz2RgnptJDKkOt45lpELRDmI5coj2F1IHrfIsoeE5NrwvW4HhUlwnYeabOF9bNqf6Dn iAXgf/RrQPOc/9a5GaCnQ53jIF6ZyWjMGKPLESAxQDiezf1gZcQuZVrwSft5YnSkYMC/pakt 1rGFi1WBwlHIjo8w4rmyV2k3McQKrnJ02ybl/3/EUXFrhxYQl1i6cROiXYubqLXR8QXYaOhp jbYt1SavXTtheBiAuez9NOCGa+2zHuq3pU4YVnhuEBYAAAAAAAA= --------------ms080904050307050803000805-- --===============2104887474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2104887474==-- From sip-bounces@ietf.org Wed Apr 2 02:51:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1029C28C43C; Wed, 2 Apr 2008 02:51:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCF128C43C for ; Wed, 2 Apr 2008 02:51:47 -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 XhVImLKfHocP for ; Wed, 2 Apr 2008 02:51:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AEF9328C3EF for ; Wed, 2 Apr 2008 02:51:46 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3C5052287E; Wed, 2 Apr 2008 11:43:17 +0200 (CEST) X-AuditID: c1b4fb3e-ae198bb000004ec0-5f-47f3553504ad Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1C67A2286E; Wed, 2 Apr 2008 11:43:17 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 11:43:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 11:43:15 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals thread-index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+Nw References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> From: "Hans Erik van Elburg" To: "Francois Audet" , "Juha Heinanen" , "Christer Holmberg" X-OriginalArrivalTime: 02 Apr 2008 09:43:16.0809 (UTC) FILETIME=[FA310390:01C894A5] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It is clearly not the same as History-Info header as has been explained in the draft and in several previous threads. It has also been explained why History-Info can not be used for this as is. A simple new header with a clear semantics which provides a clean solution to the problem is therefore not even challenged by the History-Info header. Instead you should argue why History-Info is so bloody good that we should use it for this. We just learned that it is not even usable as a diagnostic tool. Why carry a whole log of request URI rewrites around when you are only interested in the current target??? /Hans Erik -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Tuesday, April 01, 2008 6:18 PM To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals Any addition of a new header that nobody can explain properly why it's not the same as History-Info IS rocket science. It sounds like we are getting paid by the number of URI we add to SIP. > -----Original Message----- > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > Sent: Tuesday, April 01, 2008 01:07 > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > The point is that History-Info does not solve the problem so something > new is needed anyway. > > And proper use of History-Info is rocket science as Dale has shown. > > /Hans Erik > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Francois Audet > Sent: Tuesday, April 01, 2008 2:16 AM > To: Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > There are existing implementations of History-Info in the field. > > It's not rocket science. > > And I don't see why introducing something else will be simpler. It > will just be extra complexity. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Juha Heinanen > > Sent: Saturday, March 29, 2008 05:48 > > To: Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > Christer Holmberg writes: > > > > > However, I still fail to understand how Target would be more > > "complex" > > > than e.g. History-Info. > > > > christer, > > > > ANY solution for anything must be MUCH simpler than history-info, > > which is far too complex by itself. > > > > i haven't seen anyone fully implement history-info and most likely > > that is because of its complexity. if you are now going to invent > > some other mechanism that is as complex or even more > complex, it has > > no change in real world. > > > > i therefore suggest that h-i is deprecated and a replaced > by a simpler > > > mechanism. > > > > -- juha > > _______________________________________________ > > 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 sip-bounces@ietf.org Wed Apr 2 03:04:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A837728C478; Wed, 2 Apr 2008 03:04:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322E728C469; Wed, 2 Apr 2008 03:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 0SaiV1uuJuDN; Wed, 2 Apr 2008 03:04:22 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 64B3F3A6DC0; Wed, 2 Apr 2008 03:04:22 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m32A5cMt016686; Wed, 2 Apr 2008 05:06:25 -0500 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:03:59 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:03:59 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:03:59 +0300 Message-ID: <47F35A1E.4070109@nokia.com> Date: Wed, 02 Apr 2008 13:04:14 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Ben Campbell References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> In-Reply-To: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> X-OriginalArrivalTime: 02 Apr 2008 10:03:59.0357 (UTC) FILETIME=[DECECAD0:01C894A8] X-Nokia-AV: Clean Cc: Sip List , Simple WG Subject: Re: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ext Ben Campbell wrote: > Hi, > > I have reviewed draft-ietf-sip-xcapevent-01 for WGLC, and have some > comments. Apologies in advance for getting this in late. > > General: > > While I do not have many major technical concerns, I think the > presentation could use some work. I share Miguel's concern that the > organization of section 4.1 needs work. More specifics below: > right, it will be rephrased > Specific Comments: > > Section 4.1 Paragraph 2 (editorial): > > "Once these nodes will be > created, the notification bodies will indicate their content." > > I find this sentence confusing. I suggest something like "If this node > is later created, the notification body will indicate its content." > much better phrased. > Section 4.4, paragraph 1(clarity): > "The usage of hierarchical lists and > references, etc. can thus be omitted." > > You say that the usage of hierarchical lists and references > can be omitted. Are they actually being forbidden in this context, or > do you just mean to say that they are optional? If features of the > resource list format are forbidden, then this draft needs normative > language saying explicitly what is not to be used. If you just mean to > say that they are optional, what are the interoperability issues if > one device chooses to use them but the peer does not understand them? > > "As it is > anticipated that the XCAP server will be collocated with the SIP > notifier, the subscriber MAY use relative XCAP URIs." > > Is it the authors' intention to require this collocation? That seems > to be an architectural consequence of allowing relative URIs, unless > we assert that if an implementation is architected differently, it is > up to the implementation to be able to dereference relative URIs. > in practice, the sip notifier must be aware of changes made by another protocol, i.e. http in this case. If these servers (notifier & http (xcap) daemon) are separated they need some sort of immediate mechanism to signal these events. It can be done with some unspecified ways, but the most simple one is when they are running on the very same host. However, even that simplest case is pretty hard (or complex enough) to implement properly (implementation description can be a long story although you are using OSS tools, like e.g. linux with Apache + xcap_module and some decent Sip stack with all the source code), and the intention is to define only the very simplest use-case here. It is not ruled out that they were separated but that would be much, much more difficult to implement, and there are many obstacles and open issues there. So there's magic (outside the scope of this i-d) here how to map the sip-uri to the xcap-root-uri, but this, the most simple use-case is what i'd expect to be implemented (and maybe, even some minor deployment as well ;-)). Also we agreed with Miguel to be more explicit about this magic, does it sound sufficient to you ? > Paragraph 2(editorial): > > "If no Accept header is specified to a SUBSCRIBE request, the NOTIFY > messages will also contain bodies in this MIME type." > > I am confused by the word "also" in this context--does this imply that > the body in this MIME type is in addition to some other body? I think > you just mean to say that the default is xcap-diff+xml if the Accept > header is ommitted, but the wording is confusing. > right, by bad finglish. > Section 4.7, first paragraph(clarity): > > "Once there are superfluous resource > selections in the requested URI list, the notifier SHOULD NOT provide > overlapping similar responses for these resources." > > The sentence is confusing. "Once there are..." implies that there > _will_ eventually be superfuous resource selections. I think you mean > to say "If there are..." right again. > > "Only the > resources where the authenticated user has read privilege, will be > included in the XCAP-Diff format." > > That seems like a normative statement that needs normative language. > again. > The last half of the paragraph is hard to follow, as it intermingles > three distinct ideas each worthy of its own paragraph. That is, 1) > Subscriber must have read permissions to see things, 2) Subscriptions > to elements that don't exist yet are still kept in case the element is > created in the future, and 3) What happens if the subscriber switches > event parameters in a re-subscribe. I'll try to clarify it by a separation. > > > Also, have we thought about the performance and DoS implications of > requiring the notifier to keep subscription state for elements that > may or may not exist at some point in the future? I'm not saying there > is a problem, but it raises a warning flag to me. I'm willing to > believe it is okay, but it might be worth some text explaining that. good point. there are other ways to introduce DoS as well since diff-processing of many resources MAY be way too process-intensive. I'll add that in the security section. > > Paragraph 3 (clarity): > > I'm not sure what the MUST applies to here--are you saying that the > server MUST check for the condition you list as an example, or simply > that, if the notifier chooses not to send XML-Patch-Ops patches for > reasons of local policy, it MUST fall back to xcap-patching mode? the reason to drop the aggregation mode for that particular resource is that once the client have to use http, it might get out-of-sync (with "rapidly" changing resources), the rule is to be certain that it will not happen. I'll try to clarify. > > Also, I suggest reversing the order of paragraphs 3 and 4, as 4 > introduces the general principle, and 3 is more about corner cases. > ok. > Paragraph 5 (clarity): > > "RFC 3265 [RFC3265] > proposes utilization of a "version" attribute information to state > deltas in chapter 4.4. Partial-PIDF-Notify > [I-D.ietf-simple-partial-notify] requires that notifiers will not > send a new request to the same dialog unless a successful response > (200 OK) has been received for the last request. The latter applies > also to this "xcap-diff" event package." > > This is confusing--you mention the version attribute but don't seem to > indicate its use here. Why mention it at all, except maybe in a > paragraph explaining why it wasn't chosen? OTOH, you do require the > partial-pidf-notify approach--this needs some normative language, > unless it is elsewhere and I missed it. yep, this was notified by Miguel also > > > section 4.8, paragraph 1 (editorial/clarity): > > " However, > once all atomic XCAP modifications are indicated with both previous > and new ETags of each resource, it is easy to chain the modification > list for a document and possibly omit some of the patches based on > the received ETag (with HTTP) of a document." > > s/"once all"/"since all" ok. > > "After that the > subscriber MAY send a re-subscription to start the diff "aggregation" > on the server." > > Does this mean to imply the subscriber cannot start out with > aggregation turned on? (I think this may be another case of presenting > the edge case without presenting the primary use case first.) it can try to start in the aggregate mode straight away, but it may fail. So the safe way is to disable aggregation first before sync is achieved and enable it afterwards. I think I'll add something about this into those dreaded examples (in an appendix) > > > Paragraph 2: (substantive) > > You cannot safely use non-sequential CSeq to detect missing NOTIFY > requests. For example, if the NOTIFY request is challenged by an > intervening proxy, the subscriber will see non-sequential CSeq values. > It may be unusual for NOTIFY to get challenged, but unless we forbid > it, then we cannot depend on CSeq for this purpose. ok, didn't think about that at all. > > Paragraph 3 (editorial/clarity): > > "...look Section 5.1 of > [I-D.ietf-simple-xml-patch-ops]..." > > s/look/see ok. > > "It is > hardly reasonable to signal this error to the notifier even if the > error exists in the notifier process." > > I think there is an implication here that should be stated explicitly, > that is, the subscriber does not send a non-2XX response to a NOTIFY > because of an inability to apply the patch. > right. > Section 4.10 (substantive) > > It's not clear to me how this interacts with the "aggregation" > mechanism. In particular, if the notifier has more than one change in > the 5 second window, but the subscriber did not allow aggregation, how > is it handled? yep this is indeed _difficult_. Easy to write (one sentence only), but really, really hard to implement properly ;-). First off there's a SHOULD directive fortunately... I'm not 100 % sure if you mean that xcap-patching is also disabled. So there's not a big difference in this context whether you have aggregation or xcap-patching modes, since in the xcap-patching mode you will see changes e.g. from "a" to "b" to "c" with all corresponding Etags while in the aggregate mode you'll see e.g. only changes from "a" to "c" in the notification body without the intermediate state. Certainly aggregation body is smaller but it fails to show the versioning history and the diff formats differ, but the end result will be the same certainly, i.e. "c". So _if_ you obey the timer, you wait for it to expire and then send the result in both cases (and of course during this timer interval you wait for any changes in these resources, and do something relevant, e.g. store internal object states). If there's not any patching modes applied, then you should wait for the timer to expire and send appropriate actions, i.e. document(s) has either been created, modified or deleted. IIRC, in partial PIDF where we use the exact same patchings there's not a single line about this since this timer is inherited from the base PIDF package. In summary, you just don't have to do anything mysterious with timers except wait for a certain period of time. In practice, it happens to be quite a challenging task (but these specs usually _ignore_ the implementation PITA ;-)) > > Section 5, figure 3 (clarity): > > It would be nice to see this in context of an actual NOTIFY. I'll try to digest something into an appendix. That being said, the important things are bodies... > > Section 6, 2nd paragraph (nit): > > There is no need for a bullet list if it contains only one bullet. right. > > Section 7, Security Considerations (substantive) > > I think we need more here. What sort of authentication is adequate > (particularly for authenticating the notifier.) Does the potential > sensitive content create any need for privacy and integrity protection > beyond that generically needed for SIP-Events? > yep, besides DoS TLS & S/MIME recommendations some text about identity "mapping" between http & sip would be reasonable. Anything else ? THANKS Ben, Jari _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 03:08:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24C83A6EB6; Wed, 2 Apr 2008 03:08:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C48E3A6E88; Wed, 2 Apr 2008 03:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 pSUVaPEIJ0AT; Wed, 2 Apr 2008 03:08:36 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E496F28C4A1; Wed, 2 Apr 2008 03:08:11 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m32AA7BI021543; Wed, 2 Apr 2008 05:10:14 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:08:02 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:08:02 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 13:07:56 +0300 Message-ID: <47F35B0C.6010304@nokia.com> Date: Wed, 02 Apr 2008 13:08:12 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Ben Campbell References: <4B6E5040-A282-4557-8C9B-07D442AB4EC7@estacado.net> In-Reply-To: <4B6E5040-A282-4557-8C9B-07D442AB4EC7@estacado.net> X-OriginalArrivalTime: 02 Apr 2008 10:07:56.0751 (UTC) FILETIME=[6C4E3DF0:01C894A9] X-Nokia-AV: Clean Cc: Sip List , Simple WG Subject: Re: [Sip] WGLC review of draft-ietf-simple-xcap-diff-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ext Ben Campbell wrote: > (cross posting to SIP at request of SIMPLE chairs.) > > Hi, > > I just completed a slightly belated WGLC review of > draft-ietf-simple-xcap-diff-08. > > Caveat 1: I am absolutely the worst person in the IETF to review XML > schema definitions. I hope someone who actually understands those is > reviewing this draft. > well, at least these validate with ... > Caveat 2: This draft is only useful if it advances in lockstep with > the xcapevent draft in SIP. IMHO, If that draft gets significant > revisions as a result of the WGLC, this draft should probably wait > with it, as substantive changes there could conceivable have impact here. > > Other than those caveats, I think this draft is ready to progress. > > Thanks! > > Ben. > yep, these are definitely coupled anyways. thanks, Jari _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 04:52:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEF63A6E47; Wed, 2 Apr 2008 04:52:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948963A6E03 for ; Wed, 2 Apr 2008 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.959 X-Spam-Level: X-Spam-Status: No, score=-103.959 tagged_above=-999 required=5 tests=[AWL=2.640, 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 x5xEwctoL8E8 for ; Wed, 2 Apr 2008 04:52:18 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 8D2A33A6CA5 for ; Wed, 2 Apr 2008 04:52:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-203.messagelabs.com!1207137132!11879067!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22878 invoked from network); 2 Apr 2008 11:52:13 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2008 11:52:13 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m32BqH9l024224 for ; Wed, 2 Apr 2008 07:52:17 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m32BqBF8024184 for ; Wed, 2 Apr 2008 07:52:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 06:52:11 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246EDBE@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAATpZGA= References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> From: "DOLLY, MARTIN C, ATTLABS" To: "Hans Erik van Elburg" , "Francois Audet" , "Juha Heinanen" , "Christer Holmberg" Cc: sip@ietf.org Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We would prefer Target-URI as it is simpler and predictable. These are high on the evaluation criteria for operators. -----Original Message----- From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] Sent: Wednesday, April 02, 2008 5:43 AM To: Francois Audet; Juha Heinanen; Christer Holmberg Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals It is clearly not the same as History-Info header as has been explained in the draft and in several previous threads. It has also been explained why History-Info can not be used for this as is. A simple new header with a clear semantics which provides a clean solution to the problem is therefore not even challenged by the History-Info header. Instead you should argue why History-Info is so bloody good that we should use it for this. We just learned that it is not even usable as a diagnostic tool. Why carry a whole log of request URI rewrites around when you are only interested in the current target??? /Hans Erik -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Tuesday, April 01, 2008 6:18 PM To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals Any addition of a new header that nobody can explain properly why it's not the same as History-Info IS rocket science. It sounds like we are getting paid by the number of URI we add to SIP. > -----Original Message----- > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > Sent: Tuesday, April 01, 2008 01:07 > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > The point is that History-Info does not solve the problem so something > new is needed anyway. > > And proper use of History-Info is rocket science as Dale has shown. > > /Hans Erik > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Francois Audet > Sent: Tuesday, April 01, 2008 2:16 AM > To: Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > There are existing implementations of History-Info in the field. > > It's not rocket science. > > And I don't see why introducing something else will be simpler. It > will just be extra complexity. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Juha Heinanen > > Sent: Saturday, March 29, 2008 05:48 > > To: Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > Christer Holmberg writes: > > > > > However, I still fail to understand how Target would be more > > "complex" > > > than e.g. History-Info. > > > > christer, > > > > ANY solution for anything must be MUCH simpler than history-info, > > which is far too complex by itself. > > > > i haven't seen anyone fully implement history-info and most likely > > that is because of its complexity. if you are now going to invent > > some other mechanism that is as complex or even more > complex, it has > > no change in real world. > > > > i therefore suggest that h-i is deprecated and a replaced > by a simpler > > > mechanism. > > > > -- juha > > _______________________________________________ > > 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 sip-bounces@ietf.org Wed Apr 2 05:43:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56A828C566; Wed, 2 Apr 2008 05:43:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1ED28C566 for ; Wed, 2 Apr 2008 05:43:26 -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=[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 WlSUAQ6z-3qw for ; Wed, 2 Apr 2008 05:43:25 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1BC4E28C57E for ; Wed, 2 Apr 2008 05:42:54 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0A9C1222D6; Wed, 2 Apr 2008 14:36:54 +0200 (CEST) X-AuditID: c1b4fb3c-ac898bb00000193b-12-47f37de56718 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C0E2D21F7E; Wed, 2 Apr 2008 14:36:53 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 14:36:53 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 14:36:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 186402464; Wed, 2 Apr 2008 15:36:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 973E54DBBB; Wed, 2 Apr 2008 15:36:52 +0300 (EEST) Received: from n68.nomadiclab.com (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 301C34DA83; Wed, 2 Apr 2008 15:36:52 +0300 (EEST) Message-ID: <47F37DE3.9010603@ericsson.com> Date: Wed, 02 Apr 2008 15:36:51 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE2918001CEC34C@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE2918001D9F37F@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001D9F37F@DEEXC1U01.de.lucent.com> X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 02 Apr 2008 12:36:53.0187 (UTC) FILETIME=[3AD62930:01C894BE] X-Brightmail-Tracker: AAAAAA== Cc: IETF SIP List Subject: Re: [Sip] WGLC for draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0723479245==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0723479245== Content-Type: multipart/alternative; boundary="------------050700010408080505040509" This is a multi-part message in MIME format. --------------050700010408080505040509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, for me the I-D is fine as is and I have no major comments that need to be addressed by the authors. Sal DRAGE, Keith (Keith) wrote: > (As SIP WG chair) > > This WGLC ended yesterday, and as far as I can see, we have only > received one set of comments, implying that only one member of the WG > has reviewed the document. > > Two requests: > > - If you have reviewed the document, and consider it so perfect > that you have no comments, please indicate this to the list. > > - If you can find time to review the document, please send the sip > chairs a mail indicating that you are willing to do so, and when you > expect to do this by. > > Finally, if you have reviewed the document, but have not yet got around > to sending your comments, please post them as soon as possible. > > Regards > > Keith > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of DRAGE, Keith (Keith) >> Sent: Monday, March 10, 2008 11:19 PM >> To: IETF SIP List >> Subject: [Sip] WGLC for draft-ietf-sip-xcapevent-01 >> >> (As SIP WG cochair) >> >> In parallel with the WGLC on xcap-diff in the message below >> (as these are related drafts), this is to initiate a WGLC on: >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-01.txt >> >> Comments should be sent to the SIP list and to the editor by >> 31st March 2008, ie. This is a 3 week WGLC to take into >> account the overlap with the current IETF meeting. >> >> Please take some steps to indicate the severity of the >> comment (from NIT through to major technical). >> >> Obviously please follow the requirements below for comments >> on the related draft. >> >> Regards >> >> Keith >> >> >> >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Monday, March 10, 2008 10:23 PM >> To: simple mailing list >> Cc: Jari Urpalainen; sip-chairs@tools.ietf.org >> Subject: WGLC: draft-ietf-simple-xcap-diff-08 >> >> Folks - >> >> This is a Working Group Last Call for comments on >> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-08.txt >> >> The editor for draft-ietf-simple-xcap-diff and >> draft-ietf-sip- xcapevent has indicated these drafts are >> ready for WGLC. >> We're coordinating the LC time between the two working groups. >> >> Please have your comments to the editor/list by three weeks >> from today (March 31,2008). >> >> Thanks, >> >> RjS >> >> _______________________________________________ >> 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 > > --------------050700010408080505040509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

for me the I-D is fine as is and I have no major comments that need to be addressed by the authors.

Sal

DRAGE, Keith (Keith) wrote: 
(As SIP WG chair)

This WGLC ended yesterday, and as far as I can see, we have only
received one set of comments, implying that only one member of the WG
has reviewed the document.

Two requests:

-	If you have reviewed the document, and consider it so perfect
that you have no comments, please indicate this to the list. 

-	If you can find time to review the document, please send the sip
chairs a mail indicating that you are willing to do so, and when you
expect to do this by.

Finally, if you have reviewed the document, but have not yet got around
to sending your comments, please post them as soon as possible.

Regards

Keith

  
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On 
Behalf Of DRAGE, Keith (Keith)
Sent: Monday, March 10, 2008 11:19 PM
To: IETF SIP List
Subject: [Sip] WGLC for draft-ietf-sip-xcapevent-01

(As SIP WG cochair)

In parallel with the WGLC on xcap-diff in the message below 
(as these are related drafts), this is to initiate a WGLC on:

http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-01.txt 

Comments should be sent to the SIP list and to the editor by 
31st March 2008, ie. This is a 3 week WGLC to take into 
account the overlap with the current IETF meeting.

Please take some steps to indicate the severity of the 
comment (from NIT through to major technical).

Obviously please follow the requirements below for comments 
on the related draft.

Regards

Keith



-----Original Message-----
From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: Monday, March 10, 2008 10:23 PM
To: simple mailing list
Cc: Jari Urpalainen; sip-chairs@tools.ietf.org
Subject: WGLC: draft-ietf-simple-xcap-diff-08

Folks -

This is a Working Group Last Call for comments on 
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-08.txt

The editor for draft-ietf-simple-xcap-diff and 
draft-ietf-sip- xcapevent has indicated these drafts are 
ready for WGLC.
We're coordinating the LC time between the two working groups.

Please have your comments to the editor/list by three weeks 
from today (March 31,2008).

Thanks,

RjS

_______________________________________________
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

--------------050700010408080505040509-- --===============0723479245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0723479245==-- From sip-bounces@ietf.org Wed Apr 2 06:27:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F80C28C523; Wed, 2 Apr 2008 06:27:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED5A28C50D for ; Wed, 2 Apr 2008 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.994, 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 lAYugWRfLTnP for ; Wed, 2 Apr 2008 06:27:02 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id ACF4428C118 for ; Wed, 2 Apr 2008 06:27:01 -0700 (PDT) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 29641056; Wed, 02 Apr 2008 13:27:01 +0000 In-Reply-To: <041a01c8945f$8a3767f0$9ea637d0$@us> References: <2FB319C8-5072-4F0C-82AF-50F060DDC663@voxeo.com> <47F27F03.20703@cisco.com> <041a01c8945f$8a3767f0$9ea637d0$@us> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Dan York Date: Wed, 2 Apr 2008 09:26:56 -0400 To: Richard Shockey X-Mailer: Apple Mail (2.753) Cc: 'SIP List' , 'Paul Kyzivat' , 'Dean Willis' Subject: Re: [Sip] Enjoyable read... Re: I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2116671306==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2116671306== Content-Type: multipart/alternative; boundary=Apple-Mail-46--945133560 --Apple-Mail-46--945133560 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 1, 2008, at 9:19 PM, Richard Shockey wrote: > I was particularly impressed by the explicit support for RFC 3093 > > http://www.ietf.org/rfc/rfc3093.txt > > We've needed this for a long time. Which effectively defines HTTP as the new waist of the Internet hourglass, eh? (in contrast to http://tools.ietf.org/id/draft-rosenberg-internet- waist-hourglass-00.txt ) :-) Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free --Apple-Mail-46--945133560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Apr 1, 2008, at 9:19 PM, Richard Shockey = wrote:
I was particularly impressed by = the explicit support for RFC 3093


We've needed this for a long = time.

Which effectively defines HTTP as = the new waist of the Internet hourglass, = eh?


:-)
Dan

=
--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Build voice applications based on open = standards.





= --Apple-Mail-46--945133560-- --===============2116671306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2116671306==-- From sip-bounces@ietf.org Wed Apr 2 07:55:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EAB63A6966; Wed, 2 Apr 2008 07:55:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614013A6DC0; Wed, 2 Apr 2008 07:55:41 -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 r8FpvYeHSIme; Wed, 2 Apr 2008 07:55:40 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 659583A6DD7; Wed, 2 Apr 2008 07:55:40 -0700 (PDT) Received: from dialup-4.227.192.106.Dial1.Denver1.Level3.net (dialup-4.227.192.106.Dial1.Denver1.Level3.net [4.227.192.106]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id C091040053; Wed, 2 Apr 2008 08:54:34 -0600 (MDT) Message-ID: <47F39E4D.4070409@stpeter.im> Date: Wed, 02 Apr 2008 08:55:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "sip@ietf.org" , simple mailing list , XMPP Extension Discussion List Subject: [Sip] new SIP-XMPP list X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1748979953==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1748979953== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050807080508060105080102" This is a cryptographically signed message in MIME format. --------------ms050807080508060105080102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI, some folks who want to better define interworking between SIP and XMPP have started an informal discussion list. You can subscribe via either of the following URLs: http://mail.jabber.org/mailman/listinfo/sip-xmpp mailto:sip-xmpp-request@xmpp.org The intended outcome of these efforts is a full set of I-Ds that define mappings for addresses, presence, "pager mode" messages, 1-to-1 chat sessions (via MSRP on the SIP side), multiparty chat sessions (via MSRP on the SIP side and MUC on the XMPP side), multimedia sessions (via Jingle on the XMPP side), and eventually even features like file transfer, notifications, and device capabilities. We may also request a BOF at a future IETF meeting for the purpose of forming a working group or exploratory group (in accordance with RFC 5111). However, that is yet to be determined. Right now we're just hashing out some of the issues involved with interworking, so if you have an interest in the topic, feel free to join the list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms050807080508060105080102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA0MDIxNDU1MDlaMCMGCSqG SIb3DQEJBDEWBBTtlVXrj/C8mYVAyS+n/OsqR5vjOzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQB6/EpnJw5g1jUpqlcjHd6ouHqCcHCo5YADL9lrlrTZRDxs5TrVbAUNjruXLHe4J+lrFYpo p0Tz9PsALY1x4TDpnes0ZM/38ja2CBm8YlT9jkUEosUcvoxfwwfBnsDo/vzGQTk2+0CkaVhc 5MWyIg8Vmgx1xb9HtCZR8mwgcWjOvFev5plfgRXoMr+ayMwD3p8LoMqKHF2VuNbAz1syjVgH chuNLa5qBXskBnlX7fzU5TKIYd1sBaNr6j40GDDMwQck2U4Y0Tn7iGpOnCr8IuR7DIi7Fm/M Xi1NosUOSz1XQjyciWb0jmihaO3h9wNHyjbex7vVtSuN37qdUFbTkS8sAAAAAAAA --------------ms050807080508060105080102-- --===============1748979953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1748979953==-- From sip-bounces@ietf.org Wed Apr 2 08:42:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBD328C37D; Wed, 2 Apr 2008 08:42:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFE028C37D for ; Wed, 2 Apr 2008 08:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[AWL=2.052, 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 fvs1seOv8fU1 for ; Wed, 2 Apr 2008 08:42:19 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1864328C1C9 for ; Wed, 2 Apr 2008 08:42:19 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B856E22204; Wed, 2 Apr 2008 17:37:31 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-3e-47f3a83b90c5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 88BE022200; Wed, 2 Apr 2008 17:37:31 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 17:37:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 17:38:28 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15DAC007@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciU15ikttSY0DgZRKSOS5eBZj0SKg== From: "Ian Elz" To: "Francois Audet" , "Mary Barnes" , "Hans Erik van Elburg" , "Juha Heinanen" , "Christer Holmberg" X-OriginalArrivalTime: 02 Apr 2008 15:37:30.0906 (UTC) FILETIME=[769ED7A0:01C894D7] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois, You have missed one vital issue relating to History-Info. You cannot use a tel URI in History-Info as RFC3966 does not allow you to use header parameters. H-I uses header parameters for Reason and Privacy in H-I entries. To use a tel URI in a H-I entry requires that you convert it to a sip URI which requires that a suitable domain be found to create a valid entry. -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: 01 April 2008 17:30 To: Mary Barnes; Hans Erik van Elburg; Juha Heinanen; Christer Holmberg Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: Re: [Sip] Comparison of retargeting proposals The biggest problems with History-Info (IMHO) are: - It is written so that the UAC may generate the first History-Info entry or (more typically), it's proxy will. Creates some confusion on who does what. - It's optional - The number of entries can be pruned by proxies, making the content unreliable. - The last hop (i.e., replacing with contact) is not made obvious in the list (the whole point of this discussion). - People have used it as a replacement to diversion-header, i.e., to map to ISDN redirection number information. <--- This is the biggest problem All of those could be solve by a -bis. (There are also a few minor mistakes in some of the flows). > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Tuesday, April 01, 2008 06:28 > To: Hans Erik van Elburg; Audet, Francois (SC100:3055); Juha > Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > The proper use of History-Info isn't rocket science, but it > does require careful reading of the spec and proper > implementation (i.e., I agree if you don't implement the spec > properly, then it is a mess but that can be the case for any > spec that isn't implemented properly). There are some > inaccuracies in one of Dale's examples on forking that makes > it look far more error prone and problematic than it should > be. I'll respond separately with details. > > Mary. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: Tuesday, April 01, 2008 3:07 AM > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > The point is that History-Info does not solve the problem so > something new is needed anyway. > > And proper use of History-Info is rocket science as Dale has shown. > > /Hans Erik > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: Tuesday, April 01, 2008 2:16 AM > To: Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > There are existing implementations of History-Info in the field. > > It's not rocket science. > > And I don't see why introducing something else will be > simpler. It will just be extra complexity. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Juha Heinanen > > Sent: Saturday, March 29, 2008 05:48 > > To: Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > Christer Holmberg writes: > > > > > However, I still fail to understand how Target would be more > > "complex" > > > than e.g. History-Info. > > > > christer, > > > > ANY solution for anything must be MUCH simpler than history-info, > > which is far too complex by itself. > > > > i haven't seen anyone fully implement history-info and most likely > > that is because of its complexity. if you are now going to invent > > some other mechanism that is as complex or even more > complex, it has > > no change in real world. > > > > i therefore suggest that h-i is deprecated and a replaced > by a simpler > > > mechanism. > > > > -- juha > > _______________________________________________ > > 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 > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 09:08:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5D428C4CD; Wed, 2 Apr 2008 09:08:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B3428C457 for ; Wed, 2 Apr 2008 09:08:49 -0700 (PDT) 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBKWKXtKre9r for ; Wed, 2 Apr 2008 09:08:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 703C128C4CD for ; Wed, 2 Apr 2008 09:08:48 -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.240.5; Wed, 2 Apr 2008 12:08:23 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 12:08:23 -0400 From: Hadriel Kaplan To: Enrico Marocco Date: Wed, 2 Apr 2008 12:08:20 -0400 Thread-Topic: [Sip] I-D Action: draft-kaplan-sip-four-oh-00.txt Thread-Index: AciUjh8q7z8V4KmcRsur5sqvexJ0QQATG50g Message-ID: References: <47F34951.2010808@telecomitalia.it> In-Reply-To: <47F34951.2010808@telecomitalia.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Bob Penfield Subject: Re: [Sip] I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually, what's really funny is the previous version really *was* 41 pages long and Bob really *did* insist I add something to make it 42 pages long (for obvious reasons). The major piece I added to do so was page 4, with the two words "DON'T PANIC". :) -hadriel > -----Original Message----- > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Sent: Wednesday, April 02, 2008 4:53 AM > To: Hadriel Kaplan > Cc: sip@ietf.org; Bob Penfield > Subject: Re: [Sip] I-D Action: draft-kaplan-sip-four-oh-00.txt > > Hadriel Kaplan wrote: > > p.s. I apologize for the length of it - it was only 41 pages long > originally, but my co-author demanded it be expanded to 42 pages (for > obvious reasons), and thus it's a bit bloated. > > Now I'm sure: this is the answer! Lovely :-) > > -- > Ciao, > Enrico _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 09:16:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FAA43A6DB0; Wed, 2 Apr 2008 09:16:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB2F3A6949; Wed, 2 Apr 2008 09:16:46 -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 z7TKeLa31yQh; Wed, 2 Apr 2008 09:16:45 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 8BE033A6DB0; Wed, 2 Apr 2008 09:16:44 -0700 (PDT) Received: from [172.16.3.213] ([172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m32GGhW3006557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2008 11:16:43 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> From: Ben Campbell To: Jari Urpalainen In-Reply-To: <47F35A1E.4070109@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 11:16:43 -0500 References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: Re: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for the quick response. My comments for anything that still seems like an open issue are inline: On Apr 2, 2008, at 5:04 AM, Jari Urpalainen wrote: > ext Ben Campbell wrote: [...] >> Section 4.4, paragraph 1(clarity): >> "The usage of hierarchical lists and >> references, etc. can thus be omitted." >> >> You say that the usage of hierarchical lists and references >> can be omitted. Are they actually being forbidden in this context, >> or do you just mean to say that they are optional? If features of >> the resource list format are forbidden, then this draft needs >> normative language saying explicitly what is not to be used. If you >> just mean to say that they are optional, what are the >> interoperability issues if one device chooses to use them but the >> peer does not understand them? Do you have any thoughts concerning the above comment? >> >> >> "As it is >> anticipated that the XCAP server will be collocated with the SIP >> notifier, the subscriber MAY use relative XCAP URIs." >> >> Is it the authors' intention to require this collocation? That >> seems to be an architectural consequence of allowing relative URIs, >> unless we assert that if an implementation is architected >> differently, it is up to the implementation to be able to >> dereference relative URIs. >> > in practice, the sip notifier must be aware of changes made by > another protocol, i.e. http in this case. If these servers (notifier > & http (xcap) daemon) are separated they need some sort of immediate > mechanism to signal these events. It can be done with some > unspecified ways, but the most simple one is when they are running > on the very same host. However, even that simplest case is pretty > hard (or complex enough) to implement properly (implementation > description can be a long story although you are using OSS tools, > like e.g. linux with Apache + xcap_module and some decent Sip stack > with all the source code), and the intention is to define only the > very simplest use-case here. It is not ruled out that they were > separated but that would be much, much more difficult to implement, > and there are many obstacles and open issues there. So there's magic > (outside the scope of this i-d) here how to map the sip-uri to the > xcap-root-uri, but this, the most simple use-case is what i'd expect > to be implemented (and maybe, even some minor deployment as well ;-)). > > Also we agreed with Miguel to be more explicit about this magic, > does it sound sufficient to you ? Likely. As long as we mention the need for the notifier to learn about changes at the XCAP server, and that such mechanisms are out of scope for this document. It makes sense to mention collocation as an example way to solve this, but it's only an example. [...] >> >> Paragraph 3 (clarity): >> >> I'm not sure what the MUST applies to here--are you saying that the >> server MUST check for the condition you list as an example, or >> simply that, if the notifier chooses not to send XML-Patch-Ops >> patches for reasons of local policy, it MUST fall back to xcap- >> patching mode? > the reason to drop the aggregation mode for that particular resource > is that once the client have to use http, it might get out-of-sync > (with "rapidly" changing resources), the rule is to be certain that > it will not happen. I'll try to clarify. Thanks. I think it would be helpful to have a section dedicated describing the issue, and mention the ways to work around it. [...] >> >> "After that the >> subscriber MAY send a re-subscription to start the diff >> "aggregation" >> on the server." >> >> Does this mean to imply the subscriber cannot start out with >> aggregation turned on? (I think this may be another case of >> presenting the edge case without presenting the primary use case >> first.) > it can try to start in the aggregate mode straight away, but it may > fail. So the safe way is to disable aggregation first before sync is > achieved and enable it afterwards. I think I'll add something about > this into those dreaded examples (in an appendix) See my previous comment about having a separate section to describe the issue and possible solutions. It's also important that we are clear on whether the delayed activation of "aggregation" mode is simply an optional solution to a potential issue, or is a normative requirement. > >> >> >> Paragraph 2: (substantive) >> >> You cannot safely use non-sequential CSeq to detect missing NOTIFY >> requests. For example, if the NOTIFY request is challenged by an >> intervening proxy, the subscriber will see non-sequential CSeq >> values. It may be unusual for NOTIFY to get challenged, but unless >> we forbid it, then we cannot depend on CSeq for this purpose. > ok, didn't think about that at all. This one needs some thought, then. There are actually a lot more causes than just digest challenges that may cause the client to see non-sequential CSeqs. If detection of lost notifies is critical, we need another solution (either to detect lost notifies or to remove the need to do so.) >> Section 4.10 (substantive) >> >> It's not clear to me how this interacts with the "aggregation" >> mechanism. In particular, if the notifier has more than one change >> in the 5 second window, but the subscriber did not allow >> aggregation, how is it handled? > yep this is indeed _difficult_. Easy to write (one sentence only), > but really, really hard to implement properly ;-). First off there's > a SHOULD directive fortunately... I'm not 100 % sure if you mean > that xcap-patching is also disabled. So there's not a big difference > in this context whether you have aggregation or xcap-patching modes, > since in the xcap-patching mode you will see changes e.g. from "a" > to "b" to "c" with all corresponding Etags while in the aggregate > mode you'll see e.g. only changes from "a" to "c" in the > notification body without the intermediate state. Certainly > aggregation body is smaller but it fails to show the versioning > history and the diff formats differ, but the end result will be the > same certainly, i.e. "c". So _if_ you obey the timer, you wait for > it to expire and then send the result in both cases (and of course > during this timer interval you wait for any changes in these > resources, and do something relevant, e.g. store internal object > states). If there's not any patching modes applied, then you should > wait for the timer to expire and send appropriate actions, i.e. > document(s) has either been created, modified or deleted. I'm not sure I understand what you mean on the last two sentences--can you give an example? > IIRC, in partial PIDF where we use the exact same patchings there's > not a single line about this since this timer is inherited from the > base PIDF package. In summary, you just don't have to do anything > mysterious with timers except wait for a certain period of time. In > practice, it happens to be quite a challenging task (but these specs > usually _ignore_ the implementation PITA ;-)) It's still not clear to me if this is just a "hard implementation" problem or if it is really a conflict in normative requirements. Coding aside, what do you expect the most commen behavior to be if multiple changes occur inside the 5 second window, but the client has not allowed aggregation? (The example requested above might help me understand this.) > >> >> Section 5, figure 3 (clarity): >> >> It would be nice to see this in context of an actual NOTIFY. > I'll try to digest something into an appendix. That being said, the > important things are bodies... To some degree, it is up to the companion draft to define the body in detail--this draft really talks about the SIP-event package, so I do think it is appropriate to show real message flows including the SIP parts. [...] >> >> Section 7, Security Considerations (substantive) >> >> I think we need more here. What sort of authentication is adequate >> (particularly for authenticating the notifier.) Does the potential >> sensitive content create any need for privacy and integrity >> protection beyond that generically needed for SIP-Events? >> > yep, besides DoS TLS & S/MIME recommendations some text about > identity "mapping" between http & sip would be reasonable. Anything > else ? I had not thought of the identity mapping issue--that discussion always seems to get more "interesting" than you might expect :-) It might be worth adding SIPS thoughts to any TLS discussion. Thanks! Ben. _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 09:19:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6AF83A6F4B; Wed, 2 Apr 2008 09:19:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD293A6F45 for ; Wed, 2 Apr 2008 09:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.438 X-Spam-Level: X-Spam-Status: No, score=-5.438 tagged_above=-999 required=5 tests=[AWL=1.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 1Y14qDg5F3kY for ; Wed, 2 Apr 2008 09:19:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0C09B3A6EE7 for ; Wed, 2 Apr 2008 09:19: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 m32GJkd05202; Wed, 2 Apr 2008 16:19:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 11:19:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> In-Reply-To: <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPA= References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> From: "Francois Audet" To: "Hans Erik van Elburg" , "Juha Heinanen" , "Christer Holmberg" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The loose-route proposal is clear, but attempts to solve a much larger problem. The new header proposal is very far from clear, as was demonstrated by the mailing list discussion, where nobody seems to agree on what the header was supposed to mean. Most people didn't understand why it was different than the P-Called-ID (or whatever that was). Furthermore, what would that header actually mean? Is is the original target as inserted by the first UAC? If so, why is it different than the To header? Is it the target as modified by the originating domain's proxy (for example, "fixing" the phone number to make it into a real E.164 number in a Tel or SIP URI?)? Or is it the last retargeting address? Or any retargeting in between? And how do you define retargeting in the first place? The answers that Christer provided actually confused people who tought they understood the proposal (i.e., people who tought we were talking about the P-Called header). And finally, somebody needs to demonstrate how this can not overlap with History-Info. Saying its "simpler" is misleading. It's simpler until we analyse completely what we are actually shooting for. > -----Original Message----- > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > Sent: Wednesday, April 02, 2008 02:43 > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > It is clearly not the same as History-Info header as has been > explained in the draft and in several previous threads. It > has also been explained why History-Info can not be used for > this as is. > > A simple new header with a clear semantics which provides a > clean solution to the problem is therefore not even > challenged by the History-Info header. Instead you should > argue why History-Info is so bloody good that we should use > it for this. We just learned that it is not even usable as a > diagnostic tool. > > Why carry a whole log of request URI rewrites around when you > are only interested in the current target??? > > /Hans Erik > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, April 01, 2008 6:18 PM > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > Any addition of a new header that nobody can explain properly > why it's not the same as History-Info IS rocket science. > > It sounds like we are getting paid by the number of URI we > add to SIP. > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > > Sent: Tuesday, April 01, 2008 01:07 > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > The point is that History-Info does not solve the problem > so something > > > new is needed anyway. > > > > And proper use of History-Info is rocket science as Dale has shown. > > > > /Hans Erik > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Francois Audet > > Sent: Tuesday, April 01, 2008 2:16 AM > > To: Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > There are existing implementations of History-Info in the field. > > > > It's not rocket science. > > > > And I don't see why introducing something else will be simpler. It > > will just be extra complexity. > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Juha Heinanen > > > Sent: Saturday, March 29, 2008 05:48 > > > To: Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > Christer Holmberg writes: > > > > > > > However, I still fail to understand how Target would be more > > > "complex" > > > > than e.g. History-Info. > > > > > > christer, > > > > > > ANY solution for anything must be MUCH simpler than history-info, > > > which is far too complex by itself. > > > > > > i haven't seen anyone fully implement history-info and > most likely > > > that is because of its complexity. if you are now going > to invent > > > some other mechanism that is as complex or even more > > complex, it has > > > no change in real world. > > > > > > i therefore suggest that h-i is deprecated and a replaced > > by a simpler > > > > > mechanism. > > > > > > -- juha > > > _______________________________________________ > > > 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 sip-bounces@ietf.org Wed Apr 2 09:36:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064AD28C4C4; Wed, 2 Apr 2008 09:36:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0749A3A6D35 for ; Wed, 2 Apr 2008 09:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=1.045, 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 Xe3ikVecf4mE for ; Wed, 2 Apr 2008 09:36:00 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id E672228C597 for ; Wed, 2 Apr 2008 09:34:55 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32GYnv04782; Wed, 2 Apr 2008 16:34:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 11:34:34 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15DEE261@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciU15ikttSY0DgZRKSOS5eBZj0SKgABw/Ug References: <1ECE0EB50388174790F9694F77522CCF15DAC007@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Ian Elz" , "Mary Barnes" , "Hans Erik van Elburg" , "Juha Heinanen" , "Christer Holmberg" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org That's not a problem with History-Info, it's a "problem" with Tel URIs. Tel URIs doesn't allow to use "?Reason=302" or whatever, which makes sense because Tel URIs are not necessarily used by SIP. It could be used by PSTN, H.323, whatever you want. So allowing SIP parameters in there (like embedded SIP headers) makes no sense. If you want to force SIP, don't use a Tel URI. Why are we talking about these types of parameters in the first place? If we need to add something to History-Info to clarify the target parameter (whatever that means), then it should be a History Info parameter, not a URI parameter. > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, April 02, 2008 08:38 > To: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00); > Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > Francois, > > You have missed one vital issue relating to History-Info. > > You cannot use a tel URI in History-Info as RFC3966 does not > allow you to use header parameters. H-I uses header > parameters for Reason and Privacy in H-I entries. > > To use a tel URI in a H-I entry requires that you convert it > to a sip URI which requires that a suitable domain be found > to create a valid entry. > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 01 April 2008 17:30 > To: Mary Barnes; Hans Erik van Elburg; Juha Heinanen; > Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > The biggest problems with History-Info (IMHO) are: > > - It is written so that the UAC may generate the first > History-Info entry > or (more typically), it's proxy will. Creates some > confusion on who does what. > - It's optional > - The number of entries can be pruned by proxies, making the > content unreliable. > - The last hop (i.e., replacing with contact) is not made > obvious in the list (the > whole point of this discussion). > - People have used it as a replacement to diversion-header, > i.e., to map to > ISDN redirection number information. <--- This is the > biggest problem > > All of those could be solve by a -bis. > > (There are also a few minor mistakes in some of the flows). > > > -----Original Message----- > > From: Barnes, Mary (RICH2:AR00) > > Sent: Tuesday, April 01, 2008 06:28 > > To: Hans Erik van Elburg; Audet, Francois (SC100:3055); > Juha Heinanen; > > Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > The proper use of History-Info isn't rocket science, but it does > > require careful reading of the spec and proper > implementation (i.e., I > > agree if you don't implement the spec properly, then it is > a mess but > > that can be the case for any spec that isn't implemented properly). > > There are some inaccuracies in one of Dale's examples on > forking that > > makes it look far more error prone and problematic than it > should be. > > I'll respond separately with details. > > > > Mary. > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Hans Erik van Elburg > > Sent: Tuesday, April 01, 2008 3:07 AM > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > The point is that History-Info does not solve the problem > so something > > new is needed anyway. > > > > And proper use of History-Info is rocket science as Dale has shown. > > > > /Hans Erik > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Francois Audet > > Sent: Tuesday, April 01, 2008 2:16 AM > > To: Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > There are existing implementations of History-Info in the field. > > > > It's not rocket science. > > > > And I don't see why introducing something else will be simpler. It > > will just be extra complexity. > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Juha Heinanen > > > Sent: Saturday, March 29, 2008 05:48 > > > To: Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > Christer Holmberg writes: > > > > > > > However, I still fail to understand how Target would be more > > > "complex" > > > > than e.g. History-Info. > > > > > > christer, > > > > > > ANY solution for anything must be MUCH simpler than history-info, > > > which is far too complex by itself. > > > > > > i haven't seen anyone fully implement history-info and > most likely > > > that is because of its complexity. if you are now going > to invent > > > some other mechanism that is as complex or even more > > complex, it has > > > no change in real world. > > > > > > i therefore suggest that h-i is deprecated and a replaced > > by a simpler > > > > > mechanism. > > > > > > -- juha > > > _______________________________________________ > > > 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 > > > > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 09:53:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB3428C403; Wed, 2 Apr 2008 09:53:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF493A6A09 for ; Wed, 2 Apr 2008 09:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.950, 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 S0yjyeCJ-9ok for ; Wed, 2 Apr 2008 09:53:05 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 399B03A6F3D for ; Wed, 2 Apr 2008 09:53:05 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32Gr0v08000; Wed, 2 Apr 2008 16:53:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 11:52:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15E38A9C@zrc2hxm0.corp.nortel.com> In-Reply-To: <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA92SiA= References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> From: "Francois Audet" To: "Hans Erik van Elburg" , "Juha Heinanen" , "Christer Holmberg" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Again, the burden is on the proponent of the new header to prove that a new header is needed when we apparently have headers that carries the same information, and more. > -----Original Message----- > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > Sent: Wednesday, April 02, 2008 02:43 > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > It is clearly not the same as History-Info header as has been > explained in the draft and in several previous threads. It > has also been explained why History-Info can not be used for > this as is. > > A simple new header with a clear semantics which provides a > clean solution to the problem is therefore not even > challenged by the History-Info header. Instead you should > argue why History-Info is so bloody good that we should use > it for this. We just learned that it is not even usable as a > diagnostic tool. > > Why carry a whole log of request URI rewrites around when you > are only interested in the current target??? > > /Hans Erik > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, April 01, 2008 6:18 PM > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > Any addition of a new header that nobody can explain properly > why it's not the same as History-Info IS rocket science. > > It sounds like we are getting paid by the number of URI we > add to SIP. > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > > Sent: Tuesday, April 01, 2008 01:07 > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > The point is that History-Info does not solve the problem > so something > > > new is needed anyway. > > > > And proper use of History-Info is rocket science as Dale has shown. > > > > /Hans Erik > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Francois Audet > > Sent: Tuesday, April 01, 2008 2:16 AM > > To: Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > There are existing implementations of History-Info in the field. > > > > It's not rocket science. > > > > And I don't see why introducing something else will be simpler. It > > will just be extra complexity. > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Juha Heinanen > > > Sent: Saturday, March 29, 2008 05:48 > > > To: Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > Christer Holmberg writes: > > > > > > > However, I still fail to understand how Target would be more > > > "complex" > > > > than e.g. History-Info. > > > > > > christer, > > > > > > ANY solution for anything must be MUCH simpler than history-info, > > > which is far too complex by itself. > > > > > > i haven't seen anyone fully implement history-info and > most likely > > > that is because of its complexity. if you are now going > to invent > > > some other mechanism that is as complex or even more > > complex, it has > > > no change in real world. > > > > > > i therefore suggest that h-i is deprecated and a replaced > > by a simpler > > > > > mechanism. > > > > > > -- juha > > > _______________________________________________ > > > 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 sip-bounces@ietf.org Wed Apr 2 10:24:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215253A6D28; Wed, 2 Apr 2008 10:24:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406383A6D28 for ; Wed, 2 Apr 2008 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.94 X-Spam-Level: X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[AWL=2.309, 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 sO4zj9ZVD6mo for ; Wed, 2 Apr 2008 10:24:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B36933A6C95 for ; Wed, 2 Apr 2008 10:24:22 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 41B9921392; Wed, 2 Apr 2008 19:19:41 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-f9-47f3c02d5eed Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 17DDF2133F; Wed, 2 Apr 2008 19:19:41 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 19:19:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 19:19:20 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals thread-index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloA== References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Hans Erik van Elburg" , "Juha Heinanen" X-OriginalArrivalTime: 02 Apr 2008 17:19:40.0907 (UTC) FILETIME=[BC62C3B0:01C894E5] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois, I believe the confusion you are talking about was related to the first version of the draft, where we also talked about the P-Called-Party-ID header etc. I tried to clarify that, and make the second version of the draft more clear. Based on the comments I have received the issues were solved/clarified in the second version of the draft. The only text left about P-Called-Party-ID is the paragraph where we DO explain the difference between it and Target. Regards, Christer -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: 2. huhtikuuta 2008 19:19 To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals The loose-route proposal is clear, but attempts to solve a much larger problem. The new header proposal is very far from clear, as was demonstrated by the mailing list discussion, where nobody seems to agree on what the header was supposed to mean. Most people didn't understand why it was different than the P-Called-ID (or whatever that was). Furthermore, what would that header actually mean? Is is the original target as inserted by the first UAC? If so, why is it different than the To header? Is it the target as modified by the originating domain's proxy (for example, "fixing" the phone number to make it into a real E.164 number in a Tel or SIP URI?)? Or is it the last retargeting address? Or any retargeting in between? And how do you define retargeting in the first place? The answers that Christer provided actually confused people who tought they understood the proposal (i.e., people who tought we were talking about the P-Called header). And finally, somebody needs to demonstrate how this can not overlap with History-Info. Saying its "simpler" is misleading. It's simpler until we analyse completely what we are actually shooting for. > -----Original Message----- > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > Sent: Wednesday, April 02, 2008 02:43 > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > It is clearly not the same as History-Info header as has been > explained in the draft and in several previous threads. It > has also been explained why History-Info can not be used for > this as is. > > A simple new header with a clear semantics which provides a > clean solution to the problem is therefore not even > challenged by the History-Info header. Instead you should > argue why History-Info is so bloody good that we should use > it for this. We just learned that it is not even usable as a > diagnostic tool. > > Why carry a whole log of request URI rewrites around when you > are only interested in the current target??? > > /Hans Erik > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, April 01, 2008 6:18 PM > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > Any addition of a new header that nobody can explain properly > why it's not the same as History-Info IS rocket science. > > It sounds like we are getting paid by the number of URI we > add to SIP. > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > > Sent: Tuesday, April 01, 2008 01:07 > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > The point is that History-Info does not solve the problem > so something > > > new is needed anyway. > > > > And proper use of History-Info is rocket science as Dale has shown. > > > > /Hans Erik > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Francois Audet > > Sent: Tuesday, April 01, 2008 2:16 AM > > To: Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > There are existing implementations of History-Info in the field. > > > > It's not rocket science. > > > > And I don't see why introducing something else will be simpler. It > > will just be extra complexity. > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Juha Heinanen > > > Sent: Saturday, March 29, 2008 05:48 > > > To: Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > Christer Holmberg writes: > > > > > > > However, I still fail to understand how Target would be more > > > "complex" > > > > than e.g. History-Info. > > > > > > christer, > > > > > > ANY solution for anything must be MUCH simpler than history-info, > > > which is far too complex by itself. > > > > > > i haven't seen anyone fully implement history-info and > most likely > > > that is because of its complexity. if you are now going > to invent > > > some other mechanism that is as complex or even more > > complex, it has > > > no change in real world. > > > > > > i therefore suggest that h-i is deprecated and a replaced > > by a simpler > > > > > mechanism. > > > > > > -- juha > > > _______________________________________________ > > > 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 sip-bounces@ietf.org Wed Apr 2 11:19:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8523A6EAD; Wed, 2 Apr 2008 11:19:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADE53A6D95 for ; Wed, 2 Apr 2008 11:19:03 -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 Esy8rj8mFBYR for ; Wed, 2 Apr 2008 11:18:59 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1F77D3A6EAD for ; Wed, 2 Apr 2008 11:18:54 -0700 (PDT) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m32IIrTf003204; Wed, 2 Apr 2008 13:18:54 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m32IIrA13187; Wed, 2 Apr 2008 13:18:53 -0500 (CDT) Message-ID: <47F3CE0D.4040808@alcatel-lucent.com> Date: Wed, 02 Apr 2008 13:18:53 -0500 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: In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "sip@ietf.org" , Bob Penfield Subject: Re: [Sip] I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > Greetings, > Given today's relative importance in history - being the date Swiss farmers had their largest spaghetti crop harvest, Sweden introduced color television, the USSR connected Kremvax to Usenet, the Alabama state government changed the value of Pi to 3.0, and much more - we took it upon ourselves to write up and submit a new Internet-Draft for an update to RFC 3261 (and a bunch of other RFCs): P2P2PSIP, a.k.a. SIP v4.0. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt Hadriel: Given the problems we have had with UDP, I think your draft should deprecate UDP in favor of carrying IP datagrams on avian carriers (RFC 1149). The benefits are many, and the frame format is very simple: The IP datagram is printed, on a small scroll of paper, in hexadecimal, with each octet separated by whitestuff and blackstuff. The scroll of paper is wrapped around one leg of the avian carrier. A band of duct tape is used to secure the datagram's edges. The bandwidth is limited to the leg length. The MTU is variable, and paradoxically, generally increases with increased carrier age. A typical MTU is 256 milligrams. Some datagram padding may be needed. Upon receipt, the duct tape is removed and the paper copy of the datagram is optically scanned into a electronically transmittable form. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 11:33:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0F13A6F4D; Wed, 2 Apr 2008 11:33:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEF928C58B for ; Wed, 2 Apr 2008 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.666, 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 Y5rKijzXxyIv for ; Wed, 2 Apr 2008 11:32:55 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id D174E3A6829 for ; Wed, 2 Apr 2008 11:31:22 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m32IVHhV010379; Wed, 2 Apr 2008 13:31:17 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 13:29:56 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 20:29:53 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 20:29:52 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001DDF6D3@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-sip-media-security-requirements-04 Thread-index: AciL2ZJONuqQeMSERNe9+RvYoavWlwJFZnNg References: From: "DRAGE, Keith \(Keith\)" To: "Dean Willis" , "SIP List" X-OriginalArrivalTime: 02 Apr 2008 18:29:53.0120 (UTC) FILETIME=[8B0F7600:01C894EF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Cullen Jennings , Dan Wing Subject: Re: [Sip] WGLC for draft-ietf-sip-media-security-requirements-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org [As WG cochair] 3 more days left of this WGLC and I do not believe I have seen any comments yet. If you have posted comments then do not panic, they are not lost - I am just working from memory. Is the document perfect? If so tell us. You are just making the final polishing to an extensive set of comments and will post shortly? Please do so with all despatch. Have not yet looked at it? Then please do so - we need this document reviewed and finished. Regards Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Saturday, March 22, 2008 5:00 AM > To: SIP List > Cc: Cullen Jennings; Dan Wing; DRAGE, Keith (Keith) > Subject: WGLC for draft-ietf-sip-media-security-requirements-04 > > > I'm pleased to announce a Working Group Last Call on the > Media Security Requirements document. > > Please give this a final read through and send any comments > to the author and the working group mailing list. > > I'd like to wrap this by April 7. We should be ready to move > on to the DTLS framework document immediately afterwards. I hope. > > For your reading pleasure, here's a link to the most recent > version of the requirements doc: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-media-secur > ity-requirements-04.txt > > > -- > Dean Willis > Officiously Acting as Co-Chair > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 12:24:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F143A684F; Wed, 2 Apr 2008 12:24:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCB428C4B9 for ; Wed, 2 Apr 2008 12:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.560, 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 SSFQZPW3MFC4 for ; Wed, 2 Apr 2008 12:24:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4B04C28C518 for ; Wed, 2 Apr 2008 12:20:52 -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.240.5; Wed, 2 Apr 2008 15:20:27 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 15:20:27 -0400 From: Hadriel Kaplan To: "Vijay K. Gurbani" Date: Wed, 2 Apr 2008 15:20:26 -0400 Thread-Topic: [Sip] I-D Action: draft-kaplan-sip-four-oh-00.txt Thread-Index: AciU7fUeuRdYIxAiTTi6T0UxwycxxwAAlP+w Message-ID: References: <47F3CE0D.4040808@alcatel-lucent.com> In-Reply-To: <47F3CE0D.4040808@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Bob Penfield Subject: Re: [Sip] I-D Action: draft-kaplan-sip-four-oh-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hmmm... I thought RFC 1149 was at a lower layer, so UDP just rides on IP on top of Avian. Really, it's essentially just another wireless layer-1, which I guess would be "WiFly" instead of WiFi. I'll leave it to Dan's draft-wing-it to handle how one does that, if we need a sipping-style use-case. But I really think RFC 1149 is for the birds, and would pigeon-hole us into one specific path. That would create a chicken-and-egg problem, because without 1149 being popular, people would not flock to SIPv4, and that would fowl up 1149 becoming popular. I'd rather duck that issue, and instead home-in on publishing a SIPv4 draft to sow the seeds, and letting it fly, and we can smooth any ruffled feathers later. That way people can migrate to SIPv4 now, until the final published doc is grounded. If SIPv4 and WiFly come home to roost we can crow about it later, but for now we need to let SIPv4 out of the cage, with space to stretch its wings and take off. -hadriel > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Wednesday, April 02, 2008 2:19 PM > To: Hadriel Kaplan > Cc: sip@ietf.org; Bob Penfield > Subject: Re: [Sip] I-D Action: draft-kaplan-sip-four-oh-00.txt > > Hadriel Kaplan wrote: > > Greetings, > > Given today's relative importance in history - being the date Swiss > farmers had their largest spaghetti crop harvest, Sweden introduced color > television, the USSR connected Kremvax to Usenet, the Alabama state > government changed the value of Pi to 3.0, and much more - we took it upon > ourselves to write up and submit a new Internet-Draft for an update to RFC > 3261 (and a bunch of other RFCs): P2P2PSIP, a.k.a. SIP v4.0. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt > > Hadriel: Given the problems we have had with UDP, I think your draft > should deprecate UDP in favor of carrying IP datagrams on avian > carriers (RFC 1149). The benefits are many, and the frame format > is very simple: > > The IP datagram is printed, on a small scroll of paper, in > hexadecimal, with each octet separated by whitestuff and blackstuff. > The scroll of paper is wrapped around one leg of the avian carrier. > A band of duct tape is used to secure the datagram's edges. The > bandwidth is limited to the leg length. The MTU is variable, and > paradoxically, generally increases with increased carrier age. A > typical MTU is 256 milligrams. Some datagram padding may be needed. > > Upon receipt, the duct tape is removed and the paper copy of the > datagram is optically scanned into a electronically transmittable > form. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 2 12:24:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC2B28C528; Wed, 2 Apr 2008 12:24:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9690228C49C for ; Wed, 2 Apr 2008 12:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.871, 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 rgav0z5aWCVl for ; Wed, 2 Apr 2008 12:24:07 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 903C728C5BB for ; Wed, 2 Apr 2008 12:21:10 -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 m32JL3d29910; Wed, 2 Apr 2008 19:21:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 14:20:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3Kg References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Hans Erik van Elburg" , "Juha Heinanen" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org As much as I read this, I still can't figure an example where the P-Called-Header and the Target header are different: As defined in RFC3455 [5], if a SIP entity, which acts as registrar/ home proxy for the terminating user, re-writes the Request-URI with the contact address of the registered UA it may insert a P-Called- Party-ID header field with the previous value of the Request-URI. The Target header field and P-Called-Party-ID header field have different semantics. The Target header field represents the current target identity, while the P-Called-Party-ID represents the last Request-URI value used to reach the user before the Request-URI value was re-written with the Contact address of the UAS. In some cases the P-Called-Party-ID may be the same as the current target but, it may also be the last route taken (not equal to the current target) to deliver the request. Therefore the P-Called-Party-ID can not be used in a generic SIP environment to represent the current target. Can you give one. It seems to me that in both cases, the headers will include the last Request-URI "just before it's replaced by the Contact used in Registration". Moving to History-Info... The current text in History-Info is not clear at all about recording both "current target" and recording the target that corresponds to the "Contact that was used in Registration" for the last hop. In fact, none of the example illustrate the process. The implication from the examples is that the proxy retargetting would magically know the contact address. My personal preference would be to up-issue History-Info to have a clear indication (say a History-Info parameter) that identifies the Contact, plus some rule mandating that the previous entry would be the last target. I would also want to fix all the examples to illustrate it. I will note that for that approach to work, History-Info only needs to be supported at the terminating retargeting proxy (just like target header). The alternative is to use the proposed Target header. If we decide to go that route, I still think that we need to up-issue History-Info (if anything to illustrates how the Target header works in conjunction to it). In either case I think we need to update History-Info at the same time as we fix this problem. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, April 02, 2008 10:19 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Juha Heinanen > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > > Francois, > > I believe the confusion you are talking about was related to > the first version of the draft, where we also talked about > the P-Called-Party-ID header etc. > > I tried to clarify that, and make the second version of the > draft more clear. Based on the comments I have received the > issues were solved/clarified in the second version of the draft. > > The only text left about P-Called-Party-ID is the paragraph > where we DO explain the difference between it and Target. > > Regards, > > Christer > > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 2. huhtikuuta 2008 19:19 > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > The loose-route proposal is clear, but attempts to solve a > much larger problem. > > The new header proposal is very far from clear, as was > demonstrated by the mailing list discussion, where nobody > seems to agree on what the header was supposed to mean. Most > people didn't understand why it was different than the > P-Called-ID (or whatever that was). > > Furthermore, what would that header actually mean? Is is the > original target as inserted by the first UAC? If so, why is > it different than the To header? Is it the target as modified > by the originating domain's proxy (for example, "fixing" the > phone number to make it into a real > E.164 number in a Tel or SIP URI?)? Or is it the last > retargeting address? Or any retargeting in between? And how > do you define retargeting in the first place? > > The answers that Christer provided actually confused people > who tought they understood the proposal (i.e., people who > tought we were talking about the P-Called header). > > And finally, somebody needs to demonstrate how this can not > overlap with History-Info. Saying its "simpler" is > misleading. It's simpler until we analyse completely what we > are actually shooting for. > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > > Sent: Wednesday, April 02, 2008 02:43 > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > It is clearly not the same as History-Info header as has been > > explained in the draft and in several previous threads. It has also > > been explained why History-Info can not be used for this as is. > > > > A simple new header with a clear semantics which provides a clean > > solution to the problem is therefore not even challenged by the > > History-Info header. Instead you should argue why > History-Info is so > > bloody good that we should use it for this. We just learned > that it is > > not even usable as a diagnostic tool. > > > > Why carry a whole log of request URI rewrites around when > you are only > > interested in the current target??? > > > > /Hans Erik > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, April 01, 2008 6:18 PM > > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > Any addition of a new header that nobody can explain > properly why it's > > not the same as History-Info IS rocket science. > > > > It sounds like we are getting paid by the number of URI we > add to SIP. > > > > > -----Original Message----- > > > From: Hans Erik van Elburg > [mailto:hanserik.van.elburg@ericsson.com] > > > Sent: Tuesday, April 01, 2008 01:07 > > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > > > The point is that History-Info does not solve the problem > > so something > > > > > new is needed anyway. > > > > > > And proper use of History-Info is rocket science as Dale > has shown. > > > > > > /Hans Erik > > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Francois Audet > > > Sent: Tuesday, April 01, 2008 2:16 AM > > > To: Juha Heinanen; Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > There are existing implementations of History-Info in the field. > > > > > > It's not rocket science. > > > > > > And I don't see why introducing something else will be > simpler. It > > > will just be extra complexity. > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of > > > > Juha Heinanen > > > > Sent: Saturday, March 29, 2008 05:48 > > > > To: Christer Holmberg > > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > > > Christer Holmberg writes: > > > > > > > > > However, I still fail to understand how Target would be more > > > > "complex" > > > > > than e.g. History-Info. > > > > > > > > christer, > > > > > > > > ANY solution for anything must be MUCH simpler than > history-info, > > > > which is far too complex by itself. > > > > > > > > i haven't seen anyone fully implement history-info and > > most likely > > > > that is because of its complexity. if you are now going > > to invent > > > > some other mechanism that is as complex or even more > > > complex, it has > > > > no change in real world. > > > > > > > > i therefore suggest that h-i is deprecated and a replaced > > > by a simpler > > > > > > > mechanism. > > > > > > > > -- juha > > > > _______________________________________________ > > > > 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 sip-bounces@ietf.org Wed Apr 2 13:22:35 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4115B3A6A25; Wed, 2 Apr 2008 13:22:35 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC62A3A6A25 for ; Wed, 2 Apr 2008 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_PILL=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 uYDTPnwEKFni for ; Wed, 2 Apr 2008 13:22:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 11D0D3A6B78 for ; Wed, 2 Apr 2008 13:22:32 -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.240.5; Wed, 2 Apr 2008 16:22:07 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 16:22:05 -0400 From: Hadriel Kaplan To: Francois Audet , Christer Holmberg , Hans Erik van Elburg , Juha Heinanen Date: Wed, 2 Apr 2008 16:22:01 -0400 Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgAAJ90TA= Message-ID: References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Francois Audet > > Can you give one. It seems to me that in both cases, the headers will > include the last Request-URI "just before it's replaced by the Contact > used > in Registration". From a previous email I sent a long time ago, given the following reasonably complex scenario, where "RTRG" means Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and the single letters represent connections: RTRG RRT +---+ +---+ |R1 | |R2 | B /+---+\ C E /+---+\ F RT / \ RT RT / \ RT +---+/ \+---+ D +---+/ \+---+ |P1 | |P2 +---+P3 | |P4 | A /+---+ +---+ +---+ +---+\ G / \ +---+/ \+---+ |UAC| |UAS| +---+ +---+ Goal: to get the req-uri seen on "C" (right?). UA-Loose-routing sets the req-uri to that seen on connection "C". Target gives you C. PCPID gives you E. Hist-Info gives you A,B,C,D,E,F. To header gives you A. C != E, because P2 and P3 could be swapping req-uri's as they 3261 route. UALR draft says "stop swapping when you route", but Target draft does not. -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 sip-bounces@ietf.org Wed Apr 2 14:58:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85CB3A6A84; Wed, 2 Apr 2008 14:58:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1039A3A6A84 for ; Wed, 2 Apr 2008 14:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_PILL=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 iYFzh2I7CPtg for ; Wed, 2 Apr 2008 14:58:39 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E38DE3A6A51 for ; Wed, 2 Apr 2008 14:58:38 -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 m32LwYd20405; Wed, 2 Apr 2008 21:58:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:58:34 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15E395B9@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgAAJ90TAAA6Il4A== References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Christer Holmberg" , "Hans Erik van Elburg" , "Juha Heinanen" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Re-Targeting (RTRG) is when a Proxy changes a Request-URI to a different one, outside of normal routing. That's ok. For example, bob@example.com to alice@example.com. What is the difference between RRT (Re-Routing) and Routing (Routing)? I don't get it. And I don't see in here the place where the Request-URI is changed to the Contact that was used in the REGISTER (i.e., where example.com changes bob@example.com to bob@bobpc.example.com). That is really the missing part, no? Is that what you call RRT? And if so, why is there an extra leg between it and the UAS? Is it because P4 is an outbound proxy? And I still don't see why C != E. It would only be different if loose route was not used by the proxies (e.g., RFC 2543 proxies). Is that what you mean? If so, doesn't this mean P-Called-Party-ID is essentially useless and IMS can't use it anyways? So we should just fix P-Called-Party-ID spec instead? > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, April 02, 2008 13:22 > To: Audet, Francois (SC100:3055); Christer Holmberg; Hans > Erik van Elburg; Juha Heinanen > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Francois Audet > > > > Can you give one. It seems to me that in both cases, the > headers will > > include the last Request-URI "just before it's replaced by > the Contact > > used in Registration". > > From a previous email I sent a long time ago, given the > following reasonably complex scenario, where "RTRG" means > Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and > the single letters represent connections: > > RTRG RRT > +---+ +---+ > |R1 | |R2 | > B /+---+\ C E /+---+\ F > RT / \ RT RT / \ RT > +---+/ \+---+ D +---+/ \+---+ > |P1 | |P2 +---+P3 | |P4 | > A /+---+ +---+ +---+ +---+\ G > / \ > +---+/ \+---+ > |UAC| |UAS| > +---+ +---+ > > Goal: to get the req-uri seen on "C" (right?). > > UA-Loose-routing sets the req-uri to that seen on connection "C". > Target gives you C. > PCPID gives you E. > Hist-Info gives you A,B,C,D,E,F. > To header gives you A. > > C != E, because P2 and P3 could be swapping req-uri's as they > 3261 route. UALR draft says "stop swapping when you route", > but Target draft does not. > > -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 sip-bounces@ietf.org Wed Apr 2 16:07:00 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF5428C2B7; Wed, 2 Apr 2008 16:06:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF823A6831 for ; Wed, 2 Apr 2008 16:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_PILL=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 9ng3+MGzC7OH for ; Wed, 2 Apr 2008 16:06:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1F80028C4DE for ; Wed, 2 Apr 2008 16:05:27 -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.240.5; Wed, 2 Apr 2008 19:05:02 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 2 Apr 2008 19:05:02 -0400 From: Hadriel Kaplan To: Francois Audet , Christer Holmberg , Hans Erik van Elburg , Juha Heinanen Date: Wed, 2 Apr 2008 19:05:01 -0400 Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgAAJ90TAAA6Il4AABYJUQ Message-ID: References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E395B9@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15E395B9@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > > Re-Targeting (RTRG) is when a Proxy changes a Request-URI to a different > one, outside of > normal routing. That's ok. For example, bob@example.com to > alice@example.com. > What is the difference between RRT (Re-Routing) and Routing (Routing)? I > don't get it. I believe, based on the email discussion back in January, that "Re-Targeting" is when a Proxy re-targets the request to a new entity, so yes for example from bob to charlie. In that situation, I believe what both Jonathan and Christer want is the "target-info" (the stuff we're trying to preserve) to be replaced by the new set (charlie's set). Re-Routing is when the proxy/registrar replaces the req-uri due to AoR->contact resolution. In that case we want to preserve the pre-resolved target info. Routing is when a proxy routes. I believe the intention was that this mean the proxy does not touch the req-uri, but my guess is that's not agreed is reality. (more on that later) > And I don't see in here the place where the Request-URI is changed to the > Contact > that was used in the REGISTER (i.e., where example.com changes > bob@example.com to > bob@bobpc.example.com). That is really the missing part, no? That is R2 in the diagram. > Is that what you call RRT? And if so, why is there an extra leg between it > and the > UAS? Is it because P4 is an outbound proxy? P4 is an outbound proxy. But to be clear, what's going on here is call goes to bob@biloxi.com at R1, gets re-targeted by R1 to charlie@cambridge.com at R2, and R2 resolves it to charlie@trs80.cambridge.com (assuming Charlie's UA is trs80). > And I still don't see why C != E. It would only be different if loose > route was not > used by the proxies (e.g., RFC 2543 proxies). Is that what you mean? If > so, doesn't this > mean P-Called-Party-ID is essentially useless and IMS can't use it > anyways? So we should > just fix P-Called-Party-ID spec instead? I don't know that part. I am not taking any "side" on this issue. I am merely trying to bring clarity through ascii art. :) My personal experience is proxies replace req-uri during routing a LOT, even when they're not resolving AoR->contact nor "re-targeting". And what they're changing the req-uri to does not usually affect the identity of the called party, because the username portion is not being changed, and it's an e.164. So PCPID "works". But for this target-info use-case you want parameters from the original req-uri, and those may not be there by the time it gets to R2 and a PCPID is created. So that's my guess of why C != E. But it's just a guess. > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Francois Audet > > > > > > Can you give one. It seems to me that in both cases, the > > headers will > > > include the last Request-URI "just before it's replaced by > > the Contact > > > used in Registration". > > > > From a previous email I sent a long time ago, given the > > following reasonably complex scenario, where "RTRG" means > > Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and > > the single letters represent connections: > > > > RTRG RRT > > +---+ +---+ > > |R1 | |R2 | > > B /+---+\ C E /+---+\ F > > RT / \ RT RT / \ RT > > +---+/ \+---+ D +---+/ \+---+ > > |P1 | |P2 +---+P3 | |P4 | > > A /+---+ +---+ +---+ +---+\ G > > / \ > > +---+/ \+---+ > > |UAC| |UAS| > > +---+ +---+ > > > > Goal: to get the req-uri seen on "C" (right?). > > > > UA-Loose-routing sets the req-uri to that seen on connection "C". > > Target gives you C. > > PCPID gives you E. > > Hist-Info gives you A,B,C,D,E,F. > > To header gives you A. > > > > C != E, because P2 and P3 could be swapping req-uri's as they > > 3261 route. UALR draft says "stop swapping when you route", > > but Target draft does not. > > > > -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 sip-bounces@ietf.org Wed Apr 2 18:45:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2628928C1D8; Wed, 2 Apr 2008 18:45:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5408428C19C for ; Wed, 2 Apr 2008 18:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.868, 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 8Iqc4ArSudhj for ; Wed, 2 Apr 2008 18:45:56 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 418EF28C0D8 for ; Wed, 2 Apr 2008 18:45:56 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m331jnCb024018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 2 Apr 2008 20:45:51 -0500 Message-Id: <5C6820DA-CF95-4AAF-89B0-E61B9EF2B878@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 20:45:44 -0500 References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E395B9@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org" , "DOLLY, MARTIN C, ATTLABS" , Francois Audet , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 2, 2008, at 6:05 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> >> Re-Targeting (RTRG) is when a Proxy changes a Request-URI to a >> different >> one, outside of >> normal routing. That's ok. For example, bob@example.com to >> alice@example.com. >> What is the difference between RRT (Re-Routing) and Routing >> (Routing)? I >> don't get it. > > I believe, based on the email discussion back in January, that "Re- > Targeting" is when a Proxy re-targets the request to a new entity, > so yes for example from bob to charlie. In that situation, I > believe what both Jonathan and Christer want is the "target- > info" (the stuff we're trying to preserve) to be replaced by the new > set (charlie's set). > > Re-Routing is when the proxy/registrar replaces the req-uri due to > AoR->contact resolution. In that case we want to preserve the pre- > resolved target info. > The difference between retargeting and rerouting is that rerouting preserves the expected response identity, and retargeting doesn't. Assume connected-identity. In a "direct" call, one where no proxy routing is done, we'd expect to see that the identity sent by the target corresponds to the identity given for the target in the request URI. That is, if Alice has invited Bob, she's expecting the connected- identity to be sourced from Bob. This is preserved by typical "proxy contact routing", to which I applied the term "rerouting". The request URI gets changed by the proxy, but the targeted identity doesn't. So if Alice sends an INVITE for Bob's AOR to Bob's proxy, and Bob's proxy reroutes the INVITE to Bob's UA using a registered Contact, Bob still gets the call, and a connected-identity expressed by his UA will still be for "Bob". However, if Bob's proxy retargeted the request to SpanishInquisition, the connected identity would no longer match with the request. I call this the "unanticipated respondent problem". After all, nobody expects the Spanish Inquisition to answer Bob's calls. This could be a real problem is we were using security functions, since Alice might 1) not have keys for use with the Spanish Inquisition, and 2) Alice might reasonably wonder why they answered Bob's call. Had we instead used a 302 to redirect Alice to the Spanish Inquisition, she'd at least be forewarned. So, routing and rerouting operations imply that the response identity is equivalent to the pre-operation target identity. Retargeting implies that the response identity is not equivalent to the pre- operation target identity. > Routing is when a proxy routes. I believe the intention was that > this mean the proxy does not touch the req-uri, but my guess is > that's not agreed is reality. (more on that later) In RFC 2543, routing always required changing the ReqURI. RFC 3261 loose-routing changed this, and proxies only change the Request URI when changing the target. RFC 3261 does not distinguish between target changes that change the identity of the target and those that do not, hence the new terms "rerouting" and "retargeting". much text deleted . . . > > My personal experience is proxies replace req-uri during routing a > LOT, even when they're not resolving AoR->contact nor "re- > targeting". And what they're changing the req-uri to does not > usually affect the identity of the called party, because the > username portion is not being changed, and it's an e.164. So PCPID > "works". But for this target-info use-case you want parameters from > the original req-uri, and those may not be there by the time it gets > to R2 and a PCPID is created. So that's my guess of why C != E. But > it's just a guess. I'd call that operation rerouting, not routing. It is the functional equivalent of replacing the request-URI with a Contact -- it's just that the new request-URI is determined by some means other than registration against the AOR. This might be, for example, via static provisioning, or by matching against a TRIP routing table. The fact that the userparts encode phone numbers is essentially irrelevant to the question of what type of operation (routing, rerouting, retargeting) is used, although it might be very important to how the proxy might decide which operation to use and which destination to encode. -- 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 sip-bounces@ietf.org Wed Apr 2 22:19:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406703A6971; Wed, 2 Apr 2008 22:19:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB193A69CA for ; Wed, 2 Apr 2008 22:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, 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 LEzd3ijTo-g5 for ; Wed, 2 Apr 2008 22:19:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AB49E3A6971 for ; Wed, 2 Apr 2008 22:19: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.240.5; Thu, 3 Apr 2008 01:18:42 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 3 Apr 2008 01:18:42 -0400 From: Hadriel Kaplan To: Dean Willis Date: Thu, 3 Apr 2008 01:18:42 -0400 Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciVLGVFeLpoVzfNROaVY334S1XU/QAGwYLQ Message-ID: References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E395B9@zrc2hxm0.corp.nortel.com> <5C6820DA-CF95-4AAF-89B0-E61B9EF2B878@softarmor.com> In-Reply-To: <5C6820DA-CF95-4AAF-89B0-E61B9EF2B878@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "DOLLY, MARTIN C, ATTLABS" , Francois Audet , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > On Apr 2, 2008, at 6:05 PM, Hadriel Kaplan wrote: > > > Routing is when a proxy routes. I believe the intention was that > > this mean the proxy does not touch the req-uri, but my guess is > > that's not agreed is reality. (more on that later) > > In RFC 2543, routing always required changing the ReqURI. RFC 3261 > loose-routing changed this, and proxies only change the Request URI > when changing the target. RFC 3261 does not distinguish between target > changes that change the identity of the target and those that do not, > hence the new terms "rerouting" and "retargeting". Sorry I should have been clearer. I didn't mean it was in question what rfc3261 meant, I meant it was in question what "proxies" actually do. Now the quick answer is, if they don't do what 3261 says, those ain't "proxies". And I agree that I'm using a bad term here - I think the issue at hand is actually what real sip hops do in the real world, even those claiming to be a "proxy", not what rfc3261 Proxies (with a capital P) do. > I'd call that operation rerouting, not routing. It is the functional > equivalent of replacing the request-URI with a Contact -- it's just > that the new request-URI is determined by some means other than > registration against the AOR. This might be, for example, via static > provisioning, or by matching against a TRIP routing table. Or based on an ENUM response... > The fact > that the userparts encode phone numbers is essentially irrelevant to > the question of what type of operation (routing, rerouting, > retargeting) is used, although it might be very important to how the > proxy might decide which operation to use and which destination to > encode. Yes, exactly. And yet that proxy has absolutely no idea if it's re-routed or re-targeted by changing the hostpart. -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 sip-bounces@ietf.org Thu Apr 3 05:29:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E88028C65D; Thu, 3 Apr 2008 05:29:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614E33A69C9; Thu, 3 Apr 2008 05:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 gu7n71y1-UZt; Thu, 3 Apr 2008 05:29:39 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0DBBF3A6B48; Thu, 3 Apr 2008 05:29:38 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m33CSiL5024201; Thu, 3 Apr 2008 15:29:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:28:40 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:28:40 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:28:40 +0300 Message-ID: <47F4CD85.3090203@nokia.com> Date: Thu, 03 Apr 2008 15:28:53 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Ben Campbell References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> In-Reply-To: <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> X-OriginalArrivalTime: 03 Apr 2008 12:28:40.0505 (UTC) FILETIME=[3F969A90:01C89586] X-Nokia-AV: Clean Cc: Sip List , Simple WG Subject: Re: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ext Ben Campbell wrote: > Thanks for the quick response. My comments for anything that still > seems like an open issue are inline: > > > On Apr 2, 2008, at 5:04 AM, Jari Urpalainen wrote: >> ext Ben Campbell wrote: > > [...] > >>> Section 4.4, paragraph 1(clarity): >>> "The usage of hierarchical lists and >>> references, etc. can thus be omitted." >>> >>> You say that the usage of hierarchical lists and references >>> can be omitted. Are they actually being forbidden in this context, >>> or do you just mean to say that they are optional? If features of >>> the resource list format are forbidden, then this draft needs >>> normative language saying explicitly what is not to be used. If you >>> just mean to say that they are optional, what are the >>> interoperability issues if one device chooses to use them but the >>> peer does not understand them? > > Do you have any thoughts concerning the above comment? Sorry, i already made an actual fix, but forgot to reply. Yep, these are "sophisticated" features which don't bring in any value here --> "...MUST NOT be used" > >>> >>> >>> "As it is >>> anticipated that the XCAP server will be collocated with the SIP >>> notifier, the subscriber MAY use relative XCAP URIs." >>> >>> Is it the authors' intention to require this collocation? That seems >>> to be an architectural consequence of allowing relative URIs, unless >>> we assert that if an implementation is architected differently, it >>> is up to the implementation to be able to dereference relative URIs. >>> >> in practice, the sip notifier must be aware of changes made by >> another protocol, i.e. http in this case. If these servers (notifier >> & http (xcap) daemon) are separated they need some sort of immediate >> mechanism to signal these events. It can be done with some >> unspecified ways, but the most simple one is when they are running on >> the very same host. However, even that simplest case is pretty hard >> (or complex enough) to implement properly (implementation description >> can be a long story although you are using OSS tools, like e.g. linux >> with Apache + xcap_module and some decent Sip stack with all the >> source code), and the intention is to define only the very simplest >> use-case here. It is not ruled out that they were separated but that >> would be much, much more difficult to implement, and there are many >> obstacles and open issues there. So there's magic (outside the scope >> of this i-d) here how to map the sip-uri to the xcap-root-uri, but >> this, the most simple use-case is what i'd expect to be implemented >> (and maybe, even some minor deployment as well ;-)). >> >> Also we agreed with Miguel to be more explicit about this magic, does >> it sound sufficient to you ? > > Likely. As long as we mention the need for the notifier to learn about > changes at the XCAP server, and that such mechanisms are out of scope > for this document. It makes sense to mention collocation as an example > way to solve this, but it's only an example. > > [...] fine. > > >>> >>> Paragraph 3 (clarity): >>> >>> I'm not sure what the MUST applies to here--are you saying that the >>> server MUST check for the condition you list as an example, or >>> simply that, if the notifier chooses not to send XML-Patch-Ops >>> patches for reasons of local policy, it MUST fall back to >>> xcap-patching mode? >> the reason to drop the aggregation mode for that particular resource >> is that once the client have to use http, it might get out-of-sync >> (with "rapidly" changing resources), the rule is to be certain that >> it will not happen. I'll try to clarify. > > Thanks. I think it would be helpful to have a section dedicated > describing the issue, and mention the ways to work around it. > > [...] i 've added a whole new chapter about this into the "notifier generation" and re-arranged things so that it SHOULD be now much more unambiquous. > > >>> >>> "After that the >>> subscriber MAY send a re-subscription to start the diff "aggregation" >>> on the server." >>> >>> Does this mean to imply the subscriber cannot start out with >>> aggregation turned on? (I think this may be another case of >>> presenting the edge case without presenting the primary use case >>> first.) >> it can try to start in the aggregate mode straight away, but it may >> fail. So the safe way is to disable aggregation first before sync is >> achieved and enable it afterwards. I think I'll add something about >> this into those dreaded examples (in an appendix) > > See my previous comment about having a separate section to describe > the issue and possible solutions. It's also important that we are > clear on whether the delayed activation of "aggregation" mode is > simply an optional solution to a potential issue, or is a normative > requirement. > As the aggregate mode has its drawbacks when versioning is not supported in http, I think I've managed to fix the text... >> >>> >>> >>> Paragraph 2: (substantive) >>> >>> You cannot safely use non-sequential CSeq to detect missing NOTIFY >>> requests. For example, if the NOTIFY request is challenged by an >>> intervening proxy, the subscriber will see non-sequential CSeq >>> values. It may be unusual for NOTIFY to get challenged, but unless >>> we forbid it, then we cannot depend on CSeq for this purpose. >> ok, didn't think about that at all. > > This one needs some thought, then. There are actually a lot more > causes than just digest challenges that may cause the client to see > non-sequential CSeqs. If detection of lost notifies is critical, we > need another solution (either to detect lost notifies or to remove the > need to do so.) now I've managed to put this "utter crap" myself :-), sorry, i.e. unordering doesn't happen when the notifier acts _properly_, so it's better to move that text altogether. > >>> Section 4.10 (substantive) >>> >>> It's not clear to me how this interacts with the "aggregation" >>> mechanism. In particular, if the notifier has more than one change >>> in the 5 second window, but the subscriber did not allow >>> aggregation, how is it handled? >> yep this is indeed _difficult_. Easy to write (one sentence only), >> but really, really hard to implement properly ;-). First off there's >> a SHOULD directive fortunately... I'm not 100 % sure if you mean that >> xcap-patching is also disabled. So there's not a big difference in >> this context whether you have aggregation or xcap-patching modes, >> since in the xcap-patching mode you will see changes e.g. from "a" to >> "b" to "c" with all corresponding Etags while in the aggregate mode >> you'll see e.g. only changes from "a" to "c" in the notification body >> without the intermediate state. Certainly aggregation body is smaller >> but it fails to show the versioning history and the diff formats >> differ, but the end result will be the same certainly, i.e. "c". So >> _if_ you obey the timer, you wait for it to expire and then send the >> result in both cases (and of course during this timer interval you >> wait for any changes in these resources, and do something relevant, >> e.g. store internal object states). If there's not any patching >> modes applied, then you should wait for the timer to expire and send >> appropriate actions, i.e. document(s) has either been created, >> modified or deleted. > > I'm not sure I understand what you mean on the last two sentences--can > you give an example? btw. just noted that a rate limit was per a _user_ what would that mean ? so should be per _subscription_. let's say you'll notify a initial document at some time x. then comes two changes 1 & 2 for the same document within 2 seconds (ETags are those timestamps): NOTIFY 1 -- x change 1 -- x+1s. change 2 -- x+2s. NOTIFY 2 -- x+5s. so if those two changes are reported (NOTIFY 2) _without any patching_ you'll report the document uri reference with Etags at time x+5s due to this 5s rate limitation: with xcap-patching you could have: while with the "aggregate" mode: So the first one shows the simplest case, and then the more complex xcap-patching and lastly aggregate, does this help ? I've the intention to add something similar to an appendix regardless of the pain... So as can be seen from the example "aggregate" and "xcap-patching" both aggregate patches, but the "real" aggregate can do much clever decisions with the added complexity. And i've made it now explicit that the notifier MAY respond with all of these 3 ways if aggregate is requested. If notifier requests xcap-patching "aggregate" MUST NOT be used, and with "no-patching" naturally only the simplest mode is allowed. > >> IIRC, in partial PIDF where we use the exact same patchings there's >> not a single line about this since this timer is inherited from the >> base PIDF package. In summary, you just don't have to do anything >> mysterious with timers except wait for a certain period of time. In >> practice, it happens to be quite a challenging task (but these specs >> usually _ignore_ the implementation PITA ;-)) > > It's still not clear to me if this is just a "hard implementation" > problem or if it is really a conflict in normative requirements. > Coding aside, what do you expect the most commen behavior to be if > multiple changes occur inside the 5 second window, but the client has > not allowed aggregation? (The example requested above might help me > understand this.) > imo it is not a conflict, just a PITA in implementations, though sometimes a very nice optimization. >> >>> >>> Section 5, figure 3 (clarity): >>> >>> It would be nice to see this in context of an actual NOTIFY. >> I'll try to digest something into an appendix. That being said, the >> important things are bodies... > > To some degree, it is up to the companion draft to define the body in > detail--this draft really talks about the SIP-event package, so I do > think it is appropriate to show real message flows including the SIP > parts. > > [...] > yep, though from sip event pov. only the event-paramer and conditional headers are really relevant, and indeed the body examples are not shown in other specs, which allow virtually everything. In this case, this package _requires_ those limitations to those formats with/without patching, so it is definitely good to have good examples. >>> >>> Section 7, Security Considerations (substantive) >>> >>> I think we need more here. What sort of authentication is adequate >>> (particularly for authenticating the notifier.) Does the potential >>> sensitive content create any need for privacy and integrity >>> protection beyond that generically needed for SIP-Events? >>> >> yep, besides DoS TLS & S/MIME recommendations some text about >> identity "mapping" between http & sip would be reasonable. Anything >> else ? > > I had not thought of the identity mapping issue--that discussion > always seems to get more "interesting" than you might expect :-) It > might be worth adding SIPS thoughts to any TLS discussion. yep. > > Thanks! > > Ben. Thanks again, Jari _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 3 06:28:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB3428C64B; Thu, 3 Apr 2008 06:28:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7394C28C1B6; Thu, 3 Apr 2008 06:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, 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 EHnkTZzBIyeE; Thu, 3 Apr 2008 06:28:54 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id A77363A6AF4; Thu, 3 Apr 2008 06:28:53 -0700 (PDT) Received: from [10.0.1.193] (adsl-68-94-18-109.dsl.rcsntx.swbell.net [68.94.18.109]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m33DSolE050096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2008 08:28:54 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Jari Urpalainen In-Reply-To: <47F4CD85.3090203@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 08:28:49 -0500 References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> <47F4CD85.3090203@nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: Re: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 3, 2008, at 7:28 AM, Jari Urpalainen wrote: [...] >>> >>>> >>>> >>>> Paragraph 2: (substantive) >>>> >>>> You cannot safely use non-sequential CSeq to detect missing >>>> NOTIFY requests. For example, if the NOTIFY request is challenged >>>> by an intervening proxy, the subscriber will see non-sequential >>>> CSeq values. It may be unusual for NOTIFY to get challenged, but >>>> unless we forbid it, then we cannot depend on CSeq for this >>>> purpose. >>> ok, didn't think about that at all. >> >> This one needs some thought, then. There are actually a lot more >> causes than just digest challenges that may cause the client to see >> non-sequential CSeqs. If detection of lost notifies is critical, we >> need another solution (either to detect lost notifies or to remove >> the need to do so.) > now I've managed to put this "utter crap" myself :-), sorry, i.e. > unordering doesn't happen when the notifier acts _properly_, so it's > better to move that text altogether. The text was more about missing NOTIFY requests than it was out-of- order NOTIFYs (CSeq will actually catch the out-of-order case). Are you saying that it is okay to not be able to detect missing NOTIFYs, even in patch mode? Note that missing and out-of-order notifies can (rarely, we hope) happen due to intervening devices even if the notifier is perfectly well behaved. > >> >>>> Section 4.10 (substantive) >>>> >>>> It's not clear to me how this interacts with the "aggregation" >>>> mechanism. In particular, if the notifier has more than one >>>> change in the 5 second window, but the subscriber did not allow >>>> aggregation, how is it handled? >>> yep this is indeed _difficult_. Easy to write (one sentence only), >>> but really, really hard to implement properly ;-). First off >>> there's a SHOULD directive fortunately... I'm not 100 % sure if >>> you mean that xcap-patching is also disabled. So there's not a big >>> difference in this context whether you have aggregation or xcap- >>> patching modes, since in the xcap-patching mode you will see >>> changes e.g. from "a" to "b" to "c" with all corresponding Etags >>> while in the aggregate mode you'll see e.g. only changes from "a" >>> to "c" in the notification body without the intermediate state. >>> Certainly aggregation body is smaller but it fails to show the >>> versioning history and the diff formats differ, but the end result >>> will be the same certainly, i.e. "c". So _if_ you obey the timer, >>> you wait for it to expire and then send the result in both cases >>> (and of course during this timer interval you wait for any changes >>> in these resources, and do something relevant, e.g. store internal >>> object states). If there's not any patching modes applied, then >>> you should wait for the timer to expire and send appropriate >>> actions, i.e. document(s) has either been created, modified or >>> deleted. >> >> I'm not sure I understand what you mean on the last two sentences-- >> can you give an example? > btw. just noted that a rate limit was per a _user_ what would that > mean ? so should be per _subscription_. > > let's say you'll notify a initial document at some time x. then > comes two changes 1 & 2 for the same document within 2 seconds > (ETags are those timestamps): > NOTIFY 1 -- x change 1 -- x+1s. > change 2 -- x+2s. > NOTIFY 2 -- x+5s. > > so if those two changes are reported (NOTIFY 2) _without any > patching_ you'll report the document uri reference with Etags at > time x+5s due to this 5s rate limitation: > > sel="resource-lists/users/sip:joe@example.com/coworkers" > previous-etag="x"/> > > > with xcap-patching you could have: > > > sel="resource-lists/users/sip:joe@example.com/coworkers" > previous-etag="x"> > > > sel="resource-lists/users/sip:joe@example.com/coworkers" > previous-etag="x+1s"> > > > ' Ah, I see you are effectively listing both change events in a single xcap-diff document, but still as separate events. That makes sense, but it was not obvious to me from the text that you could do this. I don't recall if the data format doc addressed it or not. It would definitely help to include examples for each mode of operation. > > > while with the "aggregate" mode: > > > sel="resource-lists/users/sip:joe@example.com/coworkers" > previous-etag="x"> > > > > > So the first one shows the simplest case, and then the more complex > xcap-patching and lastly aggregate, does this help ? I've the > intention to add something similar to an appendix regardless of the > pain... > > So as can be seen from the example "aggregate" and "xcap-patching" > both aggregate patches, but the "real" aggregate can do much clever > decisions with the added complexity. > > And i've made it now explicit that the notifier MAY respond with all > of these 3 ways if aggregate is requested. If notifier requests xcap- > patching "aggregate" MUST NOT be used, and with "no-patching" > naturally only the simplest mode is allowed. > >> >>> IIRC, in partial PIDF where we use the exact same patchings >>> there's not a single line about this since this timer is inherited >>> from the base PIDF package. In summary, you just don't have to do >>> anything mysterious with timers except wait for a certain period >>> of time. In practice, it happens to be quite a challenging task >>> (but these specs usually _ignore_ the implementation PITA ;-)) >> >> It's still not clear to me if this is just a "hard implementation" >> problem or if it is really a conflict in normative requirements. >> Coding aside, what do you expect the most commen behavior to be if >> multiple changes occur inside the 5 second window, but the client >> has not allowed aggregation? (The example requested above might >> help me understand this.) >> > imo it is not a conflict, just a PITA in implementations, though > sometimes a very nice optimization. I _think_ I am okay with this, pending seeing the new text. [...] Thanks! Ben. _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 3 07:39:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FEB28C603; Thu, 3 Apr 2008 07:39:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FC328C11E; Thu, 3 Apr 2008 07:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 GgePqLKKn08P; Thu, 3 Apr 2008 07:39:51 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EF43728C693; Thu, 3 Apr 2008 07:39:50 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m33EeVjV013977; Thu, 3 Apr 2008 09:41:57 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 17:39:10 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 17:39:10 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 17:39:10 +0300 Message-ID: <47F4EC1A.3030301@nokia.com> Date: Thu, 03 Apr 2008 17:39:22 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Ben Campbell References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> <47F4CD85.3090203@nokia.com> In-Reply-To: X-OriginalArrivalTime: 03 Apr 2008 14:39:10.0339 (UTC) FILETIME=[7A887530:01C89598] X-Nokia-AV: Clean Cc: Sip List , Simple WG Subject: Re: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ext Ben Campbell wrote: > > On Apr 3, 2008, at 7:28 AM, Jari Urpalainen wrote: > > [...] > >>>> >>>>> >>>>> >>>>> Paragraph 2: (substantive) >>>>> >>>>> You cannot safely use non-sequential CSeq to detect missing NOTIFY >>>>> requests. For example, if the NOTIFY request is challenged by an >>>>> intervening proxy, the subscriber will see non-sequential CSeq >>>>> values. It may be unusual for NOTIFY to get challenged, but unless >>>>> we forbid it, then we cannot depend on CSeq for this purpose. >>>> ok, didn't think about that at all. >>> >>> This one needs some thought, then. There are actually a lot more >>> causes than just digest challenges that may cause the client to see >>> non-sequential CSeqs. If detection of lost notifies is critical, we >>> need another solution (either to detect lost notifies or to remove >>> the need to do so.) >> now I've managed to put this "utter crap" myself :-), sorry, i.e. >> unordering doesn't happen when the notifier acts _properly_, so it's >> better to move that text altogether. > > The text was more about missing NOTIFY requests than it was > out-of-order NOTIFYs (CSeq will actually catch the out-of-order case). > Are you saying that it is okay to not be able to detect missing > NOTIFYs, even in patch mode? Note that missing and out-of-order > notifies can (rarely, we hope) happen due to intervening devices even > if the notifier is perfectly well behaved. > the implicit rule _now_ for the notifier is: if you don't get a final 200 ack for a notify, do not send a new request and for a timeout, tear down the session (this is what i propose but as explicit). So what happens with 4xx, 5xx, 6xx etc is unspecified. So the rule for waiting for the 200 OK rules out-of-order. So if you get 4/5/6xx will that mean drop-out possibility ? no imo, since you can't send a new one unless the previous one has been sent successfully. So personally i _could_ go that far that tear down always if return code != 200, but probably some intelligent notifiers could resolve e.g. 413, though i have my doubts.... >>> >>>>> Section 4.10 (substantive) >>>>> >>>>> It's not clear to me how this interacts with the "aggregation" >>>>> mechanism. In particular, if the notifier has more than one change >>>>> in the 5 second window, but the subscriber did not allow >>>>> aggregation, how is it handled? >>>> yep this is indeed _difficult_. Easy to write (one sentence only), >>>> but really, really hard to implement properly ;-). First off >>>> there's a SHOULD directive fortunately... I'm not 100 % sure if you >>>> mean that xcap-patching is also disabled. So there's not a big >>>> difference in this context whether you have aggregation or >>>> xcap-patching modes, since in the xcap-patching mode you will see >>>> changes e.g. from "a" to "b" to "c" with all corresponding Etags >>>> while in the aggregate mode you'll see e.g. only changes from "a" >>>> to "c" in the notification body without the intermediate state. >>>> Certainly aggregation body is smaller but it fails to show the >>>> versioning history and the diff formats differ, but the end result >>>> will be the same certainly, i.e. "c". So _if_ you obey the timer, >>>> you wait for it to expire and then send the result in both cases >>>> (and of course during this timer interval you wait for any changes >>>> in these resources, and do something relevant, e.g. store internal >>>> object states). If there's not any patching modes applied, then >>>> you should wait for the timer to expire and send appropriate >>>> actions, i.e. document(s) has either been created, modified or >>>> deleted. >>> >>> I'm not sure I understand what you mean on the last two >>> sentences--can you give an example? >> btw. just noted that a rate limit was per a _user_ what would that >> mean ? so should be per _subscription_. >> >> let's say you'll notify a initial document at some time x. then comes >> two changes 1 & 2 for the same document within 2 seconds (ETags are >> those timestamps): >> NOTIFY 1 -- x change 1 -- x+1s. >> change 2 -- x+2s. >> NOTIFY 2 -- x+5s. >> >> so if those two changes are reported (NOTIFY 2) _without any >> patching_ you'll report the document uri reference with Etags at time >> x+5s due to this 5s rate limitation: >> >> > sel="resource-lists/users/sip:joe@example.com/coworkers" >> previous-etag="x"/> >> >> >> with xcap-patching you could have: >> >> >> > sel="resource-lists/users/sip:joe@example.com/coworkers" >> previous-etag="x"> >> >> >> > sel="resource-lists/users/sip:joe@example.com/coworkers" >> previous-etag="x+1s"> >> >> >> ' > > Ah, I see you are effectively listing both change events in a single > xcap-diff document, but still as separate events. That makes sense, > but it was not obvious to me from the text that you could do this. I > don't recall if the data format doc addressed it or not. It would > definitely help to include examples for each mode of operation. > it is in the format spec, it was implicit in some older versions, but i fixed that: "If several elements with the same "sel" selector value exist in the XCAP diff document, i.e. for example, the full ETag change history is indicated, the corresponding patches MUST be appliable in the given document order." >> >> >> while with the "aggregate" mode: >> >> >> > sel="resource-lists/users/sip:joe@example.com/coworkers" >> previous-etag="x"> >> >> >> >> >> So the first one shows the simplest case, and then the more complex >> xcap-patching and lastly aggregate, does this help ? I've the >> intention to add something similar to an appendix regardless of the >> pain... >> >> So as can be seen from the example "aggregate" and "xcap-patching" >> both aggregate patches, but the "real" aggregate can do much clever >> decisions with the added complexity. >> >> And i've made it now explicit that the notifier MAY respond with all >> of these 3 ways if aggregate is requested. If notifier requests >> xcap-patching "aggregate" MUST NOT be used, and with "no-patching" >> naturally only the simplest mode is allowed. >> >>> >>>> IIRC, in partial PIDF where we use the exact same patchings there's >>>> not a single line about this since this timer is inherited from the >>>> base PIDF package. In summary, you just don't have to do anything >>>> mysterious with timers except wait for a certain period of time. In >>>> practice, it happens to be quite a challenging task (but these >>>> specs usually _ignore_ the implementation PITA ;-)) >>> >>> It's still not clear to me if this is just a "hard implementation" >>> problem or if it is really a conflict in normative requirements. >>> Coding aside, what do you expect the most commen behavior to be if >>> multiple changes occur inside the 5 second window, but the client >>> has not allowed aggregation? (The example requested above might help >>> me understand this.) >>> >> imo it is not a conflict, just a PITA in implementations, though >> sometimes a very nice optimization. > > I _think_ I am okay with this, pending seeing the new text. > > [...] > > Thanks! > > Ben. > great, i really hope you have time to look at the updated text when i get it "fully" ready with those reasonable examples ... thanks, Jari _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 3 08:18:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD3028C6B1; Thu, 3 Apr 2008 08:18:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30ED93A6C9B; Thu, 3 Apr 2008 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[AWL=2.201, 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 DfuMmDQS41Mb; Thu, 3 Apr 2008 08:18:20 -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 55B733A6C61; Thu, 3 Apr 2008 08:18:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,599,1199692800"; d="scan'208";a="19791982" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 03 Apr 2008 08:18:24 -0700 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 m33FIMlX018119; Thu, 3 Apr 2008 08:18:22 -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 m33FIISR013418; Thu, 3 Apr 2008 15:18:22 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); Thu, 3 Apr 2008 11:18:21 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 11:18:20 -0400 Message-ID: <47F4F555.9020505@cisco.com> Date: Thu, 03 Apr 2008 11:18:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jari Urpalainen References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> <47F4CD85.3090203@nokia.com> <47F4EC1A.3030301@nokia.com> In-Reply-To: <47F4EC1A.3030301@nokia.com> X-OriginalArrivalTime: 03 Apr 2008 15:18:20.0696 (UTC) FILETIME=[F3747980:01C8959D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1094; t=1207235902; x=1208099902; 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]=20WGLC=20Comments=20on=20draft-ie tf-sip-xcapevent-01 |Sender:=20; bh=Vls3Jntkl1BGrjLZWoAlxs/3KST9HkIysB5OFZaBj8o=; b=R/1TmGj1voecDTavFhouRD5UhRe0SSc+tXE7iEKqb+1qSbamigoRY4JQ82 ufr4uTmDui5w52yzmFQ8H/ZLUjXUgCUjyT4eoqklFM+YqVxaEs5vhkcNF2Ul /9KwRLJ9DY; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Sip List , Simple WG Subject: Re: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jari Urpalainen wrote: > the implicit rule _now_ for the notifier is: if you don't get a final > 200 ack for a notify, do not send a new request and for a timeout, tear > down the session (this is what i propose but as explicit). So what > happens with 4xx, 5xx, 6xx etc is unspecified. So the rule for waiting > for the 200 OK rules out-of-order. So if you get 4/5/6xx will that mean > drop-out possibility ? no imo, since you can't send a new one unless the > previous one has been sent successfully. So personally i _could_ go that > far that tear down always if return code != 200, but probably some > intelligent notifiers could resolve e.g. 413, though i have my doubts.... It is always be possible to get a 401 or 407 response to a NOTIFY, and it should be possible to retry it with the proper credentials. That ought not screw up the subscription. This could happen because your nonce expired on a long lived subscription. Admittedly it would be pretty odd to have authorization in the NOTIFY direction, but it could be possible I think. 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 sip-bounces@ietf.org Thu Apr 3 08:46:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670833A6C16; Thu, 3 Apr 2008 08:46:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F03B3A6963; Thu, 3 Apr 2008 08:46:03 -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 Ryzb4DjlA6HZ; Thu, 3 Apr 2008 08:45:59 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id DF1F43A6BF7; Thu, 3 Apr 2008 08:45:58 -0700 (PDT) Received: from [172.16.3.213] ([172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m33Fk0d7065571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2008 10:46:00 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Jari Urpalainen In-Reply-To: <47F4EC1A.3030301@nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 10:45:59 -0500 References: <5DDFCB0D-ADEC-49A7-BDDC-4112A011CAF8@estacado.net> <47F35A1E.4070109@nokia.com> <208326E5-B78C-49E3-BADC-B1CE94FE2963@estacado.net> <47F4CD85.3090203@nokia.com> <47F4EC1A.3030301@nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: Sip List , Simple WG Subject: Re: [Sip] WGLC Comments on draft-ietf-sip-xcapevent-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 3, 2008, at 9:39 AM, Jari Urpalainen wrote: [...] >>>>>> You cannot safely use non-sequential CSeq to detect missing >>>>>> NOTIFY requests. For example, if the NOTIFY request is >>>>>> challenged by an intervening proxy, the subscriber will see non- >>>>>> sequential CSeq values. It may be unusual for NOTIFY to get >>>>>> challenged, but unless we forbid it, then we cannot depend on >>>>>> CSeq for this purpose. >>>>> ok, didn't think about that at all. >>>> >>>> This one needs some thought, then. There are actually a lot more >>>> causes than just digest challenges that may cause the client to >>>> see non-sequential CSeqs. If detection of lost notifies is >>>> critical, we need another solution (either to detect lost >>>> notifies or to remove the need to do so.) >>> now I've managed to put this "utter crap" myself :-), sorry, i.e. >>> unordering doesn't happen when the notifier acts _properly_, so >>> it's better to move that text altogether. >> >> The text was more about missing NOTIFY requests than it was out-of- >> order NOTIFYs (CSeq will actually catch the out-of-order case). Are >> you saying that it is okay to not be able to detect missing >> NOTIFYs, even in patch mode? Note that missing and out-of-order >> notifies can (rarely, we hope) happen due to intervening devices >> even if the notifier is perfectly well behaved. >> > the implicit rule _now_ for the notifier is: if you don't get a > final 200 ack for a notify, do not send a new request and for a > timeout, tear down the session (this is what i propose but as > explicit). So what happens with 4xx, 5xx, 6xx etc is unspecified. > So the rule for waiting for the 200 OK rules out-of-order. So if you > get 4/5/6xx will that mean drop-out possibility ? no imo, since you > can't send a new one unless the previous one has been sent > successfully. So personally i _could_ go that far that tear down > always if return code != 200, but probably some intelligent > notifiers could resolve e.g. 413, though i have my doubts.... Ah, I _think_ that helps, although keep in mind that not all non-200 responses necessarily indicate the subscription should be torn down. _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 3 09:07:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD53C28C1DA; Thu, 3 Apr 2008 09:07:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9189C3A6963; Thu, 3 Apr 2008 09:07:31 -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 JpNcnYo03mAR; Thu, 3 Apr 2008 09:07: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 ADE6328C15E; Thu, 3 Apr 2008 09:07:22 -0700 (PDT) Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m33G7LmH077909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2008 11:07:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <7730830D-3D30-488B-AC9D-59650CF6831E@nostrum.com> From: Robert Sparks To: Robert Sparks In-Reply-To: <3A1B9984-4751-48B6-96D9-E4058E4CBDE7@estacado.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 11:07:20 -0500 References: <43A3E655-E3C8-406A-B6FA-8BFCC64F0A63@estacado.net> <3A1B9984-4751-48B6-96D9-E4058E4CBDE7@estacado.net> X-Mailer: Apple Mail (2.919.2) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.92.1/6567/Thu Apr 3 07:31:07 2008 on shaman.nostrum.com X-Virus-Status: Clean Cc: sip List , sipping LIST , simple mailing list Subject: [Sip] Final Reminder: SIPit 22 registration closes tomorrow (Friday) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Registration for this SIPit closes this Friday (April 4). If you've been waiting for the deadline to register - this is it. RjS ------------ SIPit 22 will be hosted by the University of New Hampshire Interoperability Laboratory April 14 through 18, 2008. Registration is $350 (USD) per person. Registration will close April 4. Space is limited, so register early to ensure a seat. Additional registration details are available at http://www.sipit.net _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 3 10:52:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279623A6D9E; Thu, 3 Apr 2008 10:52:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5BD3A6F5D for ; Thu, 3 Apr 2008 10:52:48 -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 sDmyGm5cTkDu for ; Thu, 3 Apr 2008 10:52:47 -0700 (PDT) Received: from web54407.mail.yahoo.com (web54407.mail.yahoo.com [206.190.49.137]) by core3.amsl.com (Postfix) with SMTP id 88A1E3A6D9E for ; Thu, 3 Apr 2008 10:52:47 -0700 (PDT) Received: (qmail 42075 invoked by uid 60001); 3 Apr 2008 17:52:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=fMe7tWtyR+1XXEN3tYjW4HtsXMJ9FjdYBm7tvEe8xlmH0Oje8frmbg8Emf6HZj6uv4idDczC6R3gGjZmIQ88rNMmjY8hrJIIE/K1dxuf8KI7QUUY41Q9aWHOsbUovWJXEuygEMVw2BEOMK86EcIbGWCFYAycXQBmqoA9hdhnwl0=; Received: from [67.154.126.166] by web54407.mail.yahoo.com via HTTP; Thu, 03 Apr 2008 10:52:50 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 3 Apr 2008 10:52:50 -0700 (PDT) From: gaurav khurana To: sip@ietf.org MIME-Version: 1.0 Message-ID: <962757.42045.qm@web54407.mail.yahoo.com> Subject: [Sip] Doubt in Invite client transaction - proceeding state X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1130656643==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1130656643== Content-Type: multipart/alternative; boundary="0-1363077578-1207245170=:42045" --0-1363077578-1207245170=:42045 Content-Type: text/plain; charset=us-ascii Hi, I looked into the previous threads too but couldn't clarify my doubt, so posting the question again. My question is that how long will the client transaction be alive once we enter in proceeding state. Previous threads suggest transaction will terminate when timer B, i.e. 64*T1 expires. But, what I see in RFC3261 - 17.1.1.2 fig. 5 (INVITE Client transaction) that timer B fires only in Calling state. There's no timer shown for proceeding state. Does it mean that in proceeding state, the transaction will not terminate until the caller disconnects the call manually? GAURAV KHURANA # 91-9886646104 ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com --0-1363077578-1207245170=:42045 Content-Type: text/html; charset=us-ascii
Hi,

I looked into the previous threads too but couldn't clarify my doubt, so posting the question again.

My question is that how long will the client transaction be alive once we enter in proceeding state.

Previous threads suggest transaction will terminate when timer B, i.e. 64*T1 expires. But, what I see in RFC3261 - 17.1.1.2 fig. 5 (INVITE Client transaction) that timer B fires only in Calling state. There's no timer shown for proceeding state.

Does it mean that in proceeding state, the transaction will not terminate until the caller disconnects the call manually?
 
GAURAV KHURANA
# 91-9886646104


You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. --0-1363077578-1207245170=:42045-- --===============1130656643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1130656643==-- From sip-bounces@ietf.org Thu Apr 3 12:11:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4153928C76D; Thu, 3 Apr 2008 12:11:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5D828C749 for ; Thu, 3 Apr 2008 12:11:01 -0700 (PDT) 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.757, 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 8nvFIyogYTxm for ; Thu, 3 Apr 2008 12:10:48 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 3749528C7C2 for ; Thu, 3 Apr 2008 12:08:51 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m33J8nn28953; Thu, 3 Apr 2008 19:08:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 14:08:36 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15E794FB@zrc2hxm0.corp.nortel.com> In-Reply-To: <5C6820DA-CF95-4AAF-89B0-E61B9EF2B878@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciVLHmMqUP8i5x2QOycQ22zr2l1xwAkOK8A References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E395B9@zrc2hxm0.corp.nortel.com> <5C6820DA-CF95-4AAF-89B0-E61B9EF2B878@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Hadriel Kaplan" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, this just proves that it ain't that clear. Looks like Dean's definition of "re-routing" is broader than Hadriel's since it includes strict routing in "the middle" not just "the end". Whatever we do, we should get clear terms for "re-routing". Jonathan's draft had the merit to make all this clearer. Anyways, thanks Hadriel for confirming my understanding of your diagram. I still don't see the difference between P-Called-ID and Target, i.e., "what are the cases where C != E", unless there is 2543-style strict routing. And if there is, then I fail to see how P-Called-ID would be used: seems to me if P-Called-ID points to C instead of E, it is broken and should be fixed. Of course maybe it's my non-existent knowledge of IMS. My question to Christer would be "Is P-Called-ID as defined today, pointing to C, broken???". > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, April 02, 2008 18:46 > To: Hadriel Kaplan > Cc: Audet, Francois (SC100:3055); Christer Holmberg; Hans > Erik van Elburg; Juha Heinanen; sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > > On Apr 2, 2008, at 6:05 PM, Hadriel Kaplan wrote: > > > > > >> -----Original Message----- > >> From: Francois Audet [mailto:audet@nortel.com] > >> > >> Re-Targeting (RTRG) is when a Proxy changes a Request-URI to a > >> different one, outside of normal routing. That's ok. For example, > >> bob@example.com to alice@example.com. > >> What is the difference between RRT (Re-Routing) and Routing > >> (Routing)? I don't get it. > > > > I believe, based on the email discussion back in January, that "Re- > > Targeting" is when a Proxy re-targets the request to a new > entity, so > > yes for example from bob to charlie. In that situation, I believe > > what both Jonathan and Christer want is the "target- info" > (the stuff > > we're trying to preserve) to be replaced by the new set (charlie's > > set). > > > > Re-Routing is when the proxy/registrar replaces the req-uri due to > > AoR->contact resolution. In that case we want to preserve the pre- > > resolved target info. > > > > The difference between retargeting and rerouting is that > rerouting preserves the expected response identity, and > retargeting doesn't. > > Assume connected-identity. In a "direct" call, one where no > proxy routing is done, we'd expect to see that the identity > sent by the target corresponds to the identity given for the > target in the request URI. > > That is, if Alice has invited Bob, she's expecting the > connected- identity to be sourced from Bob. > > This is preserved by typical "proxy contact routing", to > which I applied the term "rerouting". The request URI gets > changed by the proxy, but the targeted identity doesn't. > > So if Alice sends an INVITE for Bob's AOR to Bob's proxy, and > Bob's proxy reroutes the INVITE to Bob's UA using a > registered Contact, Bob still gets the call, and a > connected-identity expressed by his UA will still be for "Bob". > > However, if Bob's proxy retargeted the request to > SpanishInquisition, the connected identity would no longer > match with the request. I call this the "unanticipated > respondent problem". After all, nobody expects the Spanish > Inquisition to answer Bob's calls. > > This could be a real problem is we were using security > functions, since Alice might 1) not have keys for use with > the Spanish Inquisition, and 2) Alice might reasonably wonder > why they answered Bob's call. > > Had we instead used a 302 to redirect Alice to the Spanish > Inquisition, she'd at least be forewarned. > > So, routing and rerouting operations imply that the response > identity is equivalent to the pre-operation target identity. > Retargeting implies that the response identity is not > equivalent to the pre- operation target identity. > > > > Routing is when a proxy routes. I believe the intention > was that this > > mean the proxy does not touch the req-uri, but my guess is > that's not > > agreed is reality. (more on that later) > > In RFC 2543, routing always required changing the ReqURI. > RFC 3261 loose-routing changed this, and proxies only change > the Request URI when changing the target. RFC 3261 does not > distinguish between target changes that change the identity > of the target and those that do not, hence the new terms > "rerouting" and "retargeting". > > much text deleted . . . > > > > > My personal experience is proxies replace req-uri during routing a > > LOT, even when they're not resolving AoR->contact nor "re- > targeting". > > And what they're changing the req-uri to does not usually > affect the > > identity of the called party, because the username portion is not > > being changed, and it's an e.164. So PCPID "works". But for this > > target-info use-case you want parameters from the original req-uri, > > and those may not be there by the time it gets to R2 and a PCPID is > > created. So that's my guess of why C != E. But it's just a guess. > > I'd call that operation rerouting, not routing. It is the > functional equivalent of replacing the request-URI with a > Contact -- it's just that the new request-URI is determined > by some means other than registration against the AOR. This > might be, for example, via static provisioning, or by > matching against a TRIP routing table. The fact that the > userparts encode phone numbers is essentially irrelevant to > the question of what type of operation (routing, rerouting, > retargeting) is used, although it might be very important to > how the proxy might decide which operation to use and which > destination to encode. > > -- > 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 sip-bounces@ietf.org Thu Apr 3 13:57:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B813A6C0D; Thu, 3 Apr 2008 13:57:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A37A28C371 for ; Thu, 3 Apr 2008 13:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[AWL=2.248, 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 ybc9RkEW2Rwj for ; Thu, 3 Apr 2008 13:57:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 096FB3A69BA for ; Thu, 3 Apr 2008 13:57:49 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2BAA020CDE; Thu, 3 Apr 2008 22:49:16 +0200 (CEST) X-AuditID: c1b4fb3e-ae198bb000004ec0-f1-47f542cbd3f7 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F351920996; Thu, 3 Apr 2008 22:49:15 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 22:49:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 22:48:26 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals thread-index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgACHxX6A= References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Hans Erik van Elburg" , "Juha Heinanen" X-OriginalArrivalTime: 03 Apr 2008 20:49:15.0778 (UTC) FILETIME=[2E018E20:01C895CC] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, The P-Called-Party-ID is only inserted by the registrar of the UAS, while the Target can be inserted also by other entities. Regards, Christer -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: 2. huhtikuuta 2008 22:21 To: Christer Holmberg; Hans Erik van Elburg; Juha Heinanen Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals As much as I read this, I still can't figure an example where the P-Called-Header and the Target header are different: As defined in RFC3455 [5], if a SIP entity, which acts as registrar/ home proxy for the terminating user, re-writes the Request-URI with the contact address of the registered UA it may insert a P-Called- Party-ID header field with the previous value of the Request-URI. The Target header field and P-Called-Party-ID header field have different semantics. The Target header field represents the current target identity, while the P-Called-Party-ID represents the last Request-URI value used to reach the user before the Request-URI value was re-written with the Contact address of the UAS. In some cases the P-Called-Party-ID may be the same as the current target but, it may also be the last route taken (not equal to the current target) to deliver the request. Therefore the P-Called-Party-ID can not be used in a generic SIP environment to represent the current target. Can you give one. It seems to me that in both cases, the headers will include the last Request-URI "just before it's replaced by the Contact used in Registration". Moving to History-Info... The current text in History-Info is not clear at all about recording both "current target" and recording the target that corresponds to the "Contact that was used in Registration" for the last hop. In fact, none of the example illustrate the process. The implication from the examples is that the proxy retargetting would magically know the contact address. My personal preference would be to up-issue History-Info to have a clear indication (say a History-Info parameter) that identifies the Contact, plus some rule mandating that the previous entry would be the last target. I would also want to fix all the examples to illustrate it. I will note that for that approach to work, History-Info only needs to be supported at the terminating retargeting proxy (just like target header). The alternative is to use the proposed Target header. If we decide to go that route, I still think that we need to up-issue History-Info (if anything to illustrates how the Target header works in conjunction to it). In either case I think we need to update History-Info at the same time as we fix this problem. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, April 02, 2008 10:19 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Juha Heinanen > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > > Francois, > > I believe the confusion you are talking about was related to the first > version of the draft, where we also talked about the P-Called-Party-ID > header etc. > > I tried to clarify that, and make the second version of the draft more > clear. Based on the comments I have received the issues were > solved/clarified in the second version of the draft. > > The only text left about P-Called-Party-ID is the paragraph where we > DO explain the difference between it and Target. > > Regards, > > Christer > > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 2. huhtikuuta 2008 19:19 > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > The loose-route proposal is clear, but attempts to solve a much larger > problem. > > The new header proposal is very far from clear, as was demonstrated by > the mailing list discussion, where nobody seems to agree on what the > header was supposed to mean. Most people didn't understand why it was > different than the P-Called-ID (or whatever that was). > > Furthermore, what would that header actually mean? Is is the original > target as inserted by the first UAC? If so, why is it different than > the To header? Is it the target as modified by the originating > domain's proxy (for example, "fixing" the phone number to make it into > a real > E.164 number in a Tel or SIP URI?)? Or is it the last retargeting > address? Or any retargeting in between? And how do you define > retargeting in the first place? > > The answers that Christer provided actually confused people who tought > they understood the proposal (i.e., people who tought we were talking > about the P-Called header). > > And finally, somebody needs to demonstrate how this can not overlap > with History-Info. Saying its "simpler" is misleading. It's simpler > until we analyse completely what we are actually shooting for. > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > > Sent: Wednesday, April 02, 2008 02:43 > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > It is clearly not the same as History-Info header as has been > > explained in the draft and in several previous threads. It has also > > been explained why History-Info can not be used for this as is. > > > > A simple new header with a clear semantics which provides a clean > > solution to the problem is therefore not even challenged by the > > History-Info header. Instead you should argue why > History-Info is so > > bloody good that we should use it for this. We just learned > that it is > > not even usable as a diagnostic tool. > > > > Why carry a whole log of request URI rewrites around when > you are only > > interested in the current target??? > > > > /Hans Erik > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, April 01, 2008 6:18 PM > > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > Any addition of a new header that nobody can explain > properly why it's > > not the same as History-Info IS rocket science. > > > > It sounds like we are getting paid by the number of URI we > add to SIP. > > > > > -----Original Message----- > > > From: Hans Erik van Elburg > [mailto:hanserik.van.elburg@ericsson.com] > > > Sent: Tuesday, April 01, 2008 01:07 > > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > > > The point is that History-Info does not solve the problem > > so something > > > > > new is needed anyway. > > > > > > And proper use of History-Info is rocket science as Dale > has shown. > > > > > > /Hans Erik > > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Francois Audet > > > Sent: Tuesday, April 01, 2008 2:16 AM > > > To: Juha Heinanen; Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > There are existing implementations of History-Info in the field. > > > > > > It's not rocket science. > > > > > > And I don't see why introducing something else will be > simpler. It > > > will just be extra complexity. > > > > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of > > > > Juha Heinanen > > > > Sent: Saturday, March 29, 2008 05:48 > > > > To: Christer Holmberg > > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > > > Christer Holmberg writes: > > > > > > > > > However, I still fail to understand how Target would be more > > > > "complex" > > > > > than e.g. History-Info. > > > > > > > > christer, > > > > > > > > ANY solution for anything must be MUCH simpler than > history-info, > > > > which is far too complex by itself. > > > > > > > > i haven't seen anyone fully implement history-info and > > most likely > > > > that is because of its complexity. if you are now going > > to invent > > > > some other mechanism that is as complex or even more > > > complex, it has > > > > no change in real world. > > > > > > > > i therefore suggest that h-i is deprecated and a replaced > > > by a simpler > > > > > > > mechanism. > > > > > > > > -- juha > > > > _______________________________________________ > > > > 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 sip-bounces@ietf.org Thu Apr 3 14:03:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A773A6D0C; Thu, 3 Apr 2008 14:03:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890DF28C313 for ; Thu, 3 Apr 2008 14:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.707, 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 orNBOHHQhKTr for ; Thu, 3 Apr 2008 14:03:12 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 68D033A6B87 for ; Thu, 3 Apr 2008 14:03:12 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m33L3An19906; Thu, 3 Apr 2008 21:03:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 16:02:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgACHxX6AAFMnqEA== References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Hans Erik van Elburg" , "Juha Heinanen" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org So what is the P-Called-Party-ID used for? I'm trying to figure out the different use cases for P-Called-Party-ID versus Target. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, April 03, 2008 13:48 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Juha Heinanen > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > > Hi, > > The P-Called-Party-ID is only inserted by the registrar of > the UAS, while the Target can be inserted also by other entities. _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 3 14:46:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424C93A6A3F; Thu, 3 Apr 2008 14:46:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F90D3A6A3F for ; Thu, 3 Apr 2008 14:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=2.101, 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 w2p-GdeSWnHt for ; Thu, 3 Apr 2008 14:45:58 -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 143BB3A67E5 for ; Thu, 3 Apr 2008 14:45:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,600,1199682000"; d="scan'208";a="4032132" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2008 17:45:31 -0400 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 m33LjVeT032428; Thu, 3 Apr 2008 17:45:31 -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 m33LjVL4007773; Thu, 3 Apr 2008 21:45:31 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); Thu, 3 Apr 2008 17:45:31 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 17:45:31 -0400 Message-ID: <47F55014.9040408@cisco.com> Date: Thu, 03 Apr 2008 17:45:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 03 Apr 2008 21:45:31.0290 (UTC) FILETIME=[09F7CFA0:01C895D4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1452; t=1207259131; x=1208123131; 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]=20Comparison=20of=20retargeting=2 0proposals |Sender:=20 |To:=20Francois=20Audet=20; bh=rXHgxJ5qpuNcoiT5bzEzinbq1rY5ZaJzbnj+uFu7Utw=; b=pquDmQJ3v91iiRlS5FBBtUs7nhhVy/KhlpXieIpzrZ66bWPNQ2DOz44O8F 2DO26k9+vLEMdKDDaJA+ngfUEtAObg5ixkOfMv2dA4dgNyaasq++v7766diz nstxl+Y2HM; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois, IMS has the notion of implicit registration, so when you register for AOR1 you may implicitly be registered for AOR2 and AOR3 as well. (Using the same Contact URI.) So, when you subsequently receive an incoming request at your Contact URI, you can't tell from the Contact address which of the AORs was the target of the request. The P-Called-Party-ID allows you to figure that out, and therefore light up the proper line, or whatever, on your phone. Paul Francois Audet wrote: > So what is the P-Called-Party-ID used for? > > I'm trying to figure out the different use cases for P-Called-Party-ID versus > Target. > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Thursday, April 03, 2008 13:48 >> To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Juha Heinanen >> Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS >> Subject: RE: [Sip] Comparison of retargeting proposals >> >> >> Hi, >> >> The P-Called-Party-ID is only inserted by the registrar of >> the UAS, while the Target can be inserted also by other entities. > _______________________________________________ > 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 sip-bounces@ietf.org Thu Apr 3 14:53:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E2B3A6BFB; Thu, 3 Apr 2008 14:53:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332DA3A6907 for ; Thu, 3 Apr 2008 14:53:55 -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 HIxcMWtnd4tz for ; Thu, 3 Apr 2008 14:53:54 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 27B143A6CA1 for ; Thu, 3 Apr 2008 14:53: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 m33Lr6K03858; Thu, 3 Apr 2008 21:53:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 16:53:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15EB7F8A@zrc2hxm0.corp.nortel.com> In-Reply-To: <47F55014.9040408@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciV1A0zCK8XrU9gTzCVtMS28R86QgAADpZA References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47F55014.9040408@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org What a mess.... I pitty the poor implementors who will have to implement this. In any case, my preference is: - An history-info-bis, with EXPLICIT history-info parameters that identify which entry is a Target and which one is the contact (from re-route). That way you wouldn't need artificial intelligence to parse the history-info. Also, we would sort-out all the bugs in history info. I can also deal with a new header, IF AND ONLY IF we also have a document that described the accurately and without any ambivalence the different between P-Called-Header and Target, AND if we still up-issue History-info to describe how it works with this new header (and how history-info tracks everything). > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 03, 2008 14:46 > To: Audet, Francois (SC100:3055) > Cc: Christer Holmberg; Hans Erik van Elburg; Juha Heinanen; > sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > Francois, > > IMS has the notion of implicit registration, so when you register for > AOR1 you may implicitly be registered for AOR2 and AOR3 as > well. (Using the same Contact URI.) > > So, when you subsequently receive an incoming request at your > Contact URI, you can't tell from the Contact address which of > the AORs was the target of the request. The P-Called-Party-ID > allows you to figure that out, and therefore light up the > proper line, or whatever, on your phone. > > Paul > > Francois Audet wrote: > > So what is the P-Called-Party-ID used for? > > > > I'm trying to figure out the different use cases for > P-Called-Party-ID > > versus Target. > > > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Thursday, April 03, 2008 13:48 > >> To: Audet, Francois (SC100:3055); Hans Erik van Elburg; > Juha Heinanen > >> Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > >> Subject: RE: [Sip] Comparison of retargeting proposals > >> > >> > >> Hi, > >> > >> The P-Called-Party-ID is only inserted by the registrar of > the UAS, > >> while the Target can be inserted also by other entities. > > _______________________________________________ > > 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 sip-bounces@ietf.org Thu Apr 3 22:12:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A31C3A6A54; Thu, 3 Apr 2008 22:12:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956B33A6C89 for ; Thu, 3 Apr 2008 22:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, 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 D1t4cXSKCy7t for ; Thu, 3 Apr 2008 22:12:35 -0700 (PDT) Received: from taimen.tutpro.com (harjus.tutpro.com [192.98.100.3]) by core3.amsl.com (Postfix) with ESMTP id A44203A6BA7 for ; Thu, 3 Apr 2008 22:12:35 -0700 (PDT) Received: by taimen.tutpro.com (Postfix, from userid 1000) id 4196133A86F; Fri, 4 Apr 2008 08:12:40 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18421.47305.126027.185083@harjus.tutpro.com> Date: Fri, 4 Apr 2008 08:12:41 +0300 To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15EB7F8A@zrc2hxm0.corp.nortel.com> References: <200803251629.m2PGTC0N025942@dragon.ariadne.com> <28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com> <18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47F55014.9040408@cisco.com> <1ECE0EB50388174790F9694F77522CCF15EB7F8A@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, Paul Kyzivat , "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet writes: > What a mess.... I pitty the poor implementors who will have to > implement this. paul's explanation about p-called-party-id was clear to me and it is extremely easy to implement in openser proxy. > In any case, my preference is: > I can also deal with a new header, IF AND ONLY IF we also have a > document that > described the accurately and without any ambivalence the different > between P-Called-Header and Target, AND if we still up-issue > History-info to describe how it works with this new header (and how > history-info tracks everything). i don't know about Target, but history-info is easy to deal with: we simply deprecate it as a too complex thing that no popular sip proxies or user agents have implemented. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 00:02:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8410E28C171; Fri, 4 Apr 2008 00:02:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37FBA3A691D for ; Fri, 4 Apr 2008 00:02:04 -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.075, 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 A6f072+VClfY for ; Fri, 4 Apr 2008 00:01:58 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id E955428C6BD for ; Fri, 4 Apr 2008 00:01:54 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so3773684wfa.31 for ; Fri, 04 Apr 2008 00:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=ZAnr5fj++Odod4sV8Ypny6dVi+sW5P82bFs5PRZ+Yos=; b=nxpUAhUahw2iWOhXTjkLAZoej56VSus1++U07QiJ/E6EaCM8l0WtW//1upEesfysrTCHKu6VxGRD73OgqcFGdqa1EWLka9E6bI9OTD4GDvwg+L0oogbSc9dvu2U+AzMmrQWb3bgcwzk63Yn1x0P4AiYyutRJv6bcEC+rwe9ZQsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type; b=CTE97lg9NuNzLXO/V2hRqBghBccf1xv5L9c3wTSJuSWBEbQ2w/rAsVJ6F4wPYYaFxeEG/rgeuLihFxxMYsfUihF/BTrkKsPxiD8qyfQvvMRUaMSFS74MTRRXnTIm/yF4Pw/xRGJ96VslViGwRZwwOXZvzVx68wsgQ2B8EIqjJJI= Received: by 10.141.176.13 with SMTP id d13mr312962rvp.196.1207292520094; Fri, 04 Apr 2008 00:02:00 -0700 (PDT) Received: by 10.141.97.13 with HTTP; Fri, 4 Apr 2008 00:02:00 -0700 (PDT) Message-ID: Date: Fri, 4 Apr 2008 12:32:00 +0530 From: "ajay thakur" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] multiple register server or multiple outbound proxies X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1387963051==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1387963051== Content-Type: multipart/alternative; boundary="----=_Part_3245_5443407.1207292520073" ------=_Part_3245_5443407.1207292520073 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have doubt about having multiple registrar server configuration and multiple outbound server configuration on the phones? And is it really required? Any comments on this ? Thanks Ajay ------=_Part_3245_5443407.1207292520073 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
I have doubt about having multiple registrar server configuration and
multiple outbound server configuration on the phones?
And is it really required? Any comments on this ?
 
 
 
Thanks
Ajay 
------=_Part_3245_5443407.1207292520073-- --===============1387963051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1387963051==-- From sip-bounces@ietf.org Fri Apr 4 00:06:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7353F28C3DC; Fri, 4 Apr 2008 00:06:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E2E28C2A1 for ; Fri, 4 Apr 2008 00:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=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 MGEo5KE2KE9T for ; Fri, 4 Apr 2008 00:06:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 850653A6878 for ; Fri, 4 Apr 2008 00:06:50 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3476rmx006913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 4 Apr 2008 02:06:55 -0500 Message-Id: <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> From: Dean Willis To: "sip@ietf.org List" In-Reply-To: <18421.47305.126027.185083@harjus.tutpro.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 02:06:48 -0500 References: <200803251629.m2PGTC0N025942@dragon.ariadne.com> <28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com> <18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47F55014.9040408@cisco.com> <1ECE0EB50388174! 790F9694F77522CCF15EB7F8A@zrc2hxm0.corp.nortel.com> <18421.47305.126027.185083@harjus.tutpro.com> X-Mailer: Apple Mail (2.919.2) Subject: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sorry about the HTML formating. I'm too lazy to wrap my lines. And yes, this should probably be in an ID, but I'm too lazy for that too. Here's why the answers seem to be confusing -- the question is confused. I'd like to try and rein it in a bit, and make a proposal. We have a couple of things we want: 1) Delivery of application-specific info (aka "parameters") from the originating UA to the terminating UA 2) Delivery of parameters from proxies to the terminating UA 3) Information to allow the terminating UA to know which application, function, or identity (or something else) at that UA is being targeted by the request, over and above the mundane aspects of the request such as ordinary headers and bodies. Presumably this information is inserted somehow along the way, either at the source UA or some intermediate (proxy or the like) node. This information may, or may not, be the same as #1 and #2 above. 4) We think we have a need for the terminating UA to figure out who inserted each bit of information. I find this compelling. 5) We think we have a need for the terminating UA to understand the entire decision tree that resulted in the call arriving at it. I don't find this compelling at all (which is why I opposed Diversion and History-Info), as I think that every application people THINK they need this for is more readily addressed by 1-3. These "needs" have been getting tangled up in the most perniciously confusing sorts of ways I can imagine. We have History-Info, Diversion, P-This-That-And-the-Other-Thing, and probably a couple of dozen other hackneyed ways to work around this problem. Quite probably a large number of the SIP extension headers we've documented have been narrow application-specific functions that really didn't need an RFC, but since an RFC is required to get a header, we've had to do a lot of work. Why don't we have an easy answer? The problem starts with SIP's take-off from HTTP. If we were using HTTP, we could use request-URI parameters to talk to the application. This works very well in HTTP land, since outside of very specialized cases, HTTP proxies don't change the request URI, and when they do it's an additive thing ; they add parameters as needed. Note that neither IETF nor W3C has found it needful to standardize HTTP request parameters. Any fool can code up a CGI script that uses new ones, and the neat thing is, they're always scoped to the application in use. Let's look at the request for my Google home page: http://www.google.com/ig?hl=en&source=iglk This conveys the location of the target node, an application identifier, and two parameters delivered to that application. The target node is www.google.com, the application is "ig", and the parameters are "hl", which has a value of "en", and "source", which has a value of "iglk". RFC 2543 just didn't work this way. Every proxy mangled the request URI to the best of its ability, such that there was absolutely no way to use the request URI to pass any useful information between UAs. I'm not sure why we went down this path. I argued against it at the time, but obviously I lost that argument. We partially fixed this with loose routing in RFC 3261, but we didn't fix it well enough, and we still have the problem. Jonathan's UA Loose Routing draft has tried to get us closer to the HTTP model (but do so with full backward compatibility), and lots of people have complained about the apparent resulting complexity. It shouldn't be complex -- it's so easy with HTTP, but SIP just isn't HTTP anymore. We've tried putting stuff into body parts, and the ongoing war over proxy manipulation of body parts and requirements for multi-part MIME has been running for years now. Besides, we don't really have a way of indicating which body part does what, as the MIME syntax just doesn't give us a handle on it. We have P-Called-Party-ID, which satisfies a subset of problem #3 by letting the terminating UA know which identity at that UA the request is targeting (and this COULD be used to indicate an application as opposed to a user, I suppose). We also have Target, a header that as proposed provides a sort of partial combination of 3, 4, and 5 by basically stacking up another header instance every time a proxy changes the request URI. As I understand the author's intentions (which is not what I get from the draft), the idea is that every URI seen on the path from UAC to UAS is recorded in an instance of the Target header, One can then read the list backwards, and sort of guess which one was inserted by various proxies and maybe figure out which one was inserted by the originating UA. I mostly like what I think I understand of the author's intentions, but it's not QUITE what I want. And I have a head ache from trying to sort this stuff out. So here's a suggestion for a Radically Different Approach. Let's define a new SIP extension header field. I call it "Params" for now. Eachs Params header field contains one or more parameter=value pairs. The only mandatory of these pairs encodes the role (UA, proxy) and identity of the node inserting the Params field. Another pair might encode the URI targeted by the request as it leaves that node (which is probably only useful for debugging). Another pair might encode the identity targeted by the request, which as we know is not the same as the URI of the request. Still more pairs would encode any parameters being delivered to the UAS terminating the request. We also need a rule: only insert a Params if you expect it to be useful to the terminating UAS. If you aren't changing something , DON'T PUT ONE IN! So, here's an example (with many fields left out) Alice-1-->AliceOutboundProxy--2-->BobHomeProxy--3-- >BobOutboundProxy--4-->Bob Message 1: (note that the param MyAppID=23 is encoded by Alice) INVITE sisp:bob@example.com SIP/2.0 From: sips:alice@192.168.2.1 To: sips:bob@example.com Call-ID: 1j9FpLxk3uxtm8tn@192.168.2.1 Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:alice@192.168.2.1,MyAppID=23 Message 2: (note no new Params) INVITE sips:bob@example.com SIP/2.0 From: sips:alice@192.168.2.1 To: sips:bob@example.com Call-ID: 1j9FpLxk3uxtm8tn@192.168.2.1 Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:alice@192.168.2.1,MyAppID=23 Message 3: (retargeting occurs) INVITE sips:bob@192.16.2.2 SIP/2.0 From: sips:alice@192.168.2.1 To: sips:bob@example.com Call-ID: 1j9FpLxk3uxtm8tn@192.168.2.1 Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS bproxy.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:alice@192.168.2.1,MyAppID=23 Params: role=proxy,src=bproxy.example.com,target= Message 4: (note no new Params) INVITE sips:bob@192.16.2.2 SIP/2.0 From: sips:alice@192.168.2.1 To: sips:bob@example.com Call-ID: 1j9FpLxk3uxtm8tn@192.168.2.1 Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS bproxy.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS boproxy.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:alice@192.168.2.1,MyAppID=23 Params: role=proxy,src=bproxy.example.com,target= So with this request, Bob's UA can look at it and say "Ok, this requested is targeted to sips:bob@example.com, so I'd best respond appropriately. And oh look, the originating UA wants me to know that MyAppID=23." Diagnostically, we can also look at it and see that there was a retargeting at the proxy bproxy.example.com, since said proxy was kind enough to insert the Params telling us so. Ok, now I can hear people screaming "But this is what History-Info does!" That might be. I'm not sure I actually understood History-Info. But this seems a bunch simpler, AND it allows for inclusion of "forward knowledge" (i.e., parameters inserted under application control) rather than only "backward knowledge" (a record of the decisions that got us here). Hence RFC 3087 / RFC 4458 type control mechanisms can be used effectively. Hint: If you have a voice mail application that is dependent on knowing that a retargeting decision resulted from a busy condition, it's easy to put a "cause=busy" into the relevant Params. Note also that this doesn't seem to capture the full range of History- Info cases. I think it is a simpler replacement that gives the required functionality. And since it's just new extension header fields, it is 100% backwards compatible. There are also some interesting anonymization interactions. For example, if you don't want to reveal a source, use anonymous or a temp- gruu in the "src=" Params. Or better yet, don't insert a Params at all! They're optional except when rerouting or retargeting. -- 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 sip-bounces@ietf.org Fri Apr 4 00:30:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520F028C1E1; Fri, 4 Apr 2008 00:30:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFDB28C290 for ; Fri, 4 Apr 2008 00:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.751, 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 TJSKNtsqmz2U for ; Fri, 4 Apr 2008 00:30:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 90AE028C5A4 for ; Fri, 4 Apr 2008 00:30:17 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m347UKUF007066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 4 Apr 2008 02:30:22 -0500 Message-Id: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> From: Dean Willis To: "sip@ietf.org List" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 02:30:15 -0500 X-Mailer: Apple Mail (2.919.2) Subject: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I define "unanticipated respondent syndrome" as the sense of surprise Alice gets when she calls Bob, only to have the call answered by Charlie. This is especially problematic if the sorts of security operations that depend on Alice having some sort of keying relationship with Charlie become important. Alice is expecting: Alice--1-->Proxy--2-->Bob but instead she gets: Alice--1-->Proxy--2-->Charlie because Bob forwarded his phone to Charlie, or because Charlie, who is authorized to do so, registered as a contact for Bob, and Bob didn't answer (or has a lwoer qvalue, or whatever) RFC 4916 lets Alice find out who answered the phone in the most difficult of cases, and other techniques like P-Asserted-Identity in a response address simpler cases (or we can use endpoint- asserted RFC 4474 Identity when the keys are known or discoverable). So that's not a problem. Alice can figure out that she's talking to Charlie, once they get connected. The only problem is cluing in Alice that she's about to be talking to Charlie instead of Bob. In the cases I've identified above, the proxy knows that it is retargeting the request to Charlie, not rerouting the request to Bob. How does it know this? It either a) knows that the Call Forwarding feature has been activated, and that's always a retarget, or b) knows that the contact for Bob was registered by Charlie, who isn't Bob (but that Charlie is authorized to register for Bob's AOR). In fact, if this the case, it knows both Charlie's authentication identity and his contact. Since the proxy knows, it should be able to inform Alice. I therefore propose a provisional response from Proxy to Alice, which I'll provisionally call "121 (Retargeting)" A proxy executing a retargeting operation (by which we mean an operation that replaces the request URI such that the authenticated identity of the new request URI is different from the authenticated identity of the old one) SHOULD return a 121 (Retargeting) provisional response. The 121 response contains a Contact header field, the value of which is the new identity being targeted. Optionally, we might include some sort of "cause" parameter, explaining why the request is being retargeted (like "Bob's dead, talk to Charlie"). If a proxy doesn't know whether it is rerouting or retargeting, it SHOULD assume that it is retargeting, and send the appropriate 121 response. In conclusion, this preserves the proxy-mediated functionality required for draft-ietf-sip-outbound, while giving us the I-know-who-I- expect-to-reach function of a 302 (Redirect). Yeah, this should be an I-D. I'm now accepting volunteer co-authors to do the dirty work, assuming this idea gets any traction. -- 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 sip-bounces@ietf.org Fri Apr 4 00:32:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E779028C18B; Fri, 4 Apr 2008 00:32:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8377B28C6AA for ; Thu, 3 Apr 2008 07:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=2.710, 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-29ln10f9WX for ; Thu, 3 Apr 2008 07:51:45 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by core3.amsl.com (Postfix) with ESMTP id 2869E28C686 for ; Thu, 3 Apr 2008 07:51:45 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id a46so2416082rne.9 for ; Thu, 03 Apr 2008 07:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=ZxAZUcUXtiKHmwclDatOpGsDfXedN5xKg7+1ZfOKRdw=; b=bP+7bUAah0dTXThvWzyxK7sqke3Kd9cPQ7pVE+PwFWk8oNv80aNTpMiGCxDrsdq1hTJO5Ma/yWrgr4TyMAaebxKiSnlej5yzgiQk/b37UgdDwlCQR98cViah7xIHAjbeg2ysawTz9vKlsoJDEwz65bu7VDFQS8JFMVirSpCsLWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Y5JZzxBQcTm0wOMrrhww51cCSo+6KbPlYokeKqnZAzxLjSXqw69KCaXvot9dIRT6WnuXWaUkAjC3JtM027Yc3sv6wBrdNFsVmYzhsLNij4aeiHOXOzxwk8diOFhS1YN93ThD7O6BBlXOpuwLv1fVc5OJvkJbTizc5/P3ryEjM6I= Received: by 10.114.78.1 with SMTP id a1mr17527223wab.104.1207234307667; Thu, 03 Apr 2008 07:51:47 -0700 (PDT) Received: by 10.114.58.7 with HTTP; Thu, 3 Apr 2008 07:51:47 -0700 (PDT) Message-ID: <87277b870804030751y71378294u847db133d79b0bcc@mail.gmail.com> Date: Thu, 3 Apr 2008 09:51:47 -0500 From: "rossi kamal" To: sip@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Mailman-Approved-At: Fri, 04 Apr 2008 00:32:54 -0700 Subject: [Sip] sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Would anyone suggest me on the key management protocols in existent SIP clients if there is article or journal it would be preferable _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 00:45:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC353A6866; Fri, 4 Apr 2008 00:45:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C13A3A681B for ; Fri, 4 Apr 2008 00:45:38 -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 AGdwkld2UJXY for ; Fri, 4 Apr 2008 00:45:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A6F243A6D0C for ; Fri, 4 Apr 2008 00:45:18 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 29B46206A4; Fri, 4 Apr 2008 09:45:22 +0200 (CEST) X-AuditID: c1b4fb3e-ac995bb000004ec0-4d-47f5dc923737 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0D0C720085; Fri, 4 Apr 2008 09:45:22 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 09:45:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 09:45:21 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D85040DEFB@esealmw109.eemea.ericsson.se> In-Reply-To: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting thread-index: AciWJd+whDoKexvjRFu9jeP6YR5SMwAAaPdA References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> From: "Hans Erik van Elburg" To: "Dean Willis" , X-OriginalArrivalTime: 04 Apr 2008 07:45:21.0717 (UTC) FILETIME=[D5EF2650:01C89627] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Is this any different then 181 Call Is Being Forwarded from RFC3261? -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, April 04, 2008 9:30 AM To: sip@ietf.org List Subject: [Sip] Preventing unanticipated respondent syndrome when retargeting I define "unanticipated respondent syndrome" as the sense of surprise Alice gets when she calls Bob, only to have the call answered by Charlie. This is especially problematic if the sorts of security operations that depend on Alice having some sort of keying relationship with Charlie become important. Alice is expecting: Alice--1-->Proxy--2-->Bob but instead she gets: Alice--1-->Proxy--2-->Charlie because Bob forwarded his phone to Charlie, or because Charlie, who is authorized to do so, registered as a contact for Bob, and Bob didn't answer (or has a lwoer qvalue, or whatever) RFC 4916 lets Alice find out who answered the phone in the most difficult of cases, and other techniques like P-Asserted-Identity in a response address simpler cases (or we can use endpoint- asserted RFC 4474 Identity when the keys are known or discoverable). So that's not a problem. Alice can figure out that she's talking to Charlie, once they get connected. The only problem is cluing in Alice that she's about to be talking to Charlie instead of Bob. In the cases I've identified above, the proxy knows that it is retargeting the request to Charlie, not rerouting the request to Bob. How does it know this? It either a) knows that the Call Forwarding feature has been activated, and that's always a retarget, or b) knows that the contact for Bob was registered by Charlie, who isn't Bob (but that Charlie is authorized to register for Bob's AOR). In fact, if this the case, it knows both Charlie's authentication identity and his contact. Since the proxy knows, it should be able to inform Alice. I therefore propose a provisional response from Proxy to Alice, which I'll provisionally call "121 (Retargeting)" A proxy executing a retargeting operation (by which we mean an operation that replaces the request URI such that the authenticated identity of the new request URI is different from the authenticated identity of the old one) SHOULD return a 121 (Retargeting) provisional response. The 121 response contains a Contact header field, the value of which is the new identity being targeted. Optionally, we might include some sort of "cause" parameter, explaining why the request is being retargeted (like "Bob's dead, talk to Charlie"). If a proxy doesn't know whether it is rerouting or retargeting, it SHOULD assume that it is retargeting, and send the appropriate 121 response. In conclusion, this preserves the proxy-mediated functionality required for draft-ietf-sip-outbound, while giving us the I-know-who-I- expect-to-reach function of a 302 (Redirect). Yeah, this should be an I-D. I'm now accepting volunteer co-authors to do the dirty work, assuming this idea gets any traction. -- 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 _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 00:57:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53BF728C5ED; Fri, 4 Apr 2008 00:57:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA36F28C439 for ; Fri, 4 Apr 2008 00:57:00 -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 8u4YDZzKR1GG for ; Fri, 4 Apr 2008 00:56:59 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 51C3428C3DC for ; Fri, 4 Apr 2008 00:56:59 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 40B22220E0; Fri, 4 Apr 2008 09:49:08 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-6a-47f5dd746c11 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 12F61220C1; Fri, 4 Apr 2008 09:49:08 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 09:49:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 09:49:07 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D85040DF21@esealmw109.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15E38A9C@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals thread-index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA92SiAAPqMGwA== References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15E38A9C@zrc2hxm0.corp.nortel.com> From: "Hans Erik van Elburg" To: "Francois Audet" , "Juha Heinanen" , "Christer Holmberg" X-OriginalArrivalTime: 04 Apr 2008 07:49:07.0788 (UTC) FILETIME=[5CAED8C0:01C89628] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Of course that is why we are having these discussions. - P-Called-Party-ID does not carry this information. As has been explained. It might sometimes carry the same URI, but it has a different meaning. - History-Information does not carry this information. As has been explained. It might somewhere carry the same URI, but if that is not extractable as being the one we need, then what good is it. You may not like it but that is how it is. Otherwise WE would not have proposed a new header. /Hans Erik -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Wednesday, April 02, 2008 6:53 PM To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals Again, the burden is on the proponent of the new header to prove that a new header is needed when we apparently have headers that carries the same information, and more. > -----Original Message----- > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > Sent: Wednesday, April 02, 2008 02:43 > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > It is clearly not the same as History-Info header as has been > explained in the draft and in several previous threads. It has also > been explained why History-Info can not be used for this as is. > > A simple new header with a clear semantics which provides a clean > solution to the problem is therefore not even challenged by the > History-Info header. Instead you should argue why History-Info is so > bloody good that we should use it for this. We just learned that it is > not even usable as a diagnostic tool. > > Why carry a whole log of request URI rewrites around when you are only > interested in the current target??? > > /Hans Erik > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, April 01, 2008 6:18 PM > To: Hans Erik van Elburg; Juha Heinanen; Christer Holmberg > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > Any addition of a new header that nobody can explain properly why it's > not the same as History-Info IS rocket science. > > It sounds like we are getting paid by the number of URI we add to SIP. > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:hanserik.van.elburg@ericsson.com] > > Sent: Tuesday, April 01, 2008 01:07 > > To: Audet, Francois (SC100:3055); Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > The point is that History-Info does not solve the problem > so something > > > new is needed anyway. > > > > And proper use of History-Info is rocket science as Dale has shown. > > > > /Hans Erik > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Francois Audet > > Sent: Tuesday, April 01, 2008 2:16 AM > > To: Juha Heinanen; Christer Holmberg > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > There are existing implementations of History-Info in the field. > > > > It's not rocket science. > > > > And I don't see why introducing something else will be simpler. It > > will just be extra complexity. > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > Juha Heinanen > > > Sent: Saturday, March 29, 2008 05:48 > > > To: Christer Holmberg > > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > > Subject: Re: [Sip] Comparison of retargeting proposals > > > > > > Christer Holmberg writes: > > > > > > > However, I still fail to understand how Target would be more > > > "complex" > > > > than e.g. History-Info. > > > > > > christer, > > > > > > ANY solution for anything must be MUCH simpler than history-info, > > > which is far too complex by itself. > > > > > > i haven't seen anyone fully implement history-info and > most likely > > > that is because of its complexity. if you are now going > to invent > > > some other mechanism that is as complex or even more > > complex, it has > > > no change in real world. > > > > > > i therefore suggest that h-i is deprecated and a replaced > > by a simpler > > > > > mechanism. > > > > > > -- juha > > > _______________________________________________ > > > 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 sip-bounces@ietf.org Fri Apr 4 01:06:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A613A6E28; Fri, 4 Apr 2008 01:06:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7C33A6DEF for ; Fri, 4 Apr 2008 01:06: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 6zgGGWt9grF8 for ; Fri, 4 Apr 2008 01:06: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 2436628C711 for ; Fri, 4 Apr 2008 01:05:04 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYS0074JJSKHT@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 09:05:08 +0100 (BST) Date: Fri, 04 Apr 2008 09:04:30 +0100 From: "Elwell, John" In-reply-to: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> To: Dean Willis , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09160A0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting Thread-Index: AciWJdzIPS0GtcMISxuKlI3WfBmyLwABHJBg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, We already have 181 Call is Being Forwarded, which has a very similar meaning. Of course, we don't specify use of the Contact header field in that response, but can't we add it? John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: 04 April 2008 08:30 > To: sip@ietf.org List > Subject: [Sip] Preventing unanticipated respondent syndrome > when retargeting > > I define "unanticipated respondent syndrome" as the sense of > surprise > Alice gets when she calls Bob, only to have the call answered by > Charlie. This is especially problematic if the sorts of security > operations that depend on Alice having some sort of keying > relationship with Charlie become important. > > Alice is expecting: > > Alice--1-->Proxy--2-->Bob > > but instead she gets: > > Alice--1-->Proxy--2-->Charlie > > because Bob forwarded his phone to Charlie, or because > Charlie, who is > authorized to do so, registered as a contact for Bob, and Bob didn't > answer (or has a lwoer qvalue, or whatever) > > RFC 4916 lets Alice find out who answered the phone in the most > difficult of cases, and other techniques like > P-Asserted-Identity in a > response address simpler cases (or we can use endpoint- asserted RFC > 4474 Identity when the keys are known or discoverable). So > that's not > a problem. Alice can figure out that she's talking to Charlie, once > they get connected. > > The only problem is cluing in Alice that she's about to be > talking to > Charlie instead of Bob. > > In the cases I've identified above, the proxy knows that it is > retargeting the request to Charlie, not rerouting the request > to Bob. > How does it know this? It either a) knows that the Call Forwarding > feature has been activated, and that's always a retarget, or > b) knows > that the contact for Bob was registered by Charlie, who isn't > Bob (but > that Charlie is authorized to register for Bob's AOR). In fact, if > this the case, it knows both Charlie's authentication > identity and his > contact. > > Since the proxy knows, it should be able to inform Alice. > > I therefore propose a provisional response from Proxy to > Alice, which > I'll provisionally call "121 (Retargeting)" > > A proxy executing a retargeting operation (by which we mean an > operation that replaces the request URI such that the authenticated > identity of the new request URI is different from the authenticated > identity of the old one) SHOULD return a 121 (Retargeting) > provisional > response. The 121 response contains a Contact header field, > the value > of which is the new identity being targeted. Optionally, we might > include some sort of "cause" parameter, explaining why the > request is > being retargeted (like "Bob's dead, talk to Charlie"). > > If a proxy doesn't know whether it is rerouting or retargeting, it > SHOULD assume that it is retargeting, and send the appropriate 121 > response. > > In conclusion, this preserves the proxy-mediated functionality > required for draft-ietf-sip-outbound, while giving us the > I-know-who-I- > expect-to-reach function of a 302 (Redirect). > > Yeah, this should be an I-D. I'm now accepting volunteer > co-authors to > do the dirty work, assuming this idea gets any traction. > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 01:19:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313AC3A6AE0; Fri, 4 Apr 2008 01:19:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB97D3A6D25 for ; Fri, 4 Apr 2008 01:19:20 -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 zCIudHGlzd9Q for ; Fri, 4 Apr 2008 01:19:20 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id EDC5E3A6AE0 for ; Fri, 4 Apr 2008 01:19:19 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYS00862KDSC9@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 09:19:23 +0100 (BST) Date: Fri, 04 Apr 2008 09:18:29 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09160B9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Next steps on RFC 4474 issues Thread-Index: AciVqVEc/grn304FTsOwcoO9BP5eOw== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] Next steps on RFC 4474 issues X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org After a longer delay than planned, I want to try to kick off discussions on RFC 4474 issues again. After much activity during IETF71, this is where I think we are, roughly speaking: There would seem to be 3 main issues: 1) Use of E.164-based SIP URIs within a SIP environment. 2) Use of E.164-based SIP URIs for numbers received from PSTN. 3) The SBC problem. Item 1)(use of E.164-based SIP URI within SIP environment) In fact, there are two angles on this item: 1a) the accuracy of the E.164 number, as characterised by questions such as "is that number assigned to the originator of this request?" This is independent of DTLS-SRTP; 1b) the meaning of the domain part, which does have a bearing on DTLS-SRTP. It means the media are secured as far as that domain, so that if that domain is an organisation you want to talk to, fine, but if it is some intermediary, then you may be concerned. I think there is a certain consensus that we can't do much more than document this problem, but on the other hand we can try to avoid it to some extent by encouraging the use of "email-style" SIP URIs. E.164-based URIs will still be needed, particularly for interworking with PSTN but also in those SIP environments where E.164 numbers are more easily handled (e.g., phones with number-based user interfaces). But perhaps we can explore more the possibility of using the two forms in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and email-style in From. I know Dan has an interesting straw man on this topic. I will call this topic "Migration from E.164 to email-style SIP URIs" and start a new thread. Item 2) (E.164-based SIP URIs from PSTN) There seems to be some interest in adding some indicator to the URI or to the header field to warn of the limited guarantee of authenticity. I will start a new thread with the title "RFC 4474 and PSTN". Item 3) (SBC traversal) This received relatively little discussion during IETF 71 and on the mailing list. I will start a new thread "RFC 4474 and SBC traversal". There is of course interaction between 1) and 3), in that SBC intervention can lead to re-signing, thereby solving 3) but introducing 1b). As I said above, I will start 3 separate threads to further discuss these three topics. The objective is to have a proposed way forward on the separate topics by the next meeting, in terms of I-Ds, BoF proposals or whatever. So if you want to address those problems, please respond to the appropriate thread. Respond to this email only if you have comments on my interpretation of the set of problems or on the proposed process. 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 sip-bounces@ietf.org Fri Apr 4 01:19:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9ABB28C287; Fri, 4 Apr 2008 01:19:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3214D3A6934 for ; Fri, 4 Apr 2008 01:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XpXZoYmJDPpN for ; Fri, 4 Apr 2008 01:19:20 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 54A8F3A6C86 for ; Fri, 4 Apr 2008 01:19: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 <0JYS00862KDSC9@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 09:19:23 +0100 (BST) Date: Fri, 04 Apr 2008 09:18:39 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Migration from E.164 to email-style SIP URIs Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On this thread I would like to explore what can be done in terms of avoiding the issues concerned with RFC 4474 and E.164-based SIP URIs by migration towards the use of email-style URIs. E.164-based URIs will still be needed, particularly for interworking with PSTN but also in those SIP environments where E.164 numbers are more easily handled (e.g., phones with number-based user interfaces). But perhaps we can explore more the possibility of using the two forms in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and email-style in From. I know Dan has an interesting straw man on this topic, which I will allow him to present himself. 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 sip-bounces@ietf.org Fri Apr 4 01:19:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84E828C33A; Fri, 4 Apr 2008 01:19:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B813A6934 for ; Fri, 4 Apr 2008 01:19:21 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=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 UlNJ+aLe-8mt for ; Fri, 4 Apr 2008 01:19:20 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B00F53A6D0C for ; Fri, 4 Apr 2008 01:19: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 <0JYS00862KDSC9@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 09:19:23 +0100 (BST) Date: Fri, 04 Apr 2008 09:19:06 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: RFC 4474 and PSTN Thread-Index: AciWIirA52huOC6IQg+xc8TTpvnc9w== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There seems to be some interest in adding some indicator to the URI or to the header field to warn of the limited guarantee of authenticity or the opposite (i.e.,lack of such an indicator would mean the guarantee is low, i.e., the identity has not been verified). I think on this issue it is just a matter of somebody putting things together into a draft. I think Dean and/or Adam were the main initiators of this proposal - something like a source=pstn parameter. Would somebody care to author a draft? Or do we need further discussion? 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 sip-bounces@ietf.org Fri Apr 4 01:19:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C5B28C391; Fri, 4 Apr 2008 01:19:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6B13A6934 for ; Fri, 4 Apr 2008 01:19:21 -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 usQaaXdxUF06 for ; Fri, 4 Apr 2008 01:19: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 15C543A6AE0 for ; Fri, 4 Apr 2008 01:19:21 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYS00862KDSC9@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 09:19:23 +0100 (BST) Date: Fri, 04 Apr 2008 09:19:21 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: RFC 4474 and SBC traversal Thread-Index: AciWIjxWjS+3AzzOTCy+OdBvKVj8Qg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SBCs do exist, often for good reasons that Hadriel has expanded on already. I firmly believe that DTLS-SRTP will not be deployable in a meaningful way without addressing this problem. Concerning solutions, we have drafts from Kai and Dan, or perhaps a merger of the two somehow would work. It also depends to some extent whether we are talking only about email-style URIs or about E.164-based URIs too. 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 sip-bounces@ietf.org Fri Apr 4 01:50:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B238128C284; Fri, 4 Apr 2008 01:50:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE003A6824 for ; Fri, 4 Apr 2008 01:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, J_CHICKENPOX_64=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 a18qZP1geRtY for ; Fri, 4 Apr 2008 01:50:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 47F7228C33A for ; Fri, 4 Apr 2008 01:50:45 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2008 08:50:50 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp051) with SMTP; 04 Apr 2008 10:50:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19l4iYpUcxlUnleFWe0CxUp4ifq/KKk2ZC1j6+HAZ OrJ7t2OEY8nYD1 Message-ID: <47F5EBE9.2070002@gmx.net> Date: Fri, 04 Apr 2008 11:50:49 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I would instead not put the SIP Identity header there. No additional work needed. Ciao Hannes Elwell, John wrote: > There seems to be some interest in adding some indicator to the URI or > to the header field to warn of the limited guarantee of authenticity or > the opposite (i.e.,lack of such an indicator would mean the guarantee is > low, i.e., the identity has not been verified). > > I think on this issue it is just a matter of somebody putting things > together into a draft. I think Dean and/or Adam were the main initiators > of this proposal - something like a source=pstn parameter. Would > somebody care to author a draft? Or do we need further discussion? > > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 01:50:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF9F28C2D5; Fri, 4 Apr 2008 01:50:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405413A6934 for ; Fri, 4 Apr 2008 01:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.791, 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 NA8r2MVS0yR6 for ; Fri, 4 Apr 2008 01:50:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0643528C284 for ; Fri, 4 Apr 2008 01:50:34 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2008 08:50:38 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp056) with SMTP; 04 Apr 2008 10:50:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+AZHhU1fOATM9r7wDKGT2tJFU15+2lcUbKl1Kwuc dZtdvTkwSGwRFX Message-ID: <47F5EBDE.3070907@gmx.net> Date: Fri, 04 Apr 2008 11:50:38 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I wonder whether RFC 4474 isn't doing fine when you assume that E.164 numbers apear in an email style format. The assumption there is, however, that devices display the domain part as well (which they don't do today) and user's actually configure their authorization policies in a way that it includes both the E.164 number and a corresponding domain name. Hence, this is not a standardization problem but a usability issue. Do I misunderstand your proposal? Ciao Hannes Elwell, John wrote: > On this thread I would like to explore what can be done in terms of > avoiding the issues concerned with RFC 4474 and E.164-based SIP URIs by > migration towards the use of email-style URIs. > E.164-based URIs will still be needed, particularly for interworking > with PSTN but also in those SIP environments where E.164 numbers are > more easily handled (e.g., phones with number-based user interfaces). > But perhaps we can explore more the possibility of using the two forms > in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and email-style > in From. I know Dan has an interesting straw man on this topic, which I > will allow him to present himself. > > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 01:50:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C0A28C3A9; Fri, 4 Apr 2008 01:50:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A472F3A6824 for ; Fri, 4 Apr 2008 01:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.784, 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 3gKHvpHgjGWh for ; Fri, 4 Apr 2008 01:50:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AEB9228C3AE for ; Fri, 4 Apr 2008 01:50:49 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2008 08:50:54 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp048) with SMTP; 04 Apr 2008 10:50:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19cDMEaJb9cVMymXvRsi/wJnptSDhorzbcODjfakr nJc/tFjQm6QkeO Message-ID: <47F5EBED.60104@gmx.net> Date: Fri, 04 Apr 2008 11:50:53 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This issue is totally independent from E.164 I don't like the idea of requiring DTLS-SRTP to provide proof of possession of the keying material. Ciao Hannes Elwell, John wrote: > SBCs do exist, often for good reasons that Hadriel has expanded on > already. I firmly believe that DTLS-SRTP will not be deployable in a > meaningful way without addressing this problem. Concerning solutions, we > have drafts from Kai and Dan, or perhaps a merger of the two somehow > would work. It also depends to some extent whether we are talking only > about email-style URIs or about E.164-based URIs too. > > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 01:55:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36883A6C28; Fri, 4 Apr 2008 01:55:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8591A28C391 for ; Fri, 4 Apr 2008 01:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.709, 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 zri7qNK7i4U3 for ; Fri, 4 Apr 2008 01:55:45 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 21D263A6824 for ; Fri, 4 Apr 2008 01:54:56 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m348sukX008724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 03:54:58 -0500 Message-Id: <69FD23C0-5B45-4423-87CB-796D36E2E5F3@softarmor.com> From: Dean Willis To: "Hans Erik van Elburg" In-Reply-To: <47B2061B1E5E494B96AA40008300D85040DEFB@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 03:54:50 -0500 References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <47B2061B1E5E494B96AA40008300D85040DEFB@esealmw109.eemea.ericsson.se> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 2:45 AM, Hans Erik van Elburg wrote: > Dean mumbled: >> I therefore propose a provisional response from Proxy to Alice, which >> I'll provisionally call "121 (Retargeting)" > Is this any different then 181 Call Is Being Forwarded from RFC3261? Well, 181 is rather totally unspecified, AFAIK. Th main difference is that the proposed 121 has a Contact that tells you where the call is being forwarded. It also specifically means that the call was "retargeted" meaning that the anticipated respondent has changed. It might be reasonable to "further specify" 181 to mean the same thing, since, AFAIK, nobody ever actually used 181 for anything. John Elwell made a try at it in draft-elwell-sipping-redirection- reason-01, but this lacked the whole "Contact" parameter bit that tells the recipient where the call is being forwarded to. -- 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 sip-bounces@ietf.org Fri Apr 4 01:56:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54AF3A6DEF; Fri, 4 Apr 2008 01:56:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE4928C162 for ; Fri, 4 Apr 2008 01:56:28 -0700 (PDT) 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.672, 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 Rh72uo39+a96 for ; Fri, 4 Apr 2008 01:56:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7F0263A6B6B for ; Fri, 4 Apr 2008 01:56:27 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m348uUit008734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 03:56:32 -0500 Message-Id: <4A61C4F4-BB29-41AA-9191-3F95C4007554@softarmor.com> From: Dean Willis To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09160A0@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 03:56:25 -0500 References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D09160A0@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 3:04 AM, Elwell, John wrote: > Dean, > > We already have 181 Call is Being Forwarded, which has a very similar > meaning. Of course, we don't specify use of the Contact header field > in > that response, but can't we add it? > I suppose that would work. The question is, does 181 imply that the anticipated response identity has changed? It seems like one might get a 181 on contact-rerouting. I suppose we could also document 181 to only apply in a retargeting (or suspected retargeting, if the proxy doesn't know) case. -- 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 sip-bounces@ietf.org Fri Apr 4 02:01:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E6B28C18E; Fri, 4 Apr 2008 02:01:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF23C3A694E for ; Fri, 4 Apr 2008 02:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=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 ZrByatqh+Yxa for ; Fri, 4 Apr 2008 02:01:25 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 71B093A6A02 for ; Fri, 4 Apr 2008 02:01:19 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id m3491MkA003248; Fri, 4 Apr 2008 11:01:22 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m3491MgK017514; Fri, 4 Apr 2008 11:01:22 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 11:01:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 11:01:21 +0200 Message-ID: <198A10EC585EC74687BCA414E2A597180211AC82@MCHP7RDA.ww002.siemens.net> In-Reply-To: <47F5EBE9.2070002@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AciWMUlF175rJYmuT7auSzcQU+dXaAAAL+jw References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F5EBE9.2070002@gmx.net> From: "Fischer, Kai" To: "Hannes Tschofenig" , "Elwell, John" X-OriginalArrivalTime: 04 Apr 2008 09:01:21.0871 (UTC) FILETIME=[73FF6DF0:01C89632] Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Hannes, what's than your recommendation how to handle SRTP (based on DTLS-SRTP) for calls originated from PSTN and transferred to IP? -Don't allow SRTP for such calls and fall back to RTP -Allow SRTP, but don't protect the certificate fingerprint Kai > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Freitag, 4. April 2008 10:51 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4474 and PSTN > > I would instead not put the SIP Identity header there. > No additional work needed. > > Ciao > Hannes > > Elwell, John wrote: > > There seems to be some interest in adding some indicator to > the URI or > > to the header field to warn of the limited guarantee of > authenticity or > > the opposite (i.e.,lack of such an indicator would mean the > guarantee is > > low, i.e., the identity has not been verified). > > > > I think on this issue it is just a matter of somebody putting things > > together into a draft. I think Dean and/or Adam were the > main initiators > > of this proposal - something like a source=pstn parameter. Would > > somebody care to author a draft? Or do we need further discussion? > > > > 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 > > > > _______________________________________________ > 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 sip-bounces@ietf.org Fri Apr 4 02:01:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90E03A6DEF; Fri, 4 Apr 2008 02:01:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB0328C2A0 for ; Fri, 4 Apr 2008 02:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.638, 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 xS9esGB6Z-og for ; Fri, 4 Apr 2008 02:01:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DDB393A6A02 for ; Fri, 4 Apr 2008 02:01:28 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3491UkG008773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 04:01:32 -0500 Message-Id: From: Dean Willis To: Hannes Tschofenig In-Reply-To: <47F5EBE9.2070002@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 04:01:20 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F5EBE9.2070002@gmx.net> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 3:50 AM, Hannes Tschofenig wrote: > I would instead not put the SIP Identity header there. > No additional work needed. Well, the problem is that you do apparently gain some benefit from the presence of the Identity header when used with DTLS-SRTP. The DTLS-SRTP draft says: > The certificate fingerprints are sent in SDP over SIP as part of the > offer/answer exchange. The SIP Identity mechanism [RFC4474] is used > to provide integrity for the fingerprints. So, to the extent that fingerprint integrity is useful, RFC 4474 identities are useful even when the assertion of identity is not strong. -- 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 sip-bounces@ietf.org Fri Apr 4 02:06:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAC13A6866; Fri, 4 Apr 2008 02:06:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1CE3A6B13 for ; Fri, 4 Apr 2008 02:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, 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 SuthKV0LMSDz for ; Fri, 4 Apr 2008 02:06:40 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BBE623A6B09 for ; Fri, 4 Apr 2008 02:06:34 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2008 09:06:39 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp052) with SMTP; 04 Apr 2008 11:06:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+C/DlrSleCpCXlNVyOdR2OWw9H7FUbOwu3XkQyqd AOfjPxDnYAnpxN Message-ID: <47F5EF9E.4000501@gmx.net> Date: Fri, 04 Apr 2008 12:06:38 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F5EBE9.2070002@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I wrote that text in the DTLS-SRTP framework document and when I wrote it I did not think about E.164 number usage. As mentioned at the last meeting a bit more detail about the different use cases needs to be written. . I don't think that there is a lot (if any) benefit of using SIP Identity when the call comes from the PSTN. Ciao Hannes Dean Willis wrote: > > > On Apr 4, 2008, at 3:50 AM, Hannes Tschofenig wrote: >> I would instead not put the SIP Identity header there. >> No additional work needed. > > > Well, the problem is that you do apparently gain some benefit from the > presence of the Identity header when used with DTLS-SRTP. > > The DTLS-SRTP draft says: > >> The certificate fingerprints are sent in SDP over SIP as part of the >> offer/answer exchange. The SIP Identity mechanism [RFC4474] is used >> to provide integrity for the fingerprints. > > So, to the extent that fingerprint integrity is useful, RFC 4474 > identities are useful even when the assertion of identity is not strong. > > -- > 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 sip-bounces@ietf.org Fri Apr 4 02:08:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4984B28C2C6; Fri, 4 Apr 2008 02:08:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7EF28C290 for ; Fri, 4 Apr 2008 02:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, J_CHICKENPOX_64=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 DfFX6FBsGUAA for ; Fri, 4 Apr 2008 02:08:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 66D433A694E for ; Fri, 4 Apr 2008 02:08:55 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2008 09:09:00 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp050) with SMTP; 04 Apr 2008 11:09:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/DOcgO+0bDaYUe9XGG/4Z2Q1ogsbxCbzDED5r4nc WFev8esOYP4QEW Message-ID: <47F5F02C.1080202@gmx.net> Date: Fri, 04 Apr 2008 12:09:00 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Fischer, Kai" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F5EBE9.2070002@gmx.net> <198A10EC585EC74687BCA414E2A597180211AC82@MCHP7RDA.ww002.siemens.net> In-Reply-To: <198A10EC585EC74687BCA414E2A597180211AC82@MCHP7RDA.ww002.siemens.net> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -Allow SRTP, but don't protect the certificate fingerprint > That's what I would do. Ciao Hannes > Kai > > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Hannes Tschofenig >> Sent: Freitag, 4. April 2008 10:51 >> To: Elwell, John >> Cc: sip@ietf.org >> Subject: Re: [Sip] RFC 4474 and PSTN >> >> I would instead not put the SIP Identity header there. >> No additional work needed. >> >> Ciao >> Hannes >> >> Elwell, John wrote: >> >>> There seems to be some interest in adding some indicator to >>> >> the URI or >> >>> to the header field to warn of the limited guarantee of >>> >> authenticity or >> >>> the opposite (i.e.,lack of such an indicator would mean the >>> >> guarantee is >> >>> low, i.e., the identity has not been verified). >>> >>> I think on this issue it is just a matter of somebody putting things >>> together into a draft. I think Dean and/or Adam were the >>> >> main initiators >> >>> of this proposal - something like a source=pstn parameter. Would >>> somebody care to author a draft? Or do we need further discussion? >>> >>> 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 >>> >>> >> _______________________________________________ >> 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 sip-bounces@ietf.org Fri Apr 4 02:11:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2445D28C3A3; Fri, 4 Apr 2008 02:11:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5AE28C35D for ; Fri, 4 Apr 2008 02:11:46 -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 cwrWWl7MPb2k for ; Fri, 4 Apr 2008 02:11:42 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2B54C28C6A6 for ; Fri, 4 Apr 2008 02:11:11 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7B801218BB; Fri, 4 Apr 2008 11:04:29 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-95-47f5ef1daf8c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 62EB3218AF; Fri, 4 Apr 2008 11:04:29 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 11:04:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 11:04:29 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D85040E12D@esealmw109.eemea.ericsson.se> In-Reply-To: <69FD23C0-5B45-4423-87CB-796D36E2E5F3@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting thread-index: AciWMZI4iny97UyUS4qwnFwoiIfU+wAADGXA References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <47B2061B1E5E494B96AA40008300D85040DEFB@esealmw109.eemea.ericsson.se> <69FD23C0-5B45-4423-87CB-796D36E2E5F3@softarmor.com> From: "Hans Erik van Elburg" To: "Dean Willis" X-OriginalArrivalTime: 04 Apr 2008 09:04:29.0043 (UTC) FILETIME=[E38F9C30:01C89632] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ETSI and TISPAN use it for their Communication Diversion service, that means that people are using it. They stick in the History-Info header containing an entry for the diverting party and an entry for the diverted-to party. In fact they use History-Info here to say something about the future of the request;-) /Hans Erik -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, April 04, 2008 10:55 AM To: Hans Erik van Elburg Cc: sip@ietf.org Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting On Apr 4, 2008, at 2:45 AM, Hans Erik van Elburg wrote: > Dean mumbled: >> I therefore propose a provisional response from Proxy to Alice, which >> I'll provisionally call "121 (Retargeting)" > Is this any different then 181 Call Is Being Forwarded from RFC3261? Well, 181 is rather totally unspecified, AFAIK. Th main difference is that the proposed 121 has a Contact that tells you where the call is being forwarded. It also specifically means that the call was "retargeted" meaning that the anticipated respondent has changed. It might be reasonable to "further specify" 181 to mean the same thing, since, AFAIK, nobody ever actually used 181 for anything. John Elwell made a try at it in draft-elwell-sipping-redirection- reason-01, but this lacked the whole "Contact" parameter bit that tells the recipient where the call is being forwarded to. -- 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 sip-bounces@ietf.org Fri Apr 4 02:17:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DA728C3A9; Fri, 4 Apr 2008 02:17:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD1B3A6B09 for ; Fri, 4 Apr 2008 02:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, J_CHICKENPOX_64=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 E8VCFAh0Bnqd for ; Fri, 4 Apr 2008 02:16:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4D88B3A694E for ; Fri, 4 Apr 2008 02:16:58 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2008 09:17:03 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp054) with SMTP; 04 Apr 2008 11:17:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/+XishelD+1q3CPqacrBXdmYKLJiXHf3gYaQygi9 hlUasKKwPC37DZ Message-ID: <47F5F20E.9060601@gmx.net> Date: Fri, 04 Apr 2008 12:17:02 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Fischer, Kai" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F5EBE9.2070002@gmx.net> <198A10EC585EC74687BCA414E2A597180211AC82@MCHP7RDA.ww002.siemens.net> <47F5F02C.1080202@gmx.net> In-Reply-To: <47F5F02C.1080202@gmx.net> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There are actually two things that could be reasonable: * Use SRTP but without DTLS-SRTP (just use SDES in this case) * Use SRTP with DTLS-SRTP but without protecting the fingerprint. Hence, SIP Identity would not be used. Ciao Hannes Hannes Tschofenig wrote: >> -Allow SRTP, but don't protect the certificate fingerprint >> >> > That's what I would do. > > > Ciao > Hannes > > >> Kai >> >> >> >> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>> Behalf Of Hannes Tschofenig >>> Sent: Freitag, 4. April 2008 10:51 >>> To: Elwell, John >>> Cc: sip@ietf.org >>> Subject: Re: [Sip] RFC 4474 and PSTN >>> >>> I would instead not put the SIP Identity header there. >>> No additional work needed. >>> >>> Ciao >>> Hannes >>> >>> Elwell, John wrote: >>> >>> >>>> There seems to be some interest in adding some indicator to >>>> >>>> >>> the URI or >>> >>> >>>> to the header field to warn of the limited guarantee of >>>> >>>> >>> authenticity or >>> >>> >>>> the opposite (i.e.,lack of such an indicator would mean the >>>> >>>> >>> guarantee is >>> >>> >>>> low, i.e., the identity has not been verified). >>>> >>>> I think on this issue it is just a matter of somebody putting things >>>> together into a draft. I think Dean and/or Adam were the >>>> >>>> >>> main initiators >>> >>> >>>> of this proposal - something like a source=pstn parameter. Would >>>> somebody care to author a draft? Or do we need further discussion? >>>> >>>> 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 >>>> >>>> >>>> >>> _______________________________________________ >>> 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 sip-bounces@ietf.org Fri Apr 4 02:19:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DEF28C383; Fri, 4 Apr 2008 02:19:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B58428C318 for ; Fri, 4 Apr 2008 02:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=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 MVFeVZWOUL91 for ; Fri, 4 Apr 2008 02:19:08 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 8B9F428C15A for ; Fri, 4 Apr 2008 02:19:08 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id m349JCil024494; Fri, 4 Apr 2008 11:19:12 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m349JBtb005092; Fri, 4 Apr 2008 11:19:11 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 11:19:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 11:19:11 +0200 Message-ID: <198A10EC585EC74687BCA414E2A597180211AC91@MCHP7RDA.ww002.siemens.net> In-Reply-To: <47F5EBED.60104@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 4474 and SBC traversal Thread-Index: AciWMVK5QVxQYO7+SsabGdzOeXAZNwAAZRRg References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> <47F5EBED.60104@gmx.net> From: "Fischer, Kai" To: "Hannes Tschofenig" , "Elwell, John" X-OriginalArrivalTime: 04 Apr 2008 09:19:11.0121 (UTC) FILETIME=[F1520810:01C89634] Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > This issue is totally independent from E.164 Not fully. SBCs may exchange the domain part of the E.164 SIP URI, which causes a break of the RFC 4474 signature. With email-style URIs a simple exchange is not possible. > > I don't like the idea of requiring DTLS-SRTP to provide proof of > possession of the keying material. It is also the other way round. If you use DTLS-SRTP to encrypt RTP, the terminating domain is interested where the call originates from and in which domain the SRTP connection is terminated. DTLS-SRTP is not initially used as mean to establish an identity rather than as the initial aim to encrypt RTP. Kai > > Ciao > Hannes > > > Elwell, John wrote: > > SBCs do exist, often for good reasons that Hadriel has expanded on > > already. I firmly believe that DTLS-SRTP will not be deployable in a > > meaningful way without addressing this problem. Concerning > solutions, we > > have drafts from Kai and Dan, or perhaps a merger of the two somehow > > would work. It also depends to some extent whether we are > talking only > > about email-style URIs or about E.164-based URIs too. > > > > 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 > > > > _______________________________________________ > 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 sip-bounces@ietf.org Fri Apr 4 02:24:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B0628C1E0; Fri, 4 Apr 2008 02:24:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7703728C1E0 for ; Fri, 4 Apr 2008 02:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.771, 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 pOYOP06HPwt8 for ; Fri, 4 Apr 2008 02:24:12 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 137F53A67F1 for ; Fri, 4 Apr 2008 02:24:11 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2008 09:24:16 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp016) with SMTP; 04 Apr 2008 11:24:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+qe98nn36qK7nP/UxrJ5pQV63jHlD8CpO8Ieg01y RHOMxtRoNfSmx0 Message-ID: <47F5F3BF.8070508@gmx.net> Date: Fri, 04 Apr 2008 12:24:15 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Fischer, Kai" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> <47F5EBED.60104@gmx.net> <198A10EC585EC74687BCA414E2A597180211AC91@MCHP7RDA.ww002.siemens.net> In-Reply-To: <198A10EC585EC74687BCA414E2A597180211AC91@MCHP7RDA.ww002.siemens.net> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Kai, >> This issue is totally independent from E.164 >> > > Not fully. SBCs may exchange the domain part of the E.164 SIP URI, which > causes a break of the RFC 4474 signature. With email-style URIs a simple > exchange is not possible. > This is true but this applies to SIP Identity in general and not to E.164 number usage with SIP Identity only. Hence, I would not tie it to this discussion. > >> I don't like the idea of requiring DTLS-SRTP to provide proof of >> possession of the keying material. >> > > It is also the other way round. If you use DTLS-SRTP to encrypt RTP, the > terminating domain is interested where the call originates from and in > which domain the SRTP connection is terminated. DTLS-SRTP is not > initially used as mean to establish an identity rather than as the > initial aim to encrypt RTP. > I understand the need to know who the end points are. However, tying DTLS-SRTP is not a good idea since it a) increases the liklihood that SIP identity never get's deployed (since it is suddently far more complex than before) b) SIP identity is used also as a identity mechanism in areas where no media is exchanged. Ciao Hannes > Kai > > >> Ciao >> Hannes >> >> >> Elwell, John wrote: >> >>> SBCs do exist, often for good reasons that Hadriel has expanded on >>> already. I firmly believe that DTLS-SRTP will not be deployable in a >>> meaningful way without addressing this problem. Concerning >>> >> solutions, we >> >>> have drafts from Kai and Dan, or perhaps a merger of the two somehow >>> would work. It also depends to some extent whether we are >>> >> talking only >> >>> about email-style URIs or about E.164-based URIs too. >>> >>> 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 >>> >>> >> _______________________________________________ >> 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 sip-bounces@ietf.org Fri Apr 4 02:42:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EACA3A6CE0; Fri, 4 Apr 2008 02:42:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FBD28C40C for ; Fri, 4 Apr 2008 02:42:33 -0700 (PDT) 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 o64u53CgZUQg for ; Fri, 4 Apr 2008 02:42:33 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 766F13A68B7 for ; Fri, 4 Apr 2008 02:42: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 <0JYS00D2IOAVS1@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 10:42:33 +0100 (BST) Date: Fri, 04 Apr 2008 10:03:16 +0100 From: "Elwell, John" In-reply-to: <47F5EBDE.3070907@gmx.net> To: Hannes Tschofenig Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciWMPa0E0JOfvx5RY6XpXhRXYrlXQAAVAYg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> Cc: sip@ietf.org Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hannes, The problem is the changing of domain part as the E.164-based URI traverses service providers, so that it no longer represents the true origin of the request. Furthermore it breaks the RFC 4474 signature, unless re-signed by the service provider. With an email-style SIP URI (i.e. one in which the user part does not look like an E.164 number), intermediate service providers cannot change the domain part (or if they do they break things entirely). John > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: 04 April 2008 09:51 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs > > I wonder whether RFC 4474 isn't doing fine when you assume that E.164 > numbers apear in an email style format. > The assumption there is, however, that devices display the > domain part > as well (which they don't do today) and user's actually > configure their > authorization policies in a way that it includes both the > E.164 number > and a corresponding domain name. > > Hence, this is not a standardization problem but a usability issue. > > Do I misunderstand your proposal? > > Ciao > Hannes > > > Elwell, John wrote: > > On this thread I would like to explore what can be done in terms of > > avoiding the issues concerned with RFC 4474 and E.164-based > SIP URIs by > > migration towards the use of email-style URIs. > > E.164-based URIs will still be needed, particularly for interworking > > with PSTN but also in those SIP environments where E.164 numbers are > > more easily handled (e.g., phones with number-based user > interfaces). > > But perhaps we can explore more the possibility of using > the two forms > > in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) > and email-style > > in From. I know Dan has an interesting straw man on this > topic, which I > > will allow him to present himself. > > > > 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 > > > > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 02:42:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8946228C603; Fri, 4 Apr 2008 02:42:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C1128C40C for ; Fri, 4 Apr 2008 02:42:34 -0700 (PDT) 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 4gp6bbwGKaSy for ; Fri, 4 Apr 2008 02:42: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 D55EB28C350 for ; Fri, 4 Apr 2008 02:42: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 <0JYS00D2IOAVS1@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 10:42:33 +0100 (BST) Date: Fri, 04 Apr 2008 10:05:20 +0100 From: "Elwell, John" In-reply-to: <47F5EBED.60104@gmx.net> To: Hannes Tschofenig Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0916129@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] RFC 4474 and SBC traversal Thread-Index: AciWMQRzeyuACkuXRLiw+npHGPjTgAAAcLFA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> <47F5EBED.60104@gmx.net> Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: 04 April 2008 09:51 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4474 and SBC traversal > > This issue is totally independent from E.164 [JRE] Agreed. > > I don't like the idea of requiring DTLS-SRTP to provide proof of > possession of the keying material. [JRE] I don't understand. Are you saying you don't want to couple DTLS-SRTP with RFC 4474 or similar? 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 sip-bounces@ietf.org Fri Apr 4 02:42:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6105328C696; Fri, 4 Apr 2008 02:42:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F3B28C421 for ; Fri, 4 Apr 2008 02:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_64=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 ZTDhZ3f5uTPp for ; Fri, 4 Apr 2008 02:42: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 3E1C628C3B5 for ; Fri, 4 Apr 2008 02:42: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 <0JYS00DAEOAVHD@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 10:42:33 +0100 (BST) Date: Fri, 04 Apr 2008 10:13:10 +0100 From: "Elwell, John" In-reply-to: <47F5EBE9.2070002@gmx.net> To: Hannes Tschofenig Message-id: <0D5F89FAC29E2C41B98A6A762007F5D091613C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AciWMR0Tal+B+ugETLynMBq4fEFwPQAAgQJg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F5EBE9.2070002@gmx.net> Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hannes, Personally I think there will be occasions when knowing that media is secured as far as a known PSTN gateway can be useful, so signing by the gateway I think can still have some value. One way to achieve this would be with an email-style SIP URI for the gateway. So I guess the questions are: 1)Whether there is any value in a gateway signing with an E.164-based SIP URI, e.g., sip:+123456789@gateway.example.org;user=phone, and if so whether this needs a qualifier such a source=PSTN. 2) Whether there is any value in a qualifier such as source=PSTN even in the absence of an RFC 4474 signature. John > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: 04 April 2008 09:51 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4474 and PSTN > > I would instead not put the SIP Identity header there. > No additional work needed. > > Ciao > Hannes > > Elwell, John wrote: > > There seems to be some interest in adding some indicator to > the URI or > > to the header field to warn of the limited guarantee of > authenticity or > > the opposite (i.e.,lack of such an indicator would mean the > guarantee is > > low, i.e., the identity has not been verified). > > > > I think on this issue it is just a matter of somebody putting things > > together into a draft. I think Dean and/or Adam were the > main initiators > > of this proposal - something like a source=pstn parameter. Would > > somebody care to author a draft? Or do we need further discussion? > > > > 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 > > > > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 02:50:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E71B28C751; Fri, 4 Apr 2008 02:50:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B100A3A684D for ; Fri, 4 Apr 2008 02:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=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 UsUPN5dxZIzW for ; Fri, 4 Apr 2008 02:50:04 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id CB2E928C771 for ; Fri, 4 Apr 2008 02:46:49 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id m349krX8023095; Fri, 4 Apr 2008 11:46:53 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m349krCH020569; Fri, 4 Apr 2008 11:46:53 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 11:46:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 11:46:50 +0200 Message-ID: <198A10EC585EC74687BCA414E2A597180211ACA5@MCHP7RDA.ww002.siemens.net> In-Reply-To: <47F5F3BF.8070508@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 4474 and SBC traversal Thread-Index: AciWNcvhzfyyVHd1QziWx1dsUCoqEgAATIQA References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> <47F5EBED.60104@gmx.net> <198A10EC585EC74687BCA414E2A597180211AC91@MCHP7RDA.ww002.siemens.net> <47F5F3BF.8070508@gmx.net> From: "Fischer, Kai" To: "Hannes Tschofenig" X-OriginalArrivalTime: 04 Apr 2008 09:46:52.0417 (UTC) FILETIME=[CF87AF10:01C89638] Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > >> This issue is totally independent from E.164 > >> > > > > Not fully. SBCs may exchange the domain part of the E.164 > SIP URI, which > > causes a break of the RFC 4474 signature. With email-style > URIs a simple > > exchange is not possible. > > > This is true but this applies to SIP Identity in general and not to > E.164 number usage with SIP Identity only. > Hence, I would not tie it to this discussion. My point was, that with E.164 an intermediary SBC is able to exchange the domain part without a possibility on the terminating side to recognize the change. With email-like SIP URIs the domain change is not possible or only with a hack. Two cases need to be differentiated: -SBC modifies SDP: This results in a necessity to create a new SIP Identity signature and a change of the domain part in the From header (valid for both types of SIP URIs email and E.164) -SBC modifies From header field only: This is applicable to E.164 only and as far as I have recognized from the past discussions a real world behavior > > > > >> I don't like the idea of requiring DTLS-SRTP to provide proof of > >> possession of the keying material. > >> > > > > It is also the other way round. If you use DTLS-SRTP to > encrypt RTP, the > > terminating domain is interested where the call originates > from and in > > which domain the SRTP connection is terminated. DTLS-SRTP is not > > initially used as mean to establish an identity rather than as the > > initial aim to encrypt RTP. > > > > I understand the need to know who the end points are. However, tying > DTLS-SRTP is not a good idea since it > a) increases the liklihood that SIP identity never get's > deployed (since > it is suddently far more complex than before) > b) SIP identity is used also as a identity mechanism in areas > where no > media is exchanged. Do you propose to not apply RFC 4474 for DTLS-SRTP fingerprint protection and to rely on something different? Kai > > Ciao > Hannes > > > Kai > > > > > >> Ciao > >> Hannes > >> > >> > >> Elwell, John wrote: > >> > >>> SBCs do exist, often for good reasons that Hadriel has expanded on > >>> already. I firmly believe that DTLS-SRTP will not be > deployable in a > >>> meaningful way without addressing this problem. Concerning > >>> > >> solutions, we > >> > >>> have drafts from Kai and Dan, or perhaps a merger of the > two somehow > >>> would work. It also depends to some extent whether we are > >>> > >> talking only > >> > >>> about email-style URIs or about E.164-based URIs too. > >>> > >>> 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 > >>> > >>> > >> _______________________________________________ > >> 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 sip-bounces@ietf.org Fri Apr 4 04:26:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9758E28C3CF; Fri, 4 Apr 2008 04:26:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCEB53A68D7 for ; Fri, 4 Apr 2008 04:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, 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 1Yo3MkzS4G4a for ; Fri, 4 Apr 2008 04:26:37 -0700 (PDT) Received: from taimen.tutpro.com (harjus.tutpro.com [192.98.100.3]) by core3.amsl.com (Postfix) with ESMTP id 40C1328C628 for ; Fri, 4 Apr 2008 04:25:26 -0700 (PDT) Received: by taimen.tutpro.com (Postfix, from userid 1000) id 98A8D33A89F; Fri, 4 Apr 2008 14:25:33 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18422.4141.562056.8980@harjus.tutpro.com> Date: Fri, 4 Apr 2008 14:25:33 +0300 To: "ajay thakur" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org Subject: [Sip] multiple register server or multiple outbound proxies X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ajay thakur writes: > I have doubt about having multiple registrar server configuration and > multiple outbound server configuration on the phones? > And is it really required? Any comments on this ? for redundancy it would have been a good idea that a SIP ua would have required to register will all configured outbound servers, but unfortunately that is not the case with outbound i-d, which makes the feature totally useless. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 04:36:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B875028C383; Fri, 4 Apr 2008 04:36:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551243A67A7 for ; Fri, 4 Apr 2008 04:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, 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 oIitZKaKHx40 for ; Fri, 4 Apr 2008 04:36:52 -0700 (PDT) Received: from taimen.tutpro.com (harjus.tutpro.com [192.98.100.3]) by core3.amsl.com (Postfix) with ESMTP id D467428C261 for ; Fri, 4 Apr 2008 04:36:51 -0700 (PDT) Received: by taimen.tutpro.com (Postfix, from userid 1000) id 5B2D533A89F; Fri, 4 Apr 2008 14:36:59 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18422.4827.289907.138057@harjus.tutpro.com> Date: Fri, 4 Apr 2008 14:36:59 +0300 To: Dean Willis In-Reply-To: <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> References: <200803251629.m2PGTC0N025942@dragon.ariadne.com> <28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com> <18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47F55014.9040408@cisco.com> <1ECE0EB50388174! 790F9694F77522CCF15EB7F8A@zrc2hxm0.corp.nortel.com> <18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: "sip@ietf.org List" Subject: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis writes: > Ok, now I can hear people screaming "But this is what History-Info > does!" > > That might be. I'm not sure I actually understood History-Info. But > this seems a bunch simpler, AND it allows for inclusion of "forward > knowledge" (i.e., parameters inserted under application control) > rather than only "backward knowledge" (a record of the decisions that > got us here). i fully agree with dean here. dean's proposal is easy understand and implement. h-i is far too complex because of all the indexing stuff, hassle with uri params vs. h-i params, etc. > Note also that this doesn't seem to capture the full range of History- > Info cases. I think it is a simpler replacement that gives the > required functionality. And since it's just new extension header > fields, it is 100% backwards compatible. again i fully agree. whatever h-i tried to accomplish was clearly to too much, because it resulted into complexity that never got implemented by popular UAs or proxies. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 04:56:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9C23A6E4B; Fri, 4 Apr 2008 04:56:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5733A6D8B for ; Fri, 4 Apr 2008 04:56:24 -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=[AWL=-0.000, 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 jErcnXnTUcxJ for ; Fri, 4 Apr 2008 04:56:23 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BA59E3A6E3B for ; Fri, 4 Apr 2008 04:55:19 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B487C221A8; Fri, 4 Apr 2008 13:49:50 +0200 (CEST) X-AuditID: c1b4fb3e-ad196bb000004ec0-de-47f615ddc95b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 10A9F2213F; Fri, 4 Apr 2008 13:49:49 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 13:49:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 13:49:32 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals thread-index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgACHxX6AAFMnqEAAeTUuw References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> From: "Hans Erik van Elburg" To: "Francois Audet" , "Christer Holmberg" , "Juha Heinanen" X-OriginalArrivalTime: 04 Apr 2008 11:49:32.0373 (UTC) FILETIME=[F267D850:01C89649] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think that in a closed environment like IMS where all proxies can be guaranteed to support loose routing, there is effectively almost no difference between P-Called-Party-ID and Target header. One case where also in IMS the Target and the P-Called-Party-ID would contain different values is for example when you call a freephone address of a certain user, where the freephone uri is a service identity on an AS. The freephone service would reroute the request to the actual user user@company.com. The user may want to know that he was called through a freephone number in this case: P-Called-Party-ID: user1@company.com Target: freephone-user1@operator.com /Hans Erik -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Thursday, April 03, 2008 11:03 PM To: Christer Holmberg; Hans Erik van Elburg; Juha Heinanen Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals So what is the P-Called-Party-ID used for? I'm trying to figure out the different use cases for P-Called-Party-ID versus Target. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, April 03, 2008 13:48 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Juha Heinanen > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > > Hi, > > The P-Called-Party-ID is only inserted by the registrar of the UAS, > while the Target can be inserted also by other entities. _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 05:03:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB2728C2AE; Fri, 4 Apr 2008 05:03:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D9428C32C for ; Fri, 4 Apr 2008 05:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 vB3XKgbr5JUD for ; Fri, 4 Apr 2008 05:03:36 -0700 (PDT) Received: from taimen.tutpro.com (harjus.tutpro.com [192.98.100.3]) by core3.amsl.com (Postfix) with ESMTP id 5F5C528C320 for ; Fri, 4 Apr 2008 05:03:36 -0700 (PDT) Received: by taimen.tutpro.com (Postfix, from userid 1000) id DBF2C33A89F; Fri, 4 Apr 2008 15:03:43 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18422.6431.775786.710973@harjus.tutpro.com> Date: Fri, 4 Apr 2008 15:03:43 +0300 To: "Hans Erik van Elburg" In-Reply-To: <47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.ericsson.se> References: <200803251629.m2PGTC0N025942@dragon.ariadne.com> <28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com> <18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Francois Audet , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hans Erik van Elburg writes: > P-Called-Party-ID: user1@company.com > Target: freephone-user1@operator.com based on the explanation yesterday on this mailing list, i got the impression that P-Called-Party-ID would in this case contain the actual called uri, i.e., the freephone uri, and r-uri would contain the contact of the answering phone. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 05:13:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B2C28C1E8; Fri, 4 Apr 2008 05:13:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36AA53A6E15 for ; Fri, 4 Apr 2008 05:13:13 -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 vKrugpm0hVNo for ; Fri, 4 Apr 2008 05:13:12 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1D2883A6E26 for ; Fri, 4 Apr 2008 05:13:12 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A3A2E22526; Fri, 4 Apr 2008 14:09:00 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-32-47f61a5c8703 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 82F7A22524; Fri, 4 Apr 2008 14:09:00 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 14:09:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 14:09:03 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D85044375A@esealmw109.eemea.ericsson.se> In-Reply-To: <18422.6431.775786.710973@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals thread-index: AciWS+1wXc7b1sgWRqaT3G1jxlAcvwAABuLg References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.eri csson.se > <18422.6431.775786.710973@harjus.tutpro.com> From: "Hans Erik van Elburg" To: "Juha Heinanen" X-OriginalArrivalTime: 04 Apr 2008 12:09:00.0018 (UTC) FILETIME=[AA605520:01C8964C] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Francois Audet , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org No, because I assumed that the freephone number is not a registered AOR of the user. The P-Called-Party-ID is effectively populated by the registrar when it replaces the AOR in the Request URI with the Contact address. So we get: Request URI = Contact address P-Called-Party-ID: user1@company.com Target: freephone-user1@operator.com /Hans Erik -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Friday, April 04, 2008 2:04 PM To: Hans Erik van Elburg Cc: Francois Audet; Christer Holmberg; sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals Hans Erik van Elburg writes: > P-Called-Party-ID: user1@company.com > Target: freephone-user1@operator.com based on the explanation yesterday on this mailing list, i got the impression that P-Called-Party-ID would in this case contain the actual called uri, i.e., the freephone uri, and r-uri would contain the contact of the answering phone. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 05:19:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F0B3A697F; Fri, 4 Apr 2008 05:19:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D2C3A697F for ; Fri, 4 Apr 2008 05:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 CeLftRc6th42 for ; Fri, 4 Apr 2008 05:19:35 -0700 (PDT) Received: from taimen.tutpro.com (harjus.tutpro.com [192.98.100.3]) by core3.amsl.com (Postfix) with ESMTP id BD4113A6AC6 for ; Fri, 4 Apr 2008 05:19:34 -0700 (PDT) Received: by taimen.tutpro.com (Postfix, from userid 1000) id 6501A33A89F; Fri, 4 Apr 2008 15:19:41 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18422.7390.345441.907652@harjus.tutpro.com> Date: Fri, 4 Apr 2008 15:19:42 +0300 To: "Hans Erik van Elburg" In-Reply-To: <47B2061B1E5E494B96AA40008300D85044375A@esealmw109.eemea.ericsson.se> References: <200803251629.m2PGTC0N025942@dragon.ariadne.com> <28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com> <18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.eri csson.se > <18422.6431.775786.710973@harjus.tutpro.com> <47B2061B1E5E494B96AA40008300D85044375A@esealmw109.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Francois Audet , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hans Erik van Elburg writes: > No, because I assumed that the freephone number is not a registered AOR > of the user. ok, so in your example proxy was forwarding the call to the freephone uri to the user, i.e., freephone number was not an alias of the user's aor. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 05:24:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC4228C434; Fri, 4 Apr 2008 05:24:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5665128C42D for ; Fri, 4 Apr 2008 05:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, 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 uJlzQa6FfXL0 for ; Fri, 4 Apr 2008 05:24:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 445A728C32C for ; Fri, 4 Apr 2008 05:24:04 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C330A207A0; Fri, 4 Apr 2008 14:24:08 +0200 (CEST) X-AuditID: c1b4fb3c-ac898bb00000193b-60-47f61de896ef Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A5CE320587; Fri, 4 Apr 2008 14:24:08 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 14:24:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 14:24:11 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> In-Reply-To: <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" thread-index: AciWJPKnCP5jigZqS/2hNXb26Vh3gQAJofpw References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F77522 CCF15EB7 F8A@zrc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> From: "Hans Erik van Elburg" To: "Dean Willis" , X-OriginalArrivalTime: 04 Apr 2008 12:24:08.0026 (UTC) FILETIME=[C7975BA0:01C8964E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There seems to be a misunderstanding here, there is no intention for stacking Target headers at all. There will always have to be zero or one target header field with one clear meaning: "current target". As soon as a retarget (using the definition from UALR draft) occurs an existing target header will have to be removed, as it no longer represents the current target. Params only seems to tackle the parameter loss issue, and it seems further to solve a different problem alltogether i.e. how to get parameters from the caller to the callee. There is a risk that parameters that where only intended to be received by user B end up at user C. /Hans Erik -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, April 04, 2008 9:07 AM To: sip@ietf.org List Subject: [Sip] Long: Thoughts on "retargeting proposals" Sorry about the HTML formating. I'm too lazy to wrap my lines. And yes, this should probably be in an ID, but I'm too lazy for that too. Here's why the answers seem to be confusing -- the question is confused. I'd like to try and rein it in a bit, and make a proposal. We have a couple of things we want: 1) Delivery of application-specific info (aka "parameters") from the originating UA to the terminating UA 2) Delivery of parameters from proxies to the terminating UA 3) Information to allow the terminating UA to know which application, function, or identity (or something else) at that UA is being targeted by the request, over and above the mundane aspects of the request such as ordinary headers and bodies. Presumably this information is inserted somehow along the way, either at the source UA or some intermediate (proxy or the like) node. This information may, or may not, be the same as #1 and #2 above. 4) We think we have a need for the terminating UA to figure out who inserted each bit of information. I find this compelling. 5) We think we have a need for the terminating UA to understand the entire decision tree that resulted in the call arriving at it. I don't find this compelling at all (which is why I opposed Diversion and History-Info), as I think that every application people THINK they need this for is more readily addressed by 1-3. These "needs" have been getting tangled up in the most perniciously confusing sorts of ways I can imagine. We have History-Info, Diversion, P-This-That-And-the-Other-Thing, and probably a couple of dozen other hackneyed ways to work around this problem. Quite probably a large number of the SIP extension headers we've documented have been narrow application-specific functions that really didn't need an RFC, but since an RFC is required to get a header, we've had to do a lot of work. Why don't we have an easy answer? The problem starts with SIP's take-off from HTTP. If we were using HTTP, we could use request-URI parameters to talk to the application. This works very well in HTTP land, since outside of very specialized cases, HTTP proxies don't change the request URI, and when they do it's an additive thing ; they add parameters as needed. Note that neither IETF nor W3C has found it needful to standardize HTTP request parameters. Any fool can code up a CGI script that uses new ones, and the neat thing is, they're always scoped to the application in use. Let's look at the request for my Google home page: http://www.google.com/ig?hl=en&source=iglk This conveys the location of the target node, an application identifier, and two parameters delivered to that application. The target node is www.google.com, the application is "ig", and the parameters are "hl", which has a value of "en", and "source", which has a value of "iglk". RFC 2543 just didn't work this way. Every proxy mangled the request URI to the best of its ability, such that there was absolutely no way to use the request URI to pass any useful information between UAs. I'm not sure why we went down this path. I argued against it at the time, but obviously I lost that argument. We partially fixed this with loose routing in RFC 3261, but we didn't fix it well enough, and we still have the problem. Jonathan's UA Loose Routing draft has tried to get us closer to the HTTP model (but do so with full backward compatibility), and lots of people have complained about the apparent resulting complexity. It shouldn't be complex -- it's so easy with HTTP, but SIP just isn't HTTP anymore. We've tried putting stuff into body parts, and the ongoing war over proxy manipulation of body parts and requirements for multi-part MIME has been running for years now. Besides, we don't really have a way of indicating which body part does what, as the MIME syntax just doesn't give us a handle on it. We have P-Called-Party-ID, which satisfies a subset of problem #3 by letting the terminating UA know which identity at that UA the request is targeting (and this COULD be used to indicate an application as opposed to a user, I suppose). We also have Target, a header that as proposed provides a sort of partial combination of 3, 4, and 5 by basically stacking up another header instance every time a proxy changes the request URI. As I understand the author's intentions (which is not what I get from the draft), the idea is that every URI seen on the path from UAC to UAS is recorded in an instance of the Target header, One can then read the list backwards, and sort of guess which one was inserted by various proxies and maybe figure out which one was inserted by the originating UA. I mostly like what I think I understand of the author's intentions, but it's not QUITE what I want. And I have a head ache from trying to sort this stuff out. So here's a suggestion for a Radically Different Approach. Let's define a new SIP extension header field. I call it "Params" for now. Eachs Params header field contains one or more parameter=value pairs. The only mandatory of these pairs encodes the role (UA, proxy) and identity of the node inserting the Params field. Another pair might encode the URI targeted by the request as it leaves that node (which is probably only useful for debugging). Another pair might encode the identity targeted by the request, which as we know is not the same as the URI of the request. Still more pairs would encode any parameters being delivered to the UAS terminating the request. We also need a rule: only insert a Params if you expect it to be useful to the terminating UAS. If you aren't changing something , DON'T PUT ONE IN! So, here's an example (with many fields left out) Alice-1-->AliceOutboundProxy--2-->BobHomeProxy--3-- >BobOutboundProxy--4-->Bob Message 1: (note that the param MyAppID=23 is encoded by Alice) INVITE sisp:bob@example.com SIP/2.0 From: sips:alice@192.168.2.1 To: sips:bob@example.com Call-ID: 1j9FpLxk3uxtm8tn@192.168.2.1 Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:alice@192.168.2.1,MyAppID=23 Message 2: (note no new Params) INVITE sips:bob@example.com SIP/2.0 From: sips:alice@192.168.2.1 To: sips:bob@example.com Call-ID: 1j9FpLxk3uxtm8tn@192.168.2.1 Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:alice@192.168.2.1,MyAppID=23 Message 3: (retargeting occurs) INVITE sips:bob@192.16.2.2 SIP/2.0 From: sips:alice@192.168.2.1 To: sips:bob@example.com Call-ID: 1j9FpLxk3uxtm8tn@192.168.2.1 Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS bproxy.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:alice@192.168.2.1,MyAppID=23 Params: role=proxy,src=bproxy.example.com,target= Message 4: (note no new Params) INVITE sips:bob@192.16.2.2 SIP/2.0 From: sips:alice@192.168.2.1 To: sips:bob@example.com Call-ID: 1j9FpLxk3uxtm8tn@192.168.2.1 Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS bproxy.example.com:5061;branch=z9hG4bKnashds7 Via: SIP/2.0/TLS boproxy.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:alice@192.168.2.1,MyAppID=23 Params: role=proxy,src=bproxy.example.com,target= So with this request, Bob's UA can look at it and say "Ok, this requested is targeted to sips:bob@example.com, so I'd best respond appropriately. And oh look, the originating UA wants me to know that MyAppID=23." Diagnostically, we can also look at it and see that there was a retargeting at the proxy bproxy.example.com, since said proxy was kind enough to insert the Params telling us so. Ok, now I can hear people screaming "But this is what History-Info does!" That might be. I'm not sure I actually understood History-Info. But this seems a bunch simpler, AND it allows for inclusion of "forward knowledge" (i.e., parameters inserted under application control) rather than only "backward knowledge" (a record of the decisions that got us here). Hence RFC 3087 / RFC 4458 type control mechanisms can be used effectively. Hint: If you have a voice mail application that is dependent on knowing that a retargeting decision resulted from a busy condition, it's easy to put a "cause=busy" into the relevant Params. Note also that this doesn't seem to capture the full range of History- Info cases. I think it is a simpler replacement that gives the required functionality. And since it's just new extension header fields, it is 100% backwards compatible. There are also some interesting anonymization interactions. For example, if you don't want to reveal a source, use anonymous or a temp- gruu in the "src=" Params. Or better yet, don't insert a Params at all! They're optional except when rerouting or retargeting. -- 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 _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 05:26:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F9928C2D5; Fri, 4 Apr 2008 05:26:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB17828C261 for ; Fri, 4 Apr 2008 05:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 BLONHs0JrLXb for ; Fri, 4 Apr 2008 05:26:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8079B28C66E for ; Fri, 4 Apr 2008 05:26:24 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 59330223E6; Fri, 4 Apr 2008 14:22:18 +0200 (CEST) X-AuditID: c1b4fb3e-af19abb000004ec0-86-47f61d7a6377 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 45E4E223DF; Fri, 4 Apr 2008 14:22:18 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 14:22:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 14:22:21 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D8504437C1@esealmw109.eemea.ericsson.se> In-Reply-To: <18422.7390.345441.907652@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals thread-index: AciWTiiZWL+QoRP4QKy4ttBdQOCtIQAACJHQ References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.eri csson.s e><18422.643 1.775786.710973@harjus.tutpro.com><47B2061B1E5E494B96AA40008300D85044375A@esealmw109.eemea.ericsson.se> <18422.7390.345441.907652@harjus.tutpro.com> From: "Hans Erik van Elburg" To: "Juha Heinanen" X-OriginalArrivalTime: 04 Apr 2008 12:22:17.0670 (UTC) FILETIME=[85D05E60:01C8964E] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Francois Audet , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Correct. /Hans Erik -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Friday, April 04, 2008 2:20 PM To: Hans Erik van Elburg Cc: Francois Audet; Christer Holmberg; sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals Hans Erik van Elburg writes: > No, because I assumed that the freephone number is not a registered AOR > of the user. ok, so in your example proxy was forwarding the call to the freephone uri to the user, i.e., freephone number was not an alias of the user's aor. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 06:12:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A6A3A6BD6; Fri, 4 Apr 2008 06:12:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4FF3A6BD6 for ; Fri, 4 Apr 2008 06:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.59 X-Spam-Level: X-Spam-Status: No, score=-4.59 tagged_above=-999 required=5 tests=[AWL=2.009, 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 mwTYOhZEzXxK for ; Fri, 4 Apr 2008 06:12: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 4C2EC3A6C80 for ; Fri, 4 Apr 2008 06:12:06 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2008 06:12:12 -0700 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 m34DCC2V013997; Fri, 4 Apr 2008 06:12:12 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m34DC4Fq023571; Fri, 4 Apr 2008 13:12:11 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, 4 Apr 2008 09:12:04 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 09:12:04 -0400 Message-ID: <47F6293D.80004@cisco.com> Date: Fri, 04 Apr 2008 09:12:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> In-Reply-To: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> X-OriginalArrivalTime: 04 Apr 2008 13:12:04.0240 (UTC) FILETIME=[79F2C900:01C89655] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3689; t=1207314732; x=1208178732; c=relaxed/simple; s=sjdkim1004; 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]=20Preventing=20unanticipated=20re spondent=20syndrome=20when=20retargeting |Sender:=20; bh=uZELEbdK4EHyphE5XmR8oFPlpL8VAg5l3ci+rlqYp8A=; b=f0Ka3ltKQVWh5a53ryKYQGP0jA0hBHSp225lxIZMpC4w98z8Zz9l0uXf9B fS/R2Ksan/iAt1gtk7TXx+g7WUUlylGmb94RQnBOW1IQGeLdKrhq0gy8XHj1 FKBCo4q8V4cVTsaSFJNMIWkYbJuP/GTJb6rafkhw5VfWtvH5Xfd/8=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, Why response code 121 when we already have 181? Perhaps it needs some added info but it seems like the right response. Second, in the case where Charlie registers with Bob's AOR, how does identity work? Won't Charlie appear to *be* Bob? Presumably it depends on what credentials Charlie uses. But I think in many cases this will indeed look like Bob. Paul Dean Willis wrote: > I define "unanticipated respondent syndrome" as the sense of surprise > Alice gets when she calls Bob, only to have the call answered by > Charlie. This is especially problematic if the sorts of security > operations that depend on Alice having some sort of keying > relationship with Charlie become important. > > Alice is expecting: > > Alice--1-->Proxy--2-->Bob > > but instead she gets: > > Alice--1-->Proxy--2-->Charlie > > because Bob forwarded his phone to Charlie, or because Charlie, who is > authorized to do so, registered as a contact for Bob, and Bob didn't > answer (or has a lwoer qvalue, or whatever) > > RFC 4916 lets Alice find out who answered the phone in the most > difficult of cases, and other techniques like P-Asserted-Identity in a > response address simpler cases (or we can use endpoint- asserted RFC > 4474 Identity when the keys are known or discoverable). So that's not > a problem. Alice can figure out that she's talking to Charlie, once > they get connected. > > The only problem is cluing in Alice that she's about to be talking to > Charlie instead of Bob. > > In the cases I've identified above, the proxy knows that it is > retargeting the request to Charlie, not rerouting the request to Bob. > How does it know this? It either a) knows that the Call Forwarding > feature has been activated, and that's always a retarget, or b) knows > that the contact for Bob was registered by Charlie, who isn't Bob (but > that Charlie is authorized to register for Bob's AOR). In fact, if > this the case, it knows both Charlie's authentication identity and his > contact. > > Since the proxy knows, it should be able to inform Alice. > > I therefore propose a provisional response from Proxy to Alice, which > I'll provisionally call "121 (Retargeting)" > > A proxy executing a retargeting operation (by which we mean an > operation that replaces the request URI such that the authenticated > identity of the new request URI is different from the authenticated > identity of the old one) SHOULD return a 121 (Retargeting) provisional > response. The 121 response contains a Contact header field, the value > of which is the new identity being targeted. Optionally, we might > include some sort of "cause" parameter, explaining why the request is > being retargeted (like "Bob's dead, talk to Charlie"). > > If a proxy doesn't know whether it is rerouting or retargeting, it > SHOULD assume that it is retargeting, and send the appropriate 121 > response. > > In conclusion, this preserves the proxy-mediated functionality > required for draft-ietf-sip-outbound, while giving us the I-know-who-I- > expect-to-reach function of a 302 (Redirect). > > Yeah, this should be an I-D. I'm now accepting volunteer co-authors to > do the dirty work, assuming this idea gets any traction. > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 06:22:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D89228C19D; Fri, 4 Apr 2008 06:22:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1243A6C28 for ; Fri, 4 Apr 2008 01:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.866 X-Spam-Level: X-Spam-Status: No, score=0.866 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwCTv422nf0I for ; Fri, 4 Apr 2008 01:29:29 -0700 (PDT) Received: from mx-01.nestgroup.net (NeSTGROUP.NET [203.200.157.75]) by core3.amsl.com (Postfix) with ESMTP id 0CA8B3A6D24 for ; Fri, 4 Apr 2008 01:29:26 -0700 (PDT) Received: from MAIL-TVM.tvm.nestgroup.net ([192.168.192.74]) by mx-01.nestgroup.net (8.13.1/8.13.1) with ESMTP id m348cmHL008723; Fri, 4 Apr 2008 14:11:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 13:58:32 +0530 Message-ID: <9A1299C7A40D7447A108107E951450CA06F3ABFE@MAIL-TVM.tvm.nestgroup.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Server for testing Thread-Index: AciWLd4rMj6CmmaGQ+6gxjmKYeM/lw== From: "Anisha Kumar" To: undisclosed-recipients:; X-Mailman-Approved-At: Fri, 04 Apr 2008 06:22:54 -0700 Subject: [Sip] Server for testing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1061978715==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1061978715== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8962D.DE523EAA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8962D.DE523EAA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi , =20 I need an opens source or freeware server that can provide Voice Mail ,Conferencing and Mobility functionalities to H.323 and a SIP endpoints. Is Asterisk the only option or are there any other such servers available for testing ? =20 Kindly do provide your valuable suggestions .Awaiting an earliest response. =20 Regards, Anisha ------_=_NextPart_001_01C8962D.DE523EAA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 ,
 
 I=20 need an opens source or freeware server that can provide Voice Mail=20 ,Conferencing and Mobility functionalities to H.323 and a SIP endpoints. = Is=20 Asterisk the only option or are there any other such servers available = for=20 testing ?
 
 Kindly do provide your valuable suggestions = .Awaiting an=20 earliest response.
 
Regards,
Anisha
------_=_NextPart_001_01C8962D.DE523EAA-- --===============1061978715== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1061978715==-- From sip-bounces@ietf.org Fri Apr 4 08:26:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2D63A6F9B; Fri, 4 Apr 2008 08:26:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A103A6F5A for ; Fri, 4 Apr 2008 08:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.045, 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 BIv41EBbQq+T for ; Fri, 4 Apr 2008 08:26:31 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 5404F3A67A1 for ; Fri, 4 Apr 2008 08:26:30 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYT00B5G4866E@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 16:26:32 +0100 (BST) Date: Fri, 04 Apr 2008 13:15:21 +0100 From: "Elwell, John" In-reply-to: A <47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.ericsson.se> To: Hans Erik van Elburg , Francois Audet , Christer Holmberg , Juha Heinanen Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095B9CC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgACHxX6AAFMnqEAAeTUuwAAGG6hA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <200803251629.m2PGTC0N025942@dragon.ariadne.com> <28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com> <18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hans Erik, This is a good example. For comparison purposes, can anyone say how we would achieve this with: i) ua-loose-route ii) history-info iii) Dean's proposal? John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hans Erik van Elburg > Sent: 04 April 2008 12:50 > To: Francois Audet; Christer Holmberg; Juha Heinanen > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: Re: [Sip] Comparison of retargeting proposals > > I think that in a closed environment like IMS where all proxies can be > guaranteed to support loose routing, there is effectively almost no > difference between P-Called-Party-ID and Target header. > > One case where also in IMS the Target and the P-Called-Party-ID would > contain different values is for example when you call a freephone > address of a certain user, where the freephone uri is a > service identity > on an AS. The freephone service would reroute the request to > the actual > user user@company.com. The user may want to know that he was called > through a freephone number in this case: > P-Called-Party-ID: user1@company.com > Target: freephone-user1@operator.com > > /Hans Erik > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, April 03, 2008 11:03 PM > To: Christer Holmberg; Hans Erik van Elburg; Juha Heinanen > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > So what is the P-Called-Party-ID used for? > > I'm trying to figure out the different use cases for P-Called-Party-ID > versus Target. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, April 03, 2008 13:48 > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; > Juha Heinanen > > Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS > > Subject: RE: [Sip] Comparison of retargeting proposals > > > > > > Hi, > > > > The P-Called-Party-ID is only inserted by the registrar of the UAS, > > while the Target can be inserted also by other entities. > _______________________________________________ > 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 sip-bounces@ietf.org Fri Apr 4 08:31:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A9D28C794; Fri, 4 Apr 2008 08:31:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676CF28C793 for ; Fri, 4 Apr 2008 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_38=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 ql6nh+paJXET for ; Fri, 4 Apr 2008 08:31: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 2D76128C540 for ; Fri, 4 Apr 2008 08:30:11 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYT00B4D49V83@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 16:27:33 +0100 (BST) Date: Fri, 04 Apr 2008 15:00:53 +0100 From: "Elwell, John" To: IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095BA9B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Review of sip-outbound-13 Thread-Index: AciWXEvN4G0kcc5IT3CC5/sITATquQ== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Sip] Review of sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think this is ready to go if the following minor comments are addressed: 1. "This specification also defines multiple keep alive schemes." Change "multiple" to "two". 2. "A Flow is a network protocol layer (layer 4) association" Change "network" to "transport". 3. "One case where a UA may not want to include the sip.instance media feature tag at all is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity." There is no statement about what should be done in this case. 4. "These registration requests include a distinct reg-id parameter in the Contact header field." I think some normative language is needed here. Perhaps change to: "For registration requests in accordance with outbound behaviour, the UA MUST include a distinct reg-id parameter in the Contact header field." 5. "the target first hop SIP note" Change "note" to "node". 6. "as this is already allowed by [RFC3261]. Section 7.5, however a UA that did not register using outbound registration" I think this should say "as this is already allowed by [RFC3261] section 7.5. However, a UA that did not register using outbound registration" 7. "Configuration indicating keepalive support for a specific target is considered an explicit indication. If these conditions are satisfied, the UA sends its keepalives according to the same guidelines described in the rest of this section as UAs which register." I don't understand the meaning of the first sentence. Is it trying to say that configuration is an alternative way of determining support for keepalive? 8. "For devices where power is not a significant concern, the UA SHOULD select a random number between 95 and 120 seconds between keepalives. When battery power is a concern, the UA SHOULD select a random number between 672 and 840 seconds (14 minutes). These times MAY be configurable." The last sentence seems to undermine the previous SHOULD strength statements. Also, what exactly can be configurable - just the upper and lower bounds? I don't think, for example, we are proposing to allow somebody to configure say 180 seconds as both upper and lower bounds (not a range, no randomisation). So I think it is the bounds that can be configurable, and even then the 20% difference must be maintained. Perhaps it should say something like: "The UA MUST select a random number between a fixed or configurable upper bound and a lower bound, where the lower bound is 20% less then the upper bound. The fixed upper bound or the default configurable upper bound SHOULD be 120 seconds (95 seconds lower bound) where battery power is not a concern and 840 seconds (672 seconds lower bound) where battery power is a concern." 9. "The delay time is computed by selecting a uniform random time between 50 and 100 percent of the wait time. The UA MUST wait for the value of the delay time before trying another registration to form a new flow for that URI." I find this a little confusing. The several paragraphs before that have all talked about wait time, or time to wait, which suggests that that is how long you wait before trying registration again. Then we suddenly have this "delay time" introduced, and it says that "UA MUST wait for the value of the delay time before trying another registration". It might be better to introduce the concept of delay time and wait time up front. Furthermore, it is not clear whether the delay time (between 50 and 100 percent of the wait time) starts when the wait time starts or when the wait time finishes. I think the examples given in the succeeding paragraph suggest it is the former interpretation. In any case, it needs to be clarified. 10. "The Edge Proxy can determine if it is the first hop by examining the Via header field." Does this still work in the case of topology hiding by an upstream entity? 11. "When a '+sip.instance' media feature parameter is present in a Contact header field of a REGISTER request (after the Contact header validation as described above), the corresponding binding is between an AOR and the combination of the instance-id (from the +sip.instance media feature parameter) and the value of reg-id parameter if it is present." I think the normative statements that follow are only concerned with the case where reg-id is present, so I think it should be changed to: "When a '+sip.instance' media feature parameter and a reg-id parameter are present in a Contact header field of a REGISTER request (after the Contact header validation as described above), the corresponding binding is between an AOR and the combination of the instance-id (from the +sip.instance media feature parameter) and the value of reg-id parameter." 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 sip-bounces@ietf.org Fri Apr 4 08:43:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5573A69F7; Fri, 4 Apr 2008 08:43:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9813A6D4B for ; Fri, 4 Apr 2008 08:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430, 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 Ppdb0ZQhU86R for ; Fri, 4 Apr 2008 08:43:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 51F073A6AB1 for ; Fri, 4 Apr 2008 08:41:22 -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.240.5; Fri, 4 Apr 2008 11:41:01 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 11:41:01 -0400 From: Hadriel Kaplan To: Dean Willis , "sip@ietf.org List" Date: Fri, 4 Apr 2008 11:40:58 -0400 Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting Thread-Index: AciWJcg/dfnHqtP2Qc2UFc9HmciZaQAQ42nQ Message-ID: References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> In-Reply-To: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Howdy, Can you describe more succinctly why this is a problem that needs fixing? (not that I don't think it would be - I'm just low on caffeine and can't grasp the issue being solved) I guess I don't get why Alice needs to know this before getting a 200? (or before a 180/183) Also, how would this "work" with forking? -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > I define "unanticipated respondent syndrome" as the sense of surprise > Alice gets when she calls Bob, only to have the call answered by > Charlie. This is especially problematic if the sorts of security > operations that depend on Alice having some sort of keying > relationship with Charlie become important. > > Alice is expecting: > > Alice--1-->Proxy--2-->Bob > > but instead she gets: > > Alice--1-->Proxy--2-->Charlie > > because Bob forwarded his phone to Charlie, or because Charlie, who is > authorized to do so, registered as a contact for Bob, and Bob didn't > answer (or has a lwoer qvalue, or whatever) > > RFC 4916 lets Alice find out who answered the phone in the most > difficult of cases, and other techniques like P-Asserted-Identity in a > response address simpler cases (or we can use endpoint- asserted RFC > 4474 Identity when the keys are known or discoverable). So that's not > a problem. Alice can figure out that she's talking to Charlie, once > they get connected. > > The only problem is cluing in Alice that she's about to be talking to > Charlie instead of Bob. > > In the cases I've identified above, the proxy knows that it is > retargeting the request to Charlie, not rerouting the request to Bob. > How does it know this? It either a) knows that the Call Forwarding > feature has been activated, and that's always a retarget, or b) knows > that the contact for Bob was registered by Charlie, who isn't Bob (but > that Charlie is authorized to register for Bob's AOR). In fact, if > this the case, it knows both Charlie's authentication identity and his > contact. > > Since the proxy knows, it should be able to inform Alice. > > I therefore propose a provisional response from Proxy to Alice, which > I'll provisionally call "121 (Retargeting)" > > A proxy executing a retargeting operation (by which we mean an > operation that replaces the request URI such that the authenticated > identity of the new request URI is different from the authenticated > identity of the old one) SHOULD return a 121 (Retargeting) provisional > response. The 121 response contains a Contact header field, the value > of which is the new identity being targeted. Optionally, we might > include some sort of "cause" parameter, explaining why the request is > being retargeted (like "Bob's dead, talk to Charlie"). > > If a proxy doesn't know whether it is rerouting or retargeting, it > SHOULD assume that it is retargeting, and send the appropriate 121 > response. > > In conclusion, this preserves the proxy-mediated functionality > required for draft-ietf-sip-outbound, while giving us the I-know-who-I- > expect-to-reach function of a 302 (Redirect). > > Yeah, this should be an I-D. I'm now accepting volunteer co-authors to > do the dirty work, assuming this idea gets any traction. > > -- > 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 _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 09:11:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BB03A6C65; Fri, 4 Apr 2008 09:11:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A9D3A6943 for ; Fri, 4 Apr 2008 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=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 0VByTiRHJaWB for ; Fri, 4 Apr 2008 09:11:44 -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 A6E203A6C65 for ; Fri, 4 Apr 2008 09:11:43 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 04 Apr 2008 09:11:50 -0700 Received: from mtcc13.mtcc.com ([10.21.149.86]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m34Fu28t012793; Fri, 4 Apr 2008 07:56:02 -0800 Message-ID: <47F65345.4030600@cisco.com> Date: Fri, 04 Apr 2008 09:11:49 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1185; t=1207324562; x=1208188562; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=1ZseCKoDp6fDg/IbhacHTb3HF2fUT62S17uFbGNe10U=; b=Q09W5NI6G8nNLhzkAx7btdyAxCKmmFyewFFFZL6XVewtwd+UTM142vosvz Y04BtNNro4sQsQgqGufacemysho1vMiugZGL49uf5JcVvntts1ZuIRDAqIQX bv+JosBkbC; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: > There seems to be some interest in adding some indicator to the URI or > to the header field to warn of the limited guarantee of authenticity or > the opposite (i.e.,lack of such an indicator would mean the guarantee is > low, i.e., the identity has not been verified). > Versus the limited guarantee of authenticity of rfc4474 generally? Let's be clear here: rfc4474 (like rfc4871) is a domain level "I take responsibility" kind of mechanism. It is not any strong proof that the local part is who it says it is. A receiver should always be at least somewhat skeptical. > I think on this issue it is just a matter of somebody putting things > together into a draft. I think Dean and/or Adam were the main initiators > of this proposal - something like a source=pstn parameter. Would > somebody care to author a draft? Or do we need further discussion? > This seems like a slippery slope here. There may plenty of other reasons that the local part might not be trusted besides being routed from the PSTN. So let me ask: what problem are we trying to solve and for whom? And lets keep in mind the skeptical receiver. Mike _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 09:57:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D315A3A6D4C; Fri, 4 Apr 2008 09:57:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A22F3A6B03 for ; Fri, 4 Apr 2008 09:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.624, 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 Dx7-tLY7paxO for ; Fri, 4 Apr 2008 09:56:57 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 9858F3A68A7 for ; Fri, 4 Apr 2008 09:56:06 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m34Gu6h20607; Fri, 4 Apr 2008 16:56:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 11:56:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15EB8BA6@zrc2hxm0.corp.nortel.com> In-Reply-To: <18422.7390.345441.907652@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciWTindEWgEc2tpRmG7legvXgjaCQAJoy3A References: <200803251629.m2PGTC0N025942@dragon.ariadne.com> <28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com> <18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8504436BB@eseal! mw109.eem ea.eri csson .se > <18422.6431.775786.710973@harjus.tutpro.com> <47B2061B1E5E494B96AA40008300D85044375A@esealmw109.eemea.ericsson.se> <18422.7390.345441.907652@harjus.tutpro.com> From: "Francois Audet" To: "Juha Heinanen" , "Hans Erik van Elburg" Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is so simple, that the people who say it's simple don't even agree on the meaning. > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, April 04, 2008 05:20 > To: Hans Erik van Elburg > Cc: Audet, Francois (SC100:3055); Christer Holmberg; > sip@ietf.org; DOLLY, MARTIN C, ATTLABS > Subject: RE: [Sip] Comparison of retargeting proposals > > Hans Erik van Elburg writes: > > > No, because I assumed that the freephone number is not a > registered AOR > of the user. > > ok, so in your example proxy was forwarding the call to the > freephone uri to the user, i.e., freephone number was not an > alias of the user's aor. > > -- juha > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 10:11:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DFF3A6B0F; Fri, 4 Apr 2008 10:11:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2C43A697F for ; Fri, 4 Apr 2008 10:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_64=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 YYQK4RpplFKX for ; Fri, 4 Apr 2008 10:11:19 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BFE6C3A6D4B for ; Fri, 4 Apr 2008 10:09:58 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYT00H2I90SJQ@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 18:10:04 +0100 (BST) Date: Fri, 04 Apr 2008 18:10:05 +0100 From: "Elwell, John" In-reply-to: <47F65345.4030600@cisco.com> To: Michael Thomas Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AciWcSnmNK/bTJUtRgCn4K2Zx1aNPgABUxhA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Michael, The proposed indicator is probably better described as "not verified" rather than "limited guarantee of authenticity". But maybe, as has also been suggested, we simply should not use RFC 4474 on requests from a PSTN gateway. John > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 04 April 2008 17:12 > To: Elwell, John > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4474 and PSTN > > Elwell, John wrote: > > There seems to be some interest in adding some indicator to > the URI or > > to the header field to warn of the limited guarantee of > authenticity or > > the opposite (i.e.,lack of such an indicator would mean the > guarantee is > > low, i.e., the identity has not been verified). > > > > Versus the limited guarantee of authenticity of rfc4474 generally? > Let's be clear here: rfc4474 (like rfc4871) is a domain level "I > take responsibility" kind of mechanism. It is not any strong proof > that the local part is who it says it is. A receiver should always be > at least somewhat skeptical. > > I think on this issue it is just a matter of somebody putting things > > together into a draft. I think Dean and/or Adam were the > main initiators > > of this proposal - something like a source=pstn parameter. Would > > somebody care to author a draft? Or do we need further discussion? > > > > This seems like a slippery slope here. There may plenty of > other reasons > that the local part might not be trusted besides being routed from the > PSTN. > > So let me ask: what problem are we trying to solve and for whom? > And lets keep in mind the skeptical receiver. > > Mike > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 10:36:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122943A6A1D; Fri, 4 Apr 2008 10:36:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6645A28C17E for ; Fri, 4 Apr 2008 10:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 5gYNt15VKxNt for ; Fri, 4 Apr 2008 10:35:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A538528C2E1 for ; Fri, 4 Apr 2008 10:35: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.240.5; Fri, 4 Apr 2008 13:34:45 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 13:34:46 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , Francois Audet , Christer Holmberg , Juha Heinanen Date: Fri, 4 Apr 2008 13:35:06 -0400 Thread-Topic: [Sip] Comparison of retargeting proposals Thread-Index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgACHxX6AAFMnqEAAeTUuwAAxmkzA= Message-ID: References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com> <1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.ericsson.se> In-Reply-To: <47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Hans > Erik van Elburg > > I think that in a closed environment like IMS where all proxies can be > guaranteed to support loose routing, there is effectively almost no > difference between P-Called-Party-ID and Target header. I beg to differ - even in IMS all "proxies" cannot be guaranteed to be doing loose-routing, if by that you mean not changing the req-uri as they forward. What's written in IMS specs and what's getting deployed/configured in the field are not identical all of the time, nor in all scenarios for the same IMS network... much like IETF SIP. (this is not to say that this has any impact on the gist of your comment or the proposals - just noting that "IMS specs" and IMS reality are not one and the same, as you're probably aware) -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 sip-bounces@ietf.org Fri Apr 4 11:09:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25643A6B62; Fri, 4 Apr 2008 11:09:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B491A3A6B31 for ; Fri, 4 Apr 2008 11:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.608, 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 86Ha9Dfz3j2u for ; Fri, 4 Apr 2008 11:09:28 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D41B33A69B5 for ; Fri, 4 Apr 2008 11:09:28 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m34I9Ug2013262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 13:09:32 -0500 Message-Id: From: Dean Willis To: "Hans Erik van Elburg" In-Reply-To: <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 13:09:25 -0500 References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! 2 CCF15EB7 F8A@zrc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 7:24 AM, Hans Erik van Elburg wrote: > There seems to be a misunderstanding here, there is no intention for > stacking Target headers at all. There will always have to be zero or > one > target header field with one clear meaning: "current target". > I believe you. But like others, I found the draft unclear, and it made more sense if I assumed a stack of Target headers. > As soon as a retarget (using the definition from UALR draft) occurs an > existing target header will have to be removed, as it no longer > represents the current target. Then it doesn't help Charlie knows that he's answering a call meant for Bob when Bob forwards his phone to Charlie and Alice calls Bob. > Params only seems to tackle the parameter loss issue, and it seems > further to solve a different problem alltogether i.e. how to get > parameters from the caller to the callee. Well, that WAS the original goal of US-Loose-Route, and is the thing we have a chartered milestone for: From our charter: Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) > There is a risk that > parameters that where only intended to be received by user B end up at > user C. Well, that can certainly happen with any header. The workaround if it worries you is to use a 302. -- 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 sip-bounces@ietf.org Fri Apr 4 11:13:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DDE83A6896; Fri, 4 Apr 2008 11:13:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9A23A6840 for ; Fri, 4 Apr 2008 11:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580, 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 WioK9228BsxW for ; Fri, 4 Apr 2008 11:13:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C20B43A67D7 for ; Fri, 4 Apr 2008 11:13:34 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m34IDInO013293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 13:13:19 -0500 Message-Id: <8796474E-14E2-4CA4-B3ED-84C5B1C005E3@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <47F6293D.80004@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 13:13:12 -0500 References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <47F6293D.80004@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 8:12 AM, Paul Kyzivat wrote: > Dean, > > Why response code 121 when we already have 181? Perhaps it needs > some added info but it seems like the right response. > 181 might well make sense. I used 121 so we could fish out any real differences with 181. > Second, in the case where Charlie registers with Bob's AOR, how does > identity work? Won't Charlie appear to *be* Bob? Presumably it > depends on what credentials Charlie uses. But I think in many cases > this will indeed look like Bob. > In the case I envision, Charlie registers like so: REGISTER example.com SIP/2.0 To: sip:bob@example.com From: sip:charlie@example.com .... The registrar authenticates the request as coming from Charlie, and checks its configuration to determine that Charlie is authorized to register to the Bob AOR. Hence, it knows that Charlie is not Bob, and that "contact routing" using the associated contact is retargeting, not rerouting. From an RFC 4474 perspective, the identity that Charlie's requests might carry would be "sip:charlie@example.com". -- 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 sip-bounces@ietf.org Fri Apr 4 11:21:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001BB28C27F; Fri, 4 Apr 2008 11:21:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E47D28C2C5 for ; Fri, 4 Apr 2008 11:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_64=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 qJzoTdkAPTuU for ; Fri, 4 Apr 2008 11:21:27 -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 9875128C476 for ; Fri, 4 Apr 2008 11:20:25 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 11:20:31 -0700 Received: from mtcc13.mtcc.com ([10.21.149.86]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m34I4gAv018125; Fri, 4 Apr 2008 10:04:42 -0800 Message-ID: <47F6716E.9080908@cisco.com> Date: Fri, 04 Apr 2008 11:20:30 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2939; t=1207332283; x=1208196283; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=H6OsAnqdcdGyUJ3GK3kMXFiFzg4fIJTfTcL6csLIesU=; b=bxcBsROn5wXS0FttCF5xIPNHMSJwxEHtljsozXVvajtB1YmMF6ehrB7kYB bF1zLjfyhIzYpoNECC/ct5AdoXeVTFEUWrt9l9IJLjaR0iLOkHr/iQIzT2+E XeFlTqfDU9; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Michael, > > The proposed indicator is probably better described as "not verified" > rather than "limited guarantee of authenticity". But maybe, as has also > been suggested, we simply should not use RFC 4474 on requests from a > PSTN gateway. > Rather than work on a solution, I'd rather hear why a receiver cares about any of this. Ie, what does the consumer of this information do differently? The experience from the email world thus far is "not much" which makes me suspicious this is too abstract a problem for the outside world to care about. A far more important question to be asking IMO is what will drive 4474 _deployment_, rather than adding bells and whistles to it. Until there's something of a critical mass then it's pretty much just speculation about the real life concerns. Mike, who's ecstatic that 7% of domains are dkim checking now but still doesn't think we know a lot about the evaluation of the localpart > John > > >> -----Original Message----- >> From: Michael Thomas [mailto:mat@cisco.com] >> Sent: 04 April 2008 17:12 >> To: Elwell, John >> Cc: sip@ietf.org >> Subject: Re: [Sip] RFC 4474 and PSTN >> >> Elwell, John wrote: >> >>> There seems to be some interest in adding some indicator to >>> >> the URI or >> >>> to the header field to warn of the limited guarantee of >>> >> authenticity or >> >>> the opposite (i.e.,lack of such an indicator would mean the >>> >> guarantee is >> >>> low, i.e., the identity has not been verified). >>> >>> >> Versus the limited guarantee of authenticity of rfc4474 generally? >> Let's be clear here: rfc4474 (like rfc4871) is a domain level "I >> take responsibility" kind of mechanism. It is not any strong proof >> that the local part is who it says it is. A receiver should always be >> at least somewhat skeptical. >> >>> I think on this issue it is just a matter of somebody putting things >>> together into a draft. I think Dean and/or Adam were the >>> >> main initiators >> >>> of this proposal - something like a source=pstn parameter. Would >>> somebody care to author a draft? Or do we need further discussion? >>> >>> >> This seems like a slippery slope here. There may plenty of >> other reasons >> that the local part might not be trusted besides being routed from the >> PSTN. >> >> So let me ask: what problem are we trying to solve and for whom? >> And lets keep in mind the skeptical receiver. >> >> Mike >> >> > _______________________________________________ > 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 sip-bounces@ietf.org Fri Apr 4 11:26:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E2328C26C; Fri, 4 Apr 2008 11:26:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E847428C43B for ; Fri, 4 Apr 2008 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 rUUdDshnC1e9 for ; Fri, 4 Apr 2008 11:26:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CFAA728C175 for ; Fri, 4 Apr 2008 11:25:02 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m34IP50M013353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 13:25:07 -0500 Message-Id: <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 13:25:00 -0500 References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 10:40 AM, Hadriel Kaplan wrote: > Howdy, > Can you describe more succinctly why this is a problem that needs > fixing? (not that I don't think it would be - I'm just low on > caffeine and can't grasp the issue being solved) I guess I don't > get why Alice needs to know this before getting a 200? (or before a > 180/183) There are several reasons why we need it before a 200. As to a a 180 or 183, I suppose it makes as much sense to convey the retargeting identity in a 100 as in a 121. As for as a 180: There's no assurance there will ever be one sent by the terminating UAS -- it may well answer immediately. First, it may be important for Alice to know that her call is going to not-Bob, lest in the earliest media phases she say something mean only for Bob's ears. If we're using sipping-certs and end-node asserted identity, Alice needs to get Charlie's cert before she can validate Charlie's identity assertion. This is not instantaneous, and the earlier the notice, the better. One can also postulate that Alice might be using other cryptotechniques (like IBE, instead of IBA) that require knowing the identity of the target and might require some setup time. You might want to go back to Jon Peterson's diatribe on how proxy retargeting breaks many things, suggesting that we should have just used 302 with end-to-end direct SIP all along. Of course, the 302 model doesn't work with the much-needed NAT traversal functions of sip- outbound, so the idea here is to offer a compromise that preserves both function sets. > Also, how would this "work" with forking? Either multiple responses (one per fork) or multiple Contacts (one per fork) in one response. Personally, I like multiple Contacts. Or we could just go ahead and deprecate forking ;-). -- 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 sip-bounces@ietf.org Fri Apr 4 11:35:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5935C3A6B85; Fri, 4 Apr 2008 11:35:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD92A3A6902 for ; Fri, 4 Apr 2008 11:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532, 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 vJXcNq84fV-m for ; Fri, 4 Apr 2008 11:35:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EE6DE3A6B4A for ; Fri, 4 Apr 2008 11:34:58 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m34IZ2K7013373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 13:35:03 -0500 Message-Id: From: Dean Willis To: Michael Thomas In-Reply-To: <47F6716E.9080908@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 13:34:56 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 1:20 PM, Michael Thomas wrote: > Elwell, John wrote: >> Michael, >> >> The proposed indicator is probably better described as "not verified" >> rather than "limited guarantee of authenticity". But maybe, as has >> also >> been suggested, we simply should not use RFC 4474 on requests from a >> PSTN gateway. >> > > Rather than work on a solution, I'd rather hear why a receiver cares > about any of this. Ie, what does the consumer of this information do > differently? The experience from the email world thus far is "not > much" > which makes me suspicious this is too abstract a problem for the > outside > world to care about. > That's a fair question. The worry is that an RFC 4474 identity assertion forms what is essentially a contract verification "I, identity service example.com, have verified according to best current practices that the party originating this message is authorized to use the identity sip:alice@example.com ". We generally assume the "best current practices" something on the order of "the party in question has presented credentials based on a secret known to sip:alice@example.com and presumably unknown to other parties, and this presentation is consistent with prior interactions had by this identity service and sip:alice@example.com". But when the identity assertion is coming from a PSTN caller ID, it's significantly less authoritative statement: "I, the identity service at example.com, think that this request came from +12142821376 because this is the calling party identifier presented to my telephony interface." There is a profound liability distinction between these two. Failure to resolve it means that RFC 4474 identity headers would never be more credible than PSTN caller-ID, and we seem to think they need to be more credible. > A far more important question to be asking IMO is what will drive > 4474 _deployment_, rather than adding bells and whistles to it. Until > there's something of a critical mass then it's pretty much just > speculation > about the real life concerns. Of course it will be driven be legal requirements around call- traceability, logging (especially in the financial services business) and intercept. Nobody cares about spam. -- 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 sip-bounces@ietf.org Fri Apr 4 12:33:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A736B3A6F82; Fri, 4 Apr 2008 12:33:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647073A6F82 for ; Fri, 4 Apr 2008 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416, 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 1OuWD9JDPAtl for ; Fri, 4 Apr 2008 12:33:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 740CC3A6AC7 for ; Fri, 4 Apr 2008 12:33:56 -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.240.5; Fri, 4 Apr 2008 15:33:36 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 15:33:36 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 4 Apr 2008 15:33:19 -0400 Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting Thread-Index: AciWgScwbhVxn+VET/S4t5sWNUhmWwABtN2w Message-ID: References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> In-Reply-To: <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > There are several reasons why we need it before a 200. As to a a 180 > or 183, I suppose it makes as much sense to convey the retargeting > identity in a 100 as in a 121. As for as a 180: There's no assurance > there will ever be one sent by the terminating UAS -- it may well > answer immediately. Yes, but my point was I think you only need/want this info at the same time a 180/183/200 comes back, so why not use them instead of creating more responses? In other words, if there is no 180 sent back but in fact Charlie answers immediately, and Alice finds out in the 200 then, isn't that ok? Less is more. :) > First, it may be important for Alice to know that her call is going to > not-Bob, lest in the earliest media phases she say something mean only > for Bob's ears. Alice can't say anything to Charlie until she gets SDP from Charlie, in a 18x or 2xx, which is why I keep wondering what's wrong with just using the already existent 18x/2xx. > If we're using sipping-certs and end-node asserted identity, Alice > needs to get Charlie's cert before she can validate Charlie's identity > assertion. This is not instantaneous, and the earlier the notice, the > better. Unfortunately 4474 won't allow that anyway in responses - you need 4916, as you well know. If you want to fix that I'm all for it, but it was shot down before. :( > You might want to go back to Jon Peterson's diatribe on how proxy > retargeting breaks many things, suggesting that we should have just > used 302 with end-to-end direct SIP all along. Of course, the 302 > model doesn't work with the much-needed NAT traversal functions of sip- > outbound, so the idea here is to offer a compromise that preserves > both function sets. I think "end-to-end" would have been broken no matter what 3261 said about 302's, for obvious reasons, but yes I don't disagree that proxy recursion for 3xx (and forking) may end up being a Faustian deal. -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 sip-bounces@ietf.org Fri Apr 4 12:37:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1645B3A6FCF; Fri, 4 Apr 2008 12:37:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A8B3A6C2D for ; Fri, 4 Apr 2008 12:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.061 X-Spam-Level: X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[AWL=1.938, BAYES_00=-2.599, J_CHICKENPOX_64=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 DH7h5GAlsp21 for ; Fri, 4 Apr 2008 12:37:08 -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 3DE4C28C731 for ; Fri, 4 Apr 2008 12:35:52 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 12:35:58 -0700 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 m34JZwUG000660; Fri, 4 Apr 2008 12:35:58 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m34JZwN8013224; Fri, 4 Apr 2008 19:35:58 GMT From: Cullen Jennings To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> Impp: xmpp:cullenfluffyjennings@jabber.org References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> Message-Id: <21B19414-1627-41B3-AC58-96729B87FEEA@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 12:35:46 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1198; t=1207337758; x=1208201758; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=GCpbgP10V5MBSQ+LghBixakuK2edly/TxwMrkQfxd78=; b=uPQpO6oa/2LAYhJ6hSsck7tkWkQLO6o+T7jwQnMH5fSL56Pu5ksqA3M0Ob 2Mcf76Gv2LknoCgyiOQUUQM1Ji23OlNM76cITX7DT9yJVpjrE+1XDqAohhTP OXnXVQny6a; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP List Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 1:19 AM, Elwell, John wrote: > There seems to be some interest in adding some indicator to the URI or > to the header field to warn of the limited guarantee of authenticity > or > the opposite (i.e.,lack of such an indicator would mean the > guarantee is > low, i.e., the identity has not been verified). > > I think on this issue it is just a matter of somebody putting things > together into a draft. I think Dean and/or Adam were the main > initiators > of this proposal - something like a source=pstn parameter. Would > somebody care to author a draft? Or do we need further discussion? > > John I think more discussion is needed of what we want to accomplish before we can sort out what mechanism are needed. There seems to be a wide range of assumptions about what we want. Culle > > _______________________________________________ > 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 sip-bounces@ietf.org Fri Apr 4 12:42:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05013A69A1; Fri, 4 Apr 2008 12:42:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21403A6DE3 for ; Fri, 4 Apr 2008 12:42:50 -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 sehv1FKWLQFC for ; Fri, 4 Apr 2008 12:42:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F0DA63A6884 for ; Fri, 4 Apr 2008 12:42: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.240.5; Fri, 4 Apr 2008 15:42:27 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 15:42:27 -0400 From: Bob Penfield To: Dean Willis , "sip@ietf.org List" Date: Fri, 4 Apr 2008 15:42:27 -0400 Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting Thread-Index: AciWJc3pvPk+G1KoS+GW6I7qWmWP7wAXIv+w Message-ID: References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> In-Reply-To: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think this could mess up User Agents that do not understand the new response code and treat it like any other 1xx. In this situation, the Proxy is acting as the UAS for the 121 response, and RFC 3261 requires that it have a to-tag. The UAC will create an dialog for the 121 response. The problem is that the Contact does not meet the criteria required for a provisional response in that it does not reach the UAS (the Proxy) that established the dialog. What will happen to any in-dialog requests sent by the UAC on the early dialog? cheers, (-:bob -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, April 04, 2008 3:30 AM To: sip@ietf.org List Subject: [Sip] Preventing unanticipated respondent syndrome when retargeting I define "unanticipated respondent syndrome" as the sense of surprise Alice gets when she calls Bob, only to have the call answered by Charlie. This is especially problematic if the sorts of security operations that depend on Alice having some sort of keying relationship with Charlie become important. Alice is expecting: Alice--1-->Proxy--2-->Bob but instead she gets: Alice--1-->Proxy--2-->Charlie because Bob forwarded his phone to Charlie, or because Charlie, who is authorized to do so, registered as a contact for Bob, and Bob didn't answer (or has a lwoer qvalue, or whatever) RFC 4916 lets Alice find out who answered the phone in the most difficult of cases, and other techniques like P-Asserted-Identity in a response address simpler cases (or we can use endpoint- asserted RFC 4474 Identity when the keys are known or discoverable). So that's not a problem. Alice can figure out that she's talking to Charlie, once they get connected. The only problem is cluing in Alice that she's about to be talking to Charlie instead of Bob. In the cases I've identified above, the proxy knows that it is retargeting the request to Charlie, not rerouting the request to Bob. How does it know this? It either a) knows that the Call Forwarding feature has been activated, and that's always a retarget, or b) knows that the contact for Bob was registered by Charlie, who isn't Bob (but that Charlie is authorized to register for Bob's AOR). In fact, if this the case, it knows both Charlie's authentication identity and his contact. Since the proxy knows, it should be able to inform Alice. I therefore propose a provisional response from Proxy to Alice, which I'll provisionally call "121 (Retargeting)" A proxy executing a retargeting operation (by which we mean an operation that replaces the request URI such that the authenticated identity of the new request URI is different from the authenticated identity of the old one) SHOULD return a 121 (Retargeting) provisional response. The 121 response contains a Contact header field, the value of which is the new identity being targeted. Optionally, we might include some sort of "cause" parameter, explaining why the request is being retargeted (like "Bob's dead, talk to Charlie"). If a proxy doesn't know whether it is rerouting or retargeting, it SHOULD assume that it is retargeting, and send the appropriate 121 response. In conclusion, this preserves the proxy-mediated functionality required for draft-ietf-sip-outbound, while giving us the I-know-who-I- expect-to-reach function of a 302 (Redirect). Yeah, this should be an I-D. I'm now accepting volunteer co-authors to do the dirty work, assuming this idea gets any traction. -- 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 _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 12:52:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278EF28C4E4; Fri, 4 Apr 2008 12:52:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42FE28C198 for ; Fri, 4 Apr 2008 12:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, J_CHICKENPOX_64=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 x3AShYJnFNi4 for ; Fri, 4 Apr 2008 12:52:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 027C028C751 for ; Fri, 4 Apr 2008 12:51: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.240.5; Fri, 4 Apr 2008 15:50:43 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 15:50:43 -0400 From: Hadriel Kaplan To: "Elwell, John" , "sip@ietf.org" Date: Fri, 4 Apr 2008 15:50:23 -0400 Thread-Topic: RFC 4474 and PSTN Thread-Index: AciWIirA52huOC6IQg+xc8TTpvnc9wAaiDCw Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Elwell, John > > There seems to be some interest in adding some indicator to the URI or > to the header field to warn of the limited guarantee of authenticity or > the opposite (i.e.,lack of such an indicator would mean the guarantee is > low, i.e., the identity has not been verified). I haven't thought about this since it was last on the list, and I think I was a proponent of it at that time, but why were we thinking this would ever be set? I mean if I'm a clid spoofer, why would I ever want to add such a param?? Isn't it like a "spam=yes" flag you're describing, and then expecting potential spammers to set it? I've forgotten the train of thought which lead to this param as a viable solution. > I think on this issue it is just a matter of somebody putting things > together into a draft. I think Dean and/or Adam were the main initiators > of this proposal - something like a source=pstn parameter. Or just source=evil. ;) -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 sip-bounces@ietf.org Fri Apr 4 12:52:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAEF3A6CA7; Fri, 4 Apr 2008 12:52:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20E428C446 for ; Fri, 4 Apr 2008 12:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.767, 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 1FCq9Ifk1mp8 for ; Fri, 4 Apr 2008 12:52:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3EF8A28C75D for ; Fri, 4 Apr 2008 12:51:15 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2008 19:51:20 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp056) with SMTP; 04 Apr 2008 21:51:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Y0zU194cYWwomIkGM+SmZL6seVkuMP/1bvsn0R5 pUPjyaK+otW4cA Message-ID: <47F686B8.6070602@gmx.net> Date: Fri, 04 Apr 2008 22:51:20 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Fischer, Kai" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> <47F5EBED.60104@gmx.net> <198A10EC585EC74687BCA414E2A597180211AC91@MCHP7RDA.ww002.siemens.net> <47F5F3BF.8070508@gmx.net> <198A10EC585EC74687BCA414E2A597180211ACA5@MCHP7RDA.ww002.siemens.net> In-Reply-To: <198A10EC585EC74687BCA414E2A597180211ACA5@MCHP7RDA.ww002.siemens.net> X-Y-GMX-Trusted: 0 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Kai, Fischer, Kai wrote: >>>> This issue is totally independent from E.164 >>>> >>>> >>> Not fully. SBCs may exchange the domain part of the E.164 >>> >> SIP URI, which >> >>> causes a break of the RFC 4474 signature. With email-style >>> >> URIs a simple >> >>> exchange is not possible. >>> >>> >> This is true but this applies to SIP Identity in general and not to >> E.164 number usage with SIP Identity only. >> Hence, I would not tie it to this discussion. >> > > My point was, that with E.164 an intermediary SBC is able to exchange > the domain part without a possibility on the terminating side to > recognize the change. > With email-like SIP URIs the domain change is not > possible or only with a hack. I see what you mean. The issue is that John, in one of his other mails, wants to add this relationship between the E.164 number and the corresponding domain. If you do not create this relationship then there are attacks possible and SIP Identity is just not the right mechanism since there is a domain that asserts certain properties and they just don't exist in this specific case. Bad luck. > Two cases need to be differentiated: > -SBC modifies SDP: This results in a necessity to create a new SIP > Identity signature and a change of the domain part in the From header > (valid for both types of SIP URIs email and E.164) > -SBC modifies From header field only: This is applicable to E.164 only > and as far as I have recognized from the past discussions a real world > behavior > > But in general there was the claim that SIP Identity does not work to well with SBCs. Dan wrote a draft about it. >>> >>> >>>> I don't like the idea of requiring DTLS-SRTP to provide proof of >>>> possession of the keying material. >>>> >>>> >>> It is also the other way round. If you use DTLS-SRTP to >>> >> encrypt RTP, the >> >>> terminating domain is interested where the call originates >>> >> from and in >> >>> which domain the SRTP connection is terminated. DTLS-SRTP is not >>> initially used as mean to establish an identity rather than as the >>> initial aim to encrypt RTP. >>> >>> >> I understand the need to know who the end points are. However, tying >> DTLS-SRTP is not a good idea since it >> a) increases the liklihood that SIP identity never get's >> deployed (since >> it is suddently far more complex than before) >> b) SIP identity is used also as a identity mechanism in areas >> where no >> media is exchanged. >> > > Do you propose to not apply RFC 4474 for DTLS-SRTP fingerprint > protection and to rely on something different? > SIP Identity works nice in certain environments. The fields that are covered by the digital signature calculation in SIP Identity have not been chosen arbitrarily. When an SBC changes some of the protected fields then there are obviously problems. Imagine a mechanism that wouldn't compute a signature at all then SBCs could do whatever they want. Good for SBCs; not so good for security. Ciao Hannes > Kai > > >> Ciao >> Hannes >> >> >>> Kai >>> >>> >>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> Elwell, John wrote: >>>> >>>> >>>>> SBCs do exist, often for good reasons that Hadriel has expanded on >>>>> already. I firmly believe that DTLS-SRTP will not be >>>>> >> deployable in a >> >>>>> meaningful way without addressing this problem. Concerning >>>>> >>>>> >>>> solutions, we >>>> >>>> >>>>> have drafts from Kai and Dan, or perhaps a merger of the >>>>> >> two somehow >> >>>>> would work. It also depends to some extent whether we are >>>>> >>>>> >>>> talking only >>>> >>>> >>>>> about email-style URIs or about E.164-based URIs too. >>>>> >>>>> 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 >> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 sip-bounces@ietf.org Fri Apr 4 13:11:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1203A6FB1; Fri, 4 Apr 2008 13:11:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A813A6F2C for ; Fri, 4 Apr 2008 13:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, 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 DhYxtiY4xqr8 for ; Fri, 4 Apr 2008 13:11:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 665E93A6C65 for ; Fri, 4 Apr 2008 13:11:45 -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.240.5; Fri, 4 Apr 2008 16:11:24 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 16:11:24 -0400 From: Hadriel Kaplan To: Hannes Tschofenig , "Fischer, Kai" Date: Fri, 4 Apr 2008 16:11:01 -0400 Thread-Topic: [Sip] RFC 4474 and SBC traversal Thread-Index: AciWjY5RkWIac0OtQmG1wN2+kKQu5wAAPL9w Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> <47F5EBED.60104@gmx.net> <198A10EC585EC74687BCA414E2A597180211AC91@MCHP7RDA.ww002.siemens.net> <47F5F3BF.8070508@gmx.net> <198A10EC585EC74687BCA414E2A597180211ACA5@MCHP7RDA.ww002.siemens.net> <47F686B8.6070602@gmx.net> In-Reply-To: <47F686B8.6070602@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > > SIP Identity works nice in certain environments. The fields that are > covered by the digital signature calculation in SIP Identity have not > been chosen arbitrarily. When an SBC changes some of the protected > fields then there are obviously problems. Actually, I think some of the fields chosen for signing did NOT need to be signed, and added nothing tangible; or if they did, the result of it making it unusable in many environments was not worth the specific security issue(s) they prevented. (specifically I am talking about the Contact, CSeq, and Call-Id) There are plenty of valuable SIP Requests which SBCs don't change bodies/From/To of that could use 4474 as is today, if it did not sign those 3 fields. For example a MESSAGE request (which does not even have a Contact, but would fail the Call-Id changing). Or a SUBSCRIBE. Or an INFO. :) > Imagine a mechanism that wouldn't compute a signature at all then SBCs > could do whatever they want. > Good for SBCs; not so good for security. Depends on how you define secure, at what layer, and most importantly for whom, but we don't need to get into that on this list. :) -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 sip-bounces@ietf.org Fri Apr 4 13:24:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4813A6A1D; Fri, 4 Apr 2008 13:24:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF893A6840 for ; Fri, 4 Apr 2008 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, 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 UwbNSD4EeB6e for ; Fri, 4 Apr 2008 13:24:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 66B8E3A6969 for ; Fri, 4 Apr 2008 13:24:51 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m34KOstQ014062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 15:24:56 -0500 Message-Id: <1EB19C3C-78BD-404F-8918-0AA08F348CBC@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 15:24:49 -0500 References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 2:33 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> >> There are several reasons why we need it before a 200. As to a a 180 >> or 183, I suppose it makes as much sense to convey the retargeting >> identity in a 100 as in a 121. As for as a 180: There's no assurance >> there will ever be one sent by the terminating UAS -- it may well >> answer immediately. > > Yes, but my point was I think you only need/want this info at the > same time a 180/183/200 comes back, so why not use them instead of > creating more responses? In other words, if there is no 180 sent > back but in fact Charlie answers immediately, and Alice finds out in > the 200 then, isn't that ok? no, because it's too late. I now have this response from somebody that I'm not expecting a response from. If Bob's proxy tells me to expect a response from Charlie, and I get a response from Charlie, that's ok. But if I just get this response from Charlie, I don't know if somebody has hacked me or what. Further, there's a timing thing -- I'm likely to get the 1x1 from Bob's proxy long (hundreds of ms) before I get the 180/200 from Charlie. So I can use that time window to prep up any keywork needed to talk to Charlie. If I wait until after Charlie sends a 200 OK and starts streaming media, it'll be harder to get it done in time. Ideally, I'd like to see Charlie's media key fingerprint in that 1x1 response. I think. > > Less is more. :) > > >> First, it may be important for Alice to know that her call is going >> to >> not-Bob, lest in the earliest media phases she say something mean >> only >> for Bob's ears. > > Alice can't say anything to Charlie until she gets SDP from Charlie, > in a 18x or 2xx, which is why I keep wondering what's wrong with > just using the already existent 18x/2xx. But how long after that SDP arrives is it before Alice can cognitively digest that she's talking to Charlie? How long until she can get Charlie's key and verify his authenticity? > > > >> If we're using sipping-certs and end-node asserted identity, Alice >> needs to get Charlie's cert before she can validate Charlie's >> identity >> assertion. This is not instantaneous, and the earlier the notice, the >> better. > > Unfortunately 4474 won't allow that anyway in responses - you need > 4916, as you well know. If you want to fix that I'm all for it, but > it was shot down before. :( I'm working on it one roadblock at a time. The Identity header mechanism of RFC 4474 works just fine in responses IFF the node inserting the response has the means to authenticate the responder's identity. While "traditional" SIP Systems using digest auth don't have this (necessitating RFC 4916), "outbound" proxies with persistent TLS connections probably can make an identity assertion. And if we're using endpoint keys for the assertion rather than keys held by proxies, the UAS can clearly make an identity assertion in a response. If we have a real PKIX, or if we have IBE/IBA, or if we have secrets shared between users, then we can use RFC 4474 Identity headers end-to- end, in both request and responses. Yes, this is a slight extension of the RFC 4474 text, but it seems to get the job done. And it's central to my current thinking on P2SIP. -- 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 sip-bounces@ietf.org Fri Apr 4 13:27:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1763A6C72; Fri, 4 Apr 2008 13:27:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920143A6CA7 for ; Fri, 4 Apr 2008 13:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 H3xnlztHXmqm for ; Fri, 4 Apr 2008 13:27:37 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B51F13A6839 for ; Fri, 4 Apr 2008 13:27:37 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m34KRfBi014079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 15:27:42 -0500 Message-Id: <510E8AE0-861A-4E91-96C8-AD0FB86A4662@softarmor.com> From: Dean Willis To: Bob Penfield In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 15:27:36 -0500 References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 2:42 PM, Bob Penfield wrote: > > I think this could mess up User Agents that do not understand the > new response code and treat it like any other 1xx. In this > situation, the Proxy is acting as the UAS for the 121 response, and > RFC 3261 requires that it have a to-tag. The UAC will create an > dialog for the 121 response. > > The problem is that the Contact does not meet the criteria required > for a provisional response in that it does not reach the UAS (the > Proxy) that established the dialog. > > What will happen to any in-dialog requests sent by the UAC on the > early dialog? This may be true. If so, it means yet more parts of the original SIP design are broken by all this early-dialog cruft that we should have just said "No, hell no, and what part of no did you not understand?" to. If so, put the new targets in Yet Another Header field. -- 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 sip-bounces@ietf.org Fri Apr 4 13:39:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E50D3A6B41; Fri, 4 Apr 2008 13:39:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B123A6F9B for ; Fri, 4 Apr 2008 13:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.473, 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 9wduXFfdChIY for ; Fri, 4 Apr 2008 13:39:32 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0DE4C3A6884 for ; Fri, 4 Apr 2008 13:39:31 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m34KdYNL014168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 15:39:36 -0500 Message-Id: <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 15:39:28 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 2:50 PM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Elwell, John >> >> There seems to be some interest in adding some indicator to the URI >> or >> to the header field to warn of the limited guarantee of >> authenticity or >> the opposite (i.e.,lack of such an indicator would mean the >> guarantee is >> low, i.e., the identity has not been verified). > > I haven't thought about this since it was last on the list, and I > think I was a proponent of it at that time, but why were we thinking > this would ever be set? I mean if I'm a clid spoofer, why would I > ever want to add such a param?? Isn't it like a "spam=yes" flag > you're describing, and then expecting potential spammers to set it? > I've forgotten the train of thought which lead to this param as a > viable solution. The Identity header essentially signs the From. It's traceable back to whoever made the signature. So, if you were an identity server, you could spoof any kind of caller ID you might want. But we'd know it was you doing it . . . What we're looking for is a way for an RFC 4474 identity server to say something about how strong it believes its assertion to be. Sure, it could lie, but then we wouldn't trust it in the future. It's much better if it volunteers the information to us that it doesn't REALLY know who the caller is, since it has only the caller-ID information to go from. If an identity server were to fully RFC 4474 "sign" a message rom a PSTN, it's even possible that the identity server operator could be held legally liable for inaccuracy in the asserted identity. In other words, if a caller-ID spoofer made a call through the example.com gateway, and the example.com identity server attaches an Identity header on to the resulting INVITE that asserts the spoofed telephone number identity, then someone injured (defrauded) by the caller could claim negligence on the part of the example.com identity server and sue for damages. This is why things like identity servers (and CAs) have statements of policy that describe their procedures and the strength of claim being made. Those published policies are legal contracts with the users of the certificates. It's part of why x.509 certs are so big and have so many things like subject-alt-names and extended key usage. SIP identity services need the same sorts of legal flexibility. Being able to sign a request on the basis of "I swear to you that it came through my gateway, but I don't know who it really came from, so I make no assertions about this identity other than that the request came through my gateway with the calling-party-ID information described herein" is really, really important. -- 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 sip-bounces@ietf.org Fri Apr 4 14:01:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBC33A6D4E; Fri, 4 Apr 2008 14:01:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171E83A6B05 for ; Fri, 4 Apr 2008 14:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 I9BsUJ22xX-p for ; Fri, 4 Apr 2008 14:01:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 53A133A6948 for ; Fri, 4 Apr 2008 14:00:17 -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.240.5; Fri, 4 Apr 2008 16:59:56 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 16:59:56 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 4 Apr 2008 16:59:26 -0400 Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting Thread-Index: AciWkeQCcxI7cK1SQx2VcRE/snXimgAARP9g Message-ID: References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> <1EB19C3C-78BD-404F-8918-0AA08F348CBC@softarmor.com> In-Reply-To: <1EB19C3C-78BD-404F-8918-0AA08F348CBC@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, April 04, 2008 4:25 PM > > On Apr 4, 2008, at 2:33 PM, Hadriel Kaplan wrote: > > Yes, but my point was I think you only need/want this info at the > > same time a 180/183/200 comes back, so why not use them instead of > > creating more responses? In other words, if there is no 180 sent > > back but in fact Charlie answers immediately, and Alice finds out in > > the 200 then, isn't that ok? > > no, because it's too late. I now have this response from somebody that > I'm not expecting a response from. So then we'll need a 121 for the 121 then too? ;) > If Bob's proxy tells me to expect a response from Charlie, and I get a > response from Charlie, that's ok. But if I just get this response from > Charlie, I don't know if somebody has hacked me or what. You won't know that for the 121 either - if someone has the callid/via/from-tag/etc. necessary to send you a fake matching response, a 121 will not be hard for them to send. Obviously if a 121 could be signed by Bob's proxy, saying "I'm sending this to Charlie", that would be interesting maybe. But you could instead just have Bob's proxy put something in the Invite it forwards to Charlie which Charlie copies in his response, to tell you he's legit to have gotten it. (and that mechanism at the same time could help avoid the rfc4474 baiting attack problem) > Further, there's a timing thing -- I'm likely to get the 1x1 from > Bob's proxy long (hundreds of ms) before I get the 180/200 from > Charlie. So I can use that time window to prep up any keywork needed > to talk to Charlie. If I wait until after Charlie sends a 200 OK and > starts streaming media, it'll be harder to get it done in time. > Ideally, I'd like to see Charlie's media key fingerprint in that 1x1 > response. I think. Currently that fingerprint is in SDP anyway, and furthermore unique to Charlie (not available to Bob's proxy or even Charlie's proxy). Isn't what you want then just rfc5027 (sec-preconditions)? > The Identity header mechanism of RFC 4474 works just fine in > responses IFF the node inserting the response has the means to > authenticate the responder's identity. While "traditional" SIP Systems > using digest auth don't have this (necessitating RFC 4916), "outbound" > proxies with persistent TLS connections probably can make an identity > assertion. And if we're using endpoint keys for the assertion rather > than keys held by proxies, the UAS can clearly make an identity > assertion in a response. I believe, from my google searching of the mail archives a while ago, that the main argument for not signing the responses was not to do with digest auth of the responder - it was because of the retarget scenario, where a retargeted-to domain could not possibly sign the response unless we allowed the To-URI to be changed in responses, which people were not wont to do due to 2543 dialog matching rules. At least that was my google impression. :) -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 sip-bounces@ietf.org Fri Apr 4 15:06:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE7C3A6996; Fri, 4 Apr 2008 15:06:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9391C3A6854 for ; Fri, 4 Apr 2008 15:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.005 X-Spam-Level: X-Spam-Status: No, score=-5.005 tagged_above=-999 required=5 tests=[AWL=1.594, 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 rANzkFpknPhY for ; Fri, 4 Apr 2008 15:06:41 -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 0AAF03A69CB for ; Fri, 4 Apr 2008 15:06:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,606,1199692800"; d="scan'208";a="20006816" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2008 15:06:39 -0700 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 m34M6dkg006141; Fri, 4 Apr 2008 15:06:39 -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 m34M6cs8005039; Fri, 4 Apr 2008 22:06:39 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); Fri, 4 Apr 2008 18:06:38 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 18:06:38 -0400 Message-ID: <47F6A68A.90206@cisco.com> Date: Fri, 04 Apr 2008 18:07:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> In-Reply-To: <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> X-OriginalArrivalTime: 04 Apr 2008 22:06:38.0515 (UTC) FILETIME=[27B4C030:01C896A0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4095; t=1207346799; x=1208210799; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=VkX8NaKApPvWhp1WhBxop6QNQDyMbWqKFRK0VkfVieI=; b=gCssfyT5Piul3dFnJoqqhzz2MH4iYKX9xwT6VO2pHta6W8D3+ozuMpXcAk /YVZftfOIiiqFnIrxWPdF8naUM7dSblXljLUF8xW7yEDzndTTC1k4TCkiJMA t1Z6DxtlA+; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There is a difficult line to walk here: On one hand the GW operator doesn't want to be held liable for asserting an address it can't verify. OTOH the UAS (should) want *some* assurance of the identity of the caller before displaying it as caller id. If the UAS won't display without a trusted signature, and the GWs won't provide a signature for anything from the PSTN, then sip phones won't ever get callerid for calls from the PSTN. If the UAS on the open internet will display anything (e.g. From) without any verification information, then I think we will, in a practical sense, have something that is far worse than the PSTN is today. (Maybe not worse than the PSTN will be when we have more IP interconnects with it.) Paul Dean Willis wrote: > On Apr 4, 2008, at 2:50 PM, Hadriel Kaplan wrote: >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >>> Elwell, John >>> >>> There seems to be some interest in adding some indicator to the URI >>> or >>> to the header field to warn of the limited guarantee of >>> authenticity or >>> the opposite (i.e.,lack of such an indicator would mean the >>> guarantee is >>> low, i.e., the identity has not been verified). >> I haven't thought about this since it was last on the list, and I >> think I was a proponent of it at that time, but why were we thinking >> this would ever be set? I mean if I'm a clid spoofer, why would I >> ever want to add such a param?? Isn't it like a "spam=yes" flag >> you're describing, and then expecting potential spammers to set it? >> I've forgotten the train of thought which lead to this param as a >> viable solution. > > The Identity header essentially signs the From. It's traceable back to > whoever made the signature. So, if you were an identity server, you > could spoof any kind of caller ID you might want. But we'd know it was > you doing it . . . > > What we're looking for is a way for an RFC 4474 identity server to say > something about how strong it believes its assertion to be. Sure, it > could lie, but then we wouldn't trust it in the future. It's much > better if it volunteers the information to us that it doesn't REALLY > know who the caller is, since it has only the caller-ID information to > go from. > > If an identity server were to fully RFC 4474 "sign" a message rom a > PSTN, it's even possible that the identity server operator could be > held legally liable for inaccuracy in the asserted identity. In other > words, if a caller-ID spoofer made a call through the example.com > gateway, and the example.com identity server attaches an Identity > header on to the resulting INVITE that asserts the spoofed telephone > number identity, then someone injured (defrauded) by the caller could > claim negligence on the part of the example.com identity server and > sue for damages. > > This is why things like identity servers (and CAs) have statements of > policy that describe their procedures and the strength of claim being > made. Those published policies are legal contracts with the users of > the certificates. It's part of why x.509 certs are so big and have so > many things like subject-alt-names and extended key usage. SIP > identity services need the same sorts of legal flexibility. Being able > to sign a request on the basis of "I swear to you that it came through > my gateway, but I don't know who it really came from, so I make no > assertions about this identity other than that the request came > through my gateway with the calling-party-ID information described > herein" is really, really important. > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 15:36:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6427728C3B8; Fri, 4 Apr 2008 15:36:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC3F3A69CB for ; Fri, 4 Apr 2008 15:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 0piYAsCgcpWx for ; Fri, 4 Apr 2008 15:36:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1591828C3E0 for ; Fri, 4 Apr 2008 15:35:08 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m34MZBCs014840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 17:35:12 -0500 Message-Id: <5C83AF52-003A-466F-8001-DCD4B8BF87A8@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 17:35:05 -0500 References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> <1EB19C3C-78BD-404F-8918-0AA08F348CBC@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 3:59 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Friday, April 04, 2008 4:25 PM >> >> On Apr 4, 2008, at 2:33 PM, Hadriel Kaplan wrote: >>> Yes, but my point was I think you only need/want this info at the >>> same time a 180/183/200 comes back, so why not use them instead of >>> creating more responses? In other words, if there is no 180 sent >>> back but in fact Charlie answers immediately, and Alice finds out in >>> the 200 then, isn't that ok? >> >> no, because it's too late. I now have this response from somebody >> that >> I'm not expecting a response from. > > So then we'll need a 121 for the 121 then too? ;) No, because teh 121 comes from an attributable source in the expected domain. > > >> If Bob's proxy tells me to expect a response from Charlie, and I >> get a >> response from Charlie, that's ok. But if I just get this response >> from >> Charlie, I don't know if somebody has hacked me or what. > > You won't know that for the 121 either - if someone has the callid/ > via/from-tag/etc. necessary to send you a fake matching response, a > 121 will not be hard for them to send. Obviously if a 121 could be > signed by Bob's proxy, saying "I'm sending this to Charlie", that > would be interesting maybe. But you could instead just have Bob's > proxy put something in the Invite it forwards to Charlie which > Charlie copies in his response, to tell you he's legit to have > gotten it. (and that mechanism at the same time could help avoid the > rfc4474 baiting attack problem) > Well, that's why I want identity-signed responses. -- dean > >> Further, there's a timing thing -- I'm likely to get the 1x1 from >> Bob's proxy long (hundreds of ms) before I get the 180/200 from >> Charlie. So I can use that time window to prep up any keywork needed >> to talk to Charlie. If I wait until after Charlie sends a 200 OK and >> starts streaming media, it'll be harder to get it done in time. >> Ideally, I'd like to see Charlie's media key fingerprint in that 1x1 >> response. I think. > > Currently that fingerprint is in SDP anyway, and furthermore unique > to Charlie (not available to Bob's proxy or even Charlie's proxy). > Isn't what you want then just rfc5027 (sec-preconditions)? Not really. There are scenarios where getting Charlie's cert fingerprint in advance of the 200 OK is useful. > > > >> The Identity header mechanism of RFC 4474 works just fine in >> responses IFF the node inserting the response has the means to >> authenticate the responder's identity. While "traditional" SIP >> Systems >> using digest auth don't have this (necessitating RFC 4916), >> "outbound" >> proxies with persistent TLS connections probably can make an identity >> assertion. And if we're using endpoint keys for the assertion rather >> than keys held by proxies, the UAS can clearly make an identity >> assertion in a response. > > I believe, from my google searching of the mail archives a while > ago, that the main argument for not signing the responses was not to > do with digest auth of the responder - it was because of the > retarget scenario, where a retargeted-to domain could not possibly > sign the response unless we allowed the To-URI to be changed in > responses, which people were not wont to do due to 2543 dialog > matching rules. At least that was my google impression. :) right -- so we use a previous provisional response from a node on the "expected path" to solve the unanticipated response problem resulting from the retarget! -- 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 sip-bounces@ietf.org Fri Apr 4 16:04:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8A53A6A0F; Fri, 4 Apr 2008 16:04:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3178F3A6A0F for ; Fri, 4 Apr 2008 16:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.622 X-Spam-Level: X-Spam-Status: No, score=-4.622 tagged_above=-999 required=5 tests=[AWL=1.977, 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 vZF1ydhfLSNI for ; Fri, 4 Apr 2008 16:04:15 -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 0FD063A689F for ; Fri, 4 Apr 2008 16:04:15 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 16:04:22 -0700 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 m34N4K2A015044; Fri, 4 Apr 2008 16:04:20 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m34N4J3N016385; Fri, 4 Apr 2008 23:04:19 GMT From: "Dan Wing" To: "'rossi kamal'" , References: <87277b870804030751y71378294u847db133d79b0bcc@mail.gmail.com> Date: Fri, 4 Apr 2008 16:04:19 -0700 Message-ID: <13eb01c896a8$36aeb2f0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87277b870804030751y71378294u847db133d79b0bcc@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWJiX4Z1lkYeXRQ8SqSfyTpmmyYAAggvdg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=724; t=1207350260; x=1208214260; 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]=20sip@ietf.org |Sender:=20; bh=mKO2hHEf5bgSrjOFbrWrPxU1lWh2U8YCSvQqUYXT2rs=; b=anMrE+8z6pfG9vsXmG9APfPVHcB7W5dMit9TocmuPYyeDPWOb3k8zKIfd8 HGmD1s4UnEk7CDVvowpWtxqC4t3hBJuyDVMz9u99VWWKQVnZIh64ExAW0ro1 +zxYbDO9bn; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Sip] sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org For SIP itself (?), or for SRTP? -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of rossi kamal > Sent: Thursday, April 03, 2008 7:52 AM > To: sip@ietf.org > Subject: [Sip] sip@ietf.org > > Would anyone suggest me on the key management protocols in > existent SIP clients > > if there is article or journal it would be preferable > _______________________________________________ > 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 sip-bounces@ietf.org Fri Apr 4 16:16:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3D93A6D94; Fri, 4 Apr 2008 16:16:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BE03A6FC5 for ; Fri, 4 Apr 2008 16:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 7trbETnRNWBf for ; Fri, 4 Apr 2008 16:16:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DE82F3A6D82 for ; Fri, 4 Apr 2008 16:15:21 -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.240.5; Fri, 4 Apr 2008 19:15:01 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 19:15:01 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 4 Apr 2008 19:15:02 -0400 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AciWk/C2jwXH0WwXROmkLKQyFAYkUwAEgM5A Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> In-Reply-To: <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > If an identity server were to fully RFC 4474 "sign" a message rom a > PSTN, it's even possible that the identity server operator could be > held legally liable for inaccuracy in the asserted identity. In other > words, if a caller-ID spoofer made a call through the example.com > gateway, and the example.com identity server attaches an Identity > header on to the resulting INVITE that asserts the spoofed telephone > number identity, then someone injured (defrauded) by the caller could > claim negligence on the part of the example.com identity server and > sue for damages. I'm pretty sure that's not possible. It's possible to sue the good guys, in the local country - but it's quite hard if not impossible for me to sue some enterprise in Thailand, for example. I don't know if verisign/thawte/etc. would give them a cert, but since we're not mandating specific "SIP 4474" certs and they can use the domain cert they legitimately got for web, I don't see how my UA is to know any better about their's than softarmor.com's cert. (without whitelists) But more importantly, if you're thinking these things would truly have *legal* ramification, then my guess is no "good-guys" would touch signing with 4474 with a ten foot pole, ever. Do DKIM email signatures have such legal implications? -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 sip-bounces@ietf.org Fri Apr 4 16:31:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43543A6CBA; Fri, 4 Apr 2008 16:31:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C683A6CA7 for ; Fri, 4 Apr 2008 16:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 RS-1tIOYZMG3 for ; Fri, 4 Apr 2008 16:31:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CCD3E3A67D5 for ; Fri, 4 Apr 2008 16:31: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.240.5; Fri, 4 Apr 2008 19:30:58 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 4 Apr 2008 19:30:58 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Dean Willis Date: Fri, 4 Apr 2008 19:30:55 -0400 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AciWoBoPwZBbMZYnSB2C6jZ5oq3hMgACchmw Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <47F6A68A.90206@cisco.com> In-Reply-To: <47F6A68A.90206@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > There is a difficult line to walk here: Yes, very. > On one hand the GW operator doesn't want to be held liable for asserting > an address it can't verify. > OTOH the UAS (should) want *some* assurance of the identity of the > caller before displaying it as caller id. But I think that's the rub - people are pointing out that a PSTN Gateway doesn't have that assurance of the CLID it got to begin with. Garbage in = garbage out. I don't disagree there is a pragmatic middle-ground though. (the reality is the CLID's correct 99%+ of the time) I'm just trying to figure out how in SIP it wouldn't quickly be worthless. > If the UAS won't display without a trusted signature, and the GWs won't > provide a signature for anything from the PSTN, then sip phones won't > ever get callerid for calls from the PSTN. Sure, but it's the first antecedent I don't think holds: it just needs to display it differently, like with a "?" at the end or some such. I know, I'm dreaming. :) This problem sucketh. -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 sip-bounces@ietf.org Fri Apr 4 16:38:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E893A68C5; Fri, 4 Apr 2008 16:38:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4273A68C0 for ; Fri, 4 Apr 2008 16:38:23 -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.289, BAYES_00=-2.599, J_CHICKENPOX_38=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 oZXxmzoNL6EL for ; Fri, 4 Apr 2008 16:38:22 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 6966E3A6996 for ; Fri, 4 Apr 2008 16:38:22 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m34NcPh11062; Fri, 4 Apr 2008 23:38:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 18:37:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15F0BBB3@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D095BA9B@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of sip-outbound-13 Thread-Index: AciWXEvN4G0kcc5IT3CC5/sITATquQAUAFLg References: <0D5F89FAC29E2C41B98A6A762007F5D095BA9B@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "IETF SIP List" , "Cullen Jennings" , "Rohan Mahy" Subject: Re: [Sip] Review of sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thank you John. I am OK with your edits 1, 2, 4, 5, 6, 8 and 11. I don't understand your point about 3. For 7, it should say "A configuration option indicating...". For 9, I'll have to defer to Rohan and Cullen because I find it confusing too. For 10, I believe that it would work if an upstream evil B2BUA does topology hiding since the proxy uses the Via in the Request and not the Path in the response. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Friday, April 04, 2008 07:01 > To: IETF SIP List > Subject: [Sip] Review of sip-outbound-13 > > I think this is ready to go if the following minor comments are > addressed: > > 1. "This > specification also defines multiple keep alive schemes." > Change "multiple" to "two". > > 2. "A Flow is a network protocol layer (layer 4) association" > Change "network" to "transport". > > 3. "One case where a UA may not want to include > the sip.instance media feature tag at all is when it is making an > anonymous request or some other privacy concern requires > that the UA > not reveal its identity." > There is no statement about what should be done in this case. > > 4. "These registration requests include a distinct reg-id parameter in > the Contact header field." > I think some normative language is needed here. Perhaps change to: > "For registration requests in accordance with outbound > behaviour, the UA MUST include a distinct reg-id parameter in > the Contact header field." > > 5. "the target first > hop SIP note" > Change "note" to "node". > > 6. "as this is already allowed by > [RFC3261]. Section 7.5, however a UA that did not register using > outbound registration" > I think this should say > "as this is already allowed by > [RFC3261] section 7.5. However, a UA that did not register using > outbound registration" > > 7. "Configuration indicating keepalive support for a specific > target is > considered an explicit indication. If these conditions are > satisfied, the UA sends its keepalives according to the same > guidelines described in the rest of this section as UAs which > register." > I don't understand the meaning of the first sentence. Is it > trying to say that configuration is an alternative way of > determining support for keepalive? > > 8. "For devices where power is > not a significant concern, the UA SHOULD select a random number > between 95 and 120 seconds between keepalives. When > battery power is > a concern, the UA SHOULD select a random number between 672 and 840 > seconds (14 minutes). These times MAY be configurable." > The last sentence seems to undermine the previous SHOULD > strength statements. Also, what exactly can be configurable - > just the upper and lower bounds? I don't think, for example, > we are proposing to allow somebody to configure say 180 > seconds as both upper and lower bounds (not a range, no > randomisation). So I think it is the bounds that can be > configurable, and even then the 20% difference must be maintained. > Perhaps it should say something like: > "The UA MUST select a random number between a fixed or > configurable upper bound and a lower bound, where the lower > bound is 20% less then the upper bound. The fixed upper bound > or the default configurable upper bound SHOULD be 120 seconds > (95 seconds lower bound) where battery power is not a concern > and 840 seconds (672 seconds lower bound) where battery power > is a concern." > > 9. "The delay time is computed by selecting a uniform random > time between > 50 and 100 percent of the wait time. The UA MUST wait for > the value > of the delay time before trying another registration to form a new > flow for that URI." > I find this a little confusing. The several paragraphs before > that have all talked about wait time, or time to wait, which > suggests that that is how long you wait before trying > registration again. Then we suddenly have this "delay time" > introduced, and it says that "UA MUST wait for the value of > the delay time before trying another registration". It might > be better to introduce the concept of delay time and wait > time up front. Furthermore, it is not clear whether the delay > time (between 50 and 100 percent of the wait time) starts > when the wait time starts or when the wait time finishes. I > think the examples given in the succeeding paragraph suggest > it is the former interpretation. In any case, it needs to be > clarified. > > 10. "The Edge Proxy can determine > if it is the first hop by examining the Via header field." > Does this still work in the case of topology hiding by an > upstream entity? > > 11. "When a '+sip.instance' media feature parameter is present in a > Contact header field of a REGISTER request (after the > Contact header > validation as described above), the corresponding binding > is between > an AOR and the combination of the instance-id (from the > +sip.instance > media feature parameter) and the value of reg-id parameter if it is > present." > I think the normative statements that follow are only > concerned with the case where reg-id is present, so I think > it should be changed to: > "When a '+sip.instance' media feature parameter and a reg-id > parameter are present in a > Contact header field of a REGISTER request (after the > Contact header > validation as described above), the corresponding binding > is between > an AOR and the combination of the instance-id (from the > +sip.instance > media feature parameter) and the value of reg-id parameter." > > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 16:53:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF503A68D3; Fri, 4 Apr 2008 16:53:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB163A6862 for ; Fri, 4 Apr 2008 16:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.72 X-Spam-Level: X-Spam-Status: No, score=-4.72 tagged_above=-999 required=5 tests=[AWL=1.879, 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 EEC6qyMYKEZp for ; Fri, 4 Apr 2008 16:52:59 -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 7D1F13A67A4 for ; Fri, 4 Apr 2008 16:52:59 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 16:53:06 -0700 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 m34Nr6jZ026716; Fri, 4 Apr 2008 16:53:06 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m34Nr5R8021190; Fri, 4 Apr 2008 23:53:06 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Dean Willis'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net><03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> Date: Fri, 4 Apr 2008 16:53:05 -0700 Message-ID: <150101c896af$073842f0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWk/C2jwXH0WwXROmkLKQyFAYkUwAEgM5AAAIvgvA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=450; t=1207353186; x=1208217186; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=nx6eRxYIIWt7Z7sLRNbXm508W6b9+DCq5kfbFRelAbs=; b=FZA8Mx8TKiUqai1exdKikFYZP9lppd/a51bRs1KJUhC5KbpSFaRRqfEaCw eSwBStDJiLOgPZ6bTmAQ6m5wNomZ6nRes5JXTi9kp6Va7IqN+XT+UJr78dZG wQ6RBGlq/D; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, "'Elwell, John'" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > But more importantly, if you're thinking these things would > truly have *legal* ramification, then my guess is no > "good-guys" would touch signing with 4474 with a ten foot > pole, ever. Do DKIM email signatures have such legal > implications? The closest analogy in DKIM would be someone that operated a T.37/RFC2305 gateway (which converts fax to email), and sends those resulting emails with their domain (example.com). -d _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 16:57:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6593A6B55; Fri, 4 Apr 2008 16:57:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDCE3A6AC0 for ; Fri, 4 Apr 2008 16:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTrcnBzAuVey for ; Fri, 4 Apr 2008 16:57:10 -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 D2DCF3A68D2 for ; Fri, 4 Apr 2008 16:57:10 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2008 16:57:18 -0700 Received: from crabapple.local ([10.21.115.143]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m34NfSKD031878; Fri, 4 Apr 2008 15:41:28 -0800 Message-ID: <47F6C05E.2080101@cisco.com> Date: Fri, 04 Apr 2008 16:57:18 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3569; t=1207352489; x=1208216489; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Dean=20Willis=20; bh=y+0o/5JMg8FoffDwrMZ/FpRSSbrAuPt4VpbYyhDiw68=; b=m7KrQeh15Z8lHSscnA1sYSxQWIsYcJdlTZ/9g0nJp0+xV3WXm5A2emRW9j wG+5Rex8SzfpLCDGuXolCvL7rJGwihV4lb1mG0j1o6Pn60Nk5Joo8wtvmY8W Wq6x6PUCJT; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Apr 4, 2008, at 1:20 PM, Michael Thomas wrote: >> Rather than work on a solution, I'd rather hear why a receiver cares >> about any of this. Ie, what does the consumer of this information do >> differently? The experience from the email world thus far is "not much" >> which makes me suspicious this is too abstract a problem for the outside >> world to care about. >> > > That's a fair question. > > The worry is that an RFC 4474 identity assertion forms what is > essentially a contract verification "I, identity service example.com, > have verified according to best current practices that the party > originating this message is authorized to use the identity > sip:alice@example.com". Is 4474 really that emphatic? Can you point me to the section that defines that (sorry, I'm not being rhetorical). That's a pretty high barrier, and strikes me as a very hard thing for any bulk signing service to guarantee. DKIM is far weaker. > > We generally assume the "best current practices" something on the > order of "the party in question has presented credentials based on a > secret known to sip:alice@example.com and presumably unknown to other > parties, and this presentation is consistent with prior interactions > had by this identity service and sip:alice@example.com". That puts an awful lot of responsibility on the signer, especially if the signer isn't colocated with the credential verification. With DKIM, we do not make that kind of guarantee; it's up to the domain itself to determine what the best practices are which might be some cryptographic guarantee (say, SMTP auth), or might be layer 8 guarantee ("you'll lose your job if you do this"). By not making any explicit guarantee about the authorization to use a given local part, we skate around this thorny issue and frankly makes it a lot easier to roll out a signer. > > But when the identity assertion is coming from a PSTN caller ID, it's > significantly less authoritative statement: "I, the identity service > at example.com, think that this request came from +12142821376 because > this is the calling party identifier presented to my telephony > interface." Why is this limited to just the PSTN? Given your average megacorp or telephant, the possibility for spoofing of the local part seems pretty significant when you're talking about bulk signers. Weakening the guarantees to "you can complain to my SIP admins" is a lot easier to achieve in real life. > > There is a profound liability distinction between these two. Failure > to resolve it means that RFC 4474 identity headers would never be more > credible than PSTN caller-ID, and we seem to think they need to be > more credible. I don't buy this: PSTN caller id is a cross domain transitive trust model. 4474 limits this to domain boundaries. That people want to put e.164 like thingies in the localpart doesn't change who controls the namespace: it's the domain's, fullstop. Trying to go anything beyond saying that the localpart is anything beyond an opaque blob as far as the receiver is concerned is essentially saying that I want to tell you my rules for laying out my name space, part of which has thingies that look (but aren't) e.164 blobs. I really don't think you want to go here. The complexity here is enormous. But I'm not sure that my question was answered though: what do you expect a receiver to do differently? Are you thinking about human factors on the UAS? Something else? Mike _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 16:59:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB71A3A6CC9; Fri, 4 Apr 2008 16:59:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D013A6CC9 for ; Fri, 4 Apr 2008 16:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.81 X-Spam-Level: X-Spam-Status: No, score=-4.81 tagged_above=-999 required=5 tests=[AWL=1.789, 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 YrWjcjT+dsLU for ; Fri, 4 Apr 2008 16:59:39 -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 C0BF43A6B3B for ; Fri, 4 Apr 2008 16:59:39 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2008 16:59:46 -0700 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 m34NxkY6019911; Fri, 4 Apr 2008 16:59:46 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m34NxjIq023380; Fri, 4 Apr 2008 23:59:45 GMT From: "Dan Wing" To: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 4 Apr 2008 16:59:45 -0700 Message-ID: <155b01c896af$f57ca910$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2562; t=1207353586; x=1208217586; 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]=20Migration=20from=20E.164=20to=2 0email-style=20SIP=20URIs |Sender:=20; bh=F+xK6AXygYJcRIZhpDIOROn2aJtodxk0vH5BQu44QLU=; b=khBcJaSPZYyCNi6wKnxqlFFuyTH3u3EWPaq+amJeClj6b2QfE16wrUEpCK oWXxqpcx6x/Yao2ET5kTxjrreC88MrYXeRtjE4RV7Oy14Nq+vb6D2g7RGB9o J40f9n8JlbezIB6LImXjdDAL/bWTesI3yqxeTPjtd9PjTODNFtDbs=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "'Elwell, John'" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Friday, April 04, 2008 1:19 AM > To: sip@ietf.org > Subject: [Sip] Migration from E.164 to email-style SIP URIs > > On this thread I would like to explore what can be done in terms of > avoiding the issues concerned with RFC 4474 and E.164-based > SIP URIs by > migration towards the use of email-style URIs. > E.164-based URIs will still be needed, particularly for interworking > with PSTN but also in those SIP environments where E.164 numbers are > more easily handled (e.g., phones with number-based user interfaces). > But perhaps we can explore more the possibility of using the two forms > in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and > email-style in From. I know Dan has an interesting straw man on > this topic, which I will allow him to present himself. One idea that someone (Jonathan?) posted to SIP, about a week before the Philadelphia meeting, was to mix both e.164 and email style identifiers. In that email, it was suggested to use a separator between the two (a "*", as I recall). I have been thinking about using both E.164-style and email-style URIs in parallel, for two reasons: 1. provide a migration path from E.164-style URIs to email-style URIs 2. allow stronger identity to be asserted for email-style URIs Here is a straw-man idea: On an outgoing request containing an e164-style URI in the From: (or PAI, as you prefer), the domain additionally places the user's email-style URI into a new header (let's call it "email-identity"). It determines the mapping between a user's E.164 URI and email URI using a flat database (example: +14085551234 -> dwing@cisco.com). This new header is signed along with everything else we like to sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or draft-wing-sip-identity-media-02.txt, as you prefer]. If the receiving domain understands email-identity, it validates the claimed identity, and it presents the email-style URI to the called party. Thus, the E.164 in the From: (or in the PAI) is essentially ignored. If the receiving domain does not understand email-identity, the receiving domain does not enjoy any benefits of the email-identity header and does not experience any harm from the email-identity header. This provides a backwards-compatible way to migrate to email-style URIs, and gives us strong identity with those email-style URIs. -d _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 17:09:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0633A6C8B; Fri, 4 Apr 2008 17:09:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C12C3A6B09 for ; Fri, 4 Apr 2008 17:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 xRSaXCGUZJIy for ; Fri, 4 Apr 2008 17:09:50 -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 C77FA3A6D1D for ; Fri, 4 Apr 2008 17:09:50 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 17:09:58 -0700 Received: from crabapple.local ([10.21.115.143]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m34Ns8kQ032379; Fri, 4 Apr 2008 15:54:08 -0800 Message-ID: <47F6C357.5000102@cisco.com> Date: Fri, 04 Apr 2008 17:09:59 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Hadriel Kaplan References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=754; t=1207353249; x=1208217249; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=OJ+vfq/kovi5EVbdOrgv7J+WDXNhht9GE5DAOl4UZeY=; b=BncMi1L5IySJ3Y2Jap0aN2sTivpYxZJyCz88divn+80Z/Ig1aSvUmm+d6j hEB/kzlG8R3ZD/V4H4bRm5RzJuxZcXv9+iZW023ylZjCZov2bl11fhofaTNg dFj7f8I3Qs; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: "sip@ietf.org" , "Elwell, John" , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > But more importantly, if you're thinking these things would truly have *legal* ramification, then my guess is no "good-guys" would touch signing with 4474 with a ten foot pole, ever. Do DKIM email signatures have such legal implications? > IANAL, but I sure hope not. It's certainly not what we intended. But I'm not convinced (yet) that this is what 4474 is trying to do. And I'm definitely not convinced that just because something in my namespace happens to superficially look like a e.164 address that I'm bound to some different standard. Would a rot13 on the e.164-like thingie be sufficient to avoid those legal implications? I'm sorry, but the implicit complexity just makes my head hurt. Mike _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 17:12:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E503A6CBE; Fri, 4 Apr 2008 17:12:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633213A68D3 for ; Fri, 4 Apr 2008 17:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.440, 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 HNbFBOYWIzux for ; Fri, 4 Apr 2008 17:12:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0AA4A3A6FF6 for ; Fri, 4 Apr 2008 17:11:46 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m350BoV4015369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 19:11:52 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 19:11:44 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 6:15 PM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> >> If an identity server were to fully RFC 4474 "sign" a message rom a >> PSTN, it's even possible that the identity server operator could be >> held legally liable for inaccuracy in the asserted identity. In other >> words, if a caller-ID spoofer made a call through the example.com >> gateway, and the example.com identity server attaches an Identity >> header on to the resulting INVITE that asserts the spoofed telephone >> number identity, then someone injured (defrauded) by the caller could >> claim negligence on the part of the example.com identity server and >> sue for damages. > > I'm pretty sure that's not possible. It's possible to sue the good > guys, in the local country - but it's quite hard if not impossible > for me to sue some enterprise in Thailand, for example. I don't > know if verisign/thawte/etc. would give them a cert, but since we're > not mandating specific "SIP 4474" certs and they can use the domain > cert they legitimately got for web, I don't see how my UA is to know > any better about their's than softarmor.com's cert. (without > whitelists) Dude, go talk to your lawyer. I'm NOT talking about a foreign identity service that is the source of caller-ID fraud. I'm talking about an allegedly trustworthy identity service that is culpably negligent because it has allowed itself to become a conduit of identity fraud. If you're a US business, and you sign a a request containing a telephone number, and it turns out you're wrong (not because you're doing it on purpose, but because you are incompetent) and I get taken in by a scammer as a result of your mistake, I can sue you for all the damages I receive. I might even win, and at the very least, I'm going to cost you a big chunk of money. But if you signed the request with a stipulation that you passed the request on, but that the identity came from the PSTN and is not something you have verified (and these things are true), then you are NOT liable, because there is no genenral expectation that PSTN caller ID is absolutely correct. You might also escape liability by very careful application of your published operations policy, but it's possible to run into the "implicit warranty" problem in some states. remember, this isn't criminal law, it's civil damages litigation, which has a much lower threshold of proof. > But more importantly, if you're thinking these things would truly > have *legal* ramification, then my guess is no "good-guys" would > touch signing with 4474 with a ten foot pole, ever. Do DKIM email > signatures have such legal implications? Certificate issuance certainly has such legal ramifications. That's why there is a mass of policy documents around each of the CAs, and why you can't really trust a cert in the absence of understanding a CA's policies, and even then you can trust it only to the extent of the insurance and assets of the CA. And it's why you're more likely to believe a Verisign or other tier-1 CA's signing than you are to believe one from the Elbonian Secret Police -- because Verisign and the other Tier-1s have done the homework to both make themselves credible and manage their liability. Even with this, I'm only describing the tip of the vast iceberg of legal complexity and liability that exist. Given this, and in the absence a mechanism for making a disclaimer, you WOULD have to be a fool to slap an identity header on something that you didn't authenticate. And yes, DKIM signatures can potentially have significant legal implications. The case law is generally undecided, but I expect it to be a lucrative area of practice for my attorneys. -- 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 sip-bounces@ietf.org Fri Apr 4 17:16:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE7A3A6FC5; Fri, 4 Apr 2008 17:16:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C335A3A689F for ; Fri, 4 Apr 2008 17:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 WRYdIfzid7ac for ; Fri, 4 Apr 2008 17:16:13 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C35973A6FD8 for ; Fri, 4 Apr 2008 17:15:21 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m350FMZk015388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 19:15:24 -0500 Message-Id: <692294A5-301A-47B5-9BAE-2874A0D2A228@softarmor.com> From: Dean Willis To: Dan Wing In-Reply-To: <150101c896af$073842f0$c5f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 19:15:17 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net><03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <150101c896af$073842f0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, "'Elwell, John'" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 6:53 PM, Dan Wing wrote: > >> But more importantly, if you're thinking these things would >> truly have *legal* ramification, then my guess is no >> "good-guys" would touch signing with 4474 with a ten foot >> pole, ever. Do DKIM email signatures have such legal >> implications? > > The closest analogy in DKIM would be someone that operated > a T.37/RFC2305 gateway (which converts fax to email), and > sends those resulting emails with their domain (example.com). If you're an operator of a DKIM system, and somebody hacks your system and sends mail that's authoritatively from your domain, you can be held liable for the consequences of the email. So could somebody who doesn't run DKIM and is hacked. But bur position is actually weaker than someone who doesn't run DKIM, because you've made a stronger assurance of trust, effectively increasing your responsibility under implicit warranty. -- 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 sip-bounces@ietf.org Fri Apr 4 17:43:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F833A6CBE; Fri, 4 Apr 2008 17:43:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5213A6CA7 for ; Fri, 4 Apr 2008 17:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 OOe4v8iPZA+a for ; Fri, 4 Apr 2008 17:43:56 -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 DF96D3A6987 for ; Fri, 4 Apr 2008 17:43:56 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2008 17:44:04 -0700 Received: from crabapple.local ([10.21.115.143]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m350SDOR001261; Fri, 4 Apr 2008 16:28:13 -0800 Message-ID: <47F6CB53.5000201@cisco.com> Date: Fri, 04 Apr 2008 17:44:03 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net><03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <150101c896af$073842f0$c5f0200a@cisco.com> <692294A5-301A-47B5-9BAE-2874A0D2A228@softarmor.com> In-Reply-To: <692294A5-301A-47B5-9BAE-2874A0D2A228@softarmor.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1524; t=1207355294; x=1208219294; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Dean=20Willis=20; bh=O/KpM9bDFZwqN4prjb9ufkSxpHQ+AHEgrwGVUiRJc5k=; b=F3XwVQZ0ppgMWM2zDTCJVtaTsnuR0K9MDdTVw8fHM9chYCcNvVzPiFtjG1 ztXZP1ZP5gUJmiitVSaSzWWldi3qOf9V4dRzUi1Iztc32zNApxwuyDUPy47b YUjD6CdM2p; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org, "'Elwell, John'" , Dan Wing Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > On Apr 4, 2008, at 6:53 PM, Dan Wing wrote: > >>> But more importantly, if you're thinking these things would >>> truly have *legal* ramification, then my guess is no >>> "good-guys" would touch signing with 4474 with a ten foot >>> pole, ever. Do DKIM email signatures have such legal >>> implications? >>> >> The closest analogy in DKIM would be someone that operated >> a T.37/RFC2305 gateway (which converts fax to email), and >> sends those resulting emails with their domain (example.com). >> > > If you're an operator of a DKIM system, and somebody hacks your system > and sends mail that's authoritatively from your domain, you can be > held liable for the consequences of the email. So could somebody who > doesn't run DKIM and is hacked. But bur position is actually weaker > than someone who doesn't run DKIM, because you've made a stronger > assurance of trust, effectively increasing your responsibility under > implicit warranty. > Anything is possible I suppose but this strikes me as rather alarmist. Lots of big domains are running DKIM these days including some big old banks who are usually pretty cautious about such things and ISP's who have pretty awful control over their user base. But we're not trying to vouch for the authorization to use a given localpart either. I'm pretty sure that if anything about this subject hinges on the likelihood or not of future litigation we are in deep do-do. Mike _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 17:54:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB47B3A69DD; Fri, 4 Apr 2008 17:54:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC5C3A69DD for ; Fri, 4 Apr 2008 17:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=2.634, BAYES_00=-2.599, GB_I_LETTER=-2, 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 keBrw1Y5qPsm for ; Fri, 4 Apr 2008 17:54: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 59A523A6917 for ; Fri, 4 Apr 2008 17:54:04 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2008 17:54:11 -0700 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 m350sBj0024377; Fri, 4 Apr 2008 17:54:11 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m350sAAE028014; Sat, 5 Apr 2008 00:54:11 GMT From: "Dan Wing" To: "'Michael Thomas'" , "'Dean Willis'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net><03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <150101c896af$073842f0$c5f0200a@cisco.com> <692294A5-301A-47B5-9BAE-2874A0D2A228@softarmor.com> <47F6CB53.5000201@cisco.com> Date: Fri, 4 Apr 2008 17:54:10 -0700 Message-ID: <15b001c896b7$8fa69620$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47F6CB53.5000201@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWtiWnQIqJ4UJiQKeBYagFugeq4wAAOhMg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2551; t=1207356851; x=1208220851; c=relaxed/simple; s=sjdkim8002; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=kyhHMEjxrl36JnokArnXXq6+J0PjL3YvFEsADB7relg=; b=cZpAtaMb/Dq/ObEMYD2DwzhicPM2pbC3zSajDTFHMWcIci3SRbja9xeYKR 33kC7sRpKnX6+uObgX4+QGbLCs/ZRjYJIKin4D3XZnQcDmK/n2rPBihRVvzl U4Q9S/2r57; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: sip@ietf.org, "'Elwell, John'" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Dean Willis wrote: > > On Apr 4, 2008, at 6:53 PM, Dan Wing wrote: > > > >>> But more importantly, if you're thinking these things would > >>> truly have *legal* ramification, then my guess is no > >>> "good-guys" would touch signing with 4474 with a ten foot > >>> pole, ever. Do DKIM email signatures have such legal > >>> implications? > >>> > >> The closest analogy in DKIM would be someone that operated > >> a T.37/RFC2305 gateway (which converts fax to email), and > >> sends those resulting emails with their domain (example.com). > >> > > > > If you're an operator of a DKIM system, and somebody hacks > your system > > and sends mail that's authoritatively from your domain, you can be > > held liable for the consequences of the email. So could > somebody who > > doesn't run DKIM and is hacked. But bur position is > actually weaker > > than someone who doesn't run DKIM, because you've made a stronger > > assurance of trust, effectively increasing your > responsibility under > > implicit warranty. > > > Anything is possible I suppose but this strikes me as rather alarmist. > Lots of big domains are running DKIM these days including some big old > banks who are usually pretty cautious about such things and ISP's who > have pretty awful control over their user base. But we're > not trying to > vouch > for the authorization to use a given localpart either. > > I'm pretty sure that if anything about this subject hinges on > the likelihood > or not of future litigation we are in deep do-do. Consider that, today, the opposite is true for the postal service, the PSTN, ISPs, and email: if you give them a letter, a phone number, a destination IP address, or a destination email address, they are expected to route that letter, phone number, IP packet, or email message accordingly. There is a 'contract' to do so, and a contract that they will not mis-route the letter, call, IP packet, or email. Similarly, when the letter, call, packet, or email is handed off by the postal service, phone company, ISP, or email provider, it has 'finished' doing its job. Someone else in your house (or place of business) might destroy the letter or mis-handle the phone call. Someone might drop the packet (your firewall, your PC that crashed). When the email is sitting on the email server, someone might guess your password, login via POP, and retrieve it without your knowledge. DKIM, and rfc4474, do much the same, in reverse. -d _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 18:07:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB0428C100; Fri, 4 Apr 2008 18:07:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4313A69DD for ; Fri, 4 Apr 2008 18:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=1.412, BAYES_00=-2.599, GB_I_LETTER=-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 Gl5jDQzFmD+q for ; Fri, 4 Apr 2008 18:07:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6995B28C183 for ; Fri, 4 Apr 2008 18:07:50 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3517fjg015608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 20:07:51 -0500 Message-Id: <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> From: Dean Willis To: Michael Thomas In-Reply-To: <47F6C05E.2080101@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 20:07:36 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 6:57 PM, Michael Thomas wrote: > Dean Willis wrote: >> >> On Apr 4, 2008, at 1:20 PM, Michael Thomas wrote: >>> Rather than work on a solution, I'd rather hear why a receiver cares >>> about any of this. Ie, what does the consumer of this information do >>> differently? The experience from the email world thus far is "not >>> much" >>> which makes me suspicious this is too abstract a problem for the >>> outside >>> world to care about. >>> >> >> That's a fair question. >> >> The worry is that an RFC 4474 identity assertion forms what is >> essentially a contract verification "I, identity service example.com, >> have verified according to best current practices that the party >> originating this message is authorized to use the identity >> sip:alice@example.com". > > Is 4474 really that emphatic? Can you point me to the section that > defines > that (sorry, I'm not being rhetorical). That's a pretty high barrier, > and strikes > me as a very hard thing for any bulk signing service to guarantee. > DKIM > is far weaker. 4474 provides a relatively strong assertion of identity. There isn't one place in the text that says it, but again and again throughout the text it covers potential weaknesses and why they aren't a problem. It talks about identities being "verified". My professional opinion is that, as written, RFC 4474, implies that the identity service has strongly vouched for the identity indicated in the header. Consider the text of Section 5: > This document defines a new role for SIP entities called an > authentication service. The authentication service role can be > instantiated by a proxy server or a user agent. Any entity that > instantiates the authentication service role MUST possess the > private key of a domain certificate. Intermediaries that instantiate > this role MUST be capable of authenticating one or more SIP users > that can register in that domain. This normatively states that the authentication service can authenticate the users for which it voices, with the strong implication (supported later in the text) that it actually does so. Consider also the discussion of trusted entities: > One solution to this problem is to use 'trusted' SIP intermediaries > that assert an identity for users in the form of a privileged SIP > header. A mechanism for doing so (with the P-Asserted-Identity > header) is given in [12]. However, this solution allows only hop- by- > hop trust between intermediaries, not end-to-end cryptographic > authentication, and it assumes a managed network of nodes with > strict mutual trust relationships, an assumption that is > incompatible with widespread Internet deployment. If you've represented yourself as a trusted provider of information, and arrange for people to trust that information, then you've entered into a contract to provide trustworthy services in a workmanlike fashion. If you do a shoddy job, you're liable for the consequences to your victims. This is true throughout legal systems derived from the British common law, including the US. That's why every mutual fund you might buy has a prospectus saying "Past history does not guarantee future performance". > >> >> We generally assume the "best current practices" something on the >> order of "the party in question has presented credentials based on a >> secret known to sip:alice@example.com and presumably unknown to other >> parties, and this presentation is consistent with prior interactions >> had by this identity service and sip:alice@example.com". > > That puts an awful lot of responsibility on the signer, especially > if the > signer isn't colocated with the credential verification. With DKIM, > we > do not make that kind of guarantee; it's up to the domain itself to > determine what the best practices are which might be some > cryptographic > guarantee (say, SMTP auth), or might be layer 8 guarantee ("you'll > lose your job if you do this"). By not making any explicit guarantee > about the authorization to use a given local part, we skate around > this thorny issue and frankly makes it a lot easier to roll out a > signer. Right. But 4474 makes strong assertions about the user part. And that's why we either have to choose to "take with a grain of salt" any Identity that contains something that might possibly be a phone number, or we have to have some way of differentiating things that came from the PSTN from those we really authenticated, or we have to follow the letter of RFC 4474 and NOT provide an identity header when there's any doubt. Several people have proposed this last choice, and it's technically valid. But since DTLS-SRTP does get some benefit from having an RFC 4474 header, this consequently weakens what we get from DTLS-SRTP whenever there's a call that originates on the PSTN and transits an IP network. This might be OK too, but if that's what we choose, then we have to document the limitation. And so far, we keep going around in circles explaining the problem. And since we can't declare consensus on something people don't understand, we'll keep going around in circles until either 1) people get it, or 2) we give up. > >> >> But when the identity assertion is coming from a PSTN caller ID, it's >> significantly less authoritative statement: "I, the identity service >> at example.com, think that this request came from +12142821376 >> because >> this is the calling party identifier presented to my telephony >> interface." > > Why is this limited to just the PSTN? Given your average megacorp or > telephant, > the possibility for spoofing of the local part seems pretty > significant > when you're > talking about bulk signers. Weakening the guarantees to "you can > complain > to my SIP admins" is a lot easier to achieve in real life. Might be. But we've currently established the expectation that an Identity header serves to authenticate the calling party for access to confidential records like voice mail, access to conference calls, and so on. We can certainly go back and write in some guidance about the meaningfulness of the assertion, if that's what we choose to do. > >> >> There is a profound liability distinction between these two. Failure >> to resolve it means that RFC 4474 identity headers would never be >> more >> credible than PSTN caller-ID, and we seem to think they need to be >> more credible. > > I don't buy this: PSTN caller id is a cross domain transitive trust > model. > 4474 limits this to domain boundaries. That people want to put e.164 > like thingies in the localpart doesn't change who controls the > namespace: > it's the domain's, fullstop. Trying to go anything beyond saying > that the > localpart is anything beyond an opaque blob as far as the receiver is > concerned is essentially saying that I want to tell you my rules for > laying > out my name space, part of which has thingies that look (but aren't) > e.164 blobs. > Right -- the law is clear that as an identity server, you're responsible for the accuracy of your work, no matter whether the user part is numeric or textual or encodoes a phone number. The question is, how do you avoid making misleading assertions? > I really don't think you want to go here. The complexity here is > enormous. > > But I'm not sure that my question was answered though: what do you > expect a receiver to do differently? Are you thinking about human > factors on the UAS? Something else? Here's what 4474 already says: > As a recipient of a request, a user agent that can verify signed > identities should also support an appropriate user interface to > render the validity of identity to a user. User agent > implementations SHOULD differentiate signed From header field values > from unsigned From header field values when rendering to an end-user > the identity of the sender of a request. So yes, we expect the UAS to treat these things differently based on the presence of an Identity header. We could equally assume that it will treat them differently based on strength of the identity assertion. For example, one might choose to request a PIN from PSTN callers attending a conference bridge, but not do so from VoIP callers who have authorized identities. -- Dean -- 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 sip-bounces@ietf.org Fri Apr 4 18:12:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D043A68C5; Fri, 4 Apr 2008 18:12:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E923A68C5 for ; Fri, 4 Apr 2008 18:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 y6heGegxvYRm for ; Fri, 4 Apr 2008 18:12:14 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id F1E4A3A681A for ; Fri, 4 Apr 2008 18:12:13 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 30D205081A; Fri, 4 Apr 2008 18:14:09 -0700 (PDT) Date: Fri, 04 Apr 2008 18:14:09 -0700 From: Eric Rescorla To: sip@ietf.org, draft-ietf-sip-media-security-requirements@tools.ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080405011409.30D205081A@romeo.rtfm.com> Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org $Id: draft-ietf-sip-media-security-requirements-04-rev.txt,v 1.2 2008/04/05 00:53:27 ekr Exp $ This document seems to me to be in good shape. I have the following comments about this document. None of these are critical so I won't cry if they don't get made, and I don't want them to hold the document up if they're controversy. S 4.1. which it is detect-attack, which provides protection against the "which is"? before the SDP answer arrives) might make the requirements to become obsolete, but at the time of writing no progress has been Not sure I know what this means: "to become obsolete" seems ungramattical here. S 4.3. The entire section on shared key conferencing doesn't lead to any requirements as far as I can tell. Does it make sense to remove it from this document? S 5.1. R-DISTINCT: The media security key management protocol MUST be capble of s/capble/capable/ S 5.3. R-OTHER-SIGNALING: A solution SHOULD be able to negotiate keys for SRTP sessions created via different call signaling protocols (e.g., between Jabber, SIP, H.323, MGCP). This is not discussed anywhere in the document. I wonder if it makes sense to remove it. Appendix A. Based on how the SRTP keys are exchanged, each SRTP key exchange mechanism belongs to one general category: signaling path: All the keying is carried in the call signaling Remove one blank line here. S A.1.12. It's a little weird to have the discussion of media path keying properties here before you describe the systems. S A.1.12.2. The issues you raise about middleboxes and clipping apply equally to DTLS-SRTP and ZRTP, no? S A.1.12.3. Again, I would think to remove this section. DTLS-SRTP Keying: Yes, because with the assumed cipher suite, TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key. This statement is not correct. With all conventional TLS modes, neither side completely controls either key. S A.1.13.1. The way you're using "public key cryptography" to mean "PKI" is not the normal terminology. DH is PKC. I would use PKI to indicate "certs are needed". So, for instance, SDP-DH and ZRTP definitely use PKC. PFS is achieved if the negotiated cipher suite includes an exponential or discrete-logarithmic key exchange (e.g., Diffie- Hellman (DH_RSA from [RFC4346]) or Elliptic Curve Diffie- Hellman [RFC4492]). I don't know what "exponential or discrete logarithmic key exchange" means. After all, RSA involves exponentiation. Presumably you mean "something with ephemeral keys". This currently means discrete log over integer and elliptic curve fields, but could be RSA in principle. S A.1.13.3. It's probably important to indicate that it is desirable to have the profile be RTP/SAVP when SRTP is used. That's a disadvantage of media path probing, for instance. I don't think that comes across clearly here. S A.3.2. This document assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as its cipher suite, which is the mandatory-to-implement cipher suite in TLS [RFC4346]. I'm not sure what the relevance of this is. I guess RSA matters, but since we negotiate a separate protection profile for SRTP, 3DES/SHA isn't that relevant. Btw, TLS 1.2. will be AES. Note also that DTLS-SRTP is compatible with RTP before the DTLS handshake. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 19:01:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6320B3A68AA; Fri, 4 Apr 2008 19:01:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76AF33A68AA for ; Fri, 4 Apr 2008 19:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 r6tWNvTGRoML for ; Fri, 4 Apr 2008 19:01:46 -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 AC27B3A67FE for ; Fri, 4 Apr 2008 19:01:46 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2008 19:01:54 -0700 Received: from crabapple.local ([10.21.115.143]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m351k2HZ004389; Fri, 4 Apr 2008 17:46:02 -0800 Message-ID: <47F6DD90.2090203@cisco.com> Date: Fri, 04 Apr 2008 19:01:52 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> In-Reply-To: <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1560; t=1207359963; x=1208223963; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Dean=20Willis=20; bh=7r9SBnaTCYqKquZDsnw7FxJS06+OpOcTjwImFOwoOoA=; b=JpoD2ZzmFAUaC7YS9VHoWnx0jojXzUcQ8T3AuEWg4C223D/IgFUOKAnPO6 32bt4jiyImy/bGf2DdxoA7oI3Ssovy6jS96PHTBRQxbHR6GXpZYfcDpdMo+h SJLbMRWXAd; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I have more to say here (sorry), but one thing leaps out at me: Dean Willis wrote: >>> But when the identity assertion is coming from a PSTN caller ID, it's >>> significantly less authoritative statement: "I, the identity service >>> at example.com, think that this request came from +12142821376 because >>> this is the calling party identifier presented to my telephony >>> interface." >> >> Why is this limited to just the PSTN? Given your average megacorp or >> telephant, >> the possibility for spoofing of the local part seems pretty significant >> when you're >> talking about bulk signers. Weakening the guarantees to "you can >> complain >> to my SIP admins" is a lot easier to achieve in real life. > > Might be. But we've currently established the expectation that an > Identity header serves to authenticate the calling party for access to > confidential records like voice mail, access to conference calls, and > so on. We can certainly go back and write in some guidance about the > meaningfulness of the assertion, if that's what we choose to do. > Wait a minute: are we talking about cross-domain Identity being used as credentials to access voice mail in another domain? Because if it's only within a given domain's administrative control, it can know the name space layout through out of band means. That is, it can know if the names that it generates to gateway e.164 addresses are bogus addresses to get at voice mail, etc. If it's the cross domain case, can you tell me the use case? Mike _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 4 20:33:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B566C3A6953; Fri, 4 Apr 2008 20:33:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83CD53A6940 for ; Fri, 4 Apr 2008 20:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 bvYZjeZfWkWB for ; Fri, 4 Apr 2008 20:33:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8C6233A6953 for ; Fri, 4 Apr 2008 20:33:00 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m353Wtxp017090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Apr 2008 22:33:02 -0500 Message-Id: <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> From: Dean Willis To: Michael Thomas In-Reply-To: <47F6DD90.2090203@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 4 Apr 2008 22:32:50 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 9:01 PM, Michael Thomas wrote: > I have more to say here (sorry), but one thing leaps out at me: > > Dean Willis wrote: >>>> But when the identity assertion is coming from a PSTN caller ID, >>>> it's >>>> significantly less authoritative statement: "I, the identity >>>> service >>>> at example.com, think that this request came from +12142821376 >>>> because >>>> this is the calling party identifier presented to my telephony >>>> interface." >>> >>> Why is this limited to just the PSTN? Given your average megacorp or >>> telephant, >>> the possibility for spoofing of the local part seems pretty >>> significant >>> when you're >>> talking about bulk signers. Weakening the guarantees to "you can >>> complain >>> to my SIP admins" is a lot easier to achieve in real life. >> >> Might be. But we've currently established the expectation that an >> Identity header serves to authenticate the calling party for access >> to confidential records like voice mail, access to conference >> calls, and so on. We can certainly go back and write in some >> guidance about the meaningfulness of the assertion, if that's what >> we choose to do. >> > Wait a minute: are we talking about cross-domain Identity being > used as credentials to access voice mail in another domain? Because > if it's only within a given domain's administrative control, it can > know > the name space layout through out of band means. That is, it can know > if the names that it generates to gateway e.164 addresses are bogus > addresses to get at voice mail, etc. > > If it's the cross domain case, can you tell me the use case? > RFC 4474 is a cross-domain authenticator. Use case: sip:JoeBob@example.com calls his voice mail provider's message retrieval box, sip:messages.example.net Since example.net trusts example.com's RFC 4474 assertions, the voicemail box at messages.example.net does not authenticate JoeBobs' request. Instead, it accepts on trust that example.com authenticated him, and plays out JoeBob's messages. This is AFAIK a valid use case for RFC 4474. Now, assume JoeBob is instead named "180055511212@example.com". All of the above works fine, until somebody calls into example.com's PSTN gateway from a spoofed Caller-ID of "18005551212" and asks said gateway to connect them to messages.example.net Here example.net needs to t be able to tell the difference between a call that originated on the IP network from 18005551212 and was properly authenticated (making a strong RFC 4474 assertion), and a call that originated on the PSTN and therefore has a weak identity assertion requiring further authentication. -- 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 sip-bounces@ietf.org Fri Apr 4 21:16:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933003A6826; Fri, 4 Apr 2008 21:16:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00A73A68FB for ; Fri, 4 Apr 2008 21:16:19 -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 ysPeczLljkdQ for ; Fri, 4 Apr 2008 21:16:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DCB513A6C4A for ; Fri, 4 Apr 2008 21:16: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.240.5; Sat, 5 Apr 2008 00:15:54 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 5 Apr 2008 00:15:54 -0400 From: Hadriel Kaplan To: Dean Willis Date: Sat, 5 Apr 2008 00:15:26 -0400 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AciWsZfBwGRg/GZDRii2PBPjn+54jAAH8Cag Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Dude, go talk to your lawyer. > > I'm NOT talking about a foreign identity service that is the source of > caller-ID fraud. I'm talking about an allegedly trustworthy identity > service that is culpably negligent because it has allowed itself to > become a conduit of identity fraud. > > If you're a US business, and you sign a a request containing a > telephone number, and it turns out you're wrong (not because you're > doing it on purpose, but because you are incompetent) and I get taken > in by a scammer as a result of your mistake, I can sue you for all the > damages I receive. I might even win, and at the very least, I'm going > to cost you a big chunk of money. Yes, and you mistook my premise I think - I was not arguing about that for a US firm (heck, in the US you could sue even without a signature ;) - I was arguing about it for a foreign one. Whether a US-based identity issuer (e.g., Verisign) has that liability for certs it gives out to foreign entities I don't know, IANAL, and isn't germane to my argument (I think). > But if you signed the request with a stipulation that you passed the > request on, but that the identity came from the PSTN and is not > something you have verified (and these things are true), then you are > NOT liable, because there is no genenral expectation that PSTN caller > ID is absolutely correct. Then everyone would set this source=unverified param, even those that have very reasonable expectation of it being legit, and we wouldn't get the semantic difference we're looking for. > Given this, and in the absence a mechanism for making a disclaimer, > you WOULD have to be a fool to slap an identity header on something > that you didn't authenticate. Then I think anyone would have to be a fool to slap an identity header on anything, including things they authenticated. SIP's trust model simply isn't HTTP's, even with SIPS and TLS and all. It isn't even really the same as email's, though certainly closer. -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 sip-bounces@ietf.org Sat Apr 5 07:48:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3EE528C25A; Sat, 5 Apr 2008 07:48:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8797E3A6D63 for ; Sat, 5 Apr 2008 07:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416, 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 o6E0ZDNxCedm for ; Sat, 5 Apr 2008 07:48:03 -0700 (PDT) Received: from taimen.tutpro.com (harjus.tutpro.com [192.98.100.3]) by core3.amsl.com (Postfix) with ESMTP id B2AA828C206 for ; Sat, 5 Apr 2008 07:48:03 -0700 (PDT) Received: by taimen.tutpro.com (Postfix, from userid 1000) id 09C6F33A8C9; Sat, 5 Apr 2008 17:48:15 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18423.37167.959520.98473@harjus.tutpro.com> Date: Sat, 5 Apr 2008 17:48:15 +0300 To: "Dan Wing" In-Reply-To: <155b01c896af$f57ca910$c5f0200a@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, "'Elwell, John'" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan Wing writes: > On an outgoing request containing an e164-style URI in the From: > (or PAI, as you prefer), the domain additionally places the user's > email-style URI into a new header (let's call it "email-identity"). > It determines the mapping between a user's E.164 URI and email URI > using a flat database (example: +14085551234 -> dwing@cisco.com). my proxy is currently is using P-Preferred-Identity header for that purpose. why is a new header needed? -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 5 09:06:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4BC3A6D2A; Sat, 5 Apr 2008 09:06:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BD63A6DEA for ; Sat, 5 Apr 2008 09:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 Wr80Mz458+sP for ; Sat, 5 Apr 2008 09:06:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BB3CB3A6D2A for ; Sat, 5 Apr 2008 09:06: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.240.5; Sat, 5 Apr 2008 12:05:54 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 5 Apr 2008 12:05:55 -0400 From: Hadriel Kaplan To: Dan Wing , "sip@ietf.org" Date: Sat, 5 Apr 2008 12:05:28 -0400 Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQACKCn/A= Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> In-Reply-To: <155b01c896af$f57ca910$c5f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "'Elwell, John'" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dan > Wing > > Here is a straw-man idea: > > On an outgoing request containing an e164-style URI in the From: > (or PAI, as you prefer), the domain additionally places the user's > email-style URI into a new header (let's call it "email-identity"). > It determines the mapping between a user's E.164 URI and email URI > using a flat database (example: +14085551234 -> dwing@cisco.com). Interesting proposal. > This new header is signed along with everything else we like to > sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or > draft-wing-sip-identity-media-02.txt, as you prefer]. You wouldn't be able to use 4474 as is, because it has no way to sign a new header, afaik. (though I'm all for a 4474bis ;) I know this is only a straw-man and too soon to get into the details, but I can't help myself, so I wonder why you wouldn't just put this email-style URI *inside* the From-URI as an escaped uri or user param. That way it avoids a new header and gets signed by 4474 as is, and really what you're saying is it is an alias property of the From-URI. > This provides a backwards-compatible way to migrate to email-style > URIs, and gives us strong identity with those email-style URIs. And lets the UAS offer its user the ability to add both the e164 and email-forms into its contact address book. I'm not sure if that's good or bad, but it's a nice feature. -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 sip-bounces@ietf.org Sat Apr 5 09:25:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DBA28C2B9; Sat, 5 Apr 2008 09:25:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D243A67E6 for ; Sat, 5 Apr 2008 09:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 qiRIs-qpqfRF for ; Sat, 5 Apr 2008 09:25:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 775F328C2F4 for ; Sat, 5 Apr 2008 09:25:24 -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.240.5; Sat, 5 Apr 2008 12:25:05 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 5 Apr 2008 12:25:03 -0400 From: Hadriel Kaplan To: Dean Willis Date: Sat, 5 Apr 2008 12:24:39 -0400 Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting Thread-Index: AciWpBeSZjZ0+71dSi2Y7rdBOEcmLgAkt3xQ Message-ID: References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> <1EB19C3C-78BD-404F-8918-0AA08F348CBC@softarmor.com> <5C83AF52-003A-466F-8001-DCD4B8BF87A8@softarmor.com> In-Reply-To: <5C83AF52-003A-466F-8001-DCD4B8BF87A8@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, April 04, 2008 6:35 PM > > On Apr 4, 2008, at 3:59 PM, Hadriel Kaplan wrote: > > > > You won't know that for the 121 either - if someone has the callid/ > > via/from-tag/etc. necessary to send you a fake matching response, a > > 121 will not be hard for them to send. Obviously if a 121 could be > > signed by Bob's proxy, saying "I'm sending this to Charlie", that > > would be interesting maybe. But you could instead just have Bob's > > proxy put something in the Invite it forwards to Charlie which > > Charlie copies in his response, to tell you he's legit to have > > gotten it. (and that mechanism at the same time could help avoid the > > rfc4474 baiting attack problem) > > Well, that's why I want identity-signed responses. Signing the response won't avoid baiting. Baiting is an attack on the called party, not the calling. The issue is Charlie or his verifier doesn't know if he should be receiving the request, since the signed To-URI is Bob's. In an early un-published form of the baiting draft I proposed a possible solution whereby Bob's proxy would in fact sign some new "re-target" header that effectively says "Charlie, Bob's domain is sending this to you". The original 4474 identity would be left as is, and none of the headers it signs would be changed so that it's verifiable, and the additional re-target identity also signs some of the same headers (minus call-id/cseq/contact) plus the new re-target header. (you can think of it as signing Christer's Target header) I removed that because I thought the solution was hokey and a troubleshooting/performance nightmare and highly unlikely to ever be deployed, and instead that Charlie could just decide who he wanted to answer calls re-targeted from, even without 4474. But if you do something like that, then that target signature could actually be copied into the 18x/2xx responses, and the UAC can verify them to see that Bob's domain explicitly allowed Charlie to get the request. But I'm not personally convinced that this is a problem which needs to be solved, given the overhead of the solution. -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 sip-bounces@ietf.org Sat Apr 5 09:36:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37183A6C1A; Sat, 5 Apr 2008 09:36:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9833F3A6E1D for ; Sat, 5 Apr 2008 09:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 ntkHJNJ6SjKY for ; Sat, 5 Apr 2008 09:36:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0640B3A6DF7 for ; Sat, 5 Apr 2008 09:36: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.240.5; Sat, 5 Apr 2008 12:36:08 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 5 Apr 2008 12:36:08 -0400 From: Hadriel Kaplan To: Dean Willis Date: Sat, 5 Apr 2008 12:35:43 -0400 Thread-Topic: [Sip] Preventing unanticipated respondent syndrome when retargeting Thread-Index: AciWpBeSZjZ0+71dSi2Y7rdBOEcmLgAlY+Ww Message-ID: References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> <1EB19C3C-78BD-404F-8918-0AA08F348CBC@softarmor.com> <5C83AF52-003A-466F-8001-DCD4B8BF87A8@softarmor.com> In-Reply-To: <5C83AF52-003A-466F-8001-DCD4B8BF87A8@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, April 04, 2008 6:35 PM > > On Apr 4, 2008, at 3:59 PM, Hadriel Kaplan wrote: > > > > I believe, from my google searching of the mail archives a while > > ago, that the main argument for not signing the responses was not to > > do with digest auth of the responder - it was because of the > > retarget scenario, where a retargeted-to domain could not possibly > > sign the response unless we allowed the To-URI to be changed in > > responses, which people were not wont to do due to 2543 dialog > > matching rules. At least that was my google impression. :) > > right -- so we use a previous provisional response from a node on the > "expected path" to solve the unanticipated response problem resulting > from the retarget! It won't help. If we're stuck with 2543-type dialog matching rules, then the 121 AND the 18x/2xx can't change them, even if the 121 was sent saying "prepare for changing", since 121 would be treated by legacy nodes as a 1xx. IF you're suggesting the 121 and subsequent responses use a new header for the re-targeted-to URI, then that solution could have been done to begin with instead of 4916 sending an UPDATE (and indeed I don't know why it wasn't, but I presume there was some valid reason). Whether we *are* stuck with 2543-type dialog matching or not is a different topic, and my guess is its subject title would be "Here there be dragons". :) -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 sip-bounces@ietf.org Sat Apr 5 10:00:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5E83A6E4C; Sat, 5 Apr 2008 10:00:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9547A3A6C75 for ; Sat, 5 Apr 2008 10:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.075 X-Spam-Level: X-Spam-Status: No, score=-5.075 tagged_above=-999 required=5 tests=[AWL=1.524, 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 iJT7gANmy5Tf for ; Sat, 5 Apr 2008 10:00:57 -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 ABA3B3A6A0B for ; Sat, 5 Apr 2008 10:00:57 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2008 10:01:06 -0700 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 m35H16g2004178; Sat, 5 Apr 2008 10:01:06 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m35H15Uu011083; Sat, 5 Apr 2008 17:01:05 GMT From: "Dan Wing" To: "'Juha Heinanen'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><155b01c896af$f57ca910$c5f0200a@cisco.com> <18423.37167.959520.98473@harjus.tutpro.com> Date: Sat, 5 Apr 2008 10:01:05 -0700 Message-ID: <16d201c8973e$a3456620$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <18423.37167.959520.98473@harjus.tutpro.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciXLBQALB+zGE+dSdm/kSq/xbSlAgAEmorQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1005; t=1207414866; x=1208278866; 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]=20Migration=20from=20E.164=20to=2 0email-style=20SIP=20URIs |Sender:=20; bh=++4Co3ID5lC6UfqqN6ijiGLW5xn6jGAPJB5mEZ6ao+E=; b=K8b2bFsGvOT4maU/Jw6PtylBgw5s78EG/43ZwiQT2a8pjwXfKu/DpYDiaA ig5bJkb54dgG+FnSA/LYv0IoD9Lr0L0ttPlZAgZQEZ186WzdLcSQX0Yhrx/S c/tc05qvhJ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org, "'Elwell, John'" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Saturday, April 05, 2008 7:48 AM > To: Dan Wing > Cc: sip@ietf.org; 'Elwell, John' > Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs > > Dan Wing writes: > > > On an outgoing request containing an e164-style URI in the From: > > (or PAI, as you prefer), the domain additionally places the user's > > email-style URI into a new header (let's call it "email-identity"). > > It determines the mapping between a user's E.164 URI and email URI > > using a flat database (example: +14085551234 -> dwing@cisco.com). > > my proxy is currently is using P-Preferred-Identity header for that > purpose. why is a new header needed? The header, containing the email-style URI, needs to be signed. I do not care if it is a new header or not, but I see value in not overloading a header with an already-defined semantic (such as P-Preferred-Identity). But this is a detail. -d _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 5 10:08:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FF13A6E1D; Sat, 5 Apr 2008 10:08:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E361E3A6E0D for ; Sat, 5 Apr 2008 10:08:17 -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.356, 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 y3tGYZoeVVpB for ; Sat, 5 Apr 2008 10:08:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 35FC73A6C41 for ; Sat, 5 Apr 2008 10:08:15 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m35H8Kj9021489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 5 Apr 2008 12:08:21 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 5 Apr 2008 12:08:15 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org" , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 4, 2008, at 11:15 PM, Hadriel Kaplan wrote: >> ... >> If you're a US business, and you sign a a request containing a >> telephone number, and it turns out you're wrong (not because you're >> doing it on purpose, but because you are incompetent) and I get taken >> in by a scammer as a result of your mistake, I can sue you for all >> the >> damages I receive. I might even win, and at the very least, I'm going >> to cost you a big chunk of money. > > Yes, and you mistook my premise I think - I was not arguing about > that for a US firm (heck, in the US you could sue even without a > signature ;) - I was arguing about it for a foreign one. Whether a > US-based identity issuer (e.g., Verisign) has that liability for > certs it gives out to foreign entities I don't know, IANAL, and > isn't germane to my argument (I think). > Ok, I'll buy that. > >> But if you signed the request with a stipulation that you passed the >> request on, but that the identity came from the PSTN and is not >> something you have verified (and these things are true), then you are >> NOT liable, because there is no genenral expectation that PSTN caller >> ID is absolutely correct. > > Then everyone would set this source=unverified param, even those > that have very reasonable expectation of it being legit, and we > wouldn't get the semantic difference we're looking for. The legal premise is "best current practice" -- you can't be absolutely sure in any case, but if you're such a doofus that you do a full RFC 4474 signature on something that we all agree can't be verified, then you may need to get slapped awake. Unfortunately, the way RFC 4474 and DTLS Framework currently interact means that NOT using RFC 4474 on PSTN-sourced calls makes you almost as much of a doofus. So we either change need to change RFC 4474 (by making a signature "mean less" OR by allowing one to make a disclaimer on the signature), or we change DTLS-SRTP framework to make it nod depend on RFC 4474 for end-to-end communication of the signature. We do have two drafts (Wing, Fischer) that would accomplish this. > >> Given this, and in the absence a mechanism for making a disclaimer, >> you WOULD have to be a fool to slap an identity header on something >> that you didn't authenticate. > > Then I think anyone would have to be a fool to slap an identity > header on anything, including things they authenticated. SIP's > trust model simply isn't HTTP's, even with SIPS and TLS and all. It > isn't even really the same as email's, though certainly closer. Appropriate legal caution is required in all commercial practices. But blatant disregard for common sense will usually get you in trouble. -- 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 sip-bounces@ietf.org Sat Apr 5 10:15:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3139E28C28D; Sat, 5 Apr 2008 10:15:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12BEA3A6A0B for ; Sat, 5 Apr 2008 10:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 kNWSyqdUV3wq for ; Sat, 5 Apr 2008 10:15:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C2D743A6C46 for ; Sat, 5 Apr 2008 10:15:26 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m35HFWO6021539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 5 Apr 2008 12:15:33 -0500 Message-Id: <954542B4-53B3-4D32-ACB9-8B358743192A@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 5 Apr 2008 12:15:26 -0500 References: <7D9AB6CF-9DAF-4F5B-B777-C695B8A30E22@softarmor.com> <9CB308A8-367B-48EA-AA7D-0665D4B4C195@softarmor.com> <1EB19C3C-78BD-404F-8918-0AA08F348CBC@softarmor.com> <5C83AF52-003A-466F-8001-DCD4B8BF87A8@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Preventing unanticipated respondent syndrome when retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 5, 2008, at 11:35 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Friday, April 04, 2008 6:35 PM >> >> On Apr 4, 2008, at 3:59 PM, Hadriel Kaplan wrote: >>> >>> I believe, from my google searching of the mail archives a while >>> ago, that the main argument for not signing the responses was not to >>> do with digest auth of the responder - it was because of the >>> retarget scenario, where a retargeted-to domain could not possibly >>> sign the response unless we allowed the To-URI to be changed in >>> responses, which people were not wont to do due to 2543 dialog >>> matching rules. At least that was my google impression. :) >> >> right -- so we use a previous provisional response from a node on the >> "expected path" to solve the unanticipated response problem resulting >> from the retarget! > > It won't help. If we're stuck with 2543-type dialog matching rules, > then the 121 AND the 18x/2xx can't change them, even if the 121 was > sent saying "prepare for changing", since 121 would be treated by > legacy nodes as a 1xx. IF you're suggesting the 121 and subsequent > responses use a new header for the re-targeted-to URI, then that > solution could have been done to begin with instead of 4916 sending > an UPDATE (and indeed I don't know why it wasn't, but I presume > there was some valid reason). > > Whether we *are* stuck with 2543-type dialog matching or not is a > different topic, and my guess is its subject title would be "Here > there be dragons". :) Alice calls Bob, gets a provisional response from Bob's proxy saying the call has been forwarded to Charlie. The prov response lets Alice know to expect something about about the response -- specifically, that it is going to be coming from someone who is not the target. So if the response from Charlie says "Yeah, I'm Bob, signed by Charlie", then Alice would understand that despite the "From" being Bob, that she's really talking to Charlie. -- 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 sip-bounces@ietf.org Sat Apr 5 10:56:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B403A6C6C; Sat, 5 Apr 2008 10:56:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC813A6ADF for ; Sat, 5 Apr 2008 10:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 EH+g-BXUQC+s for ; Sat, 5 Apr 2008 10:56:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 76AA83A6C6C for ; Sat, 5 Apr 2008 10:56:49 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m35HutsR021761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 5 Apr 2008 12:56:57 -0500 Message-Id: From: Dean Willis To: "sip@ietf.org List" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 5 Apr 2008 12:56:49 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 5, 2008, at 12:08 PM, Dean Willis wrote too quickly: > > So we either change need to change RFC 4474 (by making a signature > "mean less" OR by allowing one to make a disclaimer on the signature), > or we change DTLS-SRTP framework to make it nod depend on RFC 4474 for > end-to-end communication of the signature. We do have two drafts > (Wing, Fischer) that would accomplish this. Sorry, I wrote too quickly and left out a bridge-construct, making the above more confusing than my usual rambling. And I misphrased a word or two. Sorry. Let's retry: So we either change need to change RFC 4474 (by making a signature "mean less" OR by allowing one to make a disclaimer on the signature), or we change DTLS-SRTP framework to make it not depend on RFC 4474 for end-to-end protection of the fingerprint. We also have the issue of detecting fingerprint changes midstream, meaning that we've had a MITM on the media (that has replaced the Identity header). We do have two drafts (Wing, Fischer) that would accomplish this. The consequence of the second para above, if I understand it correctly, is that DTLS-Framework is relying on the RFC 4474 Identity header to protect the integrity of the key fingerprint which is transmitted in the SDP. If the Identity header is UA-signed, this is pretty much rock-solid. However, if it is signed by an intermediate node, then it is possible that the intermediate node has altered the SDP (and fingerprint), and that it may be colluding in interception of the media. And that's just the way RFC 4474 works, so anything that relies on it (like DTLS-SRTP framework) has this limitation. The point is that there may be a possibility to fix all these flaws in one pass. I'm not sure what solution would do this, but I have the feeling there's one out there that we just haven't quite identified yet. The logic goes this way: DTLS-SRTP framework uses RFC 4474 for integrity protection of the fingerprint. By doing so it inherits weaknesses of RFC 4474. We have noted two of these as issues: 1) RFC 4474 cannot legitimately be used for calls originating on the PSTN and transiting a gateway to SIP because it lacks a way to inform the recipient that the From: field was not actually authenticated by the authentication service. Otherwise said: as written, 4474 promises that the From: field was authenticated by the authentication service, and since in this case it wasn't authenticated, the service shouldn't be saying it was authenticated. 2) RFC 4474 headers may be subject to replacement by intermediates. While this might be required for certain uses of intermediates (such as SBCs that replace SDP because they're relaying it), it can also be used to insert an intermediary that intercepts the cleartext of the media (taps the call) without the consent of the endpoints. We could work around by fixing these problems independently -- for example, by adding the From: disclaimer proposed by Adam and the assorted SBC-traversal and fingerprint preservation/verification techniques proposed by Dan, Kai, and probably others. Or we could fix it by either fundamentally changing RFC 4474, or by providing a different fingerprint integrity mechanism for DTLS-SRTP framework and thereby breaking the dependency cycle. -- 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 sip-bounces@ietf.org Sat Apr 5 11:02:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C0728C330; Sat, 5 Apr 2008 11:02:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19ED528C258 for ; Sat, 5 Apr 2008 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.136 X-Spam-Level: X-Spam-Status: No, score=-5.136 tagged_above=-999 required=5 tests=[AWL=1.463, 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 sU5Ze8bi-qHc for ; Sat, 5 Apr 2008 11:02: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 1BFD728C334 for ; Sat, 5 Apr 2008 11:02:43 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2008 11:02:52 -0700 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 m35I2pNf017559; Sat, 5 Apr 2008 11:02:51 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m35I2p6L010361; Sat, 5 Apr 2008 18:02:51 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><155b01c896af$f57ca910$c5f0200a@cisco.com> Date: Sat, 5 Apr 2008 11:02:51 -0700 Message-ID: <170801c89747$43da95d0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQACKCn/AAA1jG0A== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2170; t=1207418571; x=1208282571; 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]=20Migration=20from=20E.164=20to=2 0email-style=20SIP=20URIs |Sender:=20; bh=+X1UvQlF5/a9XMPaX6QC9sR0680kxukZ23JxumAO4y4=; b=aUuO9JUTsmCz95N5zQTcV2R17AKXQwYa+801gK+hAYHbIl1D/9VkyvW9A+ BqWhJJG6lsY0jK6/ZcHIMD4Djs+9QMxpo9/CoTsLCCob6iVJcRTB6IjtKbr0 setzT5JAsrpkSxDikESjzBy4oeJIKmnbBCfeuVRbi1mDRwua5WXnA=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "'Elwell, John'" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Dan Wing > > > > Here is a straw-man idea: > > > > On an outgoing request containing an e164-style URI in the From: > > (or PAI, as you prefer), the domain additionally places the user's > > email-style URI into a new header (let's call it "email-identity"). > > It determines the mapping between a user's E.164 URI and email URI > > using a flat database (example: +14085551234 -> dwing@cisco.com). > > Interesting proposal. > > > This new header is signed along with everything else we like to > > sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or > > draft-wing-sip-identity-media-02.txt, as you prefer]. > > You wouldn't be able to use 4474 as is, because it has no way > to sign a new header, afaik. Right, RFC4474 is not extensible. > (though I'm all for a 4474bis ;) > I know this is only a straw-man and too soon to get into the > details, but I can't help myself, so I wonder why you > wouldn't just put this email-style URI *inside* the From-URI > as an escaped uri or user param. That way it avoids a new > header and gets signed by 4474 as is, and really what you're > saying is it is an alias property of the From-URI. That would look something like: From: Dan Wing and the originating domain (cisco.com) would provide strong identity over the entire URI, including the E.164 and the email-style portion (dwing@cisco.com). I wanted to avoid signing the E.164 in the From, because we have not yet resolved if we can do that in a meaningful way. > > This provides a backwards-compatible way to migrate to email-style > > URIs, and gives us strong identity with those email-style URIs. > > And lets the UAS offer its user the ability to add both the > e164 and email-forms into its contact address book. I'm not > sure if that's good or bad, but it's a nice feature. Right, but that could also be another attack vector if the E.164 is unsigned or only trustable hop-by-hop. -d _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 5 11:34:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAD628C3B8; Sat, 5 Apr 2008 11:34:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7855528C319 for ; Sat, 5 Apr 2008 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_38=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 VQQjDIhZ5AGh for ; Sat, 5 Apr 2008 11:34: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 AD22428C354 for ; Sat, 5 Apr 2008 11:34: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 <0JYV00F5Q7LNAE@siemenscomms.co.uk> for sip@ietf.org; Sat, 05 Apr 2008 19:34:35 +0100 (BST) Date: Sat, 05 Apr 2008 19:34:32 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF15F0BBB3@zrc2hxm0.corp.nortel.com> To: Francois Audet , IETF SIP List , Cullen Jennings , Rohan Mahy Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095BC0A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Review of sip-outbound-13 Thread-Index: AciWXEvN4G0kcc5IT3CC5/sITATquQAUAFLgACdyExA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D095BA9B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF15F0BBB3@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] Review of sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: 05 April 2008 00:38 > To: Elwell, John; IETF SIP List; Cullen Jennings; Rohan Mahy > Subject: Re: [Sip] Review of sip-outbound-13 > > Thank you John. > > I am OK with your edits 1, 2, 4, 5, 6, 8 and 11. > > I don't understand your point about 3. [JRE] It says that there is a case where a UA might not want to use the sip.instance media feature tag, yet that tag is essential for outbound. Is it saying that in such a case the UA should not use sip-outbound? > > For 7, it should say "A configuration option indicating...". [JRE] OK, on re-reading it I understand it better, since it is referring to the "explicit indication" in the previous paragraph. However, I think your proposed wording change would be be an improvement. > > For 9, I'll have to defer to Rohan and Cullen because I find it > confusing too. [JRE]Yes, and that is why I wasn't able to propose new words. > > For 10, I believe that it would work if an upstream evil B2BUA does > topology hiding since the proxy uses the Via in the Request > and not the > Path in the response. [JRE] What I meant was, if a proxy receives a REGISTER request with only a single element in the Via header field, how does it know whether the request came from a UA or from a topology-hiding B2BUA? This is probably an unlikely situation for a REGISTER request (UA -> B2BUA -> proxy), but can we rule it out? John > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Friday, April 04, 2008 07:01 > > To: IETF SIP List > > Subject: [Sip] Review of sip-outbound-13 > > > > I think this is ready to go if the following minor comments are > > addressed: > > > > 1. "This > > specification also defines multiple keep alive schemes." > > Change "multiple" to "two". > > > > 2. "A Flow is a network protocol layer (layer 4) association" > > Change "network" to "transport". > > > > 3. "One case where a UA may not want to include > > the sip.instance media feature tag at all is when it is making an > > anonymous request or some other privacy concern requires > > that the UA > > not reveal its identity." > > There is no statement about what should be done in this case. > > > > 4. "These registration requests include a distinct reg-id > parameter in > > the Contact header field." > > I think some normative language is needed here. Perhaps change to: > > "For registration requests in accordance with outbound > > behaviour, the UA MUST include a distinct reg-id parameter in > > the Contact header field." > > > > 5. "the target first > > hop SIP note" > > Change "note" to "node". > > > > 6. "as this is already allowed by > > [RFC3261]. Section 7.5, however a UA that did not register using > > outbound registration" > > I think this should say > > "as this is already allowed by > > [RFC3261] section 7.5. However, a UA that did not register using > > outbound registration" > > > > 7. "Configuration indicating keepalive support for a specific > > target is > > considered an explicit indication. If these conditions are > > satisfied, the UA sends its keepalives according to the same > > guidelines described in the rest of this section as UAs which > > register." > > I don't understand the meaning of the first sentence. Is it > > trying to say that configuration is an alternative way of > > determining support for keepalive? > > > > 8. "For devices where power is > > not a significant concern, the UA SHOULD select a random number > > between 95 and 120 seconds between keepalives. When > > battery power is > > a concern, the UA SHOULD select a random number between > 672 and 840 > > seconds (14 minutes). These times MAY be configurable." > > The last sentence seems to undermine the previous SHOULD > > strength statements. Also, what exactly can be configurable - > > just the upper and lower bounds? I don't think, for example, > > we are proposing to allow somebody to configure say 180 > > seconds as both upper and lower bounds (not a range, no > > randomisation). So I think it is the bounds that can be > > configurable, and even then the 20% difference must be maintained. > > Perhaps it should say something like: > > "The UA MUST select a random number between a fixed or > > configurable upper bound and a lower bound, where the lower > > bound is 20% less then the upper bound. The fixed upper bound > > or the default configurable upper bound SHOULD be 120 seconds > > (95 seconds lower bound) where battery power is not a concern > > and 840 seconds (672 seconds lower bound) where battery power > > is a concern." > > > > 9. "The delay time is computed by selecting a uniform random > > time between > > 50 and 100 percent of the wait time. The UA MUST wait for > > the value > > of the delay time before trying another registration to > form a new > > flow for that URI." > > I find this a little confusing. The several paragraphs before > > that have all talked about wait time, or time to wait, which > > suggests that that is how long you wait before trying > > registration again. Then we suddenly have this "delay time" > > introduced, and it says that "UA MUST wait for the value of > > the delay time before trying another registration". It might > > be better to introduce the concept of delay time and wait > > time up front. Furthermore, it is not clear whether the delay > > time (between 50 and 100 percent of the wait time) starts > > when the wait time starts or when the wait time finishes. I > > think the examples given in the succeeding paragraph suggest > > it is the former interpretation. In any case, it needs to be > > clarified. > > > > 10. "The Edge Proxy can determine > > if it is the first hop by examining the Via header field." > > Does this still work in the case of topology hiding by an > > upstream entity? > > > > 11. "When a '+sip.instance' media feature parameter is present in a > > Contact header field of a REGISTER request (after the > > Contact header > > validation as described above), the corresponding binding > > is between > > an AOR and the combination of the instance-id (from the > > +sip.instance > > media feature parameter) and the value of reg-id > parameter if it is > > present." > > I think the normative statements that follow are only > > concerned with the case where reg-id is present, so I think > > it should be changed to: > > "When a '+sip.instance' media feature parameter and a reg-id > > parameter are present in a > > Contact header field of a REGISTER request (after the > > Contact header > > validation as described above), the corresponding binding > > is between > > an AOR and the combination of the instance-id (from the > > +sip.instance > > media feature parameter) and the value of reg-id parameter." > > > > 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 > > > _______________________________________________ > 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 sip-bounces@ietf.org Sat Apr 5 11:40:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DDB28C233; Sat, 5 Apr 2008 11:40:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388A83A6B26 for ; Sat, 5 Apr 2008 11:40:27 -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 gjU0ljEGWi-U for ; Sat, 5 Apr 2008 11:40: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 820BD28C2D7 for ; Sat, 5 Apr 2008 11:40:01 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYV00F5C7UXLK@siemenscomms.co.uk> for sip@ietf.org; Sat, 05 Apr 2008 19:40:09 +0100 (BST) Date: Sat, 05 Apr 2008 19:40:07 +0100 From: "Elwell, John" In-reply-to: <16d201c8973e$a3456620$c5f0200a@cisco.com> To: Dan Wing , Juha Heinanen Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095BC0B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciXLBQALB+zGE+dSdm/kSq/xbSlAgAEmorQAANy9BA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <18423.37167.959520.98473@harjus.tutpro.com> <16d201c8973e$a3456620$c5f0200a@cisco.com> Cc: sip@ietf.org Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Also PPI is not end-to-end - it is intended only to go as far as the first proxy, where it is moved to PAI or discarded. John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 05 April 2008 18:01 > To: 'Juha Heinanen' > Cc: sip@ietf.org; Elwell, John > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > > > > > -----Original Message----- > > From: Juha Heinanen [mailto:jh@tutpro.com] > > Sent: Saturday, April 05, 2008 7:48 AM > > To: Dan Wing > > Cc: sip@ietf.org; 'Elwell, John' > > Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs > > > > Dan Wing writes: > > > > > On an outgoing request containing an e164-style URI in the From: > > > (or PAI, as you prefer), the domain additionally places > the user's > > > email-style URI into a new header (let's call it > "email-identity"). > > > It determines the mapping between a user's E.164 URI and > email URI > > > using a flat database (example: +14085551234 -> dwing@cisco.com). > > > > my proxy is currently is using P-Preferred-Identity header for that > > purpose. why is a new header needed? > > The header, containing the email-style URI, needs to be signed. > > I do not care if it is a new header or not, but I see value in not > overloading a header with an already-defined semantic (such as > P-Preferred-Identity). But this is a detail. > > -d > > _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 5 11:43:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E820628C3A7; Sat, 5 Apr 2008 11:43:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305EE3A6B26 for ; Sat, 5 Apr 2008 11:43:53 -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.101, 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 lp1e6zTVk5ZT for ; Sat, 5 Apr 2008 11:43:52 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id E712A3A6A12 for ; Sat, 5 Apr 2008 11:43:51 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYV00FA681CLK@siemenscomms.co.uk> for sip@ietf.org; Sat, 05 Apr 2008 19:44:00 +0100 (BST) Date: Sat, 05 Apr 2008 19:43:58 +0100 From: "Elwell, John" In-reply-to: <170801c89747$43da95d0$c5f0200a@cisco.com> To: Dan Wing , Hadriel Kaplan , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095BC0C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQACKCn/AAA1jG0AACqsAQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <170801c89747$43da95d0$c5f0200a@cisco.com> Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I too think the straw man from Dan is an interesting idea. The alternative that I think Hadriel is suggesting (email style as a parameter of the E.164-based SIP URI) would probably not survive any changes of the E.164-based URI by intermediaries -part of the problem with E.164-based URIs in practice. John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 05 April 2008 19:03 > To: 'Hadriel Kaplan'; sip@ietf.org > Cc: Elwell, John > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > Hadriel Kaplan wrote: > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of Dan Wing > > > > > > Here is a straw-man idea: > > > > > > On an outgoing request containing an e164-style URI in the From: > > > (or PAI, as you prefer), the domain additionally places the user's > > > email-style URI into a new header (let's call it > "email-identity"). > > > It determines the mapping between a user's E.164 URI and email URI > > > using a flat database (example: +14085551234 -> dwing@cisco.com). > > > > Interesting proposal. > > > > > This new header is signed along with everything else we like to > > > sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or > > > draft-wing-sip-identity-media-02.txt, as you prefer]. > > > > You wouldn't be able to use 4474 as is, because it has no way > > to sign a new header, afaik. > > Right, RFC4474 is not extensible. > > > (though I'm all for a 4474bis ;) > > I know this is only a straw-man and too soon to get into the > > details, but I can't help myself, so I wonder why you > > wouldn't just put this email-style URI *inside* the From-URI > > as an escaped uri or user param. That way it avoids a new > > header and gets signed by 4474 as is, and really what you're > > saying is it is an alias property of the From-URI. > > That would look something like: > > From: Dan Wing > > and the originating domain (cisco.com) would provide strong identity > over the entire URI, including the E.164 and the email-style portion > (dwing@cisco.com). > > I wanted to avoid signing the E.164 in the From, because we have not > yet resolved if we can do that in a meaningful way. > > > > This provides a backwards-compatible way to migrate to email-style > > > URIs, and gives us strong identity with those email-style URIs. > > > > And lets the UAS offer its user the ability to add both the > > e164 and email-forms into its contact address book. I'm not > > sure if that's good or bad, but it's a nice feature. > > Right, but that could also be another attack vector if the > E.164 is unsigned or only trustable hop-by-hop. > > -d > > _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 5 12:23:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8711D28C25F; Sat, 5 Apr 2008 12:23:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A0828C25F for ; Sat, 5 Apr 2008 12:23:35 -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 Sl41DdS6FgkQ for ; Sat, 5 Apr 2008 12:23: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 8252628C232 for ; Sat, 5 Apr 2008 12:23:34 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYV00I5T9VJ8Q@siemenscomms.co.uk> for sip@ietf.org; Sat, 05 Apr 2008 20:23:43 +0100 (BST) Date: Sat, 05 Apr 2008 20:23:42 +0100 From: "Elwell, John" In-reply-to: To: Dean Willis , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095BC0E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AciXRnvehox9ANm3RSCWj/AWQD8BIgAC1Pag Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: 05 April 2008 18:57 > To: sip@ietf.org List > Subject: Re: [Sip] RFC 4474 and PSTN > > > On Apr 5, 2008, at 12:08 PM, Dean Willis wrote too quickly: > > > > So we either change need to change RFC 4474 (by making a signature > > "mean less" OR by allowing one to make a disclaimer on the > signature), > > or we change DTLS-SRTP framework to make it nod depend on > RFC 4474 for > > end-to-end communication of the signature. We do have two drafts > > (Wing, Fischer) that would accomplish this. > > Sorry, I wrote too quickly and left out a bridge-construct, > making the > above more confusing than my usual rambling. And I misphrased a word > or two. Sorry. > > Let's retry: > > So we either change need to change RFC 4474 (by making a signature > "mean less" OR by allowing one to make a disclaimer on the > signature), or we change DTLS-SRTP framework to make it not > depend on > RFC 4474 for end-to-end protection of the fingerprint. > > We also have the issue of detecting fingerprint changes midstream, > meaning that we've had a MITM on the media (that has replaced the > Identity header). We do have two drafts (Wing, Fischer) that would > accomplish this. > > The consequence of the second para above, if I understand it > correctly, is that DTLS-Framework is relying on the RFC 4474 > Identity > header to protect the integrity of the key fingerprint which is > transmitted in the SDP. If the Identity header is UA-signed, > this is > pretty much rock-solid. However, if it is signed by an intermediate > node, then it is possible that the intermediate node has altered the > SDP (and fingerprint), and that it may be colluding in > interception of > the media. And that's just the way RFC 4474 works, so anything that > relies on it (like DTLS-SRTP framework) has this limitation. > > The point is that there may be a possibility to fix all these > flaws in > one pass. I'm not sure what solution would do this, but I have the > feeling there's one out there that we just haven't quite > identified yet. > > The logic goes this way: DTLS-SRTP framework uses RFC 4474 for > integrity protection of the fingerprint. By doing so it inherits > weaknesses of RFC 4474. We have noted two of these as issues: > > 1) RFC 4474 cannot legitimately be used for calls originating on the > PSTN and transiting a gateway to SIP because it lacks a way > to inform > the recipient that the From: field was not actually authenticated by > the authentication service. Otherwise said: as written, 4474 > promises > that the From: field was authenticated by the authentication > service, > and since in this case it wasn't authenticated, the service > shouldn't > be saying it was authenticated. > > 2) RFC 4474 headers may be subject to replacement by intermediates. > While this might be required for certain uses of intermediates (such > as SBCs that replace SDP because they're relaying it), it can > also be > used to insert an intermediary that intercepts the cleartext of the > media (taps the call) without the consent of the endpoints. > > We could work around by fixing these problems independently -- for > example, by adding the From: disclaimer proposed by Adam and the > assorted SBC-traversal and fingerprint preservation/verification > techniques proposed by Dan, Kai, and probably others. > > Or we could fix it by either fundamentally changing RFC 4474, or by > providing a different fingerprint integrity mechanism for DTLS-SRTP > framework and thereby breaking the dependency cycle. [JRE] But isn't this effectively what the Wing and Fischer drafts are doing, i.e., providing a different fingerprint integrity mechanism? They would probably still need something like a PSTN disclaimer solution too. 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 sip-bounces@ietf.org Sat Apr 5 18:45:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDAB3A6C14; Sat, 5 Apr 2008 18:45:08 -0700 (PDT) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B3DF93A69EA; Sat, 5 Apr 2008 18:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080406014501.B3DF93A69EA@core3.amsl.com> Date: Sat, 5 Apr 2008 18:45:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-certs-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 : Certificate Management Service for The Session Initiation Protocol (SIP) Author(s) : C. Jennings, J. Fischl Filename : draft-ietf-sip-certs-06.txt Pages : 30 Date : 2008-04-05 This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-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-certs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-05183612.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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-- From sip-bounces@ietf.org Sat Apr 5 20:05:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70ED3A69AF; Sat, 5 Apr 2008 20:05:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D01F3A699D for ; Sat, 5 Apr 2008 20:05:55 -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 YlnYoauVBbNe for ; Sat, 5 Apr 2008 20:05:54 -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 A13EC3A67E1 for ; Sat, 5 Apr 2008 20:05:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,610,1199682000"; d="scan'208";a="4203520" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2008 23:06:00 -0400 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 m36360w0008086; Sat, 5 Apr 2008 23:06:00 -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 m36360k4026259; Sun, 6 Apr 2008 03:06:00 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); Sat, 5 Apr 2008 23:06:00 -0400 Received: from [10.82.216.180] ([10.82.216.180]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Apr 2008 23:05:59 -0400 Message-ID: <47F83E30.1080004@cisco.com> Date: Sat, 05 Apr 2008 23:06:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <170801c89747$43da95d0$c5f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BC0C@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D095BC0C@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 06 Apr 2008 03:05:59.0941 (UTC) FILETIME=[23F69B50:01C89793] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3249; t=1207451160; x=1208315160; 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]=20Migration=20from=20E.164=20to=2 0email-style=20SIP=20URIs |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=BoCqsdrlGxjZuANU4b+dGnOu9gGlH2+PK5MBKYuv/fM=; b=vvJB+YAaCegZS/WIEDfZrWHVcSLeDuioBkSMw+kwIz/kxVanwPUqUzNEjp WPL6VSdJ4gojoFHvRgoJxwc6x9ftoT2Ut4oVnv9VFp0v6WyvHz5ADlEOk0cS PH+uEDFWDW; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I too think that the idea is interesting - modulo all the loose ends. Paul Elwell, John wrote: > I too think the straw man from Dan is an interesting idea. The > alternative that I think Hadriel is suggesting (email style as a > parameter of the E.164-based SIP URI) would probably not survive any > changes of the E.164-based URI by intermediaries -part of the problem > with E.164-based URIs in practice. > > John > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: 05 April 2008 19:03 >> To: 'Hadriel Kaplan'; sip@ietf.org >> Cc: Elwell, John >> Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs >> >> Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>>> Behalf Of Dan Wing >>>> >>>> Here is a straw-man idea: >>>> >>>> On an outgoing request containing an e164-style URI in the From: >>>> (or PAI, as you prefer), the domain additionally places the user's >>>> email-style URI into a new header (let's call it >> "email-identity"). >>>> It determines the mapping between a user's E.164 URI and email URI >>>> using a flat database (example: +14085551234 -> dwing@cisco.com). >>> Interesting proposal. >>> >>>> This new header is signed along with everything else we like to >>>> sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or >>>> draft-wing-sip-identity-media-02.txt, as you prefer]. >>> You wouldn't be able to use 4474 as is, because it has no way >>> to sign a new header, afaik. >> Right, RFC4474 is not extensible. >> >>> (though I'm all for a 4474bis ;) >>> I know this is only a straw-man and too soon to get into the >>> details, but I can't help myself, so I wonder why you >>> wouldn't just put this email-style URI *inside* the From-URI >>> as an escaped uri or user param. That way it avoids a new >>> header and gets signed by 4474 as is, and really what you're >>> saying is it is an alias property of the From-URI. >> That would look something like: >> >> From: Dan Wing >> >> and the originating domain (cisco.com) would provide strong identity >> over the entire URI, including the E.164 and the email-style portion >> (dwing@cisco.com). >> >> I wanted to avoid signing the E.164 in the From, because we have not >> yet resolved if we can do that in a meaningful way. >> >>>> This provides a backwards-compatible way to migrate to email-style >>>> URIs, and gives us strong identity with those email-style URIs. >>> And lets the UAS offer its user the ability to add both the >>> e164 and email-forms into its contact address book. I'm not >>> sure if that's good or bad, but it's a nice feature. >> Right, but that could also be another attack vector if the >> E.164 is unsigned or only trustable hop-by-hop. >> >> -d >> >> > _______________________________________________ > 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 sip-bounces@ietf.org Sun Apr 6 01:09:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116253A6A87; Sun, 6 Apr 2008 01:09:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481C73A6A87 for ; Sun, 6 Apr 2008 01:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, 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 j3yRg4J7wZIV for ; Sun, 6 Apr 2008 01:09:20 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 121C63A6881 for ; Sun, 6 Apr 2008 01:09:20 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3689RUN029364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 6 Apr 2008 03:09:29 -0500 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D095BC0E@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 6 Apr 2008 03:09:21 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D095BC0E@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 5, 2008, at 2:23 PM, Elwell, John wrote: >> >> On Apr 5, 2008, at 12:08 PM, Dean Willis posited: >>> >> Or we could fix it by either fundamentally changing RFC 4474, or by >> providing a different fingerprint integrity mechanism for DTLS-SRTP >> framework and thereby breaking the dependency cycle. > [JRE] But isn't this effectively what the Wing and Fischer drafts are > doing, i.e., providing a different fingerprint integrity mechanism? > They > would probably still need something like a PSTN disclaimer solution > too. It's a different thing to assert "this media goes with this INVITE" (when you sent both) than it is to assert "The identity we have authenticated as the source of this call is +19725199190" (when you don't really know). The gateway service provider sending the INVITE is certainly responsible for the INVITE, so if they want to cryptographically assert that the RTP they're also responsible for is related to that INVITE, then I don't see that as a liability. Of course if they get it wrong they might have a problem, but that's just a cost of doing business -- and it's a lot easier to make assertions about something you control (the INVITE and the RTP) than about something you don't (the Caller-ID information). In other words, if you're not asserting something as true that you reasonably have cause to expect may not be true, then you probably have no negligence, at least not of that type I've been talking about. Do we need a special disclaimer for populating a From header field with a phone number? As this is the Best Current Practice, and since we've gone to some pains in the industry to say that an unauthenticated From: is pretty much meaningless (see all the 3GPP sample calls from AlienBlaster), my opinion is no, we wouldn't need a disclaimer. As for what the drafts actually do (do either Wing or Fischer completely eliminate a dependency on RFC 4474?), I'll leave that to the working group to figure out. Although it sure looks to me like that's what they're trying to do. :-). -- 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 sip-bounces@ietf.org Sun Apr 6 06:11:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8653B3A6BB1; Sun, 6 Apr 2008 06:11:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8F83A6C0E for ; Sun, 6 Apr 2008 06:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, 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 vRWRzJmE26zO for ; Sun, 6 Apr 2008 06:11:42 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 9289228C194 for ; Sun, 6 Apr 2008 06:11:42 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m36DBgP1014437; Sun, 6 Apr 2008 08:11:42 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Apr 2008 08:11:42 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Apr 2008 15:11:39 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 15:11:39 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001DDFD38@DEEXC1U01.de.lucent.com> In-Reply-To: <47F5F3BF.8070508@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 4474 and SBC traversal Thread-index: AciWNbroyDNl1XJDT3Snho3MJfnNPQA0IZtQ References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net><47F5EBED.60104@gmx.net><198A10EC585EC74687BCA414E2A597180211AC91@MCHP7RDA.ww002.siemens.net> <47F5F3BF.8070508@gmx.net> From: "DRAGE, Keith \(Keith\)" To: "Hannes Tschofenig" , "Fischer, Kai" X-OriginalArrivalTime: 06 Apr 2008 13:11:39.0684 (UTC) FILETIME=[C0235640:01C897E7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This thread was split out by John so it was a separate thread from the E164 discussion. RFC 4474 is a SIP document. It is appropriate for the SIP WG to discuss perceived issues with a SIP WG publication. Regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Friday, April 04, 2008 10:24 AM > To: Fischer, Kai > Cc: sip@ietf.org; Elwell, John > Subject: Re: [Sip] RFC 4474 and SBC traversal > > Hi Kai, > > >> This issue is totally independent from E.164 > >> > > > > Not fully. SBCs may exchange the domain part of the E.164 SIP URI, > > which causes a break of the RFC 4474 signature. With > email-style URIs > > a simple exchange is not possible. > > > This is true but this applies to SIP Identity in general and not to > E.164 number usage with SIP Identity only. > Hence, I would not tie it to this discussion. > > > > >> I don't like the idea of requiring DTLS-SRTP to provide proof of > >> possession of the keying material. > >> > > > > It is also the other way round. If you use DTLS-SRTP to > encrypt RTP, > > the terminating domain is interested where the call originates from > > and in which domain the SRTP connection is terminated. DTLS-SRTP is > > not initially used as mean to establish an identity rather > than as the > > initial aim to encrypt RTP. > > > > I understand the need to know who the end points are. > However, tying DTLS-SRTP is not a good idea since it > a) increases the liklihood that SIP identity never get's > deployed (since it is suddently far more complex than before) > b) SIP identity is used also as a identity mechanism in areas > where no media is exchanged. > > Ciao > Hannes > > > Kai > > > > > >> Ciao > >> Hannes > >> > >> > >> Elwell, John wrote: > >> > >>> SBCs do exist, often for good reasons that Hadriel has > expanded on > >>> already. I firmly believe that DTLS-SRTP will not be > deployable in a > >>> meaningful way without addressing this problem. Concerning > >>> > >> solutions, we > >> > >>> have drafts from Kai and Dan, or perhaps a merger of the > two somehow > >>> would work. It also depends to some extent whether we are > >>> > >> talking only > >> > >>> about email-style URIs or about E.164-based URIs too. > >>> > >>> 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 > >>> > >>> > >> _______________________________________________ > >> 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 sip-bounces@ietf.org Sun Apr 6 08:50:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870EB3A67F9; Sun, 6 Apr 2008 08:50:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD253A6A9D for ; Sun, 6 Apr 2008 08:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 6bwrmQAZn3f7 for ; Sun, 6 Apr 2008 08:50:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C43F33A67CC for ; Sun, 6 Apr 2008 08:50: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.240.5; Sun, 6 Apr 2008 11:50:23 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 6 Apr 2008 11:50:23 -0400 From: Hadriel Kaplan To: "Elwell, John" , Dan Wing , "sip@ietf.org" Date: Sun, 6 Apr 2008 11:48:48 -0400 Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQACKCn/AAA1jG0AACqsAQABMid/A= Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <170801c89747$43da95d0$c5f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BC0C@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D095BC0C@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > > I too think the straw man from Dan is an interesting idea. The > alternative that I think Hadriel is suggesting (email style as a > parameter of the E.164-based SIP URI) would probably not survive any > changes of the E.164-based URI by intermediaries -part of the problem > with E.164-based URIs in practice. I don't disagree with that, obviously, but 4474 breaks in such a case anyway. In other words, I thought he was proposing both the e164 and email-style get signed, but maybe I misunderstood. Regardless, I (maybe naively) hope the changing of From-URI E.164's is a temporary situation, for anyone except those doing end-end relationship-hiding, for whom none of this will apply anyway. -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 sip-bounces@ietf.org Sun Apr 6 09:53:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F041E28C230; Sun, 6 Apr 2008 09:53:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03ED3A6B64 for ; Sun, 6 Apr 2008 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.192 X-Spam-Level: X-Spam-Status: No, score=-5.192 tagged_above=-999 required=5 tests=[AWL=1.407, 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 18TyubXB8mwA for ; Sun, 6 Apr 2008 09:53:51 -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 B69223A6DD7 for ; Sun, 6 Apr 2008 09:53:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,612,1199692800"; d="scan'208";a="10343298" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 Apr 2008 09:54:03 -0700 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 m36Gs20P007798; Sun, 6 Apr 2008 09:54:02 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m36Gs2dN022092; Sun, 6 Apr 2008 16:54:02 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Elwell, John'" , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <170801c89747$43da95d0$c5f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BC0C@GBNTHT12009MSX.gb002.siemens.net> Date: Sun, 6 Apr 2008 09:54:02 -0700 Message-ID: <189f01c89806$d140cdd0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQACKCn/AAA1jG0AACqsAQABMid/AAGwPOEA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1634; t=1207500842; x=1208364842; 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]=20Migration=20from=20E.164=20to=2 0email-style=20SIP=20URIs |Sender:=20; bh=pIX/j3D0IviCH+smM2t8EhL/TQAWpDmbH8s0h3PmGXU=; b=0YBxUAf5WbZE5pw3r5/FLW06sDjrNHG1eZx5OtstDCrooDlZAw0wE5Injg cSi8sjuKCoUDTqfhoyfhzMSs29dUUAIbUXbkdzMAtg9UPOGuY9WGyrp12Bx/ hl/MY3xfEL; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > I too think the straw man from Dan is an interesting idea. The > > alternative that I think Hadriel is suggesting (email style as a > > parameter of the E.164-based SIP URI) would probably not survive any > > changes of the E.164-based URI by intermediaries -part of > > the problem with E.164-based URIs in practice. > > I don't disagree with that, obviously, but 4474 breaks in > such a case anyway. In other words, I thought he was > proposing both the e164 and email-style get signed, but maybe > I misunderstood. The success and value of signing an E.164 is not changed by my proposal; signing the E.164 and solving the 'which domain can sign for an E.164' is orthogonal to my proposal. It is still a useful problem to solve. But, with my proposal if you received a message that had signed both: From: Dan Wing email-id: Dan Wing and the display on the receiving system could display either one, you would probably have it display both. After all, it is hard to know which one will have more meaning or value to the called party. Certainly, the signature generated by the originating domain (cisco.com) has superior security properties compared to the signature generated by an intermediary (att.net). > Regardless, I (maybe naively) hope the > changing of From-URI E.164's is a temporary situation, for > anyone except those doing end-end relationship-hiding, for > whom none of this will apply anyway. -d _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 6 10:41:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A177A3A6A29; Sun, 6 Apr 2008 10:41:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389023A69F7 for ; Sun, 6 Apr 2008 10:41:01 -0700 (PDT) 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_38=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 5su84BgnXRP7 for ; Sun, 6 Apr 2008 10:41:00 -0700 (PDT) Received: from figas.ekabal.com (figas.ekabal.com [204.61.215.10]) by core3.amsl.com (Postfix) with ESMTP id E14973A6B05 for ; Sun, 6 Apr 2008 10:40:59 -0700 (PDT) Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id m36Heqa24148; Sun, 6 Apr 2008 10:40:52 -0700 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D095BC0A@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D095BA9B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF15F0BBB3@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D095BC0A@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <8FC80DFE-05C0-4FEB-8331-E4AD4D43C910@ekabal.com> From: Rohan Mahy Date: Sun, 6 Apr 2008 10:40:53 -0700 To: "Elwell, John" X-Mailer: Apple Mail (2.753) Cc: IETF SIP List , Rohan Mahy , Francois Audet , Cullen Jennings Subject: Re: [Sip] Review of sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi John, Thanks for your detailed comments. I have a few specifics inline. On Apr 5, 2008, at 11:34 AM, Elwell, John wrote: > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Francois Audet >> Sent: 05 April 2008 00:38 >> To: Elwell, John; IETF SIP List; Cullen Jennings; Rohan Mahy >> Subject: Re: [Sip] Review of sip-outbound-13 >> >> Thank you John. >> >> I am OK with your edits 1, 2, 4, 5, 6, 8 and 11. >> >> I don't understand your point about 3. > [JRE] It says that there is a case where a UA might not want to use > the > sip.instance media feature tag, yet that tag is essential for > outbound. > Is it saying that in such a case the UA should not use sip-outbound? The text is explaining under what circumstances a UA would decide not to include +sip.instance in (any kind of) request. Outbound registration requests certainly will not work if the UA leaves this parameter out. I believe some of this is discussed in GRUU, but a complete discussion of this topic is certainly out of scope of the outbound spec. [snip] >> For 9, I'll have to defer to Rohan and Cullen because I find it >> confusing too. > [JRE]Yes, and that is why I wasn't able to propose new words. We provided SHOULD level recommendations for the timers in this section. If the UA has a good reason to do something else it MAY. The timers, the random spacing or lack thereof, even the backoff algorithm, they all could be configurable. This is all we can say and all we should say on the matter. I don't want to clutter up the text with a lot of text explaining things that UAs could do that we don't recommend. I am certainly open to reading new proposed text, but I think the current text tells implementors what they should do pretty clearly. >> For 10, I believe that it would work if an upstream evil B2BUA does >> topology hiding since the proxy uses the Via in the Request >> and not the >> Path in the response. > [JRE] What I meant was, if a proxy receives a REGISTER request with > only > a single element in the Via header field, how does it know whether the > request came from a UA or from a topology-hiding B2BUA? This is > probably > an unlikely situation for a REGISTER request (UA -> B2BUA -> > proxy), but > can we rule it out? A B2BUA has to behave as a legal UA. The B2BUA will either advertise support for the outbound option-tag or not. If it does not support outbound, the registrar won't try an outbound-style registration and the original UAC will discover that from the response (no problem). If the B2BUA wants to support outbound, it will need to follow the spec. If the B2BUA wants to simulate an outbound-aware edge proxy, and also support topology hiding, it will need to insure that there are at least two Via headers in the request. It could easily do this by adding itself twice to the Via header field (possible, but not our problem). Even if the B2BUA is truly broken and blindly copies option tags from the original UAC to the registrar (DON"T DO THIS KIDS!!!), it is unlikely that the B2BUA will know about and insert the 'ob' parameter in the first Path header. The next hop will think the first edge proxy did not support outbound and carry on with non-outbound registration. thanks, -rohan >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>> Behalf Of Elwell, John >>> Sent: Friday, April 04, 2008 07:01 >>> To: IETF SIP List >>> Subject: [Sip] Review of sip-outbound-13 >>> >>> I think this is ready to go if the following minor comments are >>> addressed: >>> >>> 1. "This >>> specification also defines multiple keep alive schemes." >>> Change "multiple" to "two". >>> >>> 2. "A Flow is a network protocol layer (layer 4) association" >>> Change "network" to "transport". >>> >>> 3. "One case where a UA may not want to include >>> the sip.instance media feature tag at all is when it is making an >>> anonymous request or some other privacy concern requires >>> that the UA >>> not reveal its identity." >>> There is no statement about what should be done in this case. >>> >>> 4. "These registration requests include a distinct reg-id >> parameter in >>> the Contact header field." >>> I think some normative language is needed here. Perhaps change to: >>> "For registration requests in accordance with outbound >>> behaviour, the UA MUST include a distinct reg-id parameter in >>> the Contact header field." >>> >>> 5. "the target first >>> hop SIP note" >>> Change "note" to "node". >>> >>> 6. "as this is already allowed by >>> [RFC3261]. Section 7.5, however a UA that did not register using >>> outbound registration" >>> I think this should say >>> "as this is already allowed by >>> [RFC3261] section 7.5. However, a UA that did not register using >>> outbound registration" >>> >>> 7. "Configuration indicating keepalive support for a specific >>> target is >>> considered an explicit indication. If these conditions are >>> satisfied, the UA sends its keepalives according to the same >>> guidelines described in the rest of this section as UAs which >>> register." >>> I don't understand the meaning of the first sentence. Is it >>> trying to say that configuration is an alternative way of >>> determining support for keepalive? >>> >>> 8. "For devices where power is >>> not a significant concern, the UA SHOULD select a random number >>> between 95 and 120 seconds between keepalives. When >>> battery power is >>> a concern, the UA SHOULD select a random number between >> 672 and 840 >>> seconds (14 minutes). These times MAY be configurable." >>> The last sentence seems to undermine the previous SHOULD >>> strength statements. Also, what exactly can be configurable - >>> just the upper and lower bounds? I don't think, for example, >>> we are proposing to allow somebody to configure say 180 >>> seconds as both upper and lower bounds (not a range, no >>> randomisation). So I think it is the bounds that can be >>> configurable, and even then the 20% difference must be maintained. >>> Perhaps it should say something like: >>> "The UA MUST select a random number between a fixed or >>> configurable upper bound and a lower bound, where the lower >>> bound is 20% less then the upper bound. The fixed upper bound >>> or the default configurable upper bound SHOULD be 120 seconds >>> (95 seconds lower bound) where battery power is not a concern >>> and 840 seconds (672 seconds lower bound) where battery power >>> is a concern." >>> >>> 9. "The delay time is computed by selecting a uniform random >>> time between >>> 50 and 100 percent of the wait time. The UA MUST wait for >>> the value >>> of the delay time before trying another registration to >> form a new >>> flow for that URI." >>> I find this a little confusing. The several paragraphs before >>> that have all talked about wait time, or time to wait, which >>> suggests that that is how long you wait before trying >>> registration again. Then we suddenly have this "delay time" >>> introduced, and it says that "UA MUST wait for the value of >>> the delay time before trying another registration". It might >>> be better to introduce the concept of delay time and wait >>> time up front. Furthermore, it is not clear whether the delay >>> time (between 50 and 100 percent of the wait time) starts >>> when the wait time starts or when the wait time finishes. I >>> think the examples given in the succeeding paragraph suggest >>> it is the former interpretation. In any case, it needs to be >>> clarified. >>> >>> 10. "The Edge Proxy can determine >>> if it is the first hop by examining the Via header field." >>> Does this still work in the case of topology hiding by an >>> upstream entity? >>> >>> 11. "When a '+sip.instance' media feature parameter is present in a >>> Contact header field of a REGISTER request (after the >>> Contact header >>> validation as described above), the corresponding binding >>> is between >>> an AOR and the combination of the instance-id (from the >>> +sip.instance >>> media feature parameter) and the value of reg-id >> parameter if it is >>> present." >>> I think the normative statements that follow are only >>> concerned with the case where reg-id is present, so I think >>> it should be changed to: >>> "When a '+sip.instance' media feature parameter and a reg-id >>> parameter are present in a >>> Contact header field of a REGISTER request (after the >>> Contact header >>> validation as described above), the corresponding binding >>> is between >>> an AOR and the combination of the instance-id (from the >>> +sip.instance >>> media feature parameter) and the value of reg-id parameter." >>> >>> 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 >>> >> _______________________________________________ >> 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 sip-bounces@ietf.org Sun Apr 6 17:22:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1153A6D50; Sun, 6 Apr 2008 17:22:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E353A6D92 for ; Sun, 6 Apr 2008 17:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.574, 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 u-iohbK+rJcw for ; Sun, 6 Apr 2008 17:22:28 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id E3B663A6D50 for ; Sun, 6 Apr 2008 17:22:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m370MZZ23652; Mon, 7 Apr 2008 00:22:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 19:22:34 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF15F0BE4F@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D095BC0A@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of sip-outbound-13 Thread-Index: AciWXEvN4G0kcc5IT3CC5/sITATquQAUAFLgACdyExAAPq4xcA== References: <0D5F89FAC29E2C41B98A6A762007F5D095BA9B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF15F0BBB3@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D095BC0A@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "IETF SIP List" , "Cullen Jennings" , "Rohan Mahy" Subject: Re: [Sip] Review of sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > For 10, I believe that it would work if an upstream evil B2BUA does > > topology hiding since the proxy uses the Via in the Request and not > > the Path in the response. > [JRE] What I meant was, if a proxy receives a REGISTER > request with only a single element in the Via header field, > how does it know whether the request came from a UA or from a > topology-hiding B2BUA? This is probably an unlikely situation > for a REGISTER request (UA -> B2BUA -> proxy), but can we rule it out? Ah, "upstream" vis-a-vis the UAC, as opposed to "upstream" vis-a-vis the outbound proxy. Of course a B2BUA can screw things up. If one decides to have a B2BUA between the Outbound proxy and the UAC (which seems to be a weird place for putting it), then obviously the B2BUA would have to comply to outbound for outbound to work. I would think that normally, the B2BUA would be on the other side or the outbound proxy, or even co-located with it. There are plenty of opportunities for a B2BUA to mess things up. I don't believe it would make sense to say anything about it. _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 6 20:17:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC6B3A6A91; Sun, 6 Apr 2008 20:17:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90ED03A6A91 for ; Sun, 6 Apr 2008 20:17:09 -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 zGarBRjMpdxf for ; Sun, 6 Apr 2008 20:17:08 -0700 (PDT) Received: from dlxapp2.laszlomail.com (dlxapp2.laszlomail.com [168.75.100.14]) by core3.amsl.com (Postfix) with ESMTP id 8A89D3A698B for ; Sun, 6 Apr 2008 20:17:08 -0700 (PDT) Received: from dlxapp2 (localhost [127.0.0.1]) by dlxapp2.laszlomail.com (8.14.0/8.14.0) with ESMTP id m373HKu0026665; Sun, 6 Apr 2008 20:17:20 -0700 Received: from [64.104.174.140] by gowebtop.com with HTTP; Sun, 6 Apr 2008 20:17:17 -0700 Date: Sun, 6 Apr 2008 20:17:17 -0700 (PDT) From: Rockson Zhengyu Li To: gaurav khurana , sip@ietf.org Message-ID: <602737813.404121207538240786.JavaMail.lzyiii@localhost> MIME-Version: 1.0 User-Agent: Laszlo Mail 2 X-Originating-IP: [64.104.174.140] Subject: Re: [Sip] Doubt in Invite client transaction - proceeding state X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1612752709==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1612752709== Content-Type: multipart/alternative; boundary="----=_Part_9617_1706834301.1207538237460" ------=_Part_9617_1706834301.1207538237460 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Gaurav, I think it's totally up to TU to determine to cancel the call or not in=20 early dialog stage, you cannot mandate all UA cancel the in call in 5 mins, can you?? -Rockson On Fri, Apr 4, 2008 at 1:52 AM, gaurav khurana wrote: Hi, I looked into the previous threads too but couldn't clarify my doubt, so=20 posting the question again. My question is that how long will the client transaction be alive once=20 we enter in proceeding state. Previous threads suggest transaction will terminate when timer B, i.e.=20 64*T1 expires. But, what I see in RFC3261 - 17.1.1.2 fig. 5 (INVITE=20 Client transaction) that timer B fires only in Calling state. There's no=20 timer shown for proceeding state. Does it mean that in proceeding state, the transaction will not=20 terminate until the caller disconnects the call manually? GAURAV KHURANA # 91-9886646104 ___________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster=20 Total Access=20 =20 , No Cost. ------------------------------ _______________________________________________ Sip mailing list=C2=A0 https://www.ietf.org/mailman/listinfo/sip=20 =C2=A0=20 This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu=20 =C2=A0=20 =C2=A0for questions on current si= p Use sipping@ietf.org =C2=A0=20 =C2=A0for new developments on the application of= =20 sip ------=_Part_9617_1706834301.1207538237460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Gaurav,

I think it's totally up to TU to determine to = cancel the call or not in early dialog stage,
you cannot mandate all UA cancel the in call in 5 mins, can y= ou??

-Rock= son


On Fri, Apr 4, 2008 at  1:52 AM, gaurav khurana wrote= :

Hi,

I looked int= o the previous threads too but couldn't clarify my doubt, so posting the qu= estion again.

My question is that how long will the client transaction be alive on= ce we enter in proceeding state.

Previous threads suggest transaction will termina= te when timer B, i.e. 64*T1 expires. But, what I see in RFC3261 - 17.1.1.2 = fig. 5 (INVITE Client transaction) that timer B fires only in Calling state= . There's no timer shown for proceeding state.

=
Does it mean that in proceeding state= , the transaction will not terminate until the caller disconnects the call = manually?
 
GA= URAV KHURANA
# 91-9886646104



<= FONT FACE=3D"Verdana" SIZE=3D"3" COLOR=3D"#000000" LETTERSPACING=3D"0" KERN= ING=3D"0">___________________________________

<= FONT FACE=3D"Verdana" SIZE=3D"3" COLOR=3D"#000000" LETTERSPACING=3D"0" KERN= ING=3D"0">You rock. That's why Blockbuster's offering you one month of Blockbuste= r Total Access, No Cost.
--------------------= ----------

_______________________________________________
This list is for NEW de= velopment of the core SIP Protocol
Use sip-implementors@cs.columbia.edu= =C2=A0=C2=A0for que= stions on current sip
Use sipp= ing@ietf.org=C2=A0=C2=A0for new developments on the application of sip<= /FONT>
------=_Part_9617_1706834301.1207538237460-- --===============1612752709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1612752709==-- From sip-bounces@ietf.org Mon Apr 7 01:24:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1008B3A6815; Mon, 7 Apr 2008 01:24:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB233A6815 for ; Mon, 7 Apr 2008 01:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=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 oxCIGUSj2fYe for ; Mon, 7 Apr 2008 01:24:49 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id C02B23A6D04 for ; Mon, 7 Apr 2008 01:24:48 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id m378OrA5029885; Mon, 7 Apr 2008 10:24:53 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m378OrnN020536; Mon, 7 Apr 2008 10:24:53 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 10:24:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 10:24:49 +0200 Message-ID: <198A10EC585EC74687BCA414E2A597180211ADCC@MCHP7RDA.ww002.siemens.net> In-Reply-To: <155b01c896af$f57ca910$c5f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQAHbjyyA= References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> From: "Fischer, Kai" To: "Dan Wing" , X-OriginalArrivalTime: 07 Apr 2008 08:24:52.0702 (UTC) FILETIME=[DA63FFE0:01C89888] Cc: "Elwell, John" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org That's an interesting proposal. I didn't get if your intention is to sign both headers (From header with E.164 and 'email-identity' header) or only the email-based one. In case signing both, an identity binding between the E.164 SIP URI and the email based one is created, which results into the other problems with RFC 4474 discussed in the two mail threads 'RFC 4474 and PSTN' / 'RFC 4474 and SBC traversal'. In case signing only the 'email-identity' header, does this mean that email-like SIP URIs are only provided in the new header field (because they are signed) and not in the From header in the long term (after migration ;-)). Kai > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Friday, April 04, 2008 1:19 AM > > To: sip@ietf.org > > Subject: [Sip] Migration from E.164 to email-style SIP URIs > > > > On this thread I would like to explore what can be done in terms of > > avoiding the issues concerned with RFC 4474 and E.164-based > > SIP URIs by > > migration towards the use of email-style URIs. > > E.164-based URIs will still be needed, particularly for interworking > > with PSTN but also in those SIP environments where E.164 numbers are > > more easily handled (e.g., phones with number-based user > interfaces). > > But perhaps we can explore more the possibility of using > the two forms > > in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and > > email-style in From. I know Dan has an interesting straw man on > > this topic, which I will allow him to present himself. > > One idea that someone (Jonathan?) posted to SIP, about a week > before the Philadelphia meeting, was to mix both e.164 and email > style identifiers. In that email, it was suggested to use a > separator between the two (a "*", as I recall). > > I have been thinking about using both E.164-style and email-style > URIs in parallel, for two reasons: > > 1. provide a migration path from E.164-style URIs to email-style > URIs > 2. allow stronger identity to be asserted for email-style URIs > > > Here is a straw-man idea: > > On an outgoing request containing an e164-style URI in the From: > (or PAI, as you prefer), the domain additionally places the user's > email-style URI into a new header (let's call it "email-identity"). > It determines the mapping between a user's E.164 URI and email URI > using a flat database (example: +14085551234 -> dwing@cisco.com). > > This new header is signed along with everything else we like to > sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or > draft-wing-sip-identity-media-02.txt, as you prefer]. > > If the receiving domain understands email-identity, it validates > the claimed identity, and it presents the email-style URI to the > called party. Thus, the E.164 in the From: (or in the PAI) is > essentially ignored. If the receiving domain does not understand > email-identity, the receiving domain does not enjoy any benefits > of the email-identity header and does not experience any harm from > the email-identity header. > > This provides a backwards-compatible way to migrate to email-style > URIs, and gives us strong identity with those email-style URIs. > > -d > > _______________________________________________ > 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 sip-bounces@ietf.org Mon Apr 7 07:06:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDBB3A6BC8; Mon, 7 Apr 2008 07:06:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF273A6E85 for ; Mon, 7 Apr 2008 07:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.059 X-Spam-Level: X-Spam-Status: No, score=-4.059 tagged_above=-999 required=5 tests=[AWL=2.190, 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 Cfg5RO1p-oLJ for ; Mon, 7 Apr 2008 07:06:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B004C3A6A90 for ; Mon, 7 Apr 2008 07:05:59 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D94162012C; Mon, 7 Apr 2008 16:06:11 +0200 (CEST) X-AuditID: c1b4fb3e-ab993bb000004ec0-a6-47fa2a539c44 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CDDE220117; Mon, 7 Apr 2008 16:06:11 +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, 7 Apr 2008 16:06:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 16:06:10 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" thread-index: AciWfx8oPelAn/qLR7y2eUSApkbWoQCOQIlg References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com><1ECE0EB50388174!790F9694F7752! 2 CCF15E B7 F8A@zrc2h xm0.corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com><7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com><47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> From: "Christer Holmberg" To: "Dean Willis" , "Hans Erik van Elburg" X-OriginalArrivalTime: 07 Apr 2008 14:06:11.0615 (UTC) FILETIME=[88C622F0:01C898B8] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Dean, >>Params only seems to tackle the parameter loss issue, and it seems >>further to solve a different problem alltogether i.e. how to get >>parameters from the caller to the callee. > >Well, that WAS the original goal of US-Loose-Route, and is the thing we have a chartered milestone for: > >From our charter: >Feb 2008 >Delivering request-URI and parameters to UAS via proxy to IESG (PS) I believe the UA loose mechanism works in the same way as the Target mechanism in that sense: if a retarget occurs, the Request-URI is overwritten, and the R-URI carries the current target. 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 sip-bounces@ietf.org Mon Apr 7 09:17:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1EE28C46C; Mon, 7 Apr 2008 09:17:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7FD28C46C for ; Mon, 7 Apr 2008 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_38=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 Z7VoFzMpGR1H for ; Mon, 7 Apr 2008 09:17:40 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id CF0C328C424 for ; Mon, 7 Apr 2008 09:17:39 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYY00H0JQK48E@siemenscomms.co.uk> for sip@ietf.org; Mon, 07 Apr 2008 17:16:57 +0100 (BST) Date: Mon, 07 Apr 2008 14:53:47 +0100 From: "Elwell, John" In-reply-to: <8FC80DFE-05C0-4FEB-8331-E4AD4D43C910@ekabal.com> To: Rohan Mahy Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095BFB7@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Review of sip-outbound-13 Thread-Index: AciYDXZTiMxPXPEuS56oV2wntLmS7gAqUD2w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D095BA9B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF15F0BBB3@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D095BC0A@GBNTHT12009MSX.gb002.siemens.net> <8FC80DFE-05C0-4FEB-8331-E4AD4D43C910@ekabal.com> Cc: IETF SIP List , Cullen Jennings , Francois Audet Subject: Re: [Sip] Review of sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Rohan, OK, I can accept the explanations you give. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Rohan Mahy > Sent: 06 April 2008 18:41 > To: Elwell, John > Cc: IETF SIP List; Rohan Mahy; Francois Audet; Cullen Jennings > Subject: Re: [Sip] Review of sip-outbound-13 > > Hi John, > > Thanks for your detailed comments. I have a few specifics inline. > > On Apr 5, 2008, at 11:34 AM, Elwell, John wrote: > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >> Behalf Of Francois Audet > >> Sent: 05 April 2008 00:38 > >> To: Elwell, John; IETF SIP List; Cullen Jennings; Rohan Mahy > >> Subject: Re: [Sip] Review of sip-outbound-13 > >> > >> Thank you John. > >> > >> I am OK with your edits 1, 2, 4, 5, 6, 8 and 11. > >> > >> I don't understand your point about 3. > > [JRE] It says that there is a case where a UA might not > want to use > > the > > sip.instance media feature tag, yet that tag is essential for > > outbound. > > Is it saying that in such a case the UA should not use sip-outbound? > The text is explaining under what circumstances a UA would > decide not > to include +sip.instance in (any kind of) request. Outbound > registration requests certainly will not work if the UA leaves this > parameter out. I believe some of this is discussed in GRUU, but a > complete discussion of this topic is certainly out of scope of the > outbound spec. > > [snip] > >> For 9, I'll have to defer to Rohan and Cullen because I find it > >> confusing too. > > [JRE]Yes, and that is why I wasn't able to propose new words. > > We provided SHOULD level recommendations for the timers in this > section. If the UA has a good reason to do something else it MAY. > The timers, the random spacing or lack thereof, even the backoff > algorithm, they all could be configurable. This is all we can say > and all we should say on the matter. I don't want to clutter up the > text with a lot of text explaining things that UAs could do that we > don't recommend. > > I am certainly open to reading new proposed text, but I think the > current text tells implementors what they should do pretty clearly. > > >> For 10, I believe that it would work if an upstream evil B2BUA does > >> topology hiding since the proxy uses the Via in the Request > >> and not the > >> Path in the response. > > [JRE] What I meant was, if a proxy receives a REGISTER > request with > > only > > a single element in the Via header field, how does it know > whether the > > request came from a UA or from a topology-hiding B2BUA? This is > > probably > > an unlikely situation for a REGISTER request (UA -> B2BUA -> > > proxy), but > > can we rule it out? > > A B2BUA has to behave as a legal UA. The B2BUA will either > advertise > support for the outbound option-tag or not. If it does not support > outbound, the registrar won't try an outbound-style registration and > the original UAC will discover that from the response (no problem). > If the B2BUA wants to support outbound, it will need to follow the > spec. If the B2BUA wants to simulate an outbound-aware edge proxy, > and also support topology hiding, it will need to insure that there > are at least two Via headers in the request. It could easily do this > by adding itself twice to the Via header field (possible, but > not our > problem). > > Even if the B2BUA is truly broken and blindly copies option > tags from > the original UAC to the registrar (DON"T DO THIS KIDS!!!), it is > unlikely that the B2BUA will know about and insert the 'ob' > parameter > in the first Path header. The next hop will think the first edge > proxy did not support outbound and carry on with non-outbound > registration. > > thanks, > -rohan > > > >>> -----Original Message----- > >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >>> Behalf Of Elwell, John > >>> Sent: Friday, April 04, 2008 07:01 > >>> To: IETF SIP List > >>> Subject: [Sip] Review of sip-outbound-13 > >>> > >>> I think this is ready to go if the following minor comments are > >>> addressed: > >>> > >>> 1. "This > >>> specification also defines multiple keep alive schemes." > >>> Change "multiple" to "two". > >>> > >>> 2. "A Flow is a network protocol layer (layer 4) association" > >>> Change "network" to "transport". > >>> > >>> 3. "One case where a UA may not want to include > >>> the sip.instance media feature tag at all is when it > is making an > >>> anonymous request or some other privacy concern requires > >>> that the UA > >>> not reveal its identity." > >>> There is no statement about what should be done in this case. > >>> > >>> 4. "These registration requests include a distinct reg-id > >> parameter in > >>> the Contact header field." > >>> I think some normative language is needed here. Perhaps change to: > >>> "For registration requests in accordance with outbound > >>> behaviour, the UA MUST include a distinct reg-id parameter in > >>> the Contact header field." > >>> > >>> 5. "the target first > >>> hop SIP note" > >>> Change "note" to "node". > >>> > >>> 6. "as this is already allowed by > >>> [RFC3261]. Section 7.5, however a UA that did not > register using > >>> outbound registration" > >>> I think this should say > >>> "as this is already allowed by > >>> [RFC3261] section 7.5. However, a UA that did not > register using > >>> outbound registration" > >>> > >>> 7. "Configuration indicating keepalive support for a specific > >>> target is > >>> considered an explicit indication. If these conditions are > >>> satisfied, the UA sends its keepalives according to the same > >>> guidelines described in the rest of this section as UAs which > >>> register." > >>> I don't understand the meaning of the first sentence. Is it > >>> trying to say that configuration is an alternative way of > >>> determining support for keepalive? > >>> > >>> 8. "For devices where power is > >>> not a significant concern, the UA SHOULD select a random number > >>> between 95 and 120 seconds between keepalives. When > >>> battery power is > >>> a concern, the UA SHOULD select a random number between > >> 672 and 840 > >>> seconds (14 minutes). These times MAY be configurable." > >>> The last sentence seems to undermine the previous SHOULD > >>> strength statements. Also, what exactly can be configurable - > >>> just the upper and lower bounds? I don't think, for example, > >>> we are proposing to allow somebody to configure say 180 > >>> seconds as both upper and lower bounds (not a range, no > >>> randomisation). So I think it is the bounds that can be > >>> configurable, and even then the 20% difference must be maintained. > >>> Perhaps it should say something like: > >>> "The UA MUST select a random number between a fixed or > >>> configurable upper bound and a lower bound, where the lower > >>> bound is 20% less then the upper bound. The fixed upper bound > >>> or the default configurable upper bound SHOULD be 120 seconds > >>> (95 seconds lower bound) where battery power is not a concern > >>> and 840 seconds (672 seconds lower bound) where battery power > >>> is a concern." > >>> > >>> 9. "The delay time is computed by selecting a uniform random > >>> time between > >>> 50 and 100 percent of the wait time. The UA MUST wait for > >>> the value > >>> of the delay time before trying another registration to > >> form a new > >>> flow for that URI." > >>> I find this a little confusing. The several paragraphs before > >>> that have all talked about wait time, or time to wait, which > >>> suggests that that is how long you wait before trying > >>> registration again. Then we suddenly have this "delay time" > >>> introduced, and it says that "UA MUST wait for the value of > >>> the delay time before trying another registration". It might > >>> be better to introduce the concept of delay time and wait > >>> time up front. Furthermore, it is not clear whether the delay > >>> time (between 50 and 100 percent of the wait time) starts > >>> when the wait time starts or when the wait time finishes. I > >>> think the examples given in the succeeding paragraph suggest > >>> it is the former interpretation. In any case, it needs to be > >>> clarified. > >>> > >>> 10. "The Edge Proxy can determine > >>> if it is the first hop by examining the Via header field." > >>> Does this still work in the case of topology hiding by an > >>> upstream entity? > >>> > >>> 11. "When a '+sip.instance' media feature parameter is > present in a > >>> Contact header field of a REGISTER request (after the > >>> Contact header > >>> validation as described above), the corresponding binding > >>> is between > >>> an AOR and the combination of the instance-id (from the > >>> +sip.instance > >>> media feature parameter) and the value of reg-id > >> parameter if it is > >>> present." > >>> I think the normative statements that follow are only > >>> concerned with the case where reg-id is present, so I think > >>> it should be changed to: > >>> "When a '+sip.instance' media feature parameter and a reg-id > >>> parameter are present in a > >>> Contact header field of a REGISTER request (after the > >>> Contact header > >>> validation as described above), the corresponding binding > >>> is between > >>> an AOR and the combination of the instance-id (from the > >>> +sip.instance > >>> media feature parameter) and the value of reg-id parameter." > >>> > >>> 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 > >>> > >> _______________________________________________ > >> 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 sip-bounces@ietf.org Mon Apr 7 09:28:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AB328C23B; Mon, 7 Apr 2008 09:28:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E621D28C23B for ; Mon, 7 Apr 2008 09:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.244 X-Spam-Level: X-Spam-Status: No, score=-5.244 tagged_above=-999 required=5 tests=[AWL=1.355, 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 uXjd6ztjZjE2 for ; Mon, 7 Apr 2008 09:28:50 -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 A643D28C262 for ; Mon, 7 Apr 2008 09:28:50 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Apr 2008 09:29:04 -0700 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 m37GT4BM002333; Mon, 7 Apr 2008 09:29:04 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m37GT3ZH023612; Mon, 7 Apr 2008 16:29:04 GMT From: "Dan Wing" To: "'Fischer, Kai'" , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <198A10EC585EC74687BCA414E2A597180211ADCC@MCHP7RDA.ww002.siemens.net> Date: Mon, 7 Apr 2008 09:29:04 -0700 Message-ID: <1e3401c898cc$7ef98050$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <198A10EC585EC74687BCA414E2A597180211ADCC@MCHP7RDA.ww002.siemens.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQAHbjyyAAEWWwAA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4791; t=1207585744; x=1208449744; 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]=20Migration=20from=20E.164=20to=2 0email-style=20SIP=20URIs |Sender:=20; bh=W0TkJ+Tw1DPtzRrrdi5lz24+IeBKEnsjzeXFTV9Ux+8=; b=gSGS6oC7GzzU7vO22GrqwKQPJl3i/K4P+Lk+ggiVf3UY8RkYH1S0uowXHX XBI5LKRI9wjnecG6YthwePtCh/tTUAX+oYl8mXZoT2PoUEShjjjQRb2v3c/K t2M/r/qMty; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "'Elwell, John'" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Fischer, Kai [mailto:kai.fischer@siemens.com] > Sent: Monday, April 07, 2008 1:25 AM > To: Dan Wing; sip@ietf.org > Cc: Elwell, John > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > That's an interesting proposal. I didn't get if your intention is to > sign both headers (From header with E.164 and 'email-identity' header) > or only the email-based one. For the purposes of my straw-man, you can assume (a) we have resolved all problems with signing E.164s in From, or you can assume (b) we have not resolved any problem with signing E.164 in From -- either way, my proposal still provides benefit: the called party can use the email- style address to establish end-to-end identity with the calling party, and can use that to establish an end-to-end SRTP session (using a mechanism similar to your draft or the Wing/Kaplan draft). > In case signing both, an identity binding between the E.164 > SIP URI and > the email based one is created, which results into the other problems > with RFC 4474 discussed in the two mail threads 'RFC 4474 and PSTN' / > 'RFC 4474 and SBC traversal'. > > In case signing only the 'email-identity' header, does this mean that > email-like SIP URIs are only provided in the new header field (because > they are signed) and not in the From header in the long term (after > migration ;-)). Once both endpoints know they can use email-style URIs, they could put the same information into the From and into the Email-Identity headers -- or sign the From and ignore the email-identity. -d > Kai > > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Friday, April 04, 2008 1:19 AM > > > To: sip@ietf.org > > > Subject: [Sip] Migration from E.164 to email-style SIP URIs > > > > > > On this thread I would like to explore what can be done > in terms of > > > avoiding the issues concerned with RFC 4474 and E.164-based > > > SIP URIs by > > > migration towards the use of email-style URIs. > > > E.164-based URIs will still be needed, particularly for > interworking > > > with PSTN but also in those SIP environments where E.164 > numbers are > > > more easily handled (e.g., phones with number-based user > > interfaces). > > > But perhaps we can explore more the possibility of using > > the two forms > > > in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and > > > email-style in From. I know Dan has an interesting straw man on > > > this topic, which I will allow him to present himself. > > > > One idea that someone (Jonathan?) posted to SIP, about a week > > before the Philadelphia meeting, was to mix both e.164 and email > > style identifiers. In that email, it was suggested to use a > > separator between the two (a "*", as I recall). > > > > I have been thinking about using both E.164-style and email-style > > URIs in parallel, for two reasons: > > > > 1. provide a migration path from E.164-style URIs to email-style > > URIs > > 2. allow stronger identity to be asserted for email-style URIs > > > > > > Here is a straw-man idea: > > > > On an outgoing request containing an e164-style URI in the From: > > (or PAI, as you prefer), the domain additionally places the user's > > email-style URI into a new header (let's call it "email-identity"). > > It determines the mapping between a user's E.164 URI and email URI > > using a flat database (example: +14085551234 -> dwing@cisco.com). > > > > This new header is signed along with everything else we like to > > sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or > > draft-wing-sip-identity-media-02.txt, as you prefer]. > > > > If the receiving domain understands email-identity, it validates > > the claimed identity, and it presents the email-style URI to the > > called party. Thus, the E.164 in the From: (or in the PAI) is > > essentially ignored. If the receiving domain does not understand > > email-identity, the receiving domain does not enjoy any benefits > > of the email-identity header and does not experience any harm from > > the email-identity header. > > > > This provides a backwards-compatible way to migrate to email-style > > URIs, and gives us strong identity with those email-style URIs. > > > > -d > > > > _______________________________________________ > > 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 sip-bounces@ietf.org Mon Apr 7 13:16:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4B93A6CF5; Mon, 7 Apr 2008 13:16:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD00A3A67A6 for ; Mon, 7 Apr 2008 13:16:38 -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=[AWL=0.335, 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 CJnZY-DvKYlg for ; Mon, 7 Apr 2008 13:16:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E366C3A6D95 for ; Mon, 7 Apr 2008 13:16:33 -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.240.5; Mon, 7 Apr 2008 16:16:20 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 7 Apr 2008 16:16:20 -0400 From: Hadriel Kaplan To: "sip@ietf.org" Date: Mon, 7 Apr 2008 16:15:42 -0400 Thread-Topic: Comments on sip-outbound-13 Thread-Index: AciY7Cdig1p4Qif2QoqKRaBTu8LPnw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Sip] Comments on sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Howdy, I have the following comments, mostly editorial nits, on the latest draft. I think these do not overlap with John Elwell's. General comment: I think it's in great shape, and very thorough. 1) I do not see any discussion of RFC 3680 SIP Registration Event Package. I assume that each registered flow's contact is treated as a unique contact in all regards to RFC 3680, right? And the reg-id and instance would be saved in the "unknown-param" XML element of the contact element, making those unique (vs. being unique contact URI's). I think maybe that should be clarified somewhere, as rfc3680 is not uncommon. 2) If a Register is 3xx redirected, does the new retargeted Register use the same reg-id, even though it's a different "flow"? (I assume so) I ask because some people use 3xx for Registers to load-balance or perform anycasting. It may be good to add this to end of section 4.2.1. 3) Page 5: Reg-id: "When a UA registers multiple times, each concurrent registration gets a unique reg-id value." Replace with: "When a UA registers multiple times, each for a different flow, each concurrent registration gets a unique reg-id value." 4) Page 12, Section 3.5.2: The proxy or registrar acts as a Session Traversal Utilities for NAT (STUN) [I-D.ietf-behave-rfc3489bis] server on the SIP signaling port. Insert "limited" before "Session". (ie, it is not a full STUN server) 5) Page 12, Section 3.5.2: Note: The STUN mechanism is very robust and allows the detection of a changed IP address. Add "and port" at the end. 6) Page 12, Section 4.1: "It also provides an easy way to guarantee uniqueness within the AOR." I'm a bit confused by that, because I don't believe we're saying one UA instance only ever represents one AoR. (ie, multiple AoR's registered on the same UA will have the same registered contact instance) Recommend removing or rewording. 7) Page 14, Section 4.2.1: For each outbound proxy URI in the set, the UAC SHOULD send a REGISTER request using this URI as the default outbound proxy. (The UA could limit the number of flows formed to conserve battery power, for example). The logic flow is awkward there. Change second sentence to start with "Alternatively, the UAC could...". 8) Page 15, Section 4.2.1: If the registering UA receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MAY re-attempt registration without an outbound proxy (subject to local policy at the client). I think what you mean at the end is instead "without using the outbound mechanism"? 9) Page 16, Section 4.3: ... For TLS protocols, there MUST also be a match between the host production in the next hop and one of the URIs contained in the subjectAltName in the peer certificate. s/production in/resolved for/ 10) Page 18, Section 4.4.1: A User Agent that forms flows, checks if the configured URI to which the UA is connecting resolves to a stream-based transport (ex: TCP and TLS over TCP). That's confusing, because double-CRLF is used for connection-oriented transports period, not only stream-based ones (ie, also used for SCTP). And no statement is made about why it checks for stream-based, so I recommend removing it or clarifying. -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 sip-bounces@ietf.org Mon Apr 7 14:49:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD943A6ED6; Mon, 7 Apr 2008 14:49:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0DF3A6ED8 for ; Mon, 7 Apr 2008 14:49:39 -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 5LA82dDvqWYG for ; Mon, 7 Apr 2008 14:49:38 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 24E673A6ED0 for ; Mon, 7 Apr 2008 14:49:37 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id u2so32535uge.46 for ; Mon, 07 Apr 2008 14:49:51 -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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=tcS0dDnY4239cEqYz10VAVbKqbrqpkmQN6ep1BnwGZo=; b=Di1YeODiA+7xpq5OeOhf14MSOwd3zhj4wSvF4sXFuEAEn+XLi9kZADbWDmGLEM+AZ3pPXFznjR9SgwMbv+n4CS/rOkuaxjMCbcz/78uG7DGlk2LitmqlCruqi2XNcae8L3tLV7jWlfTugYDbF+vNeRx6Ulq0f5sWynqETQfhH28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nm0MjZJq9uaYV8hYhjvNdC1dyXQ4Nn8YRdd4iewxg59GLuz9QDuS0UlYQwK+RGEno9Bqu8tdKJ5flC3Qla6B+gqWYCHV6+KIdXF/uPdILmbn/UZHfKwVTf+YSaLW9AKvVB9lBzWxPpV6+53uQqS9/ApoKkQ1Cq66l0krPa4DGjY= Received: by 10.142.215.5 with SMTP id n5mr2836407wfg.161.1207604990459; Mon, 07 Apr 2008 14:49:50 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Mon, 7 Apr 2008 14:49:50 -0700 (PDT) Message-ID: <953beacc0804071449y11b22ca4tead6a3659a9e9d@mail.gmail.com> Date: Mon, 7 Apr 2008 14:49:50 -0700 From: "Rohan Mahy" To: "Hadriel Kaplan" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: "sip@ietf.org" Subject: Re: [Sip] Comments on sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Mon, Apr 7, 2008 at 1:15 PM, Hadriel Kaplan wrote: > Howdy, > I have the following comments, mostly editorial nits, on the latest draft. I think these do not overlap with John Elwell's. > > General comment: I think it's in great shape, and very thorough. Thanks! > 1) I do not see any discussion of RFC 3680 SIP Registration Event Package. I assume that each registered flow's contact is treated as a unique contact in all regards to RFC 3680, right? And the reg-id and instance would be saved in the "unknown-param" XML element of the contact element, making those unique (vs. being unique contact URI's). I think maybe that should be clarified somewhere, as rfc3680 is not uncommon. Paul K had an extension to reg-event for GRUU. I think his document would be a logical place to clarify since GRUU depends on outbound. > 2) If a Register is 3xx redirected, does the new retargeted Register use the same reg-id, even though it's a different "flow"? (I assume so) I ask because some people use 3xx for Registers to load-balance or perform anycasting. It may be good to add this to end of section 4.2.1. Yes, the UA uses the same reg-id. It uses the the reg-id to indicate that this is (for example) my "2nd logical flow" to my registrar or the logical flow over my "cellular interface". Can you suggest something here or point out the specific part that is confusing.? > 3) Page 5: > Reg-id: "When a UA registers multiple times, each concurrent registration gets a unique reg-id value." Replace with: "When a UA registers multiple times, each for a different flow, each concurrent registration gets a unique reg-id value." good > 4) Page 12, Section 3.5.2: > The proxy or registrar acts as a Session > Traversal Utilities for NAT (STUN) [I-D.ietf-behave-rfc3489bis] > server on the SIP signaling port. > Insert "limited" before "Session". (ie, it is not a full STUN server) good > 5) Page 12, Section 3.5.2: > Note: The STUN mechanism is very robust and allows the detection > of a changed IP address. > Add "and port" at the end. good > 6) Page 12, Section 4.1: > "It also provides an easy way to guarantee uniqueness within the AOR." I'm a bit confused by that, because I don't believe we're saying one UA instance only ever represents one AoR. (ie, multiple AoR's registered on the same UA will have the same registered contact instance) Recommend removing or rewording. I don't see the confusion. _Within_ the AOR, the instance-id provides further disambiguation. I can absolutely use the instance with more than one AOR. > 7) Page 14, Section 4.2.1: > For each outbound proxy URI in the set, the UAC SHOULD send a > REGISTER request using this URI as the default outbound proxy. (The > UA could limit the number of flows formed to conserve battery power, > for example). > The logic flow is awkward there. Change second sentence to start with "Alternatively, the UAC could...". better > 8) Page 15, Section 4.2.1: > If the registering UA receives a 439 (First Hop Lacks Outbound > Support) response to a REGISTER request, it MAY re-attempt > registration without an outbound proxy (subject to local policy at > the client). > I think what you mean at the end is instead "without using the outbound mechanism"? yes > 9) Page 16, Section 4.3: > ... For TLS protocols, there MUST also > be a match between the host production in the next hop and one of the > URIs contained in the subjectAltName in the peer certificate. > s/production in/resolved for/ I don't think your proposed rewording is correct. Perhaps s/next hop/next hop URI/ ? > 10) Page 18, Section 4.4.1: > A User Agent that forms flows, checks if the configured URI to which > the UA is connecting resolves to a stream-based transport (ex: TCP > and TLS over TCP). > That's confusing, because double-CRLF is used for connection-oriented transports period, not only stream-based ones (ie, also used for SCTP). And no statement is made about why it checks for stream-based, so I recommend removing it or clarifying. How about: s/stream-based/connection-oriented/ ? thanks, -rohan > -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 > _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 7 15:17:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F41328C1E4; Mon, 7 Apr 2008 15:17:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6E63A6D1F for ; Mon, 7 Apr 2008 15:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 6omg0+jTcHMN for ; Mon, 7 Apr 2008 15:17:44 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 18A3628C0EF for ; Mon, 7 Apr 2008 15:17:44 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id B95DF5081A; Mon, 7 Apr 2008 15:19:47 -0700 (PDT) Date: Mon, 07 Apr 2008 15:19:47 -0700 From: Eric Rescorla To: Michael Thomas In-Reply-To: <47F6716E.9080908@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080407221947.B95DF5081A@romeo.rtfm.com> Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Fri, 04 Apr 2008 11:20:30 -0700, Michael Thomas wrote: > Mike, who's ecstatic that 7% of domains are dkim checking now Hi Mike, I was curious where you got this figure from... Thanks, -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 7 15:41:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA0D3A6A52; Mon, 7 Apr 2008 15:41:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54693A6A52 for ; Mon, 7 Apr 2008 15:41:09 -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=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 ZW4iheM0yHNh for ; Mon, 7 Apr 2008 15:41:09 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 164F63A6822 for ; Mon, 7 Apr 2008 15:41:09 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id EB4D45081A; Mon, 7 Apr 2008 15:43:12 -0700 (PDT) Date: Mon, 07 Apr 2008 15:43:12 -0700 From: Eric Rescorla To: Hannes Tschofenig In-Reply-To: <47F5EBED.60104@gmx.net> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> <47F5EBED.60104@gmx.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080407224312.EB4D45081A@romeo.rtfm.com> Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Fri, 04 Apr 2008 11:50:53 +0300, Hannes Tschofenig wrote: > > This issue is totally independent from E.164 > > I don't like the idea of requiring DTLS-SRTP to provide proof of > possession of the keying material. To be honest, I'm not even sure what this means. DTLS-SRTP inherently provides a proof that the peer you're encrypting to has keying material that matches whatever was in the fingerprint. That's a distinct question from whether the fingerprint is cryptographically bound to the message. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 7 16:17:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADBF13A6A4C; Mon, 7 Apr 2008 16:17:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6D33A6A52 for ; Mon, 7 Apr 2008 16:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 ODmFVjTGBUip for ; Mon, 7 Apr 2008 16:17:44 -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 C2A9B3A6851 for ; Mon, 7 Apr 2008 16:17:43 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2008 16:17:58 -0700 Received: from mtcc13.mtcc.com ([10.21.118.72]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m37N1wQ2011633; Mon, 7 Apr 2008 16:01:58 -0700 Message-ID: <47FAABA0.1040606@cisco.com> Date: Mon, 07 Apr 2008 16:17:52 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eric Rescorla References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <20080407221947.B95DF5081A@romeo.rtfm.com> In-Reply-To: <20080407221947.B95DF5081A@romeo.rtfm.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=714; t=1207609318; x=1208473318; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Eric=20Rescorla=20; bh=75zjV9tiYoFAgrHBWoTWpZ5dz7jxNGdh7rcekm985e4=; b=MC0dN9kGF/NZiMo+DX/GPw+d7fUUo0AIsz6624HBWfXDIoPskhBXLrKgK4 SY0sVPwOhmhzK7o66Mv8AhqCb85kNiNRceQL698FGvIPcz4nEhh1dliEaEjv Y/ZVGyki6V; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > At Fri, 04 Apr 2008 11:20:30 -0700, > Michael Thomas wrote: > >> Mike, who's ecstatic that 7% of domains are dkim checking now >> > > Hi Mike, > > I was curious where you got this figure from... > > Ha ha, I was wondering if anybody would notice :) It's from grinding through our logs. It is between Cisco and other companies since the 7% doesn't include cisco-cisco messages (it's 7% of domains we send to seem to vfy). The bottom line is that it may be somewhat optimistic since the companies who we correspond with might be more likely to be early adopters, but then again, maybe it's not all that optimistic. I was pretty surprised. Mike _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 8 00:51:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AA528C272; Tue, 8 Apr 2008 00:51:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4B53A6B17 for ; Tue, 8 Apr 2008 00:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3GbGiPRIFZa for ; Tue, 8 Apr 2008 00:50:55 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3BB643A6EBE for ; Tue, 8 Apr 2008 00:50:12 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m387oLnM016163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Apr 2008 02:50:23 -0500 Message-Id: From: Dean Willis To: "sip@ietf.org List" In-Reply-To: <20080407224312.EB4D45081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 02:50:16 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BC@GBNTHT12009MSX.gb002.siemens.net> <47F5EBED.60104@gmx.net> <20080407224312.EB4D45081A@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) Cc: John Elwell Subject: Re: [Sip] RFC 4474 and SBC traversal X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 7, 2008, at 5:43 PM, Eric Rescorla wrote: > At Fri, 04 Apr 2008 11:50:53 +0300, > Hannes Tschofenig wrote: >> >> This issue is totally independent from E.164 >> >> I don't like the idea of requiring DTLS-SRTP to provide proof of >> possession of the keying material. > > To be honest, I'm not even sure what this means. DTLS-SRTP inherently > provides a proof that the peer you're encrypting to has keying > material that matches whatever was in the fingerprint. That's > a distinct question from whether the fingerprint is cryptographically > bound to the message. Right. The only dependency between DTLS-SRTP and RFC 4474 is integrity protection of the key's fingerprint, not the actual key itself. The fingerprint is shipped in the SDP, and the key is negotiated in the media channel itself using a partial-key combination approach (aka D-H). The fingerprint is used to relate signaling to media. This works even without RFC 4474. What RFC 4474 does is reduce the opportunity for somebody on the signaling AND media paths to replace the key, and use this to tap the media flow without being noticed by endpoints. It is somewhat arguable as to how useful this integrity protection is. Of course, given that the usual implementation of RFC 4474 is for the authentication service that puts in the RFC 4474 Identity header to be a proxy that's on the signaling path, this would make it fairly easy for that proxy to collude in tapping the call. But if RFC 4474 is used end-to-end with client keys, the it provides fairly comprehensive protection. -- 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 sip-bounces@ietf.org Tue Apr 8 02:09:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6767A28C34F; Tue, 8 Apr 2008 02:09:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FC628C349 for ; Tue, 8 Apr 2008 02:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 CZHsR6r1cfFY for ; Tue, 8 Apr 2008 02:09:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1308428C34D for ; Tue, 8 Apr 2008 02:09:04 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0CD1F20592; Tue, 8 Apr 2008 11:09:18 +0200 (CEST) X-AuditID: c1b4fb3c-ab896bb00000193b-ad-47fb363d4b80 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EE78420554; Tue, 8 Apr 2008 11:09:17 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 11:09:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 11:09:17 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D850479E0E@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comparison of retargeting proposals thread-index: AciRmuXokKnUmVQyROmRmE5PNupbGQB8oDogABBlm+AAETb1YAAkC+NwAA39TPAAAleloAADZ3KgACHxX6AAFMnqEAAeTUuwAAxmkzAAt7MnIA== References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com> <47B2061B1E5E494B96AA40008300D8504436BB@esealmw109.eemea.er icsson.s e> From: "Hans Erik van Elburg" To: "Hadriel Kaplan" , "Francois Audet" , "Christer Holmberg" , "Juha Heinanen" X-OriginalArrivalTime: 08 Apr 2008 09:09:17.0725 (UTC) FILETIME=[3947FCD0:01C89958] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org, "DOLLY, MARTIN C, ATTLABS" Subject: Re: [Sip] Comparison of retargeting proposals X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well... for some strange reason IMS uses IETF SIP. I agree with you that reality is often just not right. ;-) /Hans Erik -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, April 04, 2008 7:35 PM To: Hans Erik van Elburg; Francois Audet; Christer Holmberg; Juha Heinanen Cc: sip@ietf.org; DOLLY, MARTIN C, ATTLABS Subject: RE: [Sip] Comparison of retargeting proposals > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Hans Erik van Elburg > > I think that in a closed environment like IMS where all proxies can be > guaranteed to support loose routing, there is effectively almost no > difference between P-Called-Party-ID and Target header. I beg to differ - even in IMS all "proxies" cannot be guaranteed to be doing loose-routing, if by that you mean not changing the req-uri as they forward. What's written in IMS specs and what's getting deployed/configured in the field are not identical all of the time, nor in all scenarios for the same IMS network... much like IETF SIP. (this is not to say that this has any impact on the gist of your comment or the proposals - just noting that "IMS specs" and IMS reality are not one and the same, as you're probably aware) -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 sip-bounces@ietf.org Tue Apr 8 02:29:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F6028C357; Tue, 8 Apr 2008 02:29:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AF328C357 for ; Tue, 8 Apr 2008 02:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 WbyppTFRLvKs for ; Tue, 8 Apr 2008 02:29:10 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7C71D28C130 for ; Tue, 8 Apr 2008 02:29:10 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B839D20DF8; Tue, 8 Apr 2008 11:29:24 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-0d-47fb3af40558 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 86D2C20D63; Tue, 8 Apr 2008 11:29:24 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 11:29:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 11:29:26 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" thread-index: AciWfwnoTVLaiuoBSW2dinM2JQxW/wC2sbmA References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! 2 CCF15 EB7 F8A@zrc2 hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> From: "Hans Erik van Elburg" To: "Dean Willis" X-OriginalArrivalTime: 08 Apr 2008 09:29:24.0085 (UTC) FILETIME=[0853EA50:01C8995B] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The Target header proposal clearly ties the parameters destined for the target with the current target, this means that if the current target changes these parameters will no longer be. /Hans Erik -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, April 04, 2008 8:09 PM To: Hans Erik van Elburg Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" On Apr 4, 2008, at 7:24 AM, Hans Erik van Elburg wrote: > There seems to be a misunderstanding here, there is no intention for > stacking Target headers at all. There will always have to be zero or > one target header field with one clear meaning: "current target". > I believe you. But like others, I found the draft unclear, and it made more sense if I assumed a stack of Target headers. > As soon as a retarget (using the definition from UALR draft) occurs an > existing target header will have to be removed, as it no longer > represents the current target. Then it doesn't help Charlie knows that he's answering a call meant for Bob when Bob forwards his phone to Charlie and Alice calls Bob. > Params only seems to tackle the parameter loss issue, and it seems > further to solve a different problem alltogether i.e. how to get > parameters from the caller to the callee. Well, that WAS the original goal of US-Loose-Route, and is the thing we have a chartered milestone for: From our charter: Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) > There is a risk that > parameters that where only intended to be received by user B end up at > user C. Well, that can certainly happen with any header. The workaround if it worries you is to use a 302. -- 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 sip-bounces@ietf.org Tue Apr 8 06:32:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DDF3A6BCC; Tue, 8 Apr 2008 06:32:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151B23A67F6 for ; Tue, 8 Apr 2008 06:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.174 X-Spam-Level: X-Spam-Status: No, score=-4.174 tagged_above=-999 required=5 tests=[AWL=2.075, BAYES_00=-2.599, HELO_EQ_DE=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 4HtMvyVePdul for ; Tue, 8 Apr 2008 06:32:01 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id EC9F828C3BE for ; Tue, 8 Apr 2008 06:32:00 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id m38DWCUI028858; Tue, 8 Apr 2008 15:32:12 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m38DWClu031950; Tue, 8 Apr 2008 15:32:12 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Apr 2008 15:32:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 15:32:19 +0200 Message-ID: <198A10EC585EC74687BCA414E2A597180216837C@MCHP7RDA.ww002.siemens.net> In-Reply-To: <1e3401c898cc$7ef98050$c5f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQAHbjyyAAEWWwAAAjXfQg References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <198A10EC585EC74687BCA414E2A597180211ADCC@MCHP7RDA.ww002.siemens.net> <1e3401c898cc$7ef98050$c5f0200a@cisco.com> From: "Fischer, Kai" To: "Dan Wing" , X-OriginalArrivalTime: 08 Apr 2008 13:32:10.0539 (UTC) FILETIME=[F29C67B0:01C8997C] Cc: "Elwell, John" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > > > That's an interesting proposal. I didn't get if your intention is to > > sign both headers (From header with E.164 and > 'email-identity' header) > > or only the email-based one. > > For the purposes of my straw-man, you can assume (a) we have resolved > all problems with signing E.164s in From, or you can assume > (b) we have > not resolved any problem with signing E.164 in From -- either way, my > proposal still provides benefit: the called party can use the email- > style address to establish end-to-end identity with the calling party, > and can use that to establish an end-to-end SRTP session (using a > mechanism similar to your draft or the Wing/Kaplan draft). > Let's explore your proposal further regarding the problems discussed in the other two threads (sorry for mixing the email threads now, but it is close related to the migration proposal): First problem: Weak PSTN numbers Proposal - Don't include the E.164 number in the signature if it was received from the PSTN (certificate fingerprint is still protected and bound to the email-style SIP URI of SIP Gateway provided in 'email-identity') - Include the E.164 number in the signature if not received from the PSTN That's independent from the concrete signing mechanism except that RFC 4474 does not cover the new header field Second problem: SBC traversal - If both identity information are signed it conflicts with SBCs modifying SDP information and therefore need to change the domain part of the SIP URI in the From header as well - If only the email-identity information is signed (by the Wing/Kaplan or Fischer draft), intermediary SBCs should not break the signature. However, the E.164 number has PSTN security level only as assumed above, but email-style is bound to certificate fingerprint and signed An straw man extension to your proposal, which mitigates the SBC traversal problem is to create two signatures. One signing the email-identity including the certificate fingerprint and which is protected end-to-end. The other one covering the From header field and which might re-newed during traversal by intermediaries. The disadvantage are for sure two signing processes. Kai _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 8 10:34:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277613A6DE7; Tue, 8 Apr 2008 10:34:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F533A6DFB for ; Tue, 8 Apr 2008 10:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 1ED1Sw0chTYc for ; Tue, 8 Apr 2008 10:34:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7D1EB3A692C for ; Tue, 8 Apr 2008 10:34:26 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m38HYbc3020263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Apr 2008 12:34:39 -0500 Message-Id: From: Dean Willis To: Hans Erik van Elburg In-Reply-To: <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 12:34:32 -0500 References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! ! 2 CCF15 EB7 F8A@zrc2 hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 8, 2008, at 4:29 AM, Hans Erik van Elburg wrote: > The Target header proposal clearly ties the parameters destined for > the > target with the current target, this means that if the current target > changes these parameters will no longer be. > Well then while it might be useful, it doesn't solve the chartered problem. It doesn't even attempt to solve the chartered problem. And that makes the draft itself very useful by helping to explain what the problem isn't, which we've apparently become somewhat confused about. -- 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 sip-bounces@ietf.org Tue Apr 8 10:48:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6A328C253; Tue, 8 Apr 2008 10:48:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB433A6814 for ; Tue, 8 Apr 2008 10:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 ojhDjm0dxcy3 for ; Tue, 8 Apr 2008 10:48:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BA9FD28C120 for ; Tue, 8 Apr 2008 10:48:16 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7AA5204CE; Tue, 8 Apr 2008 19:48:31 +0200 (CEST) X-AuditID: c1b4fb3c-ac097bb00000193b-e2-47fbafef6a23 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D2D892057E; Tue, 8 Apr 2008 19:48:31 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 19:48:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 19:47:26 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" thread-index: AciZntQwo36gEdNaS2+ywopwoCrvswAAIxfw References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! ! 2 CCF 15 EB7 F8A@z rc2 hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> From: "Hans Erik van Elburg" To: "Dean Willis" X-OriginalArrivalTime: 08 Apr 2008 17:48:31.0161 (UTC) FILETIME=[C22D1290:01C899A0] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It solves the chartered problem that you quoted. And it solves all the use cases listed in the UALR draft. If you go and redefine the problem, then yes the Target header may not longer solve the redefined problem. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, April 08, 2008 7:35 PM To: Hans Erik van Elburg Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" On Apr 8, 2008, at 4:29 AM, Hans Erik van Elburg wrote: > The Target header proposal clearly ties the parameters destined for > the target with the current target, this means that if the current > target changes these parameters will no longer be. > Well then while it might be useful, it doesn't solve the chartered problem. It doesn't even attempt to solve the chartered problem. And that makes the draft itself very useful by helping to explain what the problem isn't, which we've apparently become somewhat confused about. -- 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 sip-bounces@ietf.org Tue Apr 8 13:20:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1C028C3DA; Tue, 8 Apr 2008 13:20:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3B33A6C2D for ; Tue, 8 Apr 2008 13:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 c4x12cRtQZbM for ; Tue, 8 Apr 2008 13:20:53 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 492943A6A42 for ; Tue, 8 Apr 2008 13:20:51 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m38KL3nK021417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Apr 2008 15:21:04 -0500 Message-Id: From: Dean Willis To: "Hans Erik van Elburg" In-Reply-To: <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 15:20:57 -0500 References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! ! ! 2 CCF 15 EB7 F8A@z rc2 hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 8, 2008, at 12:47 PM, Hans Erik van Elburg wrote: > It solves the chartered problem that you quoted. > And it solves all the use cases listed in the UALR draft. > > If you go and redefine the problem, then yes the Target header may not > longer solve the redefined problem. > > Dean wrote: >> On Apr 8, 2008, at 4:29 AM, Hans Erik van Elburg wrote: >>> The Target header proposal clearly ties the parameters destined for >>> the target with the current target, this means that if the current >>> target changes these parameters will no longer be. >>> >> >> Well then while it might be useful, it doesn't solve the chartered >> problem. It doesn't even attempt to solve the chartered problem. >> >> And that makes the draft itself very useful by helping to explain >> what >> the problem isn't, which we've apparently become somewhat confused >> about. Ok, I'm probably confused. The chartered problem (this part I'm sure of, I wrote the charter) is for delivery of URI parameters from UAC to UAS, despite speed-dial routing and contact routing (aka "retargeting" or "rerouting", depending on your definition) in a proxy or proxies between those UAs. But you said that the current draft discards the parameters when the target changes, so by definition it wouldn't address that problem. Then you said again that it DOES solve the chartered problem. This makes me strongly suspect we're not all talking about the same problem, which seems like a real problem to me. -- 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 sip-bounces@ietf.org Tue Apr 8 14:09:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA77D28C1C3; Tue, 8 Apr 2008 14:09:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8843F28C0F9 for ; Tue, 8 Apr 2008 14:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=1.229, 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 hi+uy2A+ibxJ for ; Tue, 8 Apr 2008 14:09: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 6427A28C134 for ; Tue, 8 Apr 2008 14:09:50 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Apr 2008 14:10:07 -0700 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 m38LA7hN007598; Tue, 8 Apr 2008 14:10:07 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m38LA4G9006853; Tue, 8 Apr 2008 21:10:06 GMT From: "Dan Wing" To: "'Fischer, Kai'" , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <198A10EC585EC74687BCA414E2A597180211ADCC@MCHP7RDA.ww002.siemens.net> <1e3401c898cc$7ef98050$c5f0200a@cisco.com> <198A10EC585EC74687BCA414E2A597180216837C@MCHP7RDA.ww002.siemens.net> Date: Tue, 8 Apr 2008 14:10:06 -0700 Message-ID: <3d0301c899bc$ebd14140$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <198A10EC585EC74687BCA414E2A597180216837C@MCHP7RDA.ww002.siemens.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQAHbjyyAAEWWwAAAjXfQgABbd99A= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3425; t=1207689007; x=1208553007; 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]=20Migration=20from=20E.164=20to=2 0email-style=20SIP=20URIs |Sender:=20; bh=09cymwXWZ0d3dhLyszV7OuGPFXqtSk8u2CCFBE+hOZc=; b=GIc7zEuHuoZLnHFBOQ4es85QO0mvlXF7ImwQlYgv6Unx/m0ULNlCo8JwLR rEamrEWUYErulAw6/CU1Qc1x81IaNXnl1iQTL/ZnzgdtqKFnYztjKLwQh9TT 1omkMJDENq; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "'Elwell, John'" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Fischer, Kai [mailto:kai.fischer@siemens.com] > Sent: Tuesday, April 08, 2008 6:32 AM > To: Dan Wing; sip@ietf.org > Cc: Elwell, John > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > > > > > > That's an interesting proposal. I didn't get if your > intention is to > > > sign both headers (From header with E.164 and > > 'email-identity' header) > > > or only the email-based one. > > > > For the purposes of my straw-man, you can assume (a) we > have resolved > > all problems with signing E.164s in From, or you can assume > > (b) we have > > not resolved any problem with signing E.164 in From -- > either way, my > > proposal still provides benefit: the called party can use > the email- > > style address to establish end-to-end identity with the > calling party, > > and can use that to establish an end-to-end SRTP session (using a > > mechanism similar to your draft or the Wing/Kaplan draft). > > > Let's explore your proposal further regarding the problems > discussed in > the other two threads (sorry for mixing the email threads > now, but it is > close related to the migration proposal): > > First problem: Weak PSTN numbers > Proposal > - Don't include the E.164 number in the signature if it was received > from the PSTN (certificate fingerprint is still protected and bound to > the email-style SIP URI of SIP Gateway provided in 'email-identity') > - Include the E.164 number in the signature if not received from the > PSTN > That's independent from the concrete signing mechanism except that RFC > 4474 does not cover the new header field > > Second problem: SBC traversal > - If both identity information are signed it conflicts with SBCs > modifying SDP information and therefore need to change the domain part > of the SIP URI in the From header as well > - If only the email-identity information is signed (by the Wing/Kaplan > or Fischer draft), intermediary SBCs should not break the signature. > However, the E.164 number has PSTN security level only as > assumed above, > but email-style is bound to certificate fingerprint and signed > > An straw man extension to your proposal, which mitigates the SBC > traversal problem is to create two signatures. One signing the > email-identity including the certificate fingerprint and which is > protected end-to-end. The other one covering the From header field and > which might re-newed during traversal by intermediaries. The > disadvantage are for sure two signing processes. Sure, you could do that. But at this point in time it seems there is little value in RFC4474 signatures if there are SBCs on the path; if the SBCs support RFC4474, they will have to re-sign the identity and will have to re-write the From. In such a situation, RFC4474 provides protection of SIP requests being modified between the Service Provider (running the SBC) and yourself. You can achieve identical protection from the same attack by doing SIP-over-(D)TLS with that same SBC, and not bothering with RFC4474 (or RFC4916) to/from that SBC. (I would even go so far to say that, in the same case with your provider running an SBC, running SIP-over-(D)TLS to that provider is superior to RFC4474 because SIP-over-(D)TLS protects SIP responses; neither RFC4474 or RFC4916 protect SIP responses.) -d _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 8 14:19:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39EC43A6E51; Tue, 8 Apr 2008 14:19:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5D53A6969 for ; Tue, 8 Apr 2008 14:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 HcPIfkLmJ8zR for ; Tue, 8 Apr 2008 14:19:02 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 981133A6DE3 for ; Tue, 8 Apr 2008 14:19:02 -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.240.5; Tue, 8 Apr 2008 17:18:51 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 8 Apr 2008 17:18:48 -0400 From: Hadriel Kaplan To: Dean Willis , Hans Erik van Elburg Date: Tue, 8 Apr 2008 17:16:34 -0400 Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" Thread-Index: AciZtg6GYO3e41cnTQ69K0srBXR0mgAB3YZg Message-ID: References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! ! ! 2 CCF 15 EB7 F8A@z rc2 hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I believe the mechanism people are looking for is to get the params from UAC to UAS, UNLESS the UAS identity changes (ie, it is retargeted), in which case it should NOT deliver the UAC's original but rather the ones of the retargeter. In other words, there is a logical boundary/scope for the params, which is defined by a re-targeting operation. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > The chartered problem (this part I'm sure of, I wrote the charter) is > for delivery of URI parameters from UAC to UAS, despite speed-dial > routing and contact routing (aka "retargeting" or "rerouting", > depending on your definition) in a proxy or proxies between those UAs. > > But you said that the current draft discards the parameters when the > target changes, so by definition it wouldn't address that problem. > > Then you said again that it DOES solve the chartered problem. > > This makes me strongly suspect we're not all talking about the same > problem, which seems like a real problem to me. > > -- > 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 _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 8 14:30:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A7028C2F5; Tue, 8 Apr 2008 14:30:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADAA3A68D1 for ; Tue, 8 Apr 2008 14:30:53 -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 gtKDeH-Qthtb for ; Tue, 8 Apr 2008 14:30:52 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 6A22528C442 for ; Tue, 8 Apr 2008 14:30:40 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id AyWX1Z0020x6nqcAA0jB00; Tue, 08 Apr 2008 21:30:23 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id B9Wr1Z00M02AVH08Y00000; Tue, 08 Apr 2008 21:30:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=Ug0aFijqncIA:10 a=luUCChEeSYkA:10 a=fxejiOl9QXxdDjrza0IA:9 a=iAH35LP1k664VsjXVxYA:7 a=YfqUKtFjlHshc5uviJPxbBfo9FcA:4 a=rpjHd656CRUA:10 a=k_Ds2AWJ3RgA:10 a=k4qQewaewV0A:10 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m38LUpEA004630 for ; Tue, 8 Apr 2008 17:30:51 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m38LUpUO004626; Tue, 8 Apr 2008 17:30:51 -0400 Date: Tue, 8 Apr 2008 17:30:51 -0400 Message-Id: <200804082130.m38LUpUO004626@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> (john.elwell@siemens.com) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Elwell, John" The problem is the changing of domain part as the E.164-based URI traverses service providers, so that it no longer represents the true origin of the request. Well, yes. If you change the domain part of a URI as it traverses service providers, you're going to break things. If you mean "what the user +123456789 means in cisco.com's domain", say . If you mean "what the user +123456789 means in siemens.com's domain", say . And there's no reason to believe that there is any relationship between the two -- unless you have authoritative information about *both* domains. If you mean "the E.164 number +123456789", say . I don't see anything that will go wrong if people pay attention to what URIs are defined to mean. Now there is a problem with signing tel: URIs, how do you determine that the signer has the authority to sign a particular tel: URI, but that's a delegation-of-authority problem that is not inherently different from other delegation-of-authority problems -- you need a publicly-known root authority and a tree of delegations. 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 sip-bounces@ietf.org Tue Apr 8 15:14:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B952A3A6B17; Tue, 8 Apr 2008 15:14:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D753A3A6B4A for ; Tue, 8 Apr 2008 15:14:14 -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 x+8dJ5wRpJFX for ; Tue, 8 Apr 2008 15:14:13 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 025083A6B0A for ; Tue, 8 Apr 2008 15:14:12 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id B5be1Z0430EPchoA80Ba00; Tue, 08 Apr 2008 22:13:17 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id BAET1Z00B02AVH08M00000; Tue, 08 Apr 2008 22:14:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=smI9H8rFQ7Ix_62XfpsA:9 a=TcxBg6UPcs4koKji28QA:7 a=LESxYK90-tzhnUZKUpFIB4KkpQ8A:4 a=4rq7TwIXcRUA:10 a=O_8zS4DB41IA:10 a=HwvHyInW8OUA:10 a=mnQxEUBslVAA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m38MEREA007803 for ; Tue, 8 Apr 2008 18:14:27 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m38MER1M007799; Tue, 8 Apr 2008 18:14:27 -0400 Date: Tue, 8 Apr 2008 18:14:27 -0400 Message-Id: <200804082214.m38MER1M007799@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (message from Hadriel Kaplan on Fri, 4 Apr 2008 19:15:02 -0400) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Hadriel Kaplan > From: Dean Willis [mailto:dean.willis@softarmor.com] > > If an identity server were to fully RFC 4474 "sign" a message rom a > PSTN, it's even possible that the identity server operator could be > held legally liable for inaccuracy in the asserted identity. In other > words, if a caller-ID spoofer made a call through the example.com > gateway, and the example.com identity server attaches an Identity > header on to the resulting INVITE that asserts the spoofed telephone > number identity, then someone injured (defrauded) by the caller could > claim negligence on the part of the example.com identity server and > sue for damages. I'm pretty sure that's not possible. It's possible to sue the good guys, in the local country - but it's quite hard if not impossible for me to sue some enterprise in Thailand, for example. I don't know if verisign/thawte/etc. would give them a cert, but since we're not mandating specific "SIP 4474" certs and they can use the domain cert they legitimately got for web, I don't see how my UA is to know any better about their's than softarmor.com's cert. (without whitelists) But more importantly, if you're thinking these things would truly have *legal* ramification, then my guess is no "good-guys" would touch signing with 4474 with a ten foot pole, ever. Do DKIM email signatures have such legal implications? I think we're losing sight of the context... *If* people who receive calls actually care about authenticating the identity of callers via SIP mechanisms (rather than by recognizing voices, or originating the call themselves, etc.), then they're going to start depending on RFC 4474, etc. And once they start depending on that, bad guys will start trying to exploit that dependency, especially by exploiting identity services that do not enforce identification effectively. Indeed, we can expect bad guys to set up identity services specifically for this purpose. At that point, people will discover the hard way that some identity services are unreliable, so they will start whitelisting identity services and/or CAs that reliably enforce reliability on identity services. The sort of reputation that has wide public trust will come to be seen as a valuable asset, and identity services with that sort of reputation (of which there won't be many) will charge signficant money for their services. Within that context, a PSTN gateway will not routinely apply identification based on caller ID from an identity service which is widely trusted - they can't determine the identity well enough, and nobody is going to pay for it. Now please excuse me, I have to go wire $10,000 to a government officer in Nigeria who needs it to finance the payment of a legacy to a distant cousin of mine. (I can trust him, his From identity was certified by the Nigerian government!) 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 sip-bounces@ietf.org Tue Apr 8 15:46:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2AB83A6DFA; Tue, 8 Apr 2008 15:46:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54CF3A6DFA for ; Tue, 8 Apr 2008 15:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.545, 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 BZN9XpQMvksY for ; Tue, 8 Apr 2008 15:46:45 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 79A993A68D1 for ; Tue, 8 Apr 2008 15:46:45 -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 m38MkFT24117; Tue, 8 Apr 2008 22:46:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Apr 2008 17:46:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF16012921@zrc2hxm0.corp.nortel.com> In-Reply-To: <200804082130.m38LUpUO004626@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciZv/MEXw27w+P8SzSm9nNinZvP2wAChRtA References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> From: "Francois Audet" To: , Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Didn't we go through this already? If it says sip:+123456789@cisco.com, it's effectively a user in domain cisco.com with name "+123456789". If it says sip:+123456789@cisco.com;user=phone, it's effectively a phone number derived from a Tel URI that is currently being routed in cisco.com domain. But don't count on the domain to be authoritative of the phone number. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dale.Worley@comcast.net > Sent: Tuesday, April 08, 2008 14:31 > To: sip@ietf.org > Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs > > From: "Elwell, John" > > The problem is the changing of domain part as the E.164-based URI > traverses service providers, so that it no longer > represents the true > origin of the request. > > Well, yes. If you change the domain part of a URI as it > traverses service providers, you're going to break things. > If you mean "what the user +123456789 means in cisco.com's > domain", say . If you mean "what > the user +123456789 means in siemens.com's domain", say > . And there's no reason to > believe that there is any relationship between the two -- > unless you have authoritative information about *both* domains. > > If you mean "the E.164 number +123456789", say . > > I don't see anything that will go wrong if people pay > attention to what URIs are defined to mean. > > Now there is a problem with signing tel: URIs, how do you > determine that the signer has the authority to sign a > particular tel: URI, but that's a delegation-of-authority > problem that is not inherently different from other > delegation-of-authority problems -- you need a publicly-known > root authority and a tree of delegations. > > 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 sip-bounces@ietf.org Tue Apr 8 17:01:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60113A68C3; Tue, 8 Apr 2008 17:01:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B807D3A68C3 for ; Tue, 8 Apr 2008 17:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=1.152, 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 2grVe749emCE for ; Tue, 8 Apr 2008 17:01:27 -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 EC97E3A685D for ; Tue, 8 Apr 2008 17:01:26 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 08 Apr 2008 17:01:41 -0700 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 m3901fMm022802; Tue, 8 Apr 2008 17:01:41 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3901fRR029232; Wed, 9 Apr 2008 00:01:41 GMT From: "Dan Wing" To: , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> Date: Tue, 8 Apr 2008 17:01:40 -0700 Message-ID: <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200804082130.m38LUpUO004626@dragon.ariadne.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciZv/88p5QtWsy0TeG2z6DJDTk8CAAE/wfw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1961; t=1207699301; x=1208563301; 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:=20E.164=20-=20who=20owns=20it |Sender:=20; bh=8Lp5jsoKoN5zWnLzGktCsLvrWkj6mu574E5JEzTMKVg=; b=IYVkxj10kHG/ufYIgklNydLqK2uTFJfX1AiuVA8H6B5xJ7wQto5X9kXcn8 FiUSOHIo02XYdAOc/+NxVzvfgDc68dun7NknozuPI57yEyC1N+v2p8h0FzQT penoo/0tJv; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ... > Well, yes. If you change the domain part of a URI as it traverses > service providers, you're going to break things. If you mean "what > the user +123456789 means in cisco.com's domain", say > . If you mean "what the user +123456789 > means in siemens.com's domain", say . > And there's no reason to believe that there is any relationship > between the two -- unless you have authoritative information about > *both* domains. If those URIs included ";user=phone", there is a transitive relationship between the SIP URI and the TEL URI. Without ";user=phone", I agree that no meaning is supposed to be applied to the user-part (the part to the left of the "@"). > If you mean "the E.164 number +123456789", say . > > I don't see anything that will go wrong if people pay attention > to what URIs are defined to mean. > > Now there is a problem with signing tel: URIs, how do you determine > that the signer has the authority to sign a particular tel: URI, but > that's a delegation-of-authority problem that is not inherently > different from other delegation-of-authority problems -- you need a > publicly-known root authority and a tree of delegations. That is one approach to determining who owns something. I have a different approach, which I derived from how we determine if someone owns an IP address when we receive a TCP SYN that is proportedly from that IP address: challange them to prove that packets route the other way. Afterall, the Internet does not have a central authority for who owns an IP address (or else we could secure BGP routing better than we secure it today). In SIP, you accomplish something similar to the TCP SYN cookie by sending a SIP request towards the E.164, asking them to sign the request and return it to you. Details are in draft-wing-sip-e164-rrc-01.txt and comments are welcome. -d _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 8 17:31:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C521C3A6A79; Tue, 8 Apr 2008 17:31:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEEF3A6A79 for ; Tue, 8 Apr 2008 17:31:47 -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.287, 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 pOHi5GLtPe5i for ; Tue, 8 Apr 2008 17:31:46 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 815203A68C0 for ; Tue, 8 Apr 2008 17:31:46 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m390Vump022722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Apr 2008 19:31:58 -0500 Message-Id: <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 19:31:50 -0500 References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! ! ! ! 2 CCF 15 EB7 F8A@z rc2 hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org" Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: > > I believe the mechanism people are looking for is to get the params > from UAC to UAS, UNLESS the UAS identity changes (ie, it is > retargeted), in which case it should NOT deliver the UAC's original > but rather the ones of the retargeter. Ok, in this scenario, is "contact routing" at the proxy a retargeting? I'm guessing not. What about originating side operations, like a speed-dial application? What about parameters inserted by a proxy? -- 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 sip-bounces@ietf.org Tue Apr 8 17:40:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA27428C120; Tue, 8 Apr 2008 17:40:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BA33A6938 for ; Tue, 8 Apr 2008 17:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, SARE_FRAUD_X3=1.667] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyMS9z4lUMQb for ; Tue, 8 Apr 2008 17:40:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AA79F28C120 for ; Tue, 8 Apr 2008 17:40:39 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m390ehUc022770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Apr 2008 19:40:50 -0500 Message-Id: From: Dean Willis To: Dale.Worley@comcast.net In-Reply-To: <200804082214.m38MER1M007799@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 8 Apr 2008 19:40:38 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <200804082214.m38MER1M007799@dragon.ariadne.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 8, 2008, at 5:14 PM, Dale.Worley@comcast.net wrote: > > I think we're losing sight of the context... *If* people who receive > calls actually care about authenticating the identity of callers via > SIP mechanisms (rather than by recognizing voices, or originating the > call themselves, etc.), then they're going to start depending on RFC > 4474, etc. And once they start depending on that, bad guys will start > trying to exploit that dependency, especially by exploiting identity > services that do not enforce identification effectively. Indeed, we > can expect bad guys to set up identity services specifically for this > purpose. At that point, people will discover the hard way that some > identity services are unreliable, so they will start whitelisting > identity services and/or CAs that reliably enforce reliability on > identity services. I'm with you so far. Consequence: No "reliable" identity service will assert an identity with a phone number in it., But we NEED them to do so, otherwise we can't detect MITM attacks that affect both signaling and media. catch 22. > > > The sort of reputation that has wide public trust will come to be seen > as a valuable asset, and identity services with that sort of > reputation (of which there won't be many) will charge signficant money > for their services. > To whom? The user of the identity being authenticated, or the consumer of the authentication? Note that "quality" certs today aren't cheap. I don't have one. > Within that context, a PSTN gateway will not routinely apply > identification based on caller ID from an identity service which is > widely trusted - they can't determine the identity well enough, and > nobody is going to pay for it. So are you saying that the gateway's calls won't get Identity headers, or that they will, but they'll be signed using a bogus or less-trusted cert than would be used for calls originating from IP terminals that support strong authentication? > > Now please excuse me, I have to go wire $10,000 to a government > officer in Nigeria who needs it to finance the payment of a legacy to > a distant cousin of mine. (I can trust him, his From identity was > certified by the Nigerian government!) Can you please ask him about Barrister James and the million he was supposed to wire me for my new startup? We're launching a SIP Authentication Service, "allur419srus.com". It will be widely trusted. But James hasn't called back since I advanced his legal fees. -- 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 sip-bounces@ietf.org Tue Apr 8 19:18:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A403A6EA0; Tue, 8 Apr 2008 19:18:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295CA3A6E75 for ; Tue, 8 Apr 2008 19:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 joqHvSsVxmHs for ; Tue, 8 Apr 2008 19:18:45 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 269473A6895 for ; Tue, 8 Apr 2008 19:18:45 -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.240.5; Tue, 8 Apr 2008 22:18:34 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 8 Apr 2008 22:18:34 -0400 From: Hadriel Kaplan To: Dean Willis Date: Tue, 8 Apr 2008 22:15:57 -0400 Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" Thread-Index: AciZ2RKZhAHczElORySl93ATHZtKmQADEhQA Message-ID: References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! ! ! ! 2 CCF 15 EB7 F8A@z rc2 hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> In-Reply-To: <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: > > I believe the mechanism people are looking for is to get the params > > from UAC to UAS, UNLESS the UAS identity changes (ie, it is > > retargeted), in which case it should NOT deliver the UAC's original > > but rather the ones of the retargeter. > > Ok, in this scenario, is "contact routing" at the proxy a > retargeting? I'm guessing not. Nope, if it is simply sending it to the same UA "identity" (such as the case when it contact-routes to a registered contact of the AoR identified by the req-uri) then it's not retargeting. Under Christer's proposal, the Target header remains unchanged from whatever it was before that proxy, but req-uri still gets swapped to registered contact; under Jonathan's the req-uri is left alone and a Route header inserted for the registered contact-uri. I think both of them generally assume the same model for what makes up retargeting vs. not. Though it's not clear to me exactly how the proxies can know it. For example if a proxy receives a req-uri for "sip:sales@acme.com", would routing it to "sip:joe@acme.com" based on an ACD list be a retarget or not? What about sending it to "sip:acme.com" and it being routed to a receptionist? > What about originating side operations, like a speed-dial application? I'm not sure I understand why that's different than slow-dialing? I personally don't know what applications need this req-uri param stuff in particular. (I assume so things like Refers and 3xx can expect the params they use to reach the new target) > What about parameters inserted by a proxy? Inserted into the req-uri? Good question... for the authors. :) -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 sip-bounces@ietf.org Tue Apr 8 19:24:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDF63A6E75; Tue, 8 Apr 2008 19:24:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981F63A6EC0 for ; Tue, 8 Apr 2008 19:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.113 X-Spam-Level: X-Spam-Status: No, score=-4.113 tagged_above=-999 required=5 tests=[AWL=2.136, 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 awoq-v3Gr6uk for ; Tue, 8 Apr 2008 19:24:41 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 94C583A6E75 for ; Tue, 8 Apr 2008 19:24:41 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0765220AE8; Wed, 9 Apr 2008 04:24:57 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-dd-47fc28f81cff Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D75B720452; Wed, 9 Apr 2008 04:24:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 04:24:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 04:24:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" thread-index: AciZ2RKZhAHczElORySl93ATHZtKmQADEhQAAADEKWA= References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><28F05913385EAC43AF019413F674A0171246ED51@OCCLUST04EVS1.ugd.att.com><18414.14946.299667.816439@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF15D57E04@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D850371EB4@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DABF84@zrc2hxm0.corp.nortel.com><47B2061B1E5E494B96AA40008300D8503A2F4B@esealmw109.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF15DEE1D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com><1ECE0EB50388174!790F9694F7752! ! ! ! 2 CCF 15 EB7 F 8A@z rc2 hxm0.corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com><7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com><47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se><47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se><47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se><89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Dean Willis" X-OriginalArrivalTime: 09 Apr 2008 02:24:56.0224 (UTC) FILETIME=[E6B67A00:01C899E8] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >>>I believe the mechanism people are looking for is to get the params >>>from UAC to UAS, UNLESS the UAS identity changes (ie, it is >>>retargeted), in which case it should NOT deliver the UAC's original >>>but rather the ones of the retargeter. >> >>Ok, in this scenario, is "contact routing" at the proxy a retargeting? >>I'm guessing not. > >Nope, if it is simply sending it to the same UA "identity" (such as the case when it contact-routes to a registered >contact of the AoR identified by the req-uri) then it's not retargeting. Under Christer's proposal, the Target header >remains unchanged from whatever it was before that proxy, but req-uri still gets swapped to registered contact; under >Jonathan's the req-uri is left alone and a Route header inserted for the registered contact-uri. > >I think both of them generally assume the same model for what makes up retargeting vs. not. Correct. Subclause 3.1 of the Target draft also says: "The terms reroute, translate/translation and retarget are understood as defined in draft-rosenberg-sip-ua-loose-route-01 [8]." 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 sip-bounces@ietf.org Tue Apr 8 19:30:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C4D28C0E2; Tue, 8 Apr 2008 19:30:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DCFB28C25E for ; Tue, 8 Apr 2008 19:30:46 -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 Z-yrGMUhgC8c for ; Tue, 8 Apr 2008 19:30:45 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 939823A6EE2 for ; Tue, 8 Apr 2008 19:30:45 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA02.westchester.pa.mail.comcast.net with comcast id BD0u1Z05y0EZKEL5202n00; Wed, 09 Apr 2008 02:29:50 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA01.westchester.pa.mail.comcast.net with comcast id BEX21Z00202AVH03M00000; Wed, 09 Apr 2008 02:31:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=qqsYfXFzu42-X7HzxxAA:9 a=rYvnpkKsd4F-OxxgcxIA:7 a=f7ZMXKM8E6U3xdwy7mG7k_3l4xkA:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m392V1EA026571 for ; Tue, 8 Apr 2008 22:31:01 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m392V1oX026567; Tue, 8 Apr 2008 22:31:01 -0400 Date: Tue, 8 Apr 2008 22:31:01 -0400 Message-Id: <200804090231.m392V1oX026567@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> (dwing@cisco.com) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Dan Wing" If those URIs included ";user=phone", there is a transitive relationship between the SIP URI and the TEL URI. Without ";user=phone", I agree that no meaning is supposed to be applied to the user-part (the part to the left of the "@"). True. In that case, we have SIP URIs which are essentially aliases for tel URIs. But in that case, any signing should be of the fundamental tel URI, which then obviates the problem with an SBC that translates one alias-URI into another. In SIP, you accomplish something similar to the TCP SYN cookie by sending a SIP request towards the E.164, asking them to sign the request and return it to you. Details are in draft-wing-sip-e164-rrc-01.txt and comments are welcome. It seems like this mechanism is at most as certain as the E.164 mapping that it uses for the "reverse direction". I gather from the Enum people there is some trouble with that. It seems to me that in practice, people don't validate requestors by checking their apparent IP address, but rather by whether they can present certificates. But that is probably an issue that has been hashed over before... 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 sip-bounces@ietf.org Tue Apr 8 19:50:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5D03A694D; Tue, 8 Apr 2008 19:50:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5744F3A694D for ; Tue, 8 Apr 2008 19:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 4Idd-GATSxEu for ; Tue, 8 Apr 2008 19:50:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5BE933A6895 for ; Tue, 8 Apr 2008 19:50:56 -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.240.5; Tue, 8 Apr 2008 22:50:45 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 8 Apr 2008 22:50:45 -0400 From: Hadriel Kaplan To: Rohan Mahy Date: Tue, 8 Apr 2008 22:48:05 -0400 Thread-Topic: [Sip] Comments on sip-outbound-13 Thread-Index: AciY+T8wixZiibNzSQG55HXzKK7ODwAxV0rA Message-ID: References: <953beacc0804071449y11b22ca4tead6a3659a9e9d@mail.gmail.com> In-Reply-To: <953beacc0804071449y11b22ca4tead6a3659a9e9d@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] Comments on sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > > Paul K had an extension to reg-event for GRUU. I think his document > would be a logical place to clarify since GRUU depends on outbound. It does? Geesh. What a tangled web of dependencies we weave. ;) > > 2) If a Register is 3xx redirected, does the new retargeted Register > use the same reg-id, even though it's a different "flow"? (I assume so) I > ask because some people use 3xx for Registers to load-balance or perform > anycasting. It may be good to add this to end of section 4.2.1. > > Yes, the UA uses the same reg-id. It uses the the reg-id to indicate > that this is (for example) my "2nd logical flow" to my registrar or > the logical flow over my "cellular interface". Can you suggest > something here or point out the specific part that is confusing.? I ask because one could get a 3xx for Register at any time, for example while there is an established dialog over that flow. (but it would be weird, and we can't account for all bizarre corner cases) At the end of section 4.2.1, add: "If the registering UA receives a 3xx response to the REGISTER request, such that it moves its registration "flow", it SHOULD reuse the same reg-id value for the moved REGISTER." > > 6) Page 12, Section 4.1: > > "It also provides an easy way to guarantee uniqueness within the AOR." > I'm a bit confused by that, because I don't believe we're saying one UA > instance only ever represents one AoR. (ie, multiple AoR's registered on > the same UA will have the same registered contact instance) Recommend > removing or rewording. > > I don't see the confusion. _Within_ the AOR, the instance-id provides > further disambiguation. I can absolutely use the instance with more > than one AOR. Ahh, then maybe it's a missing comma that screwed me up. Should be: "It also provides an easy way to guarantee uniqueness, within the AoR, when multiple UA's are registered for the same AOR." Otherwise to me it looked like it was claiming the instance guaranteed uniqueness [to] the AoR. > > > 9) Page 16, Section 4.3: > > ... For TLS protocols, there MUST also > > be a match between the host production in the next hop and one of the > > URIs contained in the subjectAltName in the peer certificate. > > s/production in/resolved for/ > > I don't think your proposed rewording is correct. Perhaps s/next > hop/next hop URI/ ? OK. Is "production" a common use for it? Maybe s/production in/portion of/ as well as your URI addition? > > 10) Page 18, Section 4.4.1: > > A User Agent that forms flows, checks if the configured URI to which > > the UA is connecting resolves to a stream-based transport (ex: TCP > > and TLS over TCP). > > That's confusing, because double-CRLF is used for connection-oriented > transports period, not only stream-based ones (ie, also used for SCTP). > And no statement is made about why it checks for stream-based, so I > recommend removing it or clarifying. > > How about: > s/stream-based/connection-oriented/ ? Cool with me. -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 sip-bounces@ietf.org Tue Apr 8 20:05:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DAF28C436; Tue, 8 Apr 2008 20:05:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4C43A6D36 for ; Tue, 8 Apr 2008 20:05:08 -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 5yi1zLEf8k0k for ; Tue, 8 Apr 2008 20:05:05 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id E8ACC3A6AFD for ; Tue, 8 Apr 2008 20:05:02 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA10.westchester.pa.mail.comcast.net with comcast id B7oZ1Z00t0xGWP85A0VH00; Wed, 09 Apr 2008 03:04:17 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA12.westchester.pa.mail.comcast.net with comcast id BF5D1Z00J02AVH03Y00000; Wed, 09 Apr 2008 03:05:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=7UC4F1KthaAxQv_70PQA:9 a=oqU_Yz3zzXRHprxUu4reWPLgzVgA:4 a=mnQxEUBslVAA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m3935DEA029127 for ; Tue, 8 Apr 2008 23:05:13 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m3935DAK029123; Tue, 8 Apr 2008 23:05:13 -0400 Date: Tue, 8 Apr 2008 23:05:13 -0400 Message-Id: <200804090305.m3935DAK029123@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (message from Dean Willis on Tue, 8 Apr 2008 19:40:38 -0500) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <200804082214.m38MER1M007799@dragon.ariadne.com> Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Dean Willis So are you saying that the gateway's calls won't get Identity headers, or that they will, but they'll be signed using a bogus or less-trusted cert than would be used for calls originating from IP terminals that support strong authentication? It seems to me that any identity mechanism of the sort we have been discussing will be used only in specialized cases where strong indentity assurance are needed and can be provided, and that it is likely that gateways won't use it at all, nor will most organizations. 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 sip-bounces@ietf.org Tue Apr 8 21:06:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0033A6EED; Tue, 8 Apr 2008 21:06:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34183A6EEC for ; Tue, 8 Apr 2008 21:06:37 -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 nq6-pI0-rjMp for ; Tue, 8 Apr 2008 21:06:36 -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 6950E3A6EED for ; Tue, 8 Apr 2008 21:06:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,626,1199682000"; d="scan'208";a="4453660" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2008 00:06:53 -0400 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 m3946rrZ002636; Wed, 9 Apr 2008 00:06:53 -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 m3946rvE020409; Wed, 9 Apr 2008 04:06:53 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, 9 Apr 2008 00:06:53 -0400 Received: from [10.86.248.141] ([10.86.248.141]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 00:06:52 -0400 Message-ID: <47FC40F5.508@cisco.com> Date: Wed, 09 Apr 2008 00:07:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752! ! ! ! 2 CCF 15 EB7 F8A@z rc2 hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> In-Reply-To: <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> X-OriginalArrivalTime: 09 Apr 2008 04:06:52.0839 (UTC) FILETIME=[247FDB70:01C899F7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1996; t=1207714013; x=1208578013; 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]=20Long=3A=20Thoughts=20on=20=22re targeting=20proposals=22 |Sender:=20 |To:=20Dean=20Willis=20; bh=dyouhLCTep+smdz84w3Zr53YN8q3zguhBdPL4ist60A=; b=PAowHSMBkCaDVGctnSiWzhpqXEVrIXSAJ4/U2kHw+gXf2eytjndBVwf3bB +qgYb1BZSmXsFkqMyjfM3UMQI5+12+iWSer0zeVovwK2/X9DYQMlqIoocqX5 23z/9/7zYr; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org" Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org One thing is troubling me in this discussion: What are these parameters? Who is inserting them, and why? In my world view clients don't *generate* URIs. Rather they use URIs that have been given to them, or that they have looked up in some public registry. URIs are *created* by the recipient. In this regard they are much like postal addresses. Part of a postal address is routing, like the domain name in a URI. But the rest is like the user part of a URI. If you start sticking extra stuff into a postal address, the post office might get it to the right mailbox, but its likely to be tossed in the trash, or the extra stuff ignored. By that logic, parameters on a URI should not be passed along when a request is retargeted. The parameters are meaningful, if at all, to the retargeter. It may in fact use them to decide where to retarget. But by the same logic it shouldn't be attaching them to the retargeted URI because that amounts to constructing a URI for someone else. It should only be selecting among URIs its been given as new targets. Paul Dean Willis wrote: > On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: >> I believe the mechanism people are looking for is to get the params >> from UAC to UAS, UNLESS the UAS identity changes (ie, it is >> retargeted), in which case it should NOT deliver the UAC's original >> but rather the ones of the retargeter. > > Ok, in this scenario, is "contact routing" at the proxy a > retargeting? I'm guessing not. > > What about originating side operations, like a speed-dial application? > > What about parameters inserted by a proxy? > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 8 21:22:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA453A6EEE; Tue, 8 Apr 2008 21:22:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149D73A6CEB for ; Tue, 8 Apr 2008 21:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=1.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 Zwafg6YcbHcy for ; Tue, 8 Apr 2008 21:22:49 -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 12BF228C17A for ; Tue, 8 Apr 2008 21:22:49 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2008 21:23:06 -0700 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 m394N6Se009740; Tue, 8 Apr 2008 21:23:06 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m394N63a018519; Wed, 9 Apr 2008 04:23:06 GMT From: "Dan Wing" To: , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> Date: Tue, 8 Apr 2008 21:23:05 -0700 Message-ID: <406b01c899f9$68c470f0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200804090231.m392V1oX026567@dragon.ariadne.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciZ6dPOd8MeNZcxROqfsUMQkWaaGgADxpTg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2088; t=1207714986; x=1208578986; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=IRWWZU8MtGSt2EzMueThQkydoHtHJlNHP7qXwjBRs0w=; b=Lmh80DCUNcd0HHKRh3LYd3OXf0FMjv7DlaD/EkBn6q3OaxJCkZctSdkhov P/lVnlaC/BqwLpFWOpiNudRxpzPJAfAV85YFVfDNHbuYL++r2YLvLGfQbOJ5 qLmviDb/PR; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dale.Worley@comcast.net > Sent: Tuesday, April 08, 2008 7:31 PM > To: sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > From: "Dan Wing" > > If those URIs included ";user=phone", there is a transitive > relationship between the SIP URI and the TEL URI. Without > ";user=phone", I agree that no meaning is supposed to be applied > to the user-part (the part to the left of the "@"). > > True. In that case, we have SIP URIs which are essentially aliases > for tel URIs. But in that case, any signing should be of the > fundamental tel URI, which then obviates the problem with an SBC that > translates one alias-URI into another. But the only mechanism we have to sign, RFC4474, does not provide a way to sign a tel URI. > In SIP, you accomplish something similar to the TCP SYN cookie by > sending a SIP request towards the E.164, asking them to sign the > request and return it to you. Details are in > draft-wing-sip-e164-rrc-01.txt and comments are welcome. > > It seems like this mechanism is at most as certain as the E.164 > mapping that it uses for the "reverse direction". I gather from the > Enum people there is some trouble with that. I don't understand your statement; draft-wing-sip-e164-rrc-01.txt does not use ENUM, rather it uses the same routing that the SIP network (of proxies, B2BUAs, and SBCs) uses. > It seems to me that in practice, people don't validate requestors by > checking their apparent IP address, but rather by whether they can > present certificates. But that is probably an issue that has been > hashed over before... draft-wing-sip-e164-rrc-01.txt does not have people perform the reverse routability check. The reverse routability check happens without the users noticing, as part of validating that an E.164 request that just arrived would have a new request (towards that same E.164) routing in the same direction. -d _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 8 21:23:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CC03A6E2A; Tue, 8 Apr 2008 21:23:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177D53A6ADE for ; Tue, 8 Apr 2008 21:23:42 -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 AVuZWiA-lh3G for ; Tue, 8 Apr 2008 21:23:41 -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 17F7F3A6A92 for ; Tue, 8 Apr 2008 21:23:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,626,1199682000"; d="scan'208";a="4455183" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2008 00:23:57 -0400 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 m394NvN5009346; Wed, 9 Apr 2008 00:23:57 -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 m394NvSr023462; Wed, 9 Apr 2008 04:23:57 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, 9 Apr 2008 00:23:57 -0400 Received: from [10.86.248.141] ([10.86.248.141]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 00:23:57 -0400 Message-ID: <47FC44F6.3040802@cisco.com> Date: Wed, 09 Apr 2008 00:24:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <200804082214.m38MER1M007799@dragon.ariadne.com> <200804090305.m3935DAK029123@dragon.ariadne.com> In-Reply-To: <200804090305.m3935DAK029123@dragon.ariadne.com> X-OriginalArrivalTime: 09 Apr 2008 04:23:57.0662 (UTC) FILETIME=[87576FE0:01C899F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1542; t=1207715037; x=1208579037; 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]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=caj6MRNbd9NgCi/ZprCTkE7vFJ7S/mHQh3sQvsiyaNo=; b=AD0o8FOxGB00mCZe10j7O/6nDk8lS51jOaQAwd6vUutmlrj6nwRBNu890g VlDSOhM5K1iled93qUPCCxeFVNUsXp5OLG0n0kqod379BxY7r0C9S5uyNujD D8gZAgZIWR; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale, Suppose you are building a sip adapter for black phones. (Well, black phones with a callerid display.) What criteria should it use before displaying the callerid of the incoming call? It is restricted by hardware and convention regarding what it displays - generally just digits for the number. The customer is going to be upset if he just replaced a pstn phone, and isn't getting callerid from the same callers he used to get it from. OTOH, the phone is likely to be worried about trusting From - its just too easy to forge. Paul Dale.Worley@comcast.net wrote: > From: Dean Willis > > So are you saying that the gateway's calls won't get Identity headers, > or that they will, but they'll be signed using a bogus or less-trusted > cert than would be used for calls originating from IP terminals that > support strong authentication? > > It seems to me that any identity mechanism of the sort we have been > discussing will be used only in specialized cases where strong > indentity assurance are needed and can be provided, and that it is > likely that gateways won't use it at all, nor will most organizations. > > 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 sip-bounces@ietf.org Tue Apr 8 22:25:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9BF3A68AF; Tue, 8 Apr 2008 22:25:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1ED3A6856 for ; Tue, 8 Apr 2008 22:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.165 X-Spam-Level: X-Spam-Status: No, score=-4.165 tagged_above=-999 required=5 tests=[AWL=2.084, 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 e2fDoBr+5lUO for ; Tue, 8 Apr 2008 22:25:41 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2B6563A67E3 for ; Tue, 8 Apr 2008 22:25:41 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E1F1B21353; Wed, 9 Apr 2008 07:24:04 +0200 (CEST) X-AuditID: c1b4fb3e-ad196bb000004ec0-9f-47fc52f44f16 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C5A7D2133D; Wed, 9 Apr 2008 07:24:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 07:24:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 07:24:03 +0200 Message-ID: In-Reply-To: <47FC40F5.508@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" thread-index: AciZ9zTPPun0HbsDTCiaAKTWuyygqgACZvoQ References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752!! ! ! 2 CCF 15 EB7 F8A@z rc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> <47FC40F5.508@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Dean Willis" X-OriginalArrivalTime: 09 Apr 2008 05:24:04.0518 (UTC) FILETIME=[ED31FC60:01C89A01] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, IF the problem was to provide URI parameters "end-to-end", independent of re-targets etc, I think that could be solved using the To header. The ua-loose-route draft says: "When a SIP call is forwarded (also known as retargeting), the actual target of the address changes completely, but the To field does not." In addition, the draft says: "When a retargeting operation happens, the URI that needs to be delivered to the UAS is the SIP address or name after the most recent retargeting operation." ...and I think that is what Paul is also saying. Regards, Christer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 9. huhtikuuta 2008 7:07 To: Dean Willis Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" One thing is troubling me in this discussion: What are these parameters? Who is inserting them, and why? In my world view clients don't *generate* URIs. Rather they use URIs that have been given to them, or that they have looked up in some public registry. URIs are *created* by the recipient. In this regard they are much like postal addresses. Part of a postal address is routing, like the domain name in a URI. But the rest is like the user part of a URI. If you start sticking extra stuff into a postal address, the post office might get it to the right mailbox, but its likely to be tossed in the trash, or the extra stuff ignored. By that logic, parameters on a URI should not be passed along when a request is retargeted. The parameters are meaningful, if at all, to the retargeter. It may in fact use them to decide where to retarget. But by the same logic it shouldn't be attaching them to the retargeted URI because that amounts to constructing a URI for someone else. It should only be selecting among URIs its been given as new targets. Paul Dean Willis wrote: > On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: >> I believe the mechanism people are looking for is to get the params >> from UAC to UAS, UNLESS the UAS identity changes (ie, it is >> retargeted), in which case it should NOT deliver the UAC's original >> but rather the ones of the retargeter. > > Ok, in this scenario, is "contact routing" at the proxy a > retargeting? I'm guessing not. > > What about originating side operations, like a speed-dial application? > > What about parameters inserted by a proxy? > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 8 22:27:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B663A6931; Tue, 8 Apr 2008 22:27:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DAE3A6931 for ; Tue, 8 Apr 2008 22:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 ZHMxjtM9p0BS for ; Tue, 8 Apr 2008 22:27:37 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 930813A6784 for ; Tue, 8 Apr 2008 22:27:37 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id C98D22175B3; Tue, 8 Apr 2008 22:27:54 -0700 (PDT) Date: Tue, 08 Apr 2008 22:27:54 -0700 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080409052754.C98D22175B3@kilo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Tue, 8 Apr 2008 17:01:40 -0700, Dan Wing wrote: > > If you mean "the E.164 number +123456789", say . > > > > I don't see anything that will go wrong if people pay attention > > to what URIs are defined to mean. > > > > Now there is a problem with signing tel: URIs, how do you determine > > that the signer has the authority to sign a particular tel: URI, but > > that's a delegation-of-authority problem that is not inherently > > different from other delegation-of-authority problems -- you need a > > publicly-known root authority and a tree of delegations. > > That is one approach to determining who owns something. > > I have a different approach, which I derived from how we determine if > someone owns an IP address when we receive a TCP SYN that is > proportedly from that IP address: challange them to prove that > packets route the other way. Afterall, the Internet does not have > a central authority for who owns an IP address (or else we could > secure BGP routing better than we secure it today). > > In SIP, you accomplish something similar to the TCP SYN cookie by > sending a SIP request towards the E.164, asking them to sign the > request and return it to you. Details are in > draft-wing-sip-e164-rrc-01.txt and comments are welcome. While withholding judgement on draft-wing-sip-e164-rrc-01, I don't think this is that accurate a description of what can be inferred from the fact that a peer can complete a TCP connection initiated with a given source IP address. As you say, in order to allow a TCP connection to be established, the passive endpoint requires the active endpoint to prove (for some value of prove) that it received the passive endpoint's SYN/ACK by ACKing the passive endpoint's ISN. This arguably serves at least two security purposes: - Prevention of DoS: TCP connections consume resources on the client. Forcing the client to ACK the ISN prevents blind resource consumption attacks on the passive endpoint. (This can also be combined with a stateless cookie technique, aka SYN cookies) to produce a system where no state is consumed on the passive endpoint until the liveness check is passed. - Endpoint authentication: the ability of the active endpoint to ACK the ISN demonstrates that the active endpoint is on-path from the passive endpoint to the claimed initiating source IP address. This second guarantee is very weak for three reasons: (1) Many TCP stacks do not use sufficiently random PRNGs to generate the ISN, in which case sequence number prediction attacks are a real problem. (2) Even if the ISN is randomly generated, there are only 32 bits of ISN, so it's at least theoretically possible to guess it in a blind attack (though of course very expensive). (3) Even if we ignore the previous two considerations, all that the ability to ACK the ISN indicates is that the attacker is on-path. There are many situations in which an attacker is on-path (wireless being a commonly cited case). It's precisely for these reasons that one cannot use source IP authentication for TCP connections on the public Internet, that mechanisms such as .rhosts are deprecated, and that cryptographic mechanisms such as IPsec were designed. Incidentally, this third deficiency seems to me to be shared by draft-wing-sip-e164-rrc. Any attacker who is on path between the relying party and the target of the return routability check (either because they are on-path in the SIP routing fabric or because they are able to observe one of the links) will be able to pass the return routability check. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 03:27:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946B43A69F9; Wed, 9 Apr 2008 03:27:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EED3A69F9; Wed, 9 Apr 2008 03:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, MIME_BASE64_TEXT=1.753, 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 QS1PEBnNbfUs; Wed, 9 Apr 2008 03:27:08 -0700 (PDT) Received: from smtp05.bis.na.blackberry.com (smtp05.bis.na.blackberry.com [216.9.248.52]) by core3.amsl.com (Postfix) with ESMTP id AD3C73A69D0; Wed, 9 Apr 2008 03:27:08 -0700 (PDT) Received: from bxe145.bisx.prod.on.blackberry (bxe145.bisx.prod.on.blackberry [172.20.225.174]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id m398kHB9008768; Wed, 9 Apr 2008 10:27:22 GMT X-rim-org-msg-ref-id: 1663003971 Message-ID: <1663003971-1207736842-cardhu_decombobulator_blackberry.rim.net-1296993744-@bxe145.bisx.prod.on.blackberry> X-Priority: Normal References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <200804082214.m38MER1M007799@dragon.ariadne.com> <200804090305.m3935DAK029123@dragon.ariadne.com><47FC44F6.3040802@cisco.com> In-Reply-To: <47FC44F6.3040802@cisco.com> Sensitivity: Normal Importance: Normal To: "Paul Kyzivat" , sip-bounces@ietf.org, Dale.Worley@comcast.net From: "=?utf-8?B?RGFuIFlvcms=?=" Date: Wed, 9 Apr 2008 10:27:46 +0000 MIME-Version: 1.0 Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dyork@voxeo.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org +1 The reality is that while most of us may be aware that CallerID in the PSTN is easy to forge (and if you aren't, send me your number and I'll call you :-), the VAST majority of regular phone users actually *trust* the CallerID. So if a call comes in with the CallerID of your bank and you wind up talking to a very nice "representative", most folks will accept that as real. (I don't, but I am a paranoid security guy.) SIP without strong identity just makes it that much more trivial to spoof CallerID. It's a wonderful playground for identity thieves, phishers, fraudsters and pranksters. Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com -----Original Message----- From: Paul Kyzivat Date: Wed, 09 Apr 2008 00:24:22 To:Dale.Worley@comcast.net Cc:sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN Dale, Suppose you are building a sip adapter for black phones. (Well, black phones with a callerid display.) What criteria should it use before displaying the callerid of the incoming call? It is restricted by hardware and convention regarding what it displays - generally just digits for the number. The customer is going to be upset if he just replaced a pstn phone, and isn't getting callerid from the same callers he used to get it from. OTOH, the phone is likely to be worried about trusting From - its just too easy to forge. Paul Dale.Worley@comcast.net wrote: > From: Dean Willis > > So are you saying that the gateway's calls won't get Identity headers, > or that they will, but they'll be signed using a bogus or less-trusted > cert than would be used for calls originating from IP terminals that > support strong authentication? > > It seems to me that any identity mechanism of the sort we have been > discussing will be used only in specialized cases where strong > indentity assurance are needed and can be provided, and that it is > likely that gateways won't use it at all, nor will most organizations. > > 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 _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 03:37:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838BF3A6A42; Wed, 9 Apr 2008 03:37:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD7F3A6B8E for ; Wed, 9 Apr 2008 03:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 i95kqIryRt7M for ; Wed, 9 Apr 2008 03:37:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2439E3A68FE for ; Wed, 9 Apr 2008 03:37:32 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 09C9F21227; Wed, 9 Apr 2008 12:37:49 +0200 (CEST) X-AuditID: c1b4fb3e-af19abb000004ec0-80-47fc9c7ca2c6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D59F92106E; Wed, 9 Apr 2008 12:37:48 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 12:37:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 12:37:48 +0200 Message-ID: <47B2061B1E5E494B96AA40008300D8504DFF28@esealmw109.eemea.ericsson.se> In-Reply-To: <47FC40F5.508@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" thread-index: AciZ9zUMUVGiNM+VSLu9jsAMp4YkIgANmAwg References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><1ECE0EB50388174790F9694F77522CCF15E39032@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752!! ! ! 2 CCF 15 EB7 F8A@z rc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> <47FC40F5.508@cisco.com> From: "Hans Erik van Elburg" To: "Paul Kyzivat" , "Dean Willis" X-OriginalArrivalTime: 09 Apr 2008 10:37:48.0237 (UTC) FILETIME=[C1018FD0:01C89A2D] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is also my understanding. /Hans Erik -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, April 09, 2008 6:07 AM To: Dean Willis Cc: sip@ietf.org Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" One thing is troubling me in this discussion: What are these parameters? Who is inserting them, and why? In my world view clients don't *generate* URIs. Rather they use URIs that have been given to them, or that they have looked up in some public registry. URIs are *created* by the recipient. In this regard they are much like postal addresses. Part of a postal address is routing, like the domain name in a URI. But the rest is like the user part of a URI. If you start sticking extra stuff into a postal address, the post office might get it to the right mailbox, but its likely to be tossed in the trash, or the extra stuff ignored. By that logic, parameters on a URI should not be passed along when a request is retargeted. The parameters are meaningful, if at all, to the retargeter. It may in fact use them to decide where to retarget. But by the same logic it shouldn't be attaching them to the retargeted URI because that amounts to constructing a URI for someone else. It should only be selecting among URIs its been given as new targets. Paul Dean Willis wrote: > On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: >> I believe the mechanism people are looking for is to get the params >> from UAC to UAS, UNLESS the UAS identity changes (ie, it is >> retargeted), in which case it should NOT deliver the UAC's original >> but rather the ones of the retargeter. > > Ok, in this scenario, is "contact routing" at the proxy a > retargeting? I'm guessing not. > > What about originating side operations, like a speed-dial application? > > What about parameters inserted by a proxy? > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 04:24:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B308D3A68FE; Wed, 9 Apr 2008 04:24:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA043A68D9 for ; Wed, 9 Apr 2008 04:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=1.660, BAYES_00=-2.599, HELO_EQ_DE=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 Lzn+AVHnVtqj for ; Wed, 9 Apr 2008 04:24:02 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 8FF5A3A6842 for ; Wed, 9 Apr 2008 04:24:01 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id m39BNtjs023689; Wed, 9 Apr 2008 13:23:55 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m39BNtTR021067; Wed, 9 Apr 2008 13:23:55 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Apr 2008 13:23:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 13:23:52 +0200 Message-ID: <198A10EC585EC74687BCA414E2A597180216847D@MCHP7RDA.ww002.siemens.net> In-Reply-To: <3d0301c899bc$ebd14140$c5f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Migration from E.164 to email-style SIP URIs Thread-Index: AciWIhrd+i/w+GvMR/qpIDmZzkoKXgAiHDhQAHbjyyAAEWWwAAAjXfQgABbd99AAHtqV4A== References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <155b01c896af$f57ca910$c5f0200a@cisco.com> <198A10EC585EC74687BCA414E2A597180211ADCC@MCHP7RDA.ww002.siemens.net> <1e3401c898cc$7ef98050$c5f0200a@cisco.com> <198A10EC585EC74687BCA414E2A597180216837C@MCHP7RDA.ww002.siemens.net> <3d0301c899bc$ebd14140$c5f0200a@cisco.com> From: "Fischer, Kai" To: "Dan Wing" , X-OriginalArrivalTime: 09 Apr 2008 11:23:54.0401 (UTC) FILETIME=[31C4B110:01C89A34] Cc: "Elwell, John" Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Dienstag, 8. April 2008 23:10 > To: Fischer, Kai; sip@ietf.org > Cc: Elwell, John > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > > -----Original Message----- > > From: Fischer, Kai [mailto:kai.fischer@siemens.com] > > Sent: Tuesday, April 08, 2008 6:32 AM > > To: Dan Wing; sip@ietf.org > > Cc: Elwell, John > > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > > > Let's explore your proposal further regarding the problems > > discussed in > > the other two threads (sorry for mixing the email threads > > now, but it is > > close related to the migration proposal): > > > > First problem: Weak PSTN numbers > > Proposal > > - Don't include the E.164 number in the signature if it was received > > from the PSTN (certificate fingerprint is still protected > and bound to > > the email-style SIP URI of SIP Gateway provided in 'email-identity') > > - Include the E.164 number in the signature if not received from the > > PSTN > > That's independent from the concrete signing mechanism > except that RFC > > 4474 does not cover the new header field > > > > Second problem: SBC traversal > > - If both identity information are signed it conflicts with SBCs > > modifying SDP information and therefore need to change the > domain part > > of the SIP URI in the From header as well > > - If only the email-identity information is signed (by the > Wing/Kaplan > > or Fischer draft), intermediary SBCs should not break the signature. > > However, the E.164 number has PSTN security level only as > > assumed above, > > but email-style is bound to certificate fingerprint and signed > > > > An straw man extension to your proposal, which mitigates the SBC > > traversal problem is to create two signatures. One signing the > > email-identity including the certificate fingerprint and which is > > protected end-to-end. The other one covering the From > header field and > > which might re-newed during traversal by intermediaries. The > > disadvantage are for sure two signing processes. > > Sure, you could do that. > > But at this point in time it seems there is little value in > RFC4474 signatures if there are SBCs on the path; if the SBCs > support RFC4474, they will have to re-sign the identity and > will have to re-write the From. In such a situation, RFC4474 > provides protection of SIP requests being modified between > the Service Provider (running the SBC) and yourself. You can > achieve identical protection from the same attack by doing > SIP-over-(D)TLS with that same SBC, and not bothering with > RFC4474 (or RFC4916) to/from that SBC. I agree to that. The other way around, the second signature provides additional benfit (end-to-end property) if RFC 4474 is used in that scenarios for some reason. But that depends if the outcome of the 'RFC 4474 and SBC traversal' email thread is - Yes, there is a problem which need to be fixed or - No problem, RFC 4474 is applicable in these scenarios Kai > > (I would even go so far to say that, in the same case with > your provider running an SBC, running SIP-over-(D)TLS to that > provider is superior to RFC4474 because SIP-over-(D)TLS > protects SIP responses; neither RFC4474 or RFC4916 protect > SIP responses.) > > -d > > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 06:21:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCBF28C3B4; Wed, 9 Apr 2008 06:21:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB683A6A6C for ; Wed, 9 Apr 2008 06:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.108 X-Spam-Level: X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[AWL=1.491, 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 HO7HVL09tHls for ; Wed, 9 Apr 2008 06:21:35 -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 84F323A6B8E for ; Wed, 9 Apr 2008 06:21:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,629,1199682000"; d="scan'208";a="4491387" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2008 09:21:27 -0400 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 m39DLQIY023017; Wed, 9 Apr 2008 09:21:26 -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 m39DI6CR005866; Wed, 9 Apr 2008 13:21: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); Wed, 9 Apr 2008 09:19:39 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 09:19:39 -0400 Message-ID: <47FCC285.8010207@cisco.com> Date: Wed, 09 Apr 2008 09:20:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Christer Holmberg References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752!! ! ! 2 CCF 15 EB7 F8A@z rc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> <47FC40F5.508@cisco.com> In-Reply-To: X-OriginalArrivalTime: 09 Apr 2008 13:19:39.0358 (UTC) FILETIME=[5D4907E0:01C89A44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3561; t=1207747287; x=1208611287; 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]=20Long=3A=20Thoughts=20on=20=22re targeting=20proposals=22 |Sender:=20 |To:=20Christer=20Holmberg=20; bh=/cNPVSrjMKpfWM4a5qSp51Zl8fRmwtmOb0afohtCIi4=; b=FiYAf8uiB+sv7zxFOmVFB+tiRa3Vl0ssWTdC47rMz0Dkz8F6ituWT2OQ5O GTOmE+ruTuVpBMEq0jalgU5WxF+Rzmlt8SNZzRAFuSj0F/tqwKKFYM5NKCQt b3SPZs/jxA; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, Dean Willis Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > > IF the problem was to provide URI parameters "end-to-end", independent > of re-targets etc, I think that could be solved using the To header. Of course SBCs are inclined to change To headers also, so even they aren't safe. In fact, *nothing* is safe from an SBC. (They are lurking behind every door and corner, waiting to mess up your message under the guise of "fixing" it.) Paul > The ua-loose-route draft says: > > "When a SIP call is forwarded (also known as retargeting), the actual > target of the address changes completely, > but the To field does not." > > In addition, the draft says: > > "When a retargeting operation happens, the URI that needs to be > delivered to the UAS is the SIP address or name > after the most recent retargeting operation." > > ...and I think that is what Paul is also saying. > > Regards, > > Christer > > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 9. huhtikuuta 2008 7:07 > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" > > One thing is troubling me in this discussion: > > What are these parameters? Who is inserting them, and why? > > In my world view clients don't *generate* URIs. Rather they use URIs > that have been given to them, or that they have looked up in some public > registry. URIs are *created* by the recipient. > > In this regard they are much like postal addresses. Part of a postal > address is routing, like the domain name in a URI. But the rest is like > the user part of a URI. If you start sticking extra stuff into a postal > address, the post office might get it to the right mailbox, but its > likely to be tossed in the trash, or the extra stuff ignored. > > By that logic, parameters on a URI should not be passed along when a > request is retargeted. The parameters are meaningful, if at all, to the > retargeter. It may in fact use them to decide where to retarget. But by > the same logic it shouldn't be attaching them to the retargeted URI > because that amounts to constructing a URI for someone else. It should > only be selecting among URIs its been given as new targets. > > Paul > > Dean Willis wrote: >> On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: >>> I believe the mechanism people are looking for is to get the params >>> from UAC to UAS, UNLESS the UAS identity changes (ie, it is >>> retargeted), in which case it should NOT deliver the UAC's original >>> but rather the ones of the retargeter. >> Ok, in this scenario, is "contact routing" at the proxy a >> retargeting? I'm guessing not. >> >> What about originating side operations, like a speed-dial application? >> >> What about parameters inserted by a proxy? >> >> -- >> 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 >> > _______________________________________________ > 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 sip-bounces@ietf.org Wed Apr 9 06:52:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C4E3A69ED; Wed, 9 Apr 2008 06:52:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C583A6CEA for ; Wed, 9 Apr 2008 06:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.985 X-Spam-Level: X-Spam-Status: No, score=-103.985 tagged_above=-999 required=5 tests=[AWL=2.614, 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 2Rbg9NV194KX for ; Wed, 9 Apr 2008 06:52:11 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id EEC073A6981 for ; Wed, 9 Apr 2008 06:52:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1207749147!22876180!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23292 invoked from network); 9 Apr 2008 13:52:27 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 9 Apr 2008 13:52:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m39DqQPl010186 for ; Wed, 9 Apr 2008 09:52:26 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m39DqKEq010111 for ; Wed, 9 Apr 2008 09:52:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 08:52:21 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246EE24@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <47FCC285.8010207@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" Thread-Index: AciaRL+gKXXU8VCKRe2Qeoh6yt9ulAAA+V1A References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752!!! ! 2 CCF 15 EB7 F8A@zrc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com><47FC40F5.508@cisco.com> <47F CC285.80 10207@cisco.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Paul Kyzivat" , "Christer Holmberg" Cc: sip@ietf.org, Dean Willis Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, I do not think the question is where SBCs are, but rather where they are not. The reality is a solution needs to address that, either that or the forum developing a solution is not in touch with reality. Martin -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, April 09, 2008 9:20 AM To: Christer Holmberg Cc: sip@ietf.org; Dean Willis Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" Christer Holmberg wrote: > Hi, > > IF the problem was to provide URI parameters "end-to-end", independent > of re-targets etc, I think that could be solved using the To header. Of course SBCs are inclined to change To headers also, so even they aren't safe. In fact, *nothing* is safe from an SBC. (They are lurking behind every door and corner, waiting to mess up your message under the guise of "fixing" it.) Paul > The ua-loose-route draft says: > > "When a SIP call is forwarded (also known as retargeting), the actual > target of the address changes completely, > but the To field does not." > > In addition, the draft says: > > "When a retargeting operation happens, the URI that needs to be > delivered to the UAS is the SIP address or name > after the most recent retargeting operation." > > ...and I think that is what Paul is also saying. > > Regards, > > Christer > > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 9. huhtikuuta 2008 7:07 > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" > > One thing is troubling me in this discussion: > > What are these parameters? Who is inserting them, and why? > > In my world view clients don't *generate* URIs. Rather they use URIs > that have been given to them, or that they have looked up in some public > registry. URIs are *created* by the recipient. > > In this regard they are much like postal addresses. Part of a postal > address is routing, like the domain name in a URI. But the rest is like > the user part of a URI. If you start sticking extra stuff into a postal > address, the post office might get it to the right mailbox, but its > likely to be tossed in the trash, or the extra stuff ignored. > > By that logic, parameters on a URI should not be passed along when a > request is retargeted. The parameters are meaningful, if at all, to the > retargeter. It may in fact use them to decide where to retarget. But by > the same logic it shouldn't be attaching them to the retargeted URI > because that amounts to constructing a URI for someone else. It should > only be selecting among URIs its been given as new targets. > > Paul > > Dean Willis wrote: >> On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: >>> I believe the mechanism people are looking for is to get the params >>> from UAC to UAS, UNLESS the UAS identity changes (ie, it is >>> retargeted), in which case it should NOT deliver the UAC's original >>> but rather the ones of the retargeter. >> Ok, in this scenario, is "contact routing" at the proxy a >> retargeting? I'm guessing not. >> >> What about originating side operations, like a speed-dial application? >> >> What about parameters inserted by a proxy? >> >> -- >> 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 >> > _______________________________________________ > 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 sip-bounces@ietf.org Wed Apr 9 07:45:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89113A6B30; Wed, 9 Apr 2008 07:45:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6343A6A17 for ; Wed, 9 Apr 2008 07:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 CKWZlDUambq0 for ; Wed, 9 Apr 2008 07:45:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4E4653A6964 for ; Wed, 9 Apr 2008 07:44:55 -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.240.5; Wed, 9 Apr 2008 10:44:45 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 9 Apr 2008 10:44:45 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Christer Holmberg Date: Wed, 9 Apr 2008 10:42:08 -0400 Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" Thread-Index: AciaRKosvJeWD+G2T+KBSTPY3o/ILwACljrQ Message-ID: References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752!! ! ! 2 CCF 15 EB7 F8A@z rc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> <47FC40F5.508@cisco.com> <47FCC285.8010207@cisco.com> In-Reply-To: <47FCC285.8010207@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Dean Willis Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > Christer Holmberg wrote: > > Hi, > > > > IF the problem was to provide URI parameters "end-to-end", independent > > of re-targets etc, I think that could be solved using the To header. > > Of course SBCs are inclined to change To headers also, so even they > aren't safe. In fact, *nothing* is safe from an SBC. > (They are lurking behind every door and corner, waiting to mess up your > message under the guise of "fixing" it.) Yes, what we're actually trying to do is secretly replace your URI's with Folger's crystals, to see if anyone can tell the difference. Detecting it is pretty easy though - just look for "AYBABTU" in the URI. -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 sip-bounces@ietf.org Wed Apr 9 08:34:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E16D28C480; Wed, 9 Apr 2008 08:34:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE8328C480 for ; Wed, 9 Apr 2008 08:34:24 -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 A66AWkwYwJy0 for ; Wed, 9 Apr 2008 08:34: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 2461C28C454 for ; Wed, 9 Apr 2008 08:34:19 -0700 (PDT) Received: from [192.168.2.6] (pool-71-164-164-40.dllstx.fios.verizon.net [71.164.164.40]) (authenticated bits=0) by nostrum.com (8.14.2/8.14.1) with ESMTP id m39FYVDk066466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2008 10:34:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 10:34:31 -0500 References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752!! ! ! 2 CCF 15 EB7 F8A@z rc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> <47FC40F5.508@cisco.com> ! <47FCC285.8010207@cisco.com> X-Mailer: Apple Mail (2.919.2) Received-SPF: pass (nostrum.com: 71.164.164.40 is authenticated by a trusted mechanism) Cc: "sip@ietf.org" , Paul Kyzivat , Dean Willis , Christer Holmberg Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Call-Info: On Apr 9, 2008, at 9:42 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >> Of Paul >> Kyzivat >> >> Christer Holmberg wrote: >>> Hi, >>> >>> IF the problem was to provide URI parameters "end-to-end", >>> independent >>> of re-targets etc, I think that could be solved using the To header. >> >> Of course SBCs are inclined to change To headers also, so even they >> aren't safe. In fact, *nothing* is safe from an SBC. >> (They are lurking behind every door and corner, waiting to mess up >> your >> message under the guise of "fixing" it.) > > Yes, what we're actually trying to do is secretly replace your URI's > with Folger's crystals, to see if anyone can tell the difference. > Detecting it is pretty easy though - just look for "AYBABTU" in the > URI. > > -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 _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 08:44:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CCD3A68E8; Wed, 9 Apr 2008 08:44:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6D43A688F for ; Wed, 9 Apr 2008 08:44:47 -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 9F9azklMoLLO for ; Wed, 9 Apr 2008 08:44:46 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 4140328C40F for ; Wed, 9 Apr 2008 08:44:45 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id BNdK1Z0050bG4ec540LL00; Wed, 09 Apr 2008 15:43:25 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA03.westchester.pa.mail.comcast.net with comcast id BTkQ1Z00702AVH03P00000; Wed, 09 Apr 2008 15:44:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=POpvjHfouNYTxNlDHuIA:9 a=wNeDIOSZLG0Tc4uBjBx0KPJBew0A:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m39FiOEA020179 for ; Wed, 9 Apr 2008 11:44:24 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m39FiN9C020175; Wed, 9 Apr 2008 11:44:24 -0400 Date: Wed, 9 Apr 2008 11:44:24 -0400 Message-Id: <200804091544.m39FiN9C020175@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <47FC44F6.3040802@cisco.com> (message from Paul Kyzivat on Wed, 09 Apr 2008 00:24:22 -0400) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <200804082214.m38MER1M007799@dragon.ariadne.com> <200804090305.m3935DAK029123@dragon.ariadne.com> <47FC44F6.3040802@cisco.com> Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: Paul Kyzivat Suppose you are building a sip adapter for black phones. (Well, black phones with a callerid display.) What criteria should it use before displaying the callerid of the incoming call? That there is a From header. People have just argued at great length that PSTN caller ID is not trustable, so displaying a From header has the same level of security. 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 sip-bounces@ietf.org Wed Apr 9 08:55:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB1C3A6B90; Wed, 9 Apr 2008 08:55:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F003A68FE for ; Wed, 9 Apr 2008 08:55: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=[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 AWRkE-s9Cflq for ; Wed, 9 Apr 2008 08:55:29 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id EC91128C3FF for ; Wed, 9 Apr 2008 08:55:08 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA03.westchester.pa.mail.comcast.net with comcast id BTaQ1Z05B0cZkys5300d00; Wed, 09 Apr 2008 15:53:58 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA10.westchester.pa.mail.comcast.net with comcast id BTvM1Z00B02AVH03W00000; Wed, 09 Apr 2008 15:55:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=FoBuVND2c64YYXg0ezoA:9 a=Ti9omB-D2nZtEY7kKswA:7 a=IE5vfC6B2_pYe7xl9WhwH4xyJg8A:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m39FtLEA020993 for ; Wed, 9 Apr 2008 11:55:21 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m39FtLa6020989; Wed, 9 Apr 2008 11:55:21 -0400 Date: Wed, 9 Apr 2008 11:55:21 -0400 Message-Id: <200804091555.m39FtLa6020989@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <406b01c899f9$68c470f0$c5f0200a@cisco.com> (dwing@cisco.com) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Dan Wing" > If those URIs included ";user=phone", there is a transitive > relationship between the SIP URI and the TEL URI. Without > ";user=phone", I agree that no meaning is supposed to be applied > to the user-part (the part to the left of the "@"). > > True. In that case, we have SIP URIs which are essentially aliases > for tel URIs. But in that case, any signing should be of the > fundamental tel URI, which then obviates the problem with an SBC that > translates one alias-URI into another. But the only mechanism we have to sign, RFC4474, does not provide a way to sign a tel URI. OK, so we have several different URIs, sip:1234@domain;user=phone, which are understood to be equivalent to tel:1234 and also to each other, and because of that, SBCs feel free to translate each of these into each other, but the signing mechanism generates signatures which depend on which of these particular URIs is present. So you have to change either your signing mechanism to recognize the equivalence, or your SBCs to stop exploiting the equivalence. > In SIP, you accomplish something similar to the TCP SYN cookie by > sending a SIP request towards the E.164, asking them to sign the > request and return it to you. Details are in > draft-wing-sip-e164-rrc-01.txt and comments are welcome. > > It seems like this mechanism is at most as certain as the E.164 > mapping that it uses for the "reverse direction". I gather from the > Enum people there is some trouble with that. I don't understand your statement; draft-wing-sip-e164-rrc-01.txt does not use ENUM, rather it uses the same routing that the SIP network (of proxies, B2BUAs, and SBCs) uses. Sorry, I don't understand. You said "sending a SIP request towards the E.164", by which I understand an Enum lookup. Did you mean "sending a SIP request towards a SIP URI which purposts to represent an E.164"? Once we start thinking about that, it opens the can of worms again, in that validating sip:1234@xxx;user=phone is a different operation than validating sip:1234@yyy;user=phone, so we can validate only one of those two purportedly equivalent SIP URIs. This seems to lead back to the position that assuming those two URIs are equivalent for any purpose is a Bad Idea, and therefore we should change the SBCs behavior. > It seems to me that in practice, people don't validate requestors by > checking their apparent IP address, but rather by whether they can > present certificates. But that is probably an issue that has been > hashed over before... s/people/applications/ draft-wing-sip-e164-rrc-01.txt does not have people perform the reverse routability check. The reverse routability check happens without the users noticing, as part of validating that an E.164 request that just arrived would have a new request (towards that same E.164) routing in the same direction. What I mean is that few security mechanisms that I know of depend on determining that the purported origin of a message is its actual origin. In practice, applications use SSL, where identity is determined by certificates presented. 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 sip-bounces@ietf.org Wed Apr 9 08:58:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D963828C160; Wed, 9 Apr 2008 08:58:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B2D28C214 for ; Wed, 9 Apr 2008 08:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.08 X-Spam-Level: X-Spam-Status: No, score=-6.08 tagged_above=-999 required=5 tests=[AWL=0.519, 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 nwegiuesnzFD for ; Wed, 9 Apr 2008 08:58:35 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 70FA33A6953 for ; Wed, 9 Apr 2008 08:58:35 -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 m39Fw8q04240; Wed, 9 Apr 2008 15:58:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 10:58:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF16062558@zrc2hxm0.corp.nortel.com> In-Reply-To: <47FCC285.8010207@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Long: Thoughts on "retargeting proposals" Thread-Index: AciaRMvTS0EbE0fASYiOxsoOkjncrwAFTlRg References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><1ECE0EB50388174790F9694F77522CCF15EB7DF4@zrc2hxm0.corp.nortel.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752!! ! ! 2 CCF 15 EB7 F8A@z rc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> <47FC40F5.508@cisco.com> ! <47FCC28 5.8010207@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Christer Holmberg" Cc: sip@ietf.org, Dean Willis Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, SBCs wouldn't replace the To headers if people actually populated them properly with valid URIs (for phone numbers). The vast majority of implementations that I've seen do NOT use useful To and From headers for phone numbers. They don't use real Tel URIs (or Tel URIs embedded in sip headers). As a consequence, if somebody didn't fix them, you'd get all sorts of problems. Including address books and call logs with wrong entries, which have the unfortunate effect that trying to dial these numbers automatically often doesn't work. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, April 09, 2008 06:20 > To: Christer Holmberg > Cc: sip@ietf.org; Dean Willis > Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" > > > > Christer Holmberg wrote: > > Hi, > > > > IF the problem was to provide URI parameters "end-to-end", > independent > > of re-targets etc, I think that could be solved using the To header. > > Of course SBCs are inclined to change To headers also, so > even they aren't safe. In fact, *nothing* is safe from an SBC. > (They are lurking behind every door and corner, waiting to > mess up your message under the guise of "fixing" it.) > > Paul > > > The ua-loose-route draft says: > > > > "When a SIP call is forwarded (also known as retargeting), > the actual > > target of the address changes completely, but the To field > does not." > > > > In addition, the draft says: > > > > "When a retargeting operation happens, the URI that needs to be > > delivered to the UAS is the SIP address or name after the > most recent > > retargeting operation." > > > > ...and I think that is what Paul is also saying. > > > > Regards, > > > > Christer > > > > > > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Paul Kyzivat > > Sent: 9. huhtikuuta 2008 7:07 > > To: Dean Willis > > Cc: sip@ietf.org > > Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" > > > > One thing is troubling me in this discussion: > > > > What are these parameters? Who is inserting them, and why? > > > > In my world view clients don't *generate* URIs. Rather they > use URIs > > that have been given to them, or that they have looked up in some > > public registry. URIs are *created* by the recipient. > > > > In this regard they are much like postal addresses. Part of > a postal > > address is routing, like the domain name in a URI. But the rest is > > like the user part of a URI. If you start sticking extra > stuff into a > > postal address, the post office might get it to the right > mailbox, but > > its likely to be tossed in the trash, or the extra stuff ignored. > > > > By that logic, parameters on a URI should not be passed > along when a > > request is retargeted. The parameters are meaningful, if at all, to > > the retargeter. It may in fact use them to decide where to > retarget. > > But by the same logic it shouldn't be attaching them to the > retargeted > > URI because that amounts to constructing a URI for someone else. It > > should only be selecting among URIs its been given as new targets. > > > > Paul > > > > Dean Willis wrote: > >> On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: > >>> I believe the mechanism people are looking for is to get > the params > >>> from UAC to UAS, UNLESS the UAS identity changes (ie, it is > >>> retargeted), in which case it should NOT deliver the > UAC's original > >>> but rather the ones of the retargeter. > >> Ok, in this scenario, is "contact routing" at the proxy a > >> retargeting? I'm guessing not. > >> > >> What about originating side operations, like a speed-dial > application? > >> > >> What about parameters inserted by a proxy? > >> > >> -- > >> 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 > >> > > _______________________________________________ > > 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 sip-bounces@ietf.org Wed Apr 9 09:14:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB543A6DB8; Wed, 9 Apr 2008 09:14:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B223A6DB8 for ; Wed, 9 Apr 2008 09:14:42 -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 47aAln4+dsGz for ; Wed, 9 Apr 2008 09:14:40 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 827CA3A68FB for ; Wed, 9 Apr 2008 09:14:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id D5A451EC290; Wed, 9 Apr 2008 19:14:57 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYQRB00SSJ-k; Wed, 9 Apr 2008 19:14:48 +0300 (EEST) Received: from taimen (h136197.gprs.dnafinland.fi [87.93.136.197]) by tutpro.com (Postfix) with ESMTP; Wed, 9 Apr 2008 19:14:48 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 780EAAC0FA; Wed, 9 Apr 2008 19:14:42 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18428.60275.209757.845202@taimen.test.fi> Date: Wed, 9 Apr 2008 19:14:43 +0300 To: Dale.Worley@comcast.net In-Reply-To: <200804091555.m39FtLa6020989@dragon.ariadne.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net writes: > OK, so we have several different URIs, sip:1234@domain;user=phone, > which are understood to be equivalent to tel:1234 and also to each > other this is not true. -- juha _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 09:16:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DA13A6DC5; Wed, 9 Apr 2008 09:16:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FA428C4D0 for ; Wed, 9 Apr 2008 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.155 X-Spam-Level: X-Spam-Status: No, score=-5.155 tagged_above=-999 required=5 tests=[AWL=1.444, 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 8PnQ7zyjSCX9 for ; Wed, 9 Apr 2008 09:16:41 -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 A0D4B28C4EF for ; Wed, 9 Apr 2008 09:15:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,630,1199682000"; d="scan'208";a="4508591" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2008 12:16:06 -0400 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 m39GG7UU004733; Wed, 9 Apr 2008 12:16:07 -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 m39GG6u0005656; Wed, 9 Apr 2008 16:16:06 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, 9 Apr 2008 12:16:06 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 12:16:05 -0400 Message-ID: <47FCEBDF.5000302@cisco.com> Date: Wed, 09 Apr 2008 12:16:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <200803251629.m2PGTC0N025942@dragon.ariadne.com><47F55014.9040408@cisco.com> <1ECE0EB50388174!790F9694F7752!! ! ! 2 CCF 15 EB7 F8A@z rc2hxm0 .corp.nortel.com><18421.47305.126027.185083@harjus.tutpro.com> <7A4F9554-7C45-4E65-8A10-FCD546032FF4@softarmor.com> <47B2061B1E5E494B96AA40008300D8504437CF@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D850479EBC@esealmw109.eemea.ericsson.se> <47B2061B1E5E494B96AA40008300D8504AC05E@esealmw109.eemea.ericsson.se> <89214FFB-BFF8-4366-A3FB-120671DDD70F@softarmor.com> <47FC40F5.508@cisco.com> ! <47FCC28 5.8010207@cisco.com> <1ECE0EB50388174790F9694F77522CCF16062558@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF16062558@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 09 Apr 2008 16:16:05.0818 (UTC) FILETIME=[034EA1A0:01C89A5D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5369; t=1207757767; x=1208621767; 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]=20Long=3A=20Thoughts=20on=20=22re targeting=20proposals=22 |Sender:=20 |To:=20Francois=20Audet=20; bh=n0XI9eW5enSP4YWEtZ5eF4MtukR8rMoQBrnevwJWUG4=; b=TtvhkWXrYvbVVSgNc1NzLDNDDgkLJRLPedkLIZDxOqOE58HD3A/8NcHFeT sGq91UJwEt3/MdcSjtRdIeL/m1IzmNApmlat873Qml/lnqmvEG93edCxSw4D ZheF5HZRp2; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, Dean Willis , Christer Holmberg Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, there is no incentive to put in the right thing if it will be changed anyway. And I have no confidence that it wouldn't be changed even if it was fine. But I agree with your sentiment. IMO the proper To when "dialing" digits is a TEL URI. Unless of course you want a secure call, since there is no TELS. Paul Francois Audet wrote: > Well, SBCs wouldn't replace the To headers if people actually populated them > properly with valid URIs (for phone numbers). > > The vast majority of implementations that I've seen do NOT use useful To and >>From headers for phone numbers. They don't use real Tel URIs (or Tel URIs embedded > in sip headers). > > As a consequence, if somebody didn't fix them, you'd get all sorts of problems. > Including address books and call logs with wrong entries, which have the unfortunate > effect that trying to dial these numbers automatically often doesn't work. > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Wednesday, April 09, 2008 06:20 >> To: Christer Holmberg >> Cc: sip@ietf.org; Dean Willis >> Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" >> >> >> >> Christer Holmberg wrote: >>> Hi, >>> >>> IF the problem was to provide URI parameters "end-to-end", >> independent >>> of re-targets etc, I think that could be solved using the To header. >> Of course SBCs are inclined to change To headers also, so >> even they aren't safe. In fact, *nothing* is safe from an SBC. >> (They are lurking behind every door and corner, waiting to >> mess up your message under the guise of "fixing" it.) >> >> Paul >> >>> The ua-loose-route draft says: >>> >>> "When a SIP call is forwarded (also known as retargeting), >> the actual >>> target of the address changes completely, but the To field >> does not." >>> In addition, the draft says: >>> >>> "When a retargeting operation happens, the URI that needs to be >>> delivered to the UAS is the SIP address or name after the >> most recent >>> retargeting operation." >>> >>> ...and I think that is what Paul is also saying. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of >>> Paul Kyzivat >>> Sent: 9. huhtikuuta 2008 7:07 >>> To: Dean Willis >>> Cc: sip@ietf.org >>> Subject: Re: [Sip] Long: Thoughts on "retargeting proposals" >>> >>> One thing is troubling me in this discussion: >>> >>> What are these parameters? Who is inserting them, and why? >>> >>> In my world view clients don't *generate* URIs. Rather they >> use URIs >>> that have been given to them, or that they have looked up in some >>> public registry. URIs are *created* by the recipient. >>> >>> In this regard they are much like postal addresses. Part of >> a postal >>> address is routing, like the domain name in a URI. But the rest is >>> like the user part of a URI. If you start sticking extra >> stuff into a >>> postal address, the post office might get it to the right >> mailbox, but >>> its likely to be tossed in the trash, or the extra stuff ignored. >>> >>> By that logic, parameters on a URI should not be passed >> along when a >>> request is retargeted. The parameters are meaningful, if at all, to >>> the retargeter. It may in fact use them to decide where to >> retarget. >>> But by the same logic it shouldn't be attaching them to the >> retargeted >>> URI because that amounts to constructing a URI for someone else. It >>> should only be selecting among URIs its been given as new targets. >>> >>> Paul >>> >>> Dean Willis wrote: >>>> On Apr 8, 2008, at 4:16 PM, Hadriel Kaplan wrote: >>>>> I believe the mechanism people are looking for is to get >> the params >>>>> from UAC to UAS, UNLESS the UAS identity changes (ie, it is >>>>> retargeted), in which case it should NOT deliver the >> UAC's original >>>>> but rather the ones of the retargeter. >>>> Ok, in this scenario, is "contact routing" at the proxy a >>>> retargeting? I'm guessing not. >>>> >>>> What about originating side operations, like a speed-dial >> application? >>>> What about parameters inserted by a proxy? >>>> >>>> -- >>>> 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 >>>> >>> _______________________________________________ >>> 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 sip-bounces@ietf.org Wed Apr 9 09:34:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58E13A6CEA; Wed, 9 Apr 2008 09:34:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8B43A6953 for ; Wed, 9 Apr 2008 09:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 cB1vBVt7cWY3 for ; Wed, 9 Apr 2008 09:34:04 -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 11B883A6CEA for ; Wed, 9 Apr 2008 09:34:04 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2008 09:34:22 -0700 Received: from mtcc13.mtcc.com ([10.21.67.227]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m39GIGff013800; Wed, 9 Apr 2008 09:18:16 -0700 Message-ID: <47FCF00E.4090805@cisco.com> Date: Wed, 09 Apr 2008 09:34:22 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Juha Heinanen References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> In-Reply-To: <18428.60275.209757.845202@taimen.test.fi> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=484; t=1207757896; x=1208621896; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Juha=20Heinanen=20; bh=xiQfeIjn/WiG9PpO9pvBV0UN0SGHeHvYXbZ+ZFirMhw=; b=Eg6xu4g3Ly15dKLtWP0V6564HxbLQJtI+QGtKCMvQeXKlptYetNOJho4Yr G2UyrImUjHlTNPavxL0922vEQW51/hy2Vc7gMi2RLsK/5Y+vC4k/IePWogkP 3QsLsVV2RJ; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Dale.Worley@comcast.net writes: > > > OK, so we have several different URIs, sip:1234@domain;user=phone, > > which are understood to be equivalent to tel:1234 and also to each > > other > > this is not true. > I was wondering about that... it sure doesn't seem to me that they're the same thing at all because I have control of my sip: name space and if I manufacture e.164-like addresses that's nobody's business but mine. Mike _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 09:46:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E392E28C214; Wed, 9 Apr 2008 09:46:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE2E3A6B5A for ; Wed, 9 Apr 2008 09:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, 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 akjCHSB741Wt for ; Wed, 9 Apr 2008 09:45:57 -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 678613A6E1A for ; Wed, 9 Apr 2008 09:45:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,630,1199682000"; d="scan'208";a="4521246" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2008 12:45:24 -0400 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 m39GjOYt016911; Wed, 9 Apr 2008 12:45:24 -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 m39GjOp4015668; Wed, 9 Apr 2008 16:45:24 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, 9 Apr 2008 12:45:24 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 12:45:23 -0400 Message-ID: <47FCF2BD.9010808@cisco.com> Date: Wed, 09 Apr 2008 12:45:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Juha Heinanen References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> In-Reply-To: <18428.60275.209757.845202@taimen.test.fi> X-OriginalArrivalTime: 09 Apr 2008 16:45:23.0494 (UTC) FILETIME=[1AF6B460:01C89A61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=585; t=1207759524; x=1208623524; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Juha=20Heinanen=20; bh=QrTvTN9E7nW+fhq4Og5k4xNLmu9QATPK5RwrNtdmRyI=; b=FMK24+OVqgZXOUsARY/Ase7MU6lSmRnBrr2+vN3bygnvK5erFqsQQnIVJI Qa6/7Qy4AtYlcQsvnYyBYR9+ny2pLlBk0lTTlP70wTMa8DQdYYlB7XO7AeU3 QTx0Sz2NN0; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Dale.Worley@comcast.net writes: > > > OK, so we have several different URIs, sip:1234@domain;user=phone, > > which are understood to be equivalent to tel:1234 and also to each > > other > > this is not true. To what does "this" refer? You are correct that these URIs aren't equivalent. But I think Dale is right that they are often "understood" to be equivalent, at least to the extent that SBCs feel free to translate among them at will, and phones feel free to display the number parts without regard for the domain part. 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 sip-bounces@ietf.org Wed Apr 9 09:51:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A0C3A6C1A; Wed, 9 Apr 2008 09:51:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4B73A6D93 for ; Wed, 9 Apr 2008 09:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.24 X-Spam-Level: X-Spam-Status: No, score=-5.24 tagged_above=-999 required=5 tests=[AWL=1.359, 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 WSfu03zwthR3 for ; Wed, 9 Apr 2008 09:51:44 -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 59BD23A6C1A for ; Wed, 9 Apr 2008 09:51:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,630,1199682000"; d="scan'208";a="4521884" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2008 12:52:02 -0400 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 m39Gq2IG020741; Wed, 9 Apr 2008 12:52:02 -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 m39Gq2R0017978; Wed, 9 Apr 2008 16:52:02 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, 9 Apr 2008 12:52:02 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 12:52:01 -0400 Message-ID: <47FCF44B.9010802@cisco.com> Date: Wed, 09 Apr 2008 12:52:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <03A9C5ED-8D4C-48EF-A612-3CEAADD885BD@softarmor.com> <200804082214.m38MER1M007799@dragon.ariadne.com> <200804090305.m3935DAK029123@dragon.ariadne.com> <47FC44F6.3040802@cisco.com> <200804091544.m39FiN9C020175@dragon.ariadne.com> In-Reply-To: <200804091544.m39FiN9C020175@dragon.ariadne.com> X-OriginalArrivalTime: 09 Apr 2008 16:52:01.0661 (UTC) FILETIME=[084A2AD0:01C89A62] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1083; t=1207759922; x=1208623922; 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]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=l0HBxcYqAZxU4ds26wmzXzcgpeI1xUePPcgFCOPsaeE=; b=IPxsnZ3gFAX/GwPtH0+TDalM9o+jEtD975VOloaqflIiigRjeqNm7ikHGg Fr7I+MJjLept3DaURLVW+nNbArdHQPqmzB8jk0o8/qYmdPJY/YNaw5C8Mc/x pVThzJ9qfq; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My concern is that accepting any old From and displaying the numeric part as callerid, will in fact lower the bar considerably from what it is in the PSTN today. Of course I may be wrong about that. Perhaps the bar is already as low as it can go. Paul Dale.Worley@comcast.net wrote: > From: Paul Kyzivat > > Suppose you are building a sip adapter for black phones. (Well, black > phones with a callerid display.) > > What criteria should it use before displaying the callerid of the > incoming call? > > That there is a From header. > > People have just argued at great length that PSTN caller ID is not > trustable, so displaying a From header has the same level of security. > > 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 sip-bounces@ietf.org Wed Apr 9 09:53:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29883A6D93; Wed, 9 Apr 2008 09:53:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298F83A6E6C for ; Wed, 9 Apr 2008 09:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 lRHsfD5Bmj33 for ; Wed, 9 Apr 2008 09:53:36 -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 3BD503A6D93 for ; Wed, 9 Apr 2008 09:53:36 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2008 09:53:55 -0700 Received: from mtcc13.mtcc.com ([10.21.67.227]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m39Gbm32014596; Wed, 9 Apr 2008 09:37:48 -0700 Message-ID: <47FCF4A2.9080907@cisco.com> Date: Wed, 09 Apr 2008 09:53:54 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> In-Reply-To: <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2042; t=1207759068; x=1208623068; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Dean=20Willis=20; bh=TLrdV2KwFxgvcHZXV2GrJXWy5tZyFAe5zVBZdcyH0tw=; b=aNig+LJuDi6cEYX1gaTGlO1nsyfnbO6Qndp5+OgopbTACt2hIdVJV6TBZg qOxsMvNvHK+AEt24NPCd8Ag9TNsTyOkuTxeFhTnXyZDIo2svgKrLtdW3kqdM MBuQpC0IaX; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > On Apr 4, 2008, at 9:01 PM, Michael Thomas wrote: > >> Wait a minute: are we talking about cross-domain Identity being >> used as credentials to access voice mail in another domain? Because >> if it's only within a given domain's administrative control, it can >> know >> the name space layout through out of band means. That is, it can know >> if the names that it generates to gateway e.164 addresses are bogus >> addresses to get at voice mail, etc. >> >> If it's the cross domain case, can you tell me the use case? >> >> > > RFC 4474 is a cross-domain authenticator. > > Use case: > > sip:JoeBob@example.com calls his voice mail provider's message > retrieval box, sip:messages.example.net > > Since example.net trusts example.com's RFC 4474 assertions, the > voicemail box at messages.example.net does not authenticate JoeBobs' > request. Instead, it accepts on trust that example.com authenticated > him, and plays out JoeBob's messages. > > This is AFAIK a valid use case for RFC 4474. > It's a _valid_ use case, but is it a _real_ use case? That is, is there anybody out there using cross realm credentials in that way? Even cellular isn't handled in that way because my sim is still with my home provider even if I've roamed... But even if that's the case, why would weakening the assertion be useful? The two domains would obviously need to know quite a bit about each other, so it's not clear to me why this knowledge needs to be shipped inband. > Now, assume JoeBob is instead named "180055511212@example.com". All of > the above works fine, until somebody calls into example.com's PSTN > gateway from a spoofed Caller-ID of "18005551212" and asks said > gateway to connect them to messages.example.net > So just don't sign it. Or sign it as @example.com. Or just tell the voice mail provider not to create voice mail boxes for users with e164@example.com like addresses. This really seems tenuous to me, Dean. Mike _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 09:55:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFEF3A6B8B; Wed, 9 Apr 2008 09:55:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7347D3A6B8B for ; Wed, 9 Apr 2008 09:55:55 -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 yjCSLrbWeTFf for ; Wed, 9 Apr 2008 09:55:54 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 87D463A6983 for ; Wed, 9 Apr 2008 09:55:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id BFBDB1EC290; Wed, 9 Apr 2008 19:56:12 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM63zE63ru9H; Wed, 9 Apr 2008 19:56:06 +0300 (EEST) Received: from taimen (h136197.gprs.dnafinland.fi [87.93.136.197]) by tutpro.com (Postfix) with ESMTP; Wed, 9 Apr 2008 19:56:06 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 6C319AC0ED; Wed, 9 Apr 2008 19:56:01 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18428.62753.417918.23821@taimen.test.fi> Date: Wed, 9 Apr 2008 19:56:01 +0300 To: Paul Kyzivat In-Reply-To: <47FCF2BD.9010808@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat writes: > > > OK, so we have several different URIs, sip:1234@domain;user=phone, > > > which are understood to be equivalent to tel:1234 and also to each > > > other > > > > this is not true. > > To what does "this" refer? i don't have access to rfcs, but since the number in sip uri user part is not a globally unique e.164 number (+...), it has no meaning without the domain, i.e., tel:1234 means nothing. there must be some tel uri rfc, where this is explained. -- juha _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 10:22:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130AC3A6983; Wed, 9 Apr 2008 10:22:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50793A6BBD for ; Wed, 9 Apr 2008 10:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.279 X-Spam-Level: X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[AWL=1.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 89gf3YPxsTp6 for ; Wed, 9 Apr 2008 10:21:58 -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 276A93A6B94 for ; Wed, 9 Apr 2008 10:21:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,630,1199682000"; d="scan'208";a="4524528" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2008 13:22:15 -0400 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 m39HMFxl000752; Wed, 9 Apr 2008 13:22:15 -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 m39HMEkP029921; Wed, 9 Apr 2008 17:22:15 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); Wed, 9 Apr 2008 13:22:14 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 13:22:14 -0400 Message-ID: <47FCFB60.6010702@cisco.com> Date: Wed, 09 Apr 2008 13:22:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Juha Heinanen References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <18428.62753.417918.23821@taimen.test.fi> In-Reply-To: <18428.62753.417918.23821@taimen.test.fi> X-OriginalArrivalTime: 09 Apr 2008 17:22:14.0519 (UTC) FILETIME=[40D65870:01C89A66] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=838; t=1207761735; x=1208625735; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Juha=20Heinanen=20; bh=z6DAHmgEdTASSyjpoyzBudVRVlIQgfFju5j8GectF3I=; b=XSGxwwDu0Yk8iW9vRaGPeGOYPBHfPn0rswDWykHLRAo5dqi5tuEEa9OFJ1 lletE+1AGDtM14IVmvljGQ9ML26p0PT1xMdETRhqgrNZP1jtvRmFHxf6Jbgu HFOyAp0Y3M; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Paul Kyzivat writes: > > > > > OK, so we have several different URIs, sip:1234@domain;user=phone, > > > > which are understood to be equivalent to tel:1234 and also to each > > > > other > > > > > > this is not true. > > > > To what does "this" refer? > > i don't have access to rfcs, but since the number in sip uri user part > is not a globally unique e.164 number (+...), it has no meaning without > the domain, i.e., tel:1234 means nothing. there must be some tel uri > rfc, where this is explained. OK, if that is what you are objecting to. Agreed the example isn't a valid tel. But it is equally invalid in sip. I was overlooking that, assuming the point was simply to show some tel: and corresponding sip, and wasn't about the precise form of the digits. 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 sip-bounces@ietf.org Wed Apr 9 11:22:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFD73A687B; Wed, 9 Apr 2008 11:22:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31CD3A6D68 for ; Wed, 9 Apr 2008 11:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[AWL=1.084, 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 Dp-8HC+RZu-5 for ; Wed, 9 Apr 2008 11:22:15 -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 DC68D3A67FF for ; Wed, 9 Apr 2008 11:22:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,630,1199692800"; d="scan'208";a="20781614" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2008 11:22:34 -0700 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 m39IMYCC001518; Wed, 9 Apr 2008 11:22:34 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m39IMY7R027266; Wed, 9 Apr 2008 18:22:34 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <20080409052754.C98D22175B3@kilo.rtfm.com> Date: Wed, 9 Apr 2008 11:22:33 -0700 Message-ID: <08e001c89a6e$ae8522e0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080409052754.C98D22175B3@kilo.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaAoRI2IAMlcDaS6qeC3s6WOwnnQAa0dlA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4754; t=1207765354; x=1208629354; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=YoeA5SPq/qMESCRUAkcXJB1/WzYIXv4lAkarnma9bMc=; b=HreRfXg0VxY/SBcUzGhucP/vcnK6CK8gQbQhQNk8oi4PsBI72So2NFSPEz /at1ongy+ymohMySj5l7520HK8DIeR+UMK13jJmjFp6iGgCBFz0xCAIFjYyg tMTWM3DI3G; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Tuesday, April 08, 2008 10:28 PM > To: Dan Wing > Cc: sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > At Tue, 8 Apr 2008 17:01:40 -0700, > Dan Wing wrote: > > > If you mean "the E.164 number +123456789", say . > > > > > > I don't see anything that will go wrong if people pay attention > > > to what URIs are defined to mean. > > > > > > Now there is a problem with signing tel: URIs, how do you > determine > > > that the signer has the authority to sign a particular > tel: URI, but > > > that's a delegation-of-authority problem that is not inherently > > > different from other delegation-of-authority problems -- > you need a > > > publicly-known root authority and a tree of delegations. > > > > That is one approach to determining who owns something. > > > > I have a different approach, which I derived from how we > determine if > > someone owns an IP address when we receive a TCP SYN that is > > proportedly from that IP address: challange them to prove that > > packets route the other way. Afterall, the Internet does not have > > a central authority for who owns an IP address (or else we could > > secure BGP routing better than we secure it today). > > > > In SIP, you accomplish something similar to the TCP SYN cookie by > > sending a SIP request towards the E.164, asking them to sign the > > request and return it to you. Details are in > > draft-wing-sip-e164-rrc-01.txt and comments are welcome. > > While withholding judgement on draft-wing-sip-e164-rrc-01, I don't > think this is that accurate a description of what can be inferred > from the fact that a peer can complete a TCP connection initiated with > a given source IP address. > > As you say, in order to allow a TCP connection to be established, > the passive endpoint requires the active endpoint to prove > (for some value of prove) that it received the passive endpoint's > SYN/ACK by ACKing the passive endpoint's ISN. This arguably serves > at least two security purposes: > > - Prevention of DoS: TCP connections consume resources on the > client. Forcing the client to ACK the ISN prevents blind > resource consumption attacks on the passive endpoint. > (This can also be combined with a stateless cookie technique, > aka SYN cookies) to produce a system where no state is consumed > on the passive endpoint until the liveness check is passed. > > - Endpoint authentication: the ability of the active endpoint > to ACK the ISN demonstrates that the active endpoint is on-path > from the passive endpoint to the claimed initiating source > IP address. > > This second guarantee is very weak for three reasons: > > (1) Many TCP stacks do not use sufficiently random PRNGs to > generate the ISN, in which case sequence number prediction > attacks are a real problem. > (2) Even if the ISN is randomly generated, there are only > 32 bits of ISN, so it's at least theoretically possible > to guess it in a blind attack (though of course very > expensive). Fortunately SIP does not suffer from a 32-bit number space, so (1) and (2) are not a limitation with draft-wing-sip-e164-rrc. > (3) Even if we ignore the previous two considerations, > all that the ability to ACK the ISN indicates is that > the attacker is on-path. There are many situations > in which an attacker is on-path (wireless being a > commonly cited case). > > It's precisely for these reasons that one cannot use source IP > authentication for TCP connections on the public Internet, that > mechanisms such as .rhosts are deprecated, and that cryptographic > mechanisms such as IPsec were designed. > > Incidentally, this third deficiency seems to me to be shared > by draft-wing-sip-e164-rrc. Any attacker who is on path > between the relying party and the target of the return > routability check (either because they are on-path in > the SIP routing fabric or because they are able to > observe one of the links) will be able to pass the return > routability check. That is correct. A signature generated by the originating domain (e.g., RFC4474) would protect from such an on-path attacker -- unless of course the on-path attacker is also generated the original message and is also on-path for the return routability check. But, then, if the attacker is on-path for the return routability check, they already 'own' that E.164. Ignoring draft-wing-sip-e164-rrc for a minute, any normal INVITE for that E.164 will go to that very same attacker. -d _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 11:42:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF00828C2EC; Wed, 9 Apr 2008 11:42:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E10E28C1F8 for ; Wed, 9 Apr 2008 11:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 nBIT9HcMeF2S for ; Wed, 9 Apr 2008 11:42:01 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6D52628C2EC for ; Wed, 9 Apr 2008 11:42:01 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 601145081A; Wed, 9 Apr 2008 11:44:10 -0700 (PDT) Date: Wed, 09 Apr 2008 11:44:10 -0700 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <08e001c89a6e$ae8522e0$c5f0200a@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <20080409052754.C98D22175B3@kilo.rtfm.com> <08e001c89a6e$ae8522e0$c5f0200a@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080409184410.601145081A@romeo.rtfm.com> Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 9 Apr 2008 11:22:33 -0700, Dan Wing wrote: > > (3) Even if we ignore the previous two considerations, > > all that the ability to ACK the ISN indicates is that > > the attacker is on-path. There are many situations > > in which an attacker is on-path (wireless being a > > commonly cited case). > > > > It's precisely for these reasons that one cannot use source IP > > authentication for TCP connections on the public Internet, that > > mechanisms such as .rhosts are deprecated, and that cryptographic > > mechanisms such as IPsec were designed. > > > > Incidentally, this third deficiency seems to me to be shared > > by draft-wing-sip-e164-rrc. Any attacker who is on path > > between the relying party and the target of the return > > routability check (either because they are on-path in > > the SIP routing fabric or because they are able to > > observe one of the links) will be able to pass the return > > routability check. > > That is correct. > > A signature generated by the originating domain (e.g., RFC4474) > would protect from such an on-path attacker -- unless of course > the on-path attacker is also generated the original message > and is also on-path for the return routability check. > > But, then, if the attacker is on-path for the return > routability check, they already 'own' that E.164. Ignoring > draft-wing-sip-e164-rrc for a minute, any normal INVITE > for that E.164 will go to that very same attacker. Again, I'm not (at least not yet) passing judgment on this draft. Rather, I'm observing that your characterization of the situation with IP isn't really right. I'll have to read this draft more carefully to determine whether I think it works. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 11:53:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801613A6E85; Wed, 9 Apr 2008 11:53:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DA03A6E6C for ; Wed, 9 Apr 2008 11:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.546 X-Spam-Level: X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[AWL=1.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 KJE1y2T4zpld for ; Wed, 9 Apr 2008 11:53:41 -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 3C0D33A684E for ; Wed, 9 Apr 2008 11:53:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,630,1199692800"; d="scan'208";a="20794054" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2008 11:54:00 -0700 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 m39IrxP8003093; Wed, 9 Apr 2008 11:53:59 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m39IrxNc021806; Wed, 9 Apr 2008 18:53:59 GMT From: "Dan Wing" To: , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> Date: Wed, 9 Apr 2008 11:53:59 -0700 Message-ID: <091b01c89a73$123ea0f0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200804091555.m39FtLa6020989@dragon.ariadne.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaWlcnm8fafYUuQLSp54TYycPz4AAFwDiA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6002; t=1207767239; x=1208631239; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=UkEOTVuZ1RNoKOwQ08EIaZiz83B/pKaaBQl1xRIFNCI=; b=kuAuBtSXRDMorx5O+BTuXZILuEGnuxXzL78OB0hoViRD4MIcuFS40vdmbp UVTlbo+e0CISq8Ob6Un8DAIqS8uaQVwUQhb4zuReQE45RrANRddkUwo9oo8j y//PzUz9rh; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > From: "Dan Wing" > > If those URIs included ";user=phone", there is a transitive > > relationship between the SIP URI and the TEL URI. Without > > ";user=phone", I agree that no meaning is supposed to > be applied > > to the user-part (the part to the left of the "@"). > > > > True. In that case, we have SIP URIs which are > essentially aliases > > for tel URIs. But in that case, any signing should be of the > > fundamental tel URI, which then obviates the problem > with an SBC that > > translates one alias-URI into another. > > But the only mechanism we have to sign, RFC4474, does not provide a > way to sign a tel URI. > > OK, so we have several different URIs, sip:1234@domain;user=phone, > which are understood to be equivalent to tel:1234 and also to each > other, and because of that, SBCs feel free to translate each of these > into each other, but the signing mechanism generates signatures which > depend on which of these particular URIs is present. So you have to > change either your signing mechanism to recognize the equivalence, or > your SBCs to stop exploiting the equivalence. Yes, I agree. > > In SIP, you accomplish something similar to the TCP > SYN cookie by > > sending a SIP request towards the E.164, asking them > to sign the > > request and return it to you. Details are in > > draft-wing-sip-e164-rrc-01.txt and comments are welcome. > > > > It seems like this mechanism is at most as certain as the E.164 > > mapping that it uses for the "reverse direction". I > gather from the > > Enum people there is some trouble with that. > > I don't understand your statement; draft-wing-sip-e164-rrc-01.txt > does not use ENUM, rather it uses the same routing that the SIP > network (of proxies, B2BUAs, and SBCs) uses. > > Sorry, I don't understand. You said "sending a SIP request towards > the E.164", by which I understand an Enum lookup. Did you mean > "sending a SIP request towards a SIP URI which purposts to represent > an E.164"? draft-wing-sip-e164-rrc-01.txt says to turn the SIP URI into a TEL URI, and then generate a Return Routability Check (RRC) towards that TEL URI: "1. Strip the domain name of the From: of the incoming INVITE. This results in a TEL URI. For example, "sip:+14085551234@example.com;user=phone" is rewritten to "tel:+14085551212". 2. Rewrite the TEL URI to a SIP URI, following the Verifier's default routing rules. For example, if outgoing calls are sent to the service provider example.net, then "tel:+14085551212" is rewritten to "sip:+14085551212@example.net;user=phone". 3. Generate a random nonce. 4. Using the SIP URI constructed in step (2), construct a SIP SUBSCRIBE message with Request-URI and To headers that use that SIP URI, and an "Expires" header of 0. The SUBSCRIBE contains the random nonce in its body as Content-Type application/ return-routability-nonce. 5. Send the SUBSCRIBE message. This will cause the calling party to send a NOTIFY." > Once we start thinking about that, it opens the can of worms again, in > that validating sip:1234@xxx;user=phone is a different operation than > validating sip:1234@yyy;user=phone, so we can validate only one of > those two purportedly equivalent SIP URIs. This seems to lead back to > the position that assuming those two URIs are equivalent for any > purpose is a Bad Idea, and therefore we should change the SBCs > behavior. (I assume the omission of "+" in those two URIs was an accident.) If I receive two Invites on one day from (a) sip:+1234@yyy;user=phone and (b) sip:+1234@xxx;user=phone I expect that they were both originated by someone who really does 'own' that number. If I turn the SIP URL into a TEL URI (tel:+1234), and route it using my default routing rules, it could be routed somewhere else (sip:+1234@zzz;user=phone), and then to somewhere else again (sip:+1234@abcd;user=phone). But as long as it eventually arrives at the same place as (a) or (b) originated from -- then I am happy that my own outbound SIP routing thinks that (a) or (b) really do "own" the E.164 number "+1234" -- because that is what my SIP routing says is true. > > It seems to me that in practice, people don't validate > requestors by > > checking their apparent IP address, but rather by > whether they can > > present certificates. But that is probably an issue > that has been > > hashed over before... > > s/people/applications/ > > draft-wing-sip-e164-rrc-01.txt does not have people perform the > reverse routability check. The reverse routability check happens > without the users noticing, as part of validating that an E.164 > request that just arrived would have a new request (towards that > same E.164) routing in the same direction. > > What I mean is that few security mechanisms that I know of depend on > determining that the purported origin of a message is its actual > origin. In practice, applications use SSL, where identity is > determined by certificates presented. Doing such would require something, somewhere, to assert who owns a certain E.164. I don't know how to do that. An ENUM system cannot do that, because of a pile of reasons (ITU politics, service provider business models, LNP, and so on). Certificate Authorities, at least as they currently exist, are not capable of asserting that a company 'owns' a certain E.164 or a range of E.164s. draft-wing-sip-e164-rrc is my pragmatic approach to the problem at hand. It does not require ENUM, does not require CA's to assert who owns an E.164 -- it uses SIP itself to test if the message was originated from the same place we would route an E.164 call to. -d _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 11:56:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C13E3A687B; Wed, 9 Apr 2008 11:56:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DD33A687B for ; Wed, 9 Apr 2008 11:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.575 X-Spam-Level: X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=1.024, 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 70z30eO7GHbp for ; Wed, 9 Apr 2008 11:56:08 -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 3F0083A684E for ; Wed, 9 Apr 2008 11:56:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,630,1199692800"; d="scan'208";a="10652522" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 09 Apr 2008 11:56:27 -0700 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 m39IuRvL007677; Wed, 9 Apr 2008 11:56:27 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m39IuQWb026777; Wed, 9 Apr 2008 18:56:26 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><20080409052754.C98D22175B3@kilo.rtfm.com><08e001c89a6e$ae8522e0$c5f0200a@cisco.com> <20080409184410.601145081A@romeo.rtfm.com> Date: Wed, 9 Apr 2008 11:56:26 -0700 Message-ID: <091d01c89a73$69f4da30$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080409184410.601145081A@romeo.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciacXVMXlSqmCsvSmSMCEEBreJb/QAAeWBQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=371; t=1207767387; x=1208631387; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=hZazXrckwFI6MBRBB6SHayzN1EtVzDcy+7xQ8l0mYiU=; b=JhZoEhM5TU1f79n9HoByF0a78s4301ZKAd7tzLBmHFX/W/ARajYIYv2qIG DdydeIoGh522Pf6AhqspmKkXC8O3kcUP3SeCyjcMZl8Al+6gBwblXt2xgjEd PmJnGHIgNi; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Again, I'm not (at least not yet) passing judgment on this draft. > Rather, I'm observing that your characterization of the situation > with IP isn't really right. I'll have to read this draft more > carefully to determine whether I think it works. Well, I only said I was inspired by SYN cookies; not that I was trying to do Just As Good as SYN cookies. -d _______________________________________________ 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 caa.telesistem@telesistem.com Wed Apr 9 13:21:09 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CA928C211; Wed, 9 Apr 2008 13:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.242 X-Spam-Level: X-Spam-Status: No, score=-11.242 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 YmwafS2q0WEP; Wed, 9 Apr 2008 13:21:09 -0700 (PDT) Received: from adsl190-29-137-48.epm.net.co (adsl190-29-137-48.epm.net.co [190.29.137.48]) by core3.amsl.com (Postfix) with SMTP id 87AAE28C210; Wed, 9 Apr 2008 13:20:55 -0700 (PDT) X-Originating-IP: 128.48.48.176 by smtp.190.29.137.48; Wed, 09 Apr 2008 16:21:22 -0500 Message-ID: From: "Russel Randolph" Reply-To: "Russel Randolph" To: schema-archive@ietf.org Subject: Enjoy our MASSIVE $2400 bonus......... Date: Wed, 09 Apr 2008 16:21:22 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the worlds BIGGEST winners........ ENTER HERE http://luxgamingnetwork.com/ TO DOWNLOAD NOW! From sip-bounces@ietf.org Wed Apr 9 16:55:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB51928C32A; Wed, 9 Apr 2008 16:55:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3871D28C232 for ; Wed, 9 Apr 2008 16:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=0.495, 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 BCyO4Unx9zCi for ; Wed, 9 Apr 2008 16:55:24 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 7DBFA3A6ACB for ; Wed, 9 Apr 2008 16:54:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m39Nsb919308; Wed, 9 Apr 2008 23:54:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 18:54:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> In-Reply-To: <47FCF2BD.9010808@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFg References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Juha Heinanen" Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If if have a web page with sip:+12242@example.com;user=phone, and I click on it should result in my default SIP app to make a call to +12242@example.com. Example.com may route it to +12242@att.net or whatever. If I have a web page with tel:+12242 and I click on it, my default TELEPHONE app (which may not may not be SIP) should make a call to +12242. If my default voice app happens to be SIP, then it will send the request to my default outbound proxy. So, Juha is right, those 2 URIs are very different. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, April 09, 2008 09:46 > To: Juha Heinanen > Cc: sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > > > Juha Heinanen wrote: > > Dale.Worley@comcast.net writes: > > > > > OK, so we have several different URIs, > sip:1234@domain;user=phone, > > > which are understood to be equivalent to tel:1234 and > also to each > > > other > > > > this is not true. > > To what does "this" refer? > > You are correct that these URIs aren't equivalent. But I > think Dale is right that they are often "understood" to be > equivalent, at least to the extent that SBCs feel free to > translate among them at will, and phones feel free to display > the number parts without regard for the domain part. > > 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 sip-bounces@ietf.org Wed Apr 9 18:09:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6263A6C3D; Wed, 9 Apr 2008 18:09:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4DA23A6C3D for ; Wed, 9 Apr 2008 18:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.602 X-Spam-Level: X-Spam-Status: No, score=-5.602 tagged_above=-999 required=5 tests=[AWL=0.997, 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 e79NNFHOZtWb for ; Wed, 9 Apr 2008 18:09:47 -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 0C6C93A6B10 for ; Wed, 9 Apr 2008 18:09:47 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2008 18:10:06 -0700 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 m3A1A6Gc022847; Wed, 9 Apr 2008 18:10:06 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3A1A6o9019480; Thu, 10 Apr 2008 01:10:06 GMT From: "Dan Wing" To: "'Eric Rescorla'" , , References: <20080405011409.30D205081A@romeo.rtfm.com> Date: Wed, 9 Apr 2008 18:10:05 -0700 Message-ID: <0ec601c89aa7$9cf46f20$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080405011409.30D205081A@romeo.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciWuiPfuCQbQXPkRDG9i1BIGi/9YAD2p8JA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8032; t=1207789806; x=1208653806; 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]=20Review=20of=20draft-ietf-sip-me dia-security-requirements-04 |Sender:=20; bh=ZemstecsbJ9cifDQYd9+UbliFF+swC9/T/ct1w6iBo0=; b=muXFyxqnn1Roj9ejeul+Igg60lYfaq/nUVA4rhTVZOYyMsrjlAVe+X7EoK fNqxDICkmJ9rjT2L3DcoAtpeWkvvRhlu7d+LIqPT6c1TNU3TLlaexcTnChk3 FCmAUW3SAS; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] Review of draft-ietf-sip-media-security-requirements-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Friday, April 04, 2008 6:14 PM > To: sip@ietf.org; > draft-ietf-sip-media-security-requirements@tools.ietf.org > Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-04 > > $Id: draft-ietf-sip-media-security-requirements-04-rev.txt,v > 1.2 2008/04/05 00:53:27 ekr Exp $ > > This document seems to me to be in good shape. > > I have the following comments about this document. None of > these are critical > so I won't cry if they don't get made, and I don't want them to hold > the document up if they're controversy. > > > S 4.1. > which it is detect-attack, which provides protection against the > > "which is"? Fixed. > > before the SDP answer arrives) might make the requirements > to become > obsolete, but at the time of writing no progress has been > > Not sure I know what this means: "to become obsolete" seems > ungramattical here. Changed to: Preventing the arrival of early media (i.e., media that arrives at the SDP offerer before the SDP answer arrives) might obsolete the R-AVOID-CLIPPING requirement, but at the time of writing such early media exists in many normal call scenarios. > S 4.3. > The entire section on shared key conferencing doesn't lead to any > requirements as far as I can tell. Does it make sense to remove > it from this document? Right. It seems useful to leave it in, as mentioned at the beginning of the section: The consensus on the RTPSEC mailing list was to concentrate on unicast, point-to-point sessions. Thus, there are no requirements related to shared key conferencing. This section is retained for informational purposes. if others agree it should be removed, I can remove it. > S 5.1. > R-DISTINCT: > The media security key management protocol MUST be capble of > s/capble/capable/ Fixed. > S 5.3. > R-OTHER-SIGNALING: > A solution SHOULD be able to negotiate keys for SRTP sessions > created via different call signaling protocols (e.g., between > Jabber, SIP, H.323, MGCP). > > This is not discussed anywhere in the document. I wonder if it makes > sense to remove it. I know that my employer's products interwork between SIP and MGCP (and our proprietary SCCP) with SRTP today -- all using Security Descriptions. I know we have a need to meet this requirement with anything that replaces our Security Descriptions implementations. I expect others do, too. Would adding motivating text (in a new subsection 4.xxx) be useful? I had assumed the need was self-evident. > Appendix A. > Based on how the SRTP keys are exchanged, each SRTP key exchange > mechanism belongs to one general category: > > > > signaling path: All the keying is carried in the call signaling > > Remove one blank line here. > > > S A.1.12. > It's a little weird to have the discussion of media path keying > properties here before you describe the systems. I moved A.1.12 to a new section A.4. > S A.1.12.2. > The issues you raise about middleboxes and clipping apply equally > to DTLS-SRTP and ZRTP, no? ZRTP allows RTP to flow while the ZRTP exchange is happening, so ZRTP should incur no clipping. > S A.1.12.3. > Again, I would think to remove this section. This is the 'centralized keying' section, which is derived from the conferencing discussion (for which we have no requirements in the document -- only a non-normative discussion). I will remove it, unless someone objects. > DTLS-SRTP > Keying: Yes, because with the assumed cipher suite, > TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates > its SRTP key. > > This statement is not correct. With all conventional TLS > modes, neither side completely controls either key. Agreed. It is in the removed section, so it's gone entirely anyway. > > S A.1.13.1. > The way you're using "public key cryptography" to mean "PKI" is not > the normal terminology. DH is PKC. I would use PKI to indicate > "certs are needed". So, for instance, SDP-DH and ZRTP definitely use > PKC. Ok. Changed from: Using public key cryptography for confidentiality and authentication can introduce requirements for two types of systems: (1) a system to distribute public keys (often in the form of certificates), and (2) a system for validating certificates. to: Requiring certificates for confidentiality and authentication can introduce requirements for two types of systems: (1) a system to distribute certificates, and (2) a system for validating certificates. > PFS is achieved if the negotiated cipher suite includes an > exponential or discrete-logarithmic key exchange > (e.g., Diffie- > Hellman (DH_RSA from [RFC4346]) or Elliptic Curve Diffie- > Hellman [RFC4492]). > > I don't know what "exponential or discrete logarithmic key exchange" > means. After all, RSA involves exponentiation. Presumably you mean > "something with ephemeral keys". This currently means discrete log > over integer and elliptic curve fields, but could be RSA in principle. Thanks. I don't know where that text came from (it isn't my wording but it was in my original -00). Changed to: DTLS-SRTP PFS is provided if the negotiated cipher suite uses ephemeral keys (e.g., Diffie-Hellman (DH_RSA from [RFC4346]) or Elliptic Curve Diffie-Hellman [RFC4492]). > S A.1.13.3. > It's probably important to indicate that it is desirable to have > the profile be RTP/SAVP when SRTP is used. That's a disadvantage > of media path probing, for instance. I don't think that comes > across clearly here. There is a disadvantage with RTP/SAVP as the profile, as well, mentioned at the beginning of that section -- just prior to the list of candidate techniques. This section is titled Best Effort Encryption, and RTP/SAVP is not a candidate technique to provide best effort encryption -- RTP/SAVP causes a call to fail to complete if any of the remote forks or targets (during retargeting) rejects the call because they don't understand that profile. This is discussed at the beginning of that section, in order to justify why we need best effort encryption -- so that we can deploy SRTP without a priori knowledge of the called party's deployment of RTP/SAVP-capable endpoints at that particular moment. > S A.3.2. > This document assumes DTLS will use > TLS_RSA_WITH_3DES_EDE_CBC_SHA as > its cipher suite, which is the mandatory-to-implement > cipher suite in > TLS [RFC4346]. > > I'm not sure what the relevance of this is. This is relevant because I could have assumed a null cipher instead, which would change much of the analysis. If we use DH_RSA > I guess RSA matters, but > since we negotiate a separate protection profile for SRTP, 3DES/SHA > isn't that relevant. Btw, TLS 1.2. will be AES. Thanks, changed to: This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as its cipher suite, which is the mandatory-to-implement cipher suite in TLS [I-D.ietf-tls-rfc4346-bis]. > Note also that DTLS-SRTP is compatible with RTP before the DTLS > handshake. Only if the RTP profile is RTP/AVP; if the profile is RTP/SAVP, one expects only SRTP. Is there text that needs to change to note that in the requirements doc? -d > > > > -Ekr > > > > > > > > > > > > > _______________________________________________ > 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 sip-bounces@ietf.org Wed Apr 9 18:20:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B5A3A6989; Wed, 9 Apr 2008 18:20:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8973A6B00 for ; Wed, 9 Apr 2008 18:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.970, 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 ZHnF6NU8EP3B for ; Wed, 9 Apr 2008 18:20:55 -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 880013A6BA3 for ; Wed, 9 Apr 2008 18:20:04 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Apr 2008 18:20:24 -0700 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 m3A1KOUp030417; Wed, 9 Apr 2008 18:20:24 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3A1KNHT027701; Thu, 10 Apr 2008 01:20:23 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Paul Kyzivat'" , "'Juha Heinanen'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> Date: Wed, 9 Apr 2008 18:20:23 -0700 Message-ID: <0ecb01c89aa9$0d1ffd90$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFgAAMWYDA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2581; t=1207790424; x=1208654424; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=Yg8jXRLvEL36HQ8I3zVZQhaFPjtC6IlUmx2ljOpyUqU=; b=mZGG+h1GSczhqoukhXoOoxwrGx2BAo8Z7KO1X/Wj7iFiWzt/zVvtugBoqy ZYKG7XQtKfWaoNI18MLITHvqADTzJaP8WrIwTzBvx0P0Zp2ny08vaoIHEN88 muCWZPzmzZ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org What if I am trying to do video -- which cannot be done over the Internet (unless you are insane and enjoy video delivered over an ISDN line, naturally). -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: Wednesday, April 09, 2008 4:55 PM > To: Paul Kyzivat; Juha Heinanen > Cc: sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > If if have a web page with sip:+12242@example.com;user=phone, > and I click on > it should result in my default SIP app to make a call to > +12242@example.com. > > Example.com may route it to +12242@att.net or whatever. > > If I have a web page with tel:+12242 and I click on it, my default > TELEPHONE app (which may not may not be SIP) should make a call to > +12242. If my default voice app happens to be SIP, then it will > send the request to my default outbound proxy. > > So, Juha is right, those 2 URIs are very different. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Wednesday, April 09, 2008 09:46 > > To: Juha Heinanen > > Cc: sip@ietf.org > > Subject: Re: [Sip] E.164 - who owns it > > > > > > > > Juha Heinanen wrote: > > > Dale.Worley@comcast.net writes: > > > > > > > OK, so we have several different URIs, > > sip:1234@domain;user=phone, > > > > which are understood to be equivalent to tel:1234 and > > also to each > > > > other > > > > > > this is not true. > > > > To what does "this" refer? > > > > You are correct that these URIs aren't equivalent. But I > > think Dale is right that they are often "understood" to be > > equivalent, at least to the extent that SBCs feel free to > > translate among them at will, and phones feel free to display > > the number parts without regard for the domain part. > > > > 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 _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 19:46:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F51E3A6C04; Wed, 9 Apr 2008 19:46:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4808C3A6B38 for ; Wed, 9 Apr 2008 19:46:02 -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.945, 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 ZD3rcKfRoywE for ; Wed, 9 Apr 2008 19:46:01 -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 402DB3A6988 for ; Wed, 9 Apr 2008 19:46:01 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Apr 2008 19:46:21 -0700 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 m3A2kLOi019099; Wed, 9 Apr 2008 19:46:21 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3A2kKSm016477; Thu, 10 Apr 2008 02:46:20 GMT From: "Dan Wing" To: "'Francois Audet'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> Date: Wed, 9 Apr 2008 19:46:19 -0700 Message-ID: <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFgAAMWYDA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2653; t=1207795581; x=1208659581; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=R8lOkhLbVu6iMX9kONqizJSBzSmNS6+cnj77ANZ5wdc=; b=pRddESMSAVsBBRcQ15VqUhAmLfdU0Ns2nebPO6hOyy103ujgqlzy7EOKvl /ZHCm3kRx4sQqQCbhTL6eaMUFT6Ewe2wVAfxNTMvSDKt4oGS3igdlkYTyKJh ju9OVt5pcW; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, 'Paul Kyzivat' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org [resending with a correction; I had intended to say 'over the PSTN' (not 'over the Internet'). What if I am trying to do video -- which cannot be done over the PSTN (unless you are insane and enjoy video delivered over an ISDN line, naturally). -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: Wednesday, April 09, 2008 4:55 PM > To: Paul Kyzivat; Juha Heinanen > Cc: sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > If if have a web page with sip:+12242@example.com;user=phone, > and I click on > it should result in my default SIP app to make a call to > +12242@example.com. > > Example.com may route it to +12242@att.net or whatever. > > If I have a web page with tel:+12242 and I click on it, my default > TELEPHONE app (which may not may not be SIP) should make a call to > +12242. If my default voice app happens to be SIP, then it will > send the request to my default outbound proxy. > > So, Juha is right, those 2 URIs are very different. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Wednesday, April 09, 2008 09:46 > > To: Juha Heinanen > > Cc: sip@ietf.org > > Subject: Re: [Sip] E.164 - who owns it > > > > > > > > Juha Heinanen wrote: > > > Dale.Worley@comcast.net writes: > > > > > > > OK, so we have several different URIs, > > sip:1234@domain;user=phone, > > > > which are understood to be equivalent to tel:1234 and > > also to each > > > > other > > > > > > this is not true. > > > > To what does "this" refer? > > > > You are correct that these URIs aren't equivalent. But I > > think Dale is right that they are often "understood" to be > > equivalent, at least to the extent that SBCs feel free to > > translate among them at will, and phones feel free to display > > the number parts without regard for the domain part. > > > > 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 _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 20:05:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417903A6E07; Wed, 9 Apr 2008 20:05:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773A03A6D98 for ; Wed, 9 Apr 2008 20:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.473, 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 95dQtYAFLMzk for ; Wed, 9 Apr 2008 20:05:47 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id EEB2D3A6D48 for ; Wed, 9 Apr 2008 20:05:01 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3A35HB03603; Thu, 10 Apr 2008 03:05:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Apr 2008 22:04:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFgAAMWYDAAA6nYJQ== References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> From: "Francois Audet" To: "Dan Wing" Cc: sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2012039457==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2012039457== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89AB7.B3E2EFEC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89AB7.B3E2EFEC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, you can still do video over PSTN with H.320. I still view this as = "telephony". Not sure I understand the question. ---- Fran=E7ois AUDET, Nortel Networks mailto:audet@nortel.com -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Wed 09-Apr-08 7:46 PM To: Audet, Francois (SC100:3055) Cc: sip@ietf.org; 'Paul Kyzivat'; 'Juha Heinanen' Subject: RE: [Sip] E.164 - who owns it =20 [resending with a correction; I had intended to say 'over the PSTN' (not = 'over the Internet'). What if I am trying to do video -- which cannot be done over the PSTN = (unless you are insane and enjoy video delivered over an ISDN line, naturally). -d > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: Wednesday, April 09, 2008 4:55 PM > To: Paul Kyzivat; Juha Heinanen > Cc: sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > If if have a web page with sip:+12242@example.com;user=3Dphone, > and I click on > it should result in my default SIP app to make a call to > +12242@example.com. > > Example.com may route it to +12242@att.net or whatever. > > If I have a web page with tel:+12242 and I click on it, my default > TELEPHONE app (which may not may not be SIP) should make a call to > +12242. If my default voice app happens to be SIP, then it will > send the request to my default outbound proxy. > > So, Juha is right, those 2 URIs are very different. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Wednesday, April 09, 2008 09:46 > > To: Juha Heinanen > > Cc: sip@ietf.org > > Subject: Re: [Sip] E.164 - who owns it > > > > > > > > Juha Heinanen wrote: > > > Dale.Worley@comcast.net writes: > > > > > > > OK, so we have several different URIs, > > sip:1234@domain;user=3Dphone,=20 > > > > which are understood to be equivalent to tel:1234 and > > also to each=20 > > > > other > > > > > > this is not true. > > > > To what does "this" refer? > > > > You are correct that these URIs aren't equivalent. But I > > think Dale is right that they are often "understood" to be > > equivalent, at least to the extent that SBCs feel free to > > translate among them at will, and phones feel free to display > > the number parts without regard for the domain part. > > > > 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=20 ------_=_NextPart_001_01C89AB7.B3E2EFEC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] E.164 - who owns it

Well, you can still do video over PSTN with H.320. I = still view this as "telephony".

Not sure I understand the question.

----
Fran=E7ois AUDET, Nortel Networks
mailto:audet@nortel.com



-----Original Message-----
From: Dan Wing [mailto:dwing@cisco.com]
Sent: Wed 09-Apr-08 7:46 PM
To: Audet, Francois (SC100:3055)
Cc: sip@ietf.org; 'Paul Kyzivat'; 'Juha Heinanen'
Subject: RE: [Sip] E.164 - who owns it

[resending with a correction; I had intended to say 'over the PSTN' (not = 'over
the Internet').


What if I am trying to do video -- which cannot be done over the PSTN = (unless
you are insane and enjoy video delivered over an ISDN line, = naturally).

-d


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On
> Behalf Of Francois Audet
> Sent: Wednesday, April 09, 2008 4:55 PM
> To: Paul Kyzivat; Juha Heinanen
> Cc: sip@ietf.org
> Subject: Re: [Sip] E.164 - who owns it
>
> If if have a web page with sip:+12242@example.com;user=3Dphone,
> and I click on
> it should result in my default SIP app to make a call to
> +12242@example.com.
>
> Example.com may route it to +12242@att.net or whatever.
>
> If I have a web page with tel:+12242 and I click on it, my = default
> TELEPHONE app (which may not may not be SIP) should make a call = to
> +12242. If my default voice app happens to be SIP, then it will
> send the request to my default outbound proxy.
>
> So, Juha is right, those 2 URIs are very different.
>
> > -----Original Message-----
> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On
> > Behalf Of Paul Kyzivat
> > Sent: Wednesday, April 09, 2008 09:46
> > To: Juha Heinanen
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] E.164 - who owns it
> >
> >
> >
> > Juha Heinanen wrote:
> > > Dale.Worley@comcast.net writes:
> > >
> > >  > OK, so we have several different URIs,
> > sip:1234@domain;user=3Dphone,
> > > > which are understood to be equivalent to tel:1234 = and
> > also to each
> > > > other
> > >
> > > this is not true.
> >
> > To what does "this" refer?
> >
> > You are correct that these URIs aren't equivalent. But I
> > think Dale is right that they are often "understood" = to be
> > equivalent, at least to the extent that SBCs feel free to
> > translate among them at will, and phones feel free to = display
> > the number parts without regard for the domain part.
> >
> >     Paul
> > _______________________________________________
> > Sip mailing list  https://www.ietf.org/m= ailman/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/m= ailman/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_01C89AB7.B3E2EFEC-- --===============2012039457== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2012039457==-- From sip-bounces@ietf.org Wed Apr 9 20:06:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2E93A6E56; Wed, 9 Apr 2008 20:06:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F05A3A6EE3 for ; Wed, 9 Apr 2008 20:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 5AjutSASz4u4 for ; Wed, 9 Apr 2008 20:06:01 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 8E9C03A68DE for ; Wed, 9 Apr 2008 20:05:31 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 10CE7219C03; Wed, 9 Apr 2008 20:05:51 -0700 (PDT) Date: Wed, 09 Apr 2008 20:05:50 -0700 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <0ec601c89aa7$9cf46f20$c5f0200a@cisco.com> References: <20080405011409.30D205081A@romeo.rtfm.com> <0ec601c89aa7$9cf46f20$c5f0200a@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080410030551.10CE7219C03@kilo.rtfm.com> Cc: sip@ietf.org, draft-ietf-sip-media-security-requirements@tools.ietf.org Subject: Re: [Sip] Review of draft-ietf-sip-media-security-requirements-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 9 Apr 2008 18:10:05 -0700, Dan Wing wrote: > > before the SDP answer arrives) might make the requirements > > to become > > obsolete, but at the time of writing no progress has been > > > > Not sure I know what this means: "to become obsolete" seems > > ungramattical here. > > Changed to: > > Preventing the arrival of early media (i.e., media that > arrives at the SDP offerer before the SDP answer arrives) > might obsolete the R-AVOID-CLIPPING requirement, but at the > time of writing such early media exists in many normal call > scenarios. Looks good. > > S 4.3. > > The entire section on shared key conferencing doesn't lead to any > > requirements as far as I can tell. Does it make sense to remove > > it from this document? > > Right. It seems useful to leave it in, as mentioned at the beginning > of the section: > > The consensus on the RTPSEC mailing list was to concentrate on > unicast, point-to-point sessions. Thus, there are no requirements > related to shared key conferencing. This section is retained for > informational purposes. > > if others agree it should be removed, I can remove it. I've got no real problem with leaving it in, I just wanted to note it. > > S 5.3. > > R-OTHER-SIGNALING: > > A solution SHOULD be able to negotiate keys for SRTP sessions > > created via different call signaling protocols (e.g., between > > Jabber, SIP, H.323, MGCP). > > > > This is not discussed anywhere in the document. I wonder if it makes > > sense to remove it. > > I know that my employer's products interwork between SIP and MGCP (and > our proprietary SCCP) with SRTP today -- all using Security Descriptions. > > I know we have a need to meet this requirement with anything that > replaces our Security Descriptions implementations. I expect others > do, too. > > Would adding motivating text (in a new subsection 4.xxx) be useful? I > had assumed the need was self-evident. As a matter of form, I think it would be good to have a section with motivating text. > > S A.1.12.2. > > The issues you raise about middleboxes and clipping apply equally > > to DTLS-SRTP and ZRTP, no? > > ZRTP allows RTP to flow while the ZRTP exchange is happening, so ZRTP > should incur no clipping. > > S A.1.13.1. > > The way you're using "public key cryptography" to mean "PKI" is not > > the normal terminology. DH is PKC. I would use PKI to indicate > > "certs are needed". So, for instance, SDP-DH and ZRTP definitely use > > PKC. > > Ok. Changed from: > > Using public key cryptography for confidentiality and authentication > can introduce requirements for two types of systems: (1) a system to > distribute public keys (often in the form of certificates), and (2) a > system for validating certificates. > > to: > > Requiring certificates for confidentiality and authentication > can introduce requirements for two types of systems: (1) a system to > distribute certificates, and (2) a system for validating certificates. Looks good. > > I don't know what "exponential or discrete logarithmic key exchange" > > means. After all, RSA involves exponentiation. Presumably you mean > > "something with ephemeral keys". This currently means discrete log > > over integer and elliptic curve fields, but could be RSA in principle. > > Thanks. I don't know where that text came from (it isn't my wording > but it was in my original -00). Changed to: > > DTLS-SRTP > PFS is provided if the negotiated cipher suite uses ephemeral > keys (e.g., Diffie-Hellman (DH_RSA from [RFC4346]) or Elliptic > Curve Diffie-Hellman [RFC4492]). s/DH_RSA/DHE_RSA/. DH_RSA means static keys. > > S A.1.13.3. > > It's probably important to indicate that it is desirable to have > > the profile be RTP/SAVP when SRTP is used. That's a disadvantage > > of media path probing, for instance. I don't think that comes > > across clearly here. > > There is a disadvantage with RTP/SAVP as the profile, as well, mentioned at > the beginning of that section -- just prior to the list of candidate > techniques. > > This section is titled Best Effort Encryption, and RTP/SAVP is not a candidate > technique to provide best effort encryption -- RTP/SAVP causes a call to fail > to complete if any of the remote forks or targets (during retargeting) rejects > the call because they don't understand that profile. This is discussed at the > beginning of that section, in order to justify why we need best effort > encryption -- so that we can deploy SRTP without a priori knowledge of the > called party's deployment of RTP/SAVP-capable endpoints at that particular > moment. So, maybe I just misunderstood the situation: I had thought that with the new media cap stuff one would offer both RTP/SAVP and RTP/AVP, so you would get best effort. Am I confused? > > I guess RSA matters, but > > since we negotiate a separate protection profile for SRTP, 3DES/SHA > > isn't that relevant. Btw, TLS 1.2. will be AES. > > Thanks, changed to: > > This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as > its cipher suite, which is the mandatory-to-implement cipher suite in > TLS [I-D.ietf-tls-rfc4346-bis]. > > > Note also that DTLS-SRTP is compatible with RTP before the DTLS > > handshake. > > Only if the RTP profile is RTP/AVP; if the profile is RTP/SAVP, one expects > only SRTP. Is there text that needs to change to note that in the > requirements doc? Not sure. See my comment above about RTP/SAVP. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 9 21:17:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABBF3A686B; Wed, 9 Apr 2008 21:17:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F398E3A686B for ; Wed, 9 Apr 2008 21:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 unQG4V7++SSs for ; Wed, 9 Apr 2008 21:17:32 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0FD933A67FF for ; Wed, 9 Apr 2008 21:17:32 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3A4Hhnd031575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Apr 2008 23:17:50 -0500 Message-Id: <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> From: Dean Willis To: Michael Thomas In-Reply-To: <47FCF4A2.9080907@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 23:17:38 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 9, 2008, at 11:53 AM, Michael Thomas wrote: > >> Now, assume JoeBob is instead named "180055511212@example.com". All >> of the above works fine, until somebody calls into example.com's >> PSTN gateway from a spoofed Caller-ID of "18005551212" and asks >> said gateway to connect them to messages.example.net >> > > So just don't sign it. Or sign it as @example.com. Or just tell the > voice > mail provider not to create voice mail boxes for users with e164@example.com > like addresses. This really seems tenuous to me, Dean. I'm getting REALLY TIRED OF EXPLAINING THIS. Yeah, I know, one must say things ten time to be heard once. But this is eleven . . . ;-) We need to sign it, because SRTP-DTLS relies on the signature in order to protect the fingerprint of the media key from MITM attacks. In short, SRTP-DTLS requires RFC 4474 (for full function), and PSTN interaction precludes RFC 4474. Something has to give. As I see it, we MUST pick at least one of the following: 1) Change RFC 4474 so that it can be used with phone gateways. 2) Change DTLS-SRTP so that it doesn't depend on RFC 4474. 3) Decide that we can live without integrity protection of the media key on calls transiting PSTN gateways, and document this. We already have a strong argument for amending RFC 4474 so that SBCs that tweak the SDP don't break the Identity signature. If we do this, add the "not really an identity" flag, and mod DTLS-SRTP to account for the changes, then I think we have a full solution. -- 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 sip-bounces@ietf.org Wed Apr 9 21:20:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F4328C1C3; Wed, 9 Apr 2008 21:20:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D3128C0FA for ; Wed, 9 Apr 2008 21:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.922, 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 wCArGr8ETiDt for ; Wed, 9 Apr 2008 21:20: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 9A3C83A67FF for ; Wed, 9 Apr 2008 21:20:00 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Apr 2008 21:20:20 -0700 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 m3A4KKtf031755; Wed, 9 Apr 2008 21:20:20 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3A4KJg9019251; Thu, 10 Apr 2008 04:20:19 GMT From: "Dan Wing" To: "'Francois Audet'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> Date: Wed, 9 Apr 2008 21:20:19 -0700 Message-ID: <102501c89ac2$30337230$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFgAAMWYDAAA6nYJQACTXew DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1582; t=1207801220; x=1208665220; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=I2KVReNKVpEhW8t0MW76uYXNHvDdcZnmdgXMqdM/mJ8=; b=eSTE6nuC0DEtMNsDUeP6vJB3570HuUmmpNmLfGVbrjRPlmd4y2PalDpmsW z02UoS6khXMihpJeAnQQfV7sj4dSX6fhVOe9HxfQm2ZkMRORxVB2c6X05r92 ZN+advonTM; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, 'Paul Kyzivat' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, April 09, 2008 8:04 PM > To: Dan Wing > Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen > Subject: RE: [Sip] E.164 - who owns it > > Well, you can still do video over PSTN with H.320. I still > view this as "telephony". Sorry -- please pick something you cannot do over the PSTN. Instant Messaging, presence, high-quality video (HDTV), whatever. > Not sure I understand the question. Let me reword my previous email into a question: If you have a non-SIP telephony application that trunks towards the PSTN, and it is configured to process tel URIs, and it is asked to initiate a call that exceeds the capabilities of the PSTN (instant messaging, presence, HDTV-quality video, whatever you prefer) -- would it route the call towards a "SIP trunk" in order to gain the ability to set up that call, abort the call, or just ignore it all and trunk towards the PSTN? An additional question (statement, actually) is: We can't influence how that non-SIP telephony application provides for its own identity and authentication of tel URIs. (This is getting me to lean more towards my email-identity straw-man. With it, we can step out of this festering, smelly pile of trying to get E.164 working well with SIP and move to email-style SIP URIs. The IETF is capable of building an end-to-end identity/authentication solution around email-style SIP URIs; we have one (RFC4474) that works if we prohibit SBCs and B2BUAs from modifying SDP). -d _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 00:02:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951C33A6B00; Thu, 10 Apr 2008 00:02:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262C83A68E5 for ; Thu, 10 Apr 2008 00:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, WHOIS_PRIVPROT=1.501] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-0jYuo3x0XR for ; Thu, 10 Apr 2008 00:02:56 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id AB24C3A6B5C for ; Thu, 10 Apr 2008 00:02:55 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JZ300AB3KXEKA@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Apr 2008 08:03:14 +0100 (BST) Date: Thu, 10 Apr 2008 08:03:13 +0100 From: "Elwell, John" In-reply-to: <200804090231.m392V1oX026567@dragon.ariadne.com> To: Dale.Worley@comcast.net, sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: E.164-based SIP URIs and TEL URIs as aliases Thread-Index: AciZ6dRf5CkLt40VSESgIxnqKdrPTgA2vG6w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> Subject: [Sip] E.164-based SIP URIs and TEL URIs as aliases X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dale.Worley@comcast.net > Sent: 09 April 2008 03:31 > To: sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > > From: "Dan Wing" > > If those URIs included ";user=phone", there is a transitive > relationship between the SIP URI and the TEL URI. Without > ";user=phone", I agree that no meaning is supposed to be applied > to the user-part (the part to the left of the "@"). > > True. In that case, we have SIP URIs which are essentially aliases > for tel URIs. But in that case, any signing should be of the > fundamental tel URI, which then obviates the problem with an SBC that > translates one alias-URI into another. [JRE] But what about other parameters on the right hand side. For example, is tel:+123456789 an alias for: sip:+123456789@example.com;user=phone;gr=abd76gd6 ? I don't think so. And is: sip:+123456789@provider.net;user=phone; an alias for: sip:+123456789@example.com;user=phone;gr=abd76gd6 ? I don't think so And is: sip:+123456789@provider.net;user=phone;gr=abd76gd6 an alias for: sip:+123456789@example.com;user=phone;gr=abd76gd6 ? Possibly, assuming by routing the first one to provider.net it eventually gets changed to the latter and routed accordingly. You might ask whether these are valid examples. I believe they are, because the GRUU draft says just add a gr parameter to the AoR, and I believe the user=phone parameter is part of the AoR in this case. Of course, you wouldn't have a GRUU in a From header field, so this is perhaps not relevant to the RFC 4474 discussion (hence the change of thread name), but it is germane to the issue of how a Request URI can change as it is routed through intermediaries. 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 sip-bounces@ietf.org Thu Apr 10 05:40:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763D53A6975; Thu, 10 Apr 2008 05:40:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17043A6973 for ; Thu, 10 Apr 2008 05:40:47 -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 ST+eYMPQ8TAH for ; Thu, 10 Apr 2008 05:40:47 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id 65C523A6AB7 for ; Thu, 10 Apr 2008 05:40:05 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP; Thu, 10 Apr 2008 05:40:25 PDT 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 m3ACbVG3018447; Thu, 10 Apr 2008 05:37:31 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id m3ACeOI0009489; Thu, 10 Apr 2008 05:40:24 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 05:40:24 -0700 Received: from 10.7.241.26 ([10.7.241.26]) by namail5.corp.adobe.com ([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Apr 2008 12:40:23 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 10 Apr 2008 07:40:22 -0500 From: Heinrich Sinnreich To: Dan Wing , "'Francois Audet'" Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFgAAMWYDAAA6nYJQACTXewABHRL+8= In-Reply-To: <102501c89ac2$30337230$c5f0200a@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 10 Apr 2008 12:40:24.0600 (UTC) FILETIME=[0C273980:01C89B08] Cc: sip@ietf.org, 'Paul Kyzivat' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > (This is getting me to lean more towards my email-identity straw-man. With > it, we can step out of this festering, smelly pile of trying to get E.164 > working well with SIP and move to email-style SIP URIs. The IETF is capable > of building an end-to-end identity/authentication solution around email-style > SIP URIs; we have one (RFC4474) that works if we prohibit SBCs and B2BUAs from > modifying SDP). I believe this is the conclusion and about sums it up. Henry On 4/9/08 11:20 PM, "Dan Wing" wrote: > > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Wednesday, April 09, 2008 8:04 PM >> To: Dan Wing >> Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen >> Subject: RE: [Sip] E.164 - who owns it >> >> Well, you can still do video over PSTN with H.320. I still >> view this as "telephony". > > Sorry -- please pick something you cannot do over the PSTN. Instant > Messaging, presence, high-quality video (HDTV), whatever. > >> Not sure I understand the question. > > Let me reword my previous email into a question: > > If you have a non-SIP telephony application that trunks towards the PSTN, and > it is configured to process tel URIs, and it is asked to initiate a call that > exceeds the capabilities of the PSTN (instant messaging, presence, > HDTV-quality video, whatever you prefer) -- would it route the call towards a > "SIP trunk" in order to gain the ability to set up that call, abort the call, > or just ignore it all and trunk towards the PSTN? > > An additional question (statement, actually) is: We can't influence how that > non-SIP telephony application provides for its own identity and authentication > of tel URIs. > > (This is getting me to lean more towards my email-identity straw-man. With > it, we can step out of this festering, smelly pile of trying to get E.164 > working well with SIP and move to email-style SIP URIs. The IETF is capable > of building an end-to-end identity/authentication solution around email-style > SIP URIs; we have one (RFC4474) that works if we prohibit SBCs and B2BUAs from > modifying SDP). > > -d > > _______________________________________________ > 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 sip-bounces@ietf.org Thu Apr 10 07:46:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1B93A6B2A; Thu, 10 Apr 2008 07:46:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7033A6B2A for ; Thu, 10 Apr 2008 07:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.032 X-Spam-Level: X-Spam-Status: No, score=-4.032 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, WHOIS_PRIVPROT=1.501] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQc5ubim8sAC for ; Thu, 10 Apr 2008 07:45:58 -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 CE0E928C515 for ; Thu, 10 Apr 2008 07:45:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,636,1199682000"; d="scan'208";a="4618117" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2008 10:45:58 -0400 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 m3AEjwKD020033; Thu, 10 Apr 2008 10:45:58 -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 m3AEjsxA018572; Thu, 10 Apr 2008 14:45:58 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); Thu, 10 Apr 2008 10:45:56 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 10:45:56 -0400 Message-ID: <47FE283F.7060209@cisco.com> Date: Thu, 10 Apr 2008 10:46:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 10 Apr 2008 14:45:56.0258 (UTC) FILETIME=[955F0820:01C89B19] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3088; t=1207838758; x=1208702758; 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]=20E.164-based=20SIP=20URIs=20and= 20TEL=20URIs=20as=20aliases |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=bOP08XFHfe0VNHlAC3tV5NZNkDNMNWGFSWceXkrQa/8=; b=mJt4y4yFNrZ+JLJGLCXU2nqQJUiXa47ujXUKtMFdI5SSKmwCmLKUCSj6J2 4HPpCl96xGxof7/rRDeZlb3A4BYzAaFINuMQlM2TWRJ9xW+y1pvSHWB0h4md VwFoK0zVOg; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Dale.Worley@comcast.net >> Sent: 09 April 2008 03:31 >> To: sip@ietf.org >> Subject: Re: [Sip] E.164 - who owns it >> >> >> From: "Dan Wing" >> >> If those URIs included ";user=phone", there is a transitive >> relationship between the SIP URI and the TEL URI. Without >> ";user=phone", I agree that no meaning is supposed to be applied >> to the user-part (the part to the left of the "@"). >> >> True. In that case, we have SIP URIs which are essentially aliases >> for tel URIs. But in that case, any signing should be of the >> fundamental tel URI, which then obviates the problem with an SBC that >> translates one alias-URI into another. > [JRE] But what about other parameters on the right hand side. For > example, is > tel:+123456789 > an alias for: > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > > I don't think so. > > And is: > sip:+123456789@provider.net;user=phone; > an alias for: > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > > I don't think so > > And is: > sip:+123456789@provider.net;user=phone;gr=abd76gd6 > an alias for: > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > Possibly, assuming by routing the first one to provider.net it > eventually gets changed to the latter and routed accordingly. > > You might ask whether these are valid examples. I believe they are, > because the GRUU draft says just add a gr parameter to the AoR, and I > believe the user=phone parameter is part of the AoR in this case. IMO it is a little fuzzy whether URI parameters are actually part of an AOR. When adding or looking up a URI in a location service, it is first canonicalized by removing all URI parameters, including the "user" parameter. As a result, both sip:+123456789@provider.net;user=phone sip:+123456789@provider.net will route to the same place. Its not entirely clear to me whether the gruu is to be constructed with the canonicalized URI or the original one. But there seems to be nothing to prevent you from registering once using user=phone, and another time omitting it, or using user=ip. And you would get the same location service entry in both cases. > Of course, you wouldn't have a GRUU in a From header field, so this is > perhaps not relevant to the RFC 4474 discussion (hence the change of > thread name), but it is germane to the issue of how a Request URI can > change as it is routed through intermediaries. I think the bottom line is that we can't just toss out the term "alias" as something that is well defined. I think that A can be an alias for B for one purpose, but not be an alias for B for some other purpose. In this discussion, I think two From-URIs might sometimes be considered aliases of one another if they result in the same callerid display to the recipient, or if calls to both reach the same destination. 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 sip-bounces@ietf.org Thu Apr 10 08:14:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FB428C50D; Thu, 10 Apr 2008 08:14:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FC128C1C8 for ; Thu, 10 Apr 2008 08:14:34 -0700 (PDT) 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, 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 5ywzVqb9xGRR for ; Thu, 10 Apr 2008 08:14:33 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id A5DED28C505 for ; Thu, 10 Apr 2008 08:14:31 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so29281wfa.31 for ; Thu, 10 Apr 2008 08:14:49 -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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=1lC1ny7ygd+mVvbzWcj10lTlYl8N3d8iiu0eECwGgpA=; b=CNpI4/FpapSe4zctuEz46Sr9zscL7QEmKREGB/sjE6IwKsRGwi2rPSUYxFIn+IhlNBa9YskpRuRDcnROM07L3VvwX4tDdz1gqjCCT8exySl8LLAnJlgU/eIgxmNHbuPy1bnsbQ1Oiu7xgF+K7HM4zr2E6X0DCXxrhWazl3aY9DA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ohFHMX6/zQTz/zo4ZQzU/GHdoBIRABUPDKJy2TgT0Z1g4kQd23YuNoHd7cg4qlPPsGJ1YyvrWyFpDI1Po0wxGmlrkogwva/x7qNIkVE01LKWXLQuDYaWqUrSjbZk8HfNb3kWSee0QK3WqKi5kRP2bvgRzZQ+I0drv0PjZkYDbe8= Received: by 10.142.162.5 with SMTP id k5mr481973wfe.53.1207840489372; Thu, 10 Apr 2008 08:14:49 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Thu, 10 Apr 2008 08:14:49 -0700 (PDT) Message-ID: <953beacc0804100814n6f142761g663c23dab35f8feb@mail.gmail.com> Date: Thu, 10 Apr 2008 08:14:49 -0700 From: "Rohan Mahy" To: "Hadriel Kaplan" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <953beacc0804071449y11b22ca4tead6a3659a9e9d@mail.gmail.com> Cc: "sip@ietf.org" Subject: Re: [Sip] Comments on sip-outbound-13 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, On Tue, Apr 8, 2008 at 7:48 PM, Hadriel Kaplan wrote: > > > 2) If a Register is 3xx redirected, does the new retargeted Register > > use the same reg-id, even though it's a different "flow"? (I assume so) I > > ask because some people use 3xx for Registers to load-balance or perform > > anycasting. It may be good to add this to end of section 4.2.1. > > > > Yes, the UA uses the same reg-id. It uses the the reg-id to indicate > > that this is (for example) my "2nd logical flow" to my registrar or > > the logical flow over my "cellular interface". Can you suggest > > something here or point out the specific part that is confusing.? > > I ask because one could get a 3xx for Register at any time, for example while there is an established dialog over that flow. (but it would be weird, and we can't account for all bizarre corner cases) > At the end of section 4.2.1, add: > "If the registering UA receives a 3xx response to the REGISTER request, such that it moves its registration "flow", it SHOULD reuse the same reg-id value for the moved REGISTER." I think it may already say to do something like that overall in another place. I'll take a closer look and see if it adds or detracts from the overall clarity of the document. > > > 6) Page 12, Section 4.1: > > > "It also provides an easy way to guarantee uniqueness within the AOR." > > I'm a bit confused by that, because I don't believe we're saying one UA > > instance only ever represents one AoR. (ie, multiple AoR's registered on > > the same UA will have the same registered contact instance) Recommend > > removing or rewording. > > > > I don't see the confusion. _Within_ the AOR, the instance-id provides > > further disambiguation. I can absolutely use the instance with more > > than one AOR. > > Ahh, then maybe it's a missing comma that screwed me up. Should be: > "It also provides an easy way to guarantee uniqueness, within the AoR, when multiple UA's are registered for the same AOR." > Otherwise to me it looked like it was claiming the instance guaranteed uniqueness [to] the AoR. I think this is more confusing with the extra commas, and the RFC editor is likely to just remove them anyway. (I remember paragraph upon paragraph in the Replaces or MWI spec where the only change between the RFC and the approved ID where a bunch of commas removed.) > > > 9) Page 16, Section 4.3: > > > ... For TLS protocols, there MUST also > > > be a match between the host production in the next hop and one of the > > > URIs contained in the subjectAltName in the peer certificate. > > > s/production in/resolved for/ > > > > I don't think your proposed rewording is correct. Perhaps s/next > > hop/next hop URI/ ? Actually when I looked at the text again, it is completely wrong. If the certificate has a domain name in subjectName, but no subjectAltName, the UA should compare against that too. > OK. Is "production" a common use for it? Maybe s/production in/portion of/ as well as your URI addition? Yes. FYI: "production" has a very specific meaning. It refers to a name used inside the BNF. The host production in the RFC 3261 is shown here: SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] ... hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference thanks, -rohan _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 09:49:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0303A69B8; Thu, 10 Apr 2008 09:49:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED45A3A69B8 for ; Thu, 10 Apr 2008 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=0.454, 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 cyUHoPAGHnS1 for ; Thu, 10 Apr 2008 09:49:47 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 8B2983A68C6 for ; Thu, 10 Apr 2008 09:49:46 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3AGo3f13886; Thu, 10 Apr 2008 16:50:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 11:49:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> In-Reply-To: <102501c89ac2$30337230$c5f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFgAAMWYDAAA6nYJQACTXewABpul0A= References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> From: "Francois Audet" To: "Dan Wing" Cc: sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm still not sure I get it. If I present a Tel URI, and somebody uses it to reach me, and it just happens that we are both using SIP as our default "Telephony" client, then sure, you absolutely will be able to do whatever you want (IM, HD, etc.). The point is that if you choose to advertise a Tel URI INSTEAD of a SIP URI, don't be surprised if you have people reaching you with PSTN-capabilies only. Conversely, if you choose to advertize a SIP URI ONLY, then you may be missing out entirely on people calling from PSTN. - At least, that's the theory... > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, April 09, 2008 21:20 > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; 'Paul Kyzivat'; 'Juha Heinanen' > Subject: RE: [Sip] E.164 - who owns it > > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Wednesday, April 09, 2008 8:04 PM > > To: Dan Wing > > Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen > > Subject: RE: [Sip] E.164 - who owns it > > > > Well, you can still do video over PSTN with H.320. I still > view this > > as "telephony". > > Sorry -- please pick something you cannot do over the PSTN. > Instant Messaging, presence, high-quality video (HDTV), whatever. > > > Not sure I understand the question. > > Let me reword my previous email into a question: > > If you have a non-SIP telephony application that trunks > towards the PSTN, and it is configured to process tel URIs, > and it is asked to initiate a call that exceeds the > capabilities of the PSTN (instant messaging, presence, > HDTV-quality video, whatever you prefer) -- would it route > the call towards a "SIP trunk" in order to gain the ability > to set up that call, abort the call, or just ignore it all > and trunk towards the PSTN? > > An additional question (statement, actually) is: We can't > influence how that non-SIP telephony application provides for > its own identity and authentication of tel URIs. > > (This is getting me to lean more towards my email-identity > straw-man. With it, we can step out of this festering, > smelly pile of trying to get E.164 working well with SIP and > move to email-style SIP URIs. The IETF is capable of > building an end-to-end identity/authentication solution > around email-style SIP URIs; we have one (RFC4474) that works > if we prohibit SBCs and B2BUAs from modifying SDP). > > -d > > _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 10:02:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F4F3A6D17; Thu, 10 Apr 2008 10:02:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85EE93A68F3 for ; Thu, 10 Apr 2008 10:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.899, 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 4a1Whjkba4gC for ; Thu, 10 Apr 2008 10:02:37 -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 16BD43A69B8 for ; Thu, 10 Apr 2008 10:02:37 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 10 Apr 2008 10:02:58 -0700 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 m3AH2wmd012696; Thu, 10 Apr 2008 10:02:58 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3AH2vpx023927; Thu, 10 Apr 2008 17:02:57 GMT From: "Dan Wing" To: "'Francois Audet'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> Date: Thu, 10 Apr 2008 10:02:57 -0700 Message-ID: <136d01c89b2c$b9fc5fd0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFgAAMWYDAAA6nYJQACTXewABpul0AAAHFL8A== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3470; t=1207846978; x=1208710978; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=6ABB3ErRAb88dG98IN+QIF4pQ6nObMoaZyRgrz6RL6s=; b=buOhhY7s/4edP7QVeqanlCFiqZPVQB2F6x1mktKlSdWj7sg4c3VZsxe12I mxGrIlJAK2zv3x6NBA5EU8HacZJ9BIqBT9bRLBhfgCTjB4LCjZ+M0vYcpleV Y27OSWppJpNyHJo2hC1j/xqxReX7xxJ9k2l4S/1w/63tTWKEh2Pv8=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, 'Paul Kyzivat' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, April 10, 2008 9:50 AM > To: Dan Wing > Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen > Subject: RE: [Sip] E.164 - who owns it > > I'm still not sure I get it. > > If I present a Tel URI, and somebody uses it to reach me, and > it just happens > that we are both using SIP as our default "Telephony" client, > then sure, you > absolutely will be able to do whatever you want (IM, HD, etc.). > > The point is that if you choose to advertise a Tel URI > INSTEAD of a SIP URI, don't be > surprised if you have people reaching you with PSTN-capabilies only. Sure, folks might contact me over the PSTN if I used a TEL URI, and I agree that I wouldn't be surprised. Afterall, the PSTN remains the lowest-common denominator for interactive communications. > Conversely, if you choose to advertize a SIP URI ONLY, then > you may be missing out entirely on people calling from PSTN. > > - At least, that's the theory... Advertising a SIP URI exclusively would be as silly as advertising an email URI exclusively. You always want a way to accept incoming PSTN calls (because it is the lowest common denominator for interactive communications), and a legitimate business would also want a physical address and a postal address to receive physical packages and deliveries. -d > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Wednesday, April 09, 2008 21:20 > > To: Audet, Francois (SC100:3055) > > Cc: sip@ietf.org; 'Paul Kyzivat'; 'Juha Heinanen' > > Subject: RE: [Sip] E.164 - who owns it > > > > > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Wednesday, April 09, 2008 8:04 PM > > > To: Dan Wing > > > Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen > > > Subject: RE: [Sip] E.164 - who owns it > > > > > > Well, you can still do video over PSTN with H.320. I still > > view this > > > as "telephony". > > > > Sorry -- please pick something you cannot do over the PSTN. > > Instant Messaging, presence, high-quality video (HDTV), whatever. > > > > > Not sure I understand the question. > > > > Let me reword my previous email into a question: > > > > If you have a non-SIP telephony application that trunks > > towards the PSTN, and it is configured to process tel URIs, > > and it is asked to initiate a call that exceeds the > > capabilities of the PSTN (instant messaging, presence, > > HDTV-quality video, whatever you prefer) -- would it route > > the call towards a "SIP trunk" in order to gain the ability > > to set up that call, abort the call, or just ignore it all > > and trunk towards the PSTN? > > > > An additional question (statement, actually) is: We can't > > influence how that non-SIP telephony application provides for > > its own identity and authentication of tel URIs. > > > > (This is getting me to lean more towards my email-identity > > straw-man. With it, we can step out of this festering, > > smelly pile of trying to get E.164 working well with SIP and > > move to email-style SIP URIs. The IETF is capable of > > building an end-to-end identity/authentication solution > > around email-style SIP URIs; we have one (RFC4474) that works > > if we prohibit SBCs and B2BUAs from modifying SDP). > > > > -d > > > > _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 10:11:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390A23A6D96; Thu, 10 Apr 2008 10:11:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7213A6B89 for ; Thu, 10 Apr 2008 10:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.436, 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 mi6QrOMxjpMU for ; Thu, 10 Apr 2008 10:11:52 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9E27F28C50C for ; Thu, 10 Apr 2008 10:11:10 -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 m3AHBRh02189; Thu, 10 Apr 2008 17:11:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 12:11:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF160F4E5D@zrc2hxm0.corp.nortel.com> In-Reply-To: <136d01c89b2c$b9fc5fd0$c5f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciaYZJeLnTm1GmzR4GzaI3QZsWtwwAOvzFgAAMWYDAAA6nYJQACTXewABpul0AAAHFL8AAAU1Gg References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <136d01c89b2c$b9fc5fd0$c5f0200a@cisco.com> From: "Francois Audet" To: "Dan Wing" Cc: sip@ietf.org, Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Advertising a SIP URI exclusively would be as silly as > advertising an email URI exclusively. You always want a way > to accept incoming PSTN calls (because it is the lowest > common denominator for interactive communications), and a > legitimate business would also want a physical address and a > postal address to receive physical packages and deliveries. Agreed. Cutting to the chase, I'd put the following on my business card: tel: +1-408-495-2456 sip:audet@nortel.com mailto:audet@nortel.com Cheers. _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 10:13:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBB528C1E2; Thu, 10 Apr 2008 10:13:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B3128C1E2 for ; Thu, 10 Apr 2008 10:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.402 X-Spam-Level: X-Spam-Status: No, score=-5.402 tagged_above=-999 required=5 tests=[AWL=1.197, 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 1uieQ8Yne4a5 for ; Thu, 10 Apr 2008 10:13:42 -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 878193A68E3 for ; Thu, 10 Apr 2008 10:13:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,636,1199682000"; d="scan'208";a="4643298" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2008 13:14:01 -0400 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 m3AHE18O026073; Thu, 10 Apr 2008 13:14:01 -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 m3AHE1xZ013123; Thu, 10 Apr 2008 17:14:01 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); Thu, 10 Apr 2008 13:14:01 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 13:14:00 -0400 Message-ID: <47FE4AF4.4060401@cisco.com> Date: Thu, 10 Apr 2008 13:14:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 10 Apr 2008 17:14:00.0767 (UTC) FILETIME=[44F384F0:01C89B2E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3831; t=1207847641; x=1208711641; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Francois=20Audet=20; bh=vqZvFhD6GIUa2v7Tlrh8aBJJ2TTqtC/glBF7pPqZ0zo=; b=l3TG9y9ZiNp/t9PkhUgOZI+fbIzMP676RI1qmoTtbGOaysxRKdgmxx/x+A yMQ5ze/CJ9gfn7KDTDedUkE1siAf31FdFAS0XjJBuTpmWvJvlEYbvP6o52Aj EjwimyWA9T; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois, I agree with your point entirely. BUT, even if I choose to advertise a sip URI (with user=phone), some of the UASs I call may well display only the numeric portion as the callerid. Those people in turn may then attempt to call me back using a TEL URI, and as a result, may end up going over the PSTN, even if originating from a sip device. (I don't know how often a PSTN path will be chosen even if a sip path was possible, but probably more often than we would wish.) If the devices are half way smart, even if they only show the number they will keep the entire URI in their call log, so that if I attempt a callback via the call log it will use the whole URI. But I expect some devices will be dumber than that. I don't know that we can do anything about it, except perhaps publish some best practices drafts. But I expect it may be a problem for a long time. Paul Francois Audet wrote: > I'm still not sure I get it. > > If I present a Tel URI, and somebody uses it to reach me, and it just happens > that we are both using SIP as our default "Telephony" client, then sure, you > absolutely will be able to do whatever you want (IM, HD, etc.). > > The point is that if you choose to advertise a Tel URI INSTEAD of a SIP URI, don't be > surprised if you have people reaching you with PSTN-capabilies only. > > Conversely, if you choose to advertize a SIP URI ONLY, then you may be missing out > entirely on people calling from PSTN. > > - At least, that's the theory... > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Wednesday, April 09, 2008 21:20 >> To: Audet, Francois (SC100:3055) >> Cc: sip@ietf.org; 'Paul Kyzivat'; 'Juha Heinanen' >> Subject: RE: [Sip] E.164 - who owns it >> >> >> >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortel.com] >>> Sent: Wednesday, April 09, 2008 8:04 PM >>> To: Dan Wing >>> Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen >>> Subject: RE: [Sip] E.164 - who owns it >>> >>> Well, you can still do video over PSTN with H.320. I still >> view this >>> as "telephony". >> Sorry -- please pick something you cannot do over the PSTN. >> Instant Messaging, presence, high-quality video (HDTV), whatever. >> >>> Not sure I understand the question. >> Let me reword my previous email into a question: >> >> If you have a non-SIP telephony application that trunks >> towards the PSTN, and it is configured to process tel URIs, >> and it is asked to initiate a call that exceeds the >> capabilities of the PSTN (instant messaging, presence, >> HDTV-quality video, whatever you prefer) -- would it route >> the call towards a "SIP trunk" in order to gain the ability >> to set up that call, abort the call, or just ignore it all >> and trunk towards the PSTN? >> >> An additional question (statement, actually) is: We can't >> influence how that non-SIP telephony application provides for >> its own identity and authentication of tel URIs. >> >> (This is getting me to lean more towards my email-identity >> straw-man. With it, we can step out of this festering, >> smelly pile of trying to get E.164 working well with SIP and >> move to email-style SIP URIs. The IETF is capable of >> building an end-to-end identity/authentication solution >> around email-style SIP URIs; we have one (RFC4474) that works >> if we prohibit SBCs and B2BUAs from modifying SDP). >> >> -d >> >> > _______________________________________________ > 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 sip-bounces@ietf.org Thu Apr 10 10:18:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DCC28C0ED; Thu, 10 Apr 2008 10:18:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0233A69B8 for ; Thu, 10 Apr 2008 10:18:38 -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.878, 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 zV0k-YhOoBE8 for ; Thu, 10 Apr 2008 10:18:37 -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 E696A3A6949 for ; Thu, 10 Apr 2008 10:18:37 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 10 Apr 2008 10:18:59 -0700 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 m3AHIxNS020754; Thu, 10 Apr 2008 10:18:59 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3AHIwhv011939; Thu, 10 Apr 2008 17:18:58 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , "'Francois Audet'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> Date: Thu, 10 Apr 2008 10:18:58 -0700 Message-ID: <13d201c89b2e$f6b3f990$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47FE4AF4.4060401@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcibLk1vt0aC8tMJTIKhT2H+yleJtQAAG/tQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4539; t=1207847939; x=1208711939; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=204nCM3FgYgFvyKjDcsnkKxOg9Qr2PXlNnxo/U/fDCM=; b=g/+tjM5WiR8RuuKJ+otDSVtzPZNnS2toIBalS5WL4RS28YdefPkap7Qa5h 26O0Dw7VHjd+ZM2G5v0pEkS+E8M5m1XCazulvFSy8HxPUDjt08PALtj4uCbd SxVHwDttdA; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 10, 2008 10:14 AM > To: Francois Audet > Cc: Dan Wing; sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > Francois, > > I agree with your point entirely. > > BUT, even if I choose to advertise a sip URI (with > user=phone), some of > the UASs I call may well display only the numeric portion as the > callerid. Those people in turn may then attempt to call me > back using a > TEL URI, and as a result, may end up going over the PSTN, even if > originating from a sip device. (I don't know how often a PSTN > path will > be chosen even if a sip path was possible, but probably more > often than we would wish.) Until there is a reason to use IP, nobody cares if the call goes over the PSTN. Reasons might include, but are not limited to, encrypted media, strong identity, high-quality video, multimedia (whiteboard, screen sharing, etc.), and so on. > If the devices are half way smart, even if they only show the number > they will keep the entire URI in their call log, so that if I > attempt a > callback via the call log it will use the whole URI. But I > expect some > devices will be dumber than that. > > I don't know that we can do anything about it, except perhaps publish > some best practices drafts. But I expect it may be a problem > for a long time. Yep. -d > Paul > > Francois Audet wrote: > > I'm still not sure I get it. > > > > If I present a Tel URI, and somebody uses it to reach me, > and it just happens > > that we are both using SIP as our default "Telephony" > client, then sure, you > > absolutely will be able to do whatever you want (IM, HD, etc.). > > > > The point is that if you choose to advertise a Tel URI > INSTEAD of a SIP URI, don't be > > surprised if you have people reaching you with PSTN-capabilies only. > > > > Conversely, if you choose to advertize a SIP URI ONLY, then > you may be missing out > > entirely on people calling from PSTN. > > > > - At least, that's the theory... > > > >> -----Original Message----- > >> From: Dan Wing [mailto:dwing@cisco.com] > >> Sent: Wednesday, April 09, 2008 21:20 > >> To: Audet, Francois (SC100:3055) > >> Cc: sip@ietf.org; 'Paul Kyzivat'; 'Juha Heinanen' > >> Subject: RE: [Sip] E.164 - who owns it > >> > >> > >> > >>> -----Original Message----- > >>> From: Francois Audet [mailto:audet@nortel.com] > >>> Sent: Wednesday, April 09, 2008 8:04 PM > >>> To: Dan Wing > >>> Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen > >>> Subject: RE: [Sip] E.164 - who owns it > >>> > >>> Well, you can still do video over PSTN with H.320. I still > >> view this > >>> as "telephony". > >> Sorry -- please pick something you cannot do over the PSTN. > >> Instant Messaging, presence, high-quality video (HDTV), whatever. > >> > >>> Not sure I understand the question. > >> Let me reword my previous email into a question: > >> > >> If you have a non-SIP telephony application that trunks > >> towards the PSTN, and it is configured to process tel URIs, > >> and it is asked to initiate a call that exceeds the > >> capabilities of the PSTN (instant messaging, presence, > >> HDTV-quality video, whatever you prefer) -- would it route > >> the call towards a "SIP trunk" in order to gain the ability > >> to set up that call, abort the call, or just ignore it all > >> and trunk towards the PSTN? > >> > >> An additional question (statement, actually) is: We can't > >> influence how that non-SIP telephony application provides for > >> its own identity and authentication of tel URIs. > >> > >> (This is getting me to lean more towards my email-identity > >> straw-man. With it, we can step out of this festering, > >> smelly pile of trying to get E.164 working well with SIP and > >> move to email-style SIP URIs. The IETF is capable of > >> building an end-to-end identity/authentication solution > >> around email-style SIP URIs; we have one (RFC4474) that works > >> if we prohibit SBCs and B2BUAs from modifying SDP). > >> > >> -d > >> > >> > > _______________________________________________ > > 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 sip-bounces@ietf.org Thu Apr 10 10:19:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989603A69E2; Thu, 10 Apr 2008 10:19:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78113A6936 for ; Thu, 10 Apr 2008 10:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=1.167, 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 WqwwytSuhYFx for ; Thu, 10 Apr 2008 10:19:00 -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 B66C63A6949 for ; Thu, 10 Apr 2008 10:18:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,636,1199682000"; d="scan'208";a="4643934" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2008 13:19:17 -0400 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 m3AHJHV2028935; Thu, 10 Apr 2008 13:19: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 m3AHJHHU019222; Thu, 10 Apr 2008 17:19:17 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); Thu, 10 Apr 2008 13:19:17 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 13:19:16 -0400 Message-ID: <47FE4C30.1080309@cisco.com> Date: Thu, 10 Apr 2008 13:19:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <136d01c89b2c$b9fc5fd0$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4E5D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF160F4E5D@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 10 Apr 2008 17:19:16.0544 (UTC) FILETIME=[012B4400:01C89B2F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1083; t=1207847957; x=1208711957; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Francois=20Audet=20; bh=FOltmpgsm0/FmX4MOLelEskdkLXLnhwuC0iIrzquaY4=; b=Vft2nYX9dyhjUP2xsGEaCV+Q4XeDDvgfL49QEzpLeL9Phamw66rO99SOEa S9n1A5sg+o4D8DA0Dh3/LSog1McsU73YsAKoridtQ1NtQNzQn2iX8nXCFzCb RIigUsGzTE; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet wrote: > >> Advertising a SIP URI exclusively would be as silly as >> advertising an email URI exclusively. You always want a way >> to accept incoming PSTN calls (because it is the lowest >> common denominator for interactive communications), and a >> legitimate business would also want a physical address and a >> postal address to receive physical packages and deliveries. > > Agreed. > > Cutting to the chase, I'd put the following on my business card: > > tel: +1-408-495-2456 > sip:audet@nortel.com > mailto:audet@nortel.com Interestingly, that doesn't indicate that you are reachable via sip using the numeric address. A sip caller given the tel might figure that out, but might not. If you had user enum, and the caller used it, then all is well. But if not, and if the caller just blasts the tel uri to his SP, it may figure it out, and may not. You are going to ask why the caller would use the tel form in that case. One reason would be because the UI of the device only supports numeric input. 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 sip-bounces@ietf.org Thu Apr 10 10:27:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296323A68F3; Thu, 10 Apr 2008 10:27:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F653A6C77 for ; Thu, 10 Apr 2008 10:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 nM9HPqTIZtBw for ; Thu, 10 Apr 2008 10:27:02 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id D98683A68A8 for ; Thu, 10 Apr 2008 10:27:01 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3AHRDt03264; Thu, 10 Apr 2008 17:27:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 12:27:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF160F4EBD@zrc2hxm0.corp.nortel.com> In-Reply-To: <47FE4C30.1080309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcibLwgqWq+OExVkTbSBXV3Pf5QFpQAABHDg References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <136d01c89b2c$b9fc5fd0$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4E5D@zrc2hxm0.corp.nortel.com> <47FE4C30.1080309@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > Agreed. > > > > Cutting to the chase, I'd put the following on my business card: > > > > tel: +1-408-495-2456 > > sip:audet@nortel.com > > mailto:audet@nortel.com > > Interestingly, that doesn't indicate that you are reachable > via sip using the numeric address. Yes, I did that on purpose. I don't see a point in doing it. > A sip caller given the tel might figure that out, but might > not. If you had user enum, and the caller used it, then all > is well. But if not, and if the caller just blasts the tel > uri to his SP, it may figure it out, and may not. > > You are going to ask why the caller would use the tel form in > that case. > One reason would be because the UI of the device only > supports numeric input. So, a SIP user (or anybody young enough to prefer IM paradigm to phone paradigm) will use sip:audet@nortel.com. The old luddites with a PSTN-looking phone will keep on dialing digits on their phone. That's where the Tel URI is useful. The niche market for sip:+14084952456@nortel.com;user=phone is very small. Beyond people on this mailing list, I really don't see who would care. I really believe that practically speaking, sip:+14084952456@nortel.com;user=phone is meant to be used "on-the wire" as opposed to by users. sip:audet@nortel.com ~= http://www.att.com sip:+14084952456@nortel.com;user=phone ~= http://www.att.com/gen/landing-pages?pid=3308 I think we are rat-holing on imaginary issues. _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 10:51:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA203A6AB4; Thu, 10 Apr 2008 10:51:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5DB3A6A95 for ; Thu, 10 Apr 2008 10:51:22 -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 xXNnXXguS4ty for ; Thu, 10 Apr 2008 10:51:21 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id D18813A69B1 for ; Thu, 10 Apr 2008 10:51:20 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA10.westchester.pa.mail.comcast.net with comcast id Bny51Z0080SCNGk5A0Mh00; Thu, 10 Apr 2008 17:50:37 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA09.westchester.pa.mail.comcast.net with comcast id Btre1Z00602AVH03V00000; Thu, 10 Apr 2008 17:51:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=rtD8F3aS0SdlV_xt6VEA:9 a=-HoOuYxBtxbx6dXzcj4A:7 a=ulTBC8VtPeMcWjaAREW8YyYZmbYA:4 a=nvz6EU7xhngA:10 a=JfD0Fch1gWkA:10 a=Y6qChIQXU1wA:10 a=MQEq1R4Qs-cA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m3AHpbEA005182 for ; Thu, 10 Apr 2008 13:51:37 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m3AHpbfD005178; Thu, 10 Apr 2008 13:51:37 -0400 Date: Thu, 10 Apr 2008 13:51:37 -0400 Message-Id: <200804101751.m3AHpbfD005178@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <091b01c89a73$123ea0f0$c5f0200a@cisco.com> (dwing@cisco.com) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <091b01c89a73$123ea0f0$c5f0200a@cisco.com> Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Dan Wing" > Sorry, I don't understand. You said "sending a SIP request towards > the E.164", by which I understand an Enum lookup. Did you mean > "sending a SIP request towards a SIP URI which purposts to represent > an E.164"? draft-wing-sip-e164-rrc-01.txt says to turn the SIP URI into a TEL URI, and then generate a Return Routability Check (RRC) towards that TEL URI: "1. Strip the domain name of the From: of the incoming INVITE. This results in a TEL URI. For example, "sip:+14085551234@example.com;user=phone" is rewritten to "tel:+14085551212". 2. Rewrite the TEL URI to a SIP URI, following the Verifier's default routing rules. For example, if outgoing calls are sent to the service provider example.net, then "tel:+14085551212" is rewritten to "sip:+14085551212@example.net;user=phone". 3. Generate a random nonce. 4. Using the SIP URI constructed in step (2), construct a SIP SUBSCRIBE message with Request-URI and To headers that use that SIP URI, and an "Expires" header of 0. The SUBSCRIBE contains the random nonce in its body as Content-Type application/ return-routability-nonce. 5. Send the SUBSCRIBE message. This will cause the calling party to send a NOTIFY." Interesting... Because the verification generated by this algorithm is not quite what I expected from how it was described, and it is both narrower and probably more useful than what I expected. The verification is that "Within the Verifier's context, the routing rules that are in effect send tel:+1234 to the given domain." This actually doesn't say anything about ownership of E.164 numbers (other than that E.164 numbers are the space of URIs), but it says a tremendous amount about how requests are routed from the Verifier's context: "If I call the given number, will I reach the given domain?" That's not useful for validating an incoming caller based on an asserted E.164 origin number (unless one's local E.164 routing is known to be trustable), but it's really useful for knowing if I can call the caller back using the asserted E.164 number. 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 sip-bounces@ietf.org Thu Apr 10 11:00:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4188E3A6C11; Thu, 10 Apr 2008 11:00:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5AA3A6D7D for ; Thu, 10 Apr 2008 11:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, WHOIS_PRIVPROT=1.501] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwuLfoF2Clqg for ; Thu, 10 Apr 2008 11:00:47 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 439653A6A9A for ; Thu, 10 Apr 2008 11:00:46 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id BsqY1Z00B0b6N64A40BC00; Thu, 10 Apr 2008 17:59:41 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id Bu131Z00L02AVH08P00000; Thu, 10 Apr 2008 18:01:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=xLPoA1gjxn0A:10 a=7igci86rYXoA:10 a=qh4bsZn7IJTV6zevKLEA:9 a=LzirhUISgbtYwhVdruHIpmgSJPIA:4 a=7L8GPyMnTjgA:10 a=k4qQewaewV0A:10 a=Y6qChIQXU1wA:10 a=E8bbQR1U94EA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m3AI13EA005884 for ; Thu, 10 Apr 2008 14:01:03 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m3AI13DW005880; Thu, 10 Apr 2008 14:01:03 -0400 Date: Thu, 10 Apr 2008 14:01:03 -0400 Message-Id: <200804101801.m3AI13DW005880@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> (john.elwell@siemens.com) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "Elwell, John" [JRE] But what about other parameters on the right hand side. For example, is tel:+123456789 an alias for: sip:+123456789@example.com;user=phone;gr=abd76gd6 ? I don't think so. And is: sip:+123456789@provider.net;user=phone; an alias for: sip:+123456789@example.com;user=phone;gr=abd76gd6 ? I don't think so And is: sip:+123456789@provider.net;user=phone;gr=abd76gd6 an alias for: sip:+123456789@example.com;user=phone;gr=abd76gd6 ? Possibly, assuming by routing the first one to provider.net it eventually gets changed to the latter and routed accordingly. Personally, I agree with you that these URIs are all "different". But if we consider them to be different, any signing mechanism must consider them to be different, and any transport mechanism must avoid changing one of them into another. Previously in this discussion, people have argued that SBCs are not behaving incorrectly when they change one of these URIs into another, and that thus any signing mechanism must tolerate such a substitution. 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 sip-bounces@ietf.org Thu Apr 10 11:04:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96AD3A6D4A; Thu, 10 Apr 2008 11:04:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54F863A6DC6 for ; Thu, 10 Apr 2008 11:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.459 X-Spam-Level: X-Spam-Status: No, score=-5.459 tagged_above=-999 required=5 tests=[AWL=1.140, 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 cimSvTS6BmJB for ; Thu, 10 Apr 2008 11:04:18 -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 7F89D3A69FC for ; Thu, 10 Apr 2008 11:04:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,637,1199682000"; d="scan'208";a="4638711" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2008 14:04:37 -0400 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 m3AI4bx8020055; Thu, 10 Apr 2008 14:04:37 -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 m3AI4bui006404; Thu, 10 Apr 2008 18:04:37 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); Thu, 10 Apr 2008 14:04:37 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 14:04:36 -0400 Message-ID: <47FE56D0.40705@cisco.com> Date: Thu, 10 Apr 2008 14:05:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <136d01c89b2c$b9fc5fd0$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4E5D@zrc2hxm0.corp.nortel.com> <47FE4C30.1080309@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4EBD@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF160F4EBD@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 10 Apr 2008 18:04:36.0890 (UTC) FILETIME=[569F1FA0:01C89B35] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2143; t=1207850677; x=1208714677; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Francois=20Audet=20; bh=b77FSUQuzlowMY6MFhUpqXbfB16W8gSxsegWDiCD0nY=; b=VCHg590ACgh9ckfSyogiUa37eYeCiIo9INGXc4I8vsOfFhhimbp8/JNddm kvR2E7Xyal6XtSyJluJLsiNMBCL+RQxyffUJPxKmUz+L5Jr2hxoPpftLMA6c 5SMK+3uIhh; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet wrote: > >>> Agreed. >>> >>> Cutting to the chase, I'd put the following on my business card: >>> >>> tel: +1-408-495-2456 >>> sip:audet@nortel.com >>> mailto:audet@nortel.com >> Interestingly, that doesn't indicate that you are reachable >> via sip using the numeric address. > > Yes, I did that on purpose. I don't see a point in doing it. > >> A sip caller given the tel might figure that out, but might >> not. If you had user enum, and the caller used it, then all >> is well. But if not, and if the caller just blasts the tel >> uri to his SP, it may figure it out, and may not. >> >> You are going to ask why the caller would use the tel form in >> that case. >> One reason would be because the UI of the device only >> supports numeric input. > > So, a SIP user (or anybody young enough to prefer IM paradigm to phone > paradigm) will use sip:audet@nortel.com. > > The old luddites with a PSTN-looking phone will keep on dialing digits > on their phone. That's where the Tel URI is useful. > > The niche market for sip:+14084952456@nortel.com;user=phone is very > small. Beyond people on this mailing list, I really don't see who would > care. I really believe that practically speaking, sip:+14084952456@nortel.com;user=phone > is meant to be used "on-the wire" as opposed to by users. > > sip:audet@nortel.com ~= http://www.att.com > sip:+14084952456@nortel.com;user=phone ~= http://www.att.com/gen/landing-pages?pid=3308 > > I think we are rat-holing on imaginary issues. Perhaps. The above is a bit esoteric. A more realisic issue is what to put in From, where at the moment you can't put multiple choices. So I have to choose whether to cater to the luddites or the young. (I'm not young, but I don't think I'm *quite* a luddite. Just saddled with a lot of legacy stuff I don't have the option of changing or am too cheap to change. (I *am* cheap.)) At least with P-A-I you can put both a sip and a tel. The alternative being explored on this list of including both in normal sip signaling would solve that. 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 sip-bounces@ietf.org Thu Apr 10 11:13:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1D228C1CB; Thu, 10 Apr 2008 11:13:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0F03A6AC6 for ; Thu, 10 Apr 2008 11:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 FsLZMbTSfEIp for ; Thu, 10 Apr 2008 11:13:30 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 612653A6D8E for ; Thu, 10 Apr 2008 11:13:29 -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 m3AIDfh10289; Thu, 10 Apr 2008 18:13:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Apr 2008 13:13:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF160F504E@zrc2hxm0.corp.nortel.com> In-Reply-To: <47FE56D0.40705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcibNVirfScPJoBPSXmPGUg6EaQU5wAAP1jA References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><18428.60275.209757.845202@taimen.test.fi><47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <136d01c89b2c$b9fc5fd0$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4E5D@zrc2hxm0.corp.nortel.com> <47FE4C30.1080309@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4EBD@zrc2hxm0.corp.nortel.com> <47FE56D! 0.40705@c isco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yeah, I'd say putting sip:+14084952456@nortel.com;user=phone in From (or anything "on-the-wire") is very appropriate. I don't think we are disagreeing actually. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 10, 2008 11:05 > To: Audet, Francois (SC100:3055) > Cc: Dan Wing; sip@ietf.org; Juha Heinanen > Subject: Re: [Sip] E.164 - who owns it > > > > Francois Audet wrote: > > > >>> Agreed. > >>> > >>> Cutting to the chase, I'd put the following on my business card: > >>> > >>> tel: +1-408-495-2456 > >>> sip:audet@nortel.com > >>> mailto:audet@nortel.com > >> Interestingly, that doesn't indicate that you are > reachable via sip > >> using the numeric address. > > > > Yes, I did that on purpose. I don't see a point in doing it. > > > >> A sip caller given the tel might figure that out, but > might not. If > >> you had user enum, and the caller used it, then all is > well. But if > >> not, and if the caller just blasts the tel uri to his SP, it may > >> figure it out, and may not. > >> > >> You are going to ask why the caller would use the tel form in that > >> case. > >> One reason would be because the UI of the device only supports > >> numeric input. > > > > So, a SIP user (or anybody young enough to prefer IM > paradigm to phone > > paradigm) will use sip:audet@nortel.com. > > > > The old luddites with a PSTN-looking phone will keep on > dialing digits > > on their phone. That's where the Tel URI is useful. > > > > The niche market for sip:+14084952456@nortel.com;user=phone is very > > small. Beyond people on this mailing list, I really don't see who > > would care. I really believe that practically speaking, > > sip:+14084952456@nortel.com;user=phone > > is meant to be used "on-the wire" as opposed to by users. > > > > sip:audet@nortel.com ~= http://www.att.com > > sip:+14084952456@nortel.com;user=phone ~= > > http://www.att.com/gen/landing-pages?pid=3308 > > > > I think we are rat-holing on imaginary issues. > > Perhaps. The above is a bit esoteric. A more realisic issue > is what to put in From, where at the moment you can't put > multiple choices. So I have to choose whether to cater to the > luddites or the young. (I'm not young, but I don't think I'm > *quite* a luddite. Just saddled with a lot of legacy stuff I > don't have the option of changing or am too cheap to change. > (I *am* cheap.)) > > At least with P-A-I you can put both a sip and a tel. The > alternative being explored on this list of including both in > normal sip signaling would solve that. > > 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 sip-bounces@ietf.org Thu Apr 10 11:42:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC6F3A6B05; Thu, 10 Apr 2008 11:42:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44B53A6B05 for ; Thu, 10 Apr 2008 11:42:56 -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 RY5347vUIACt for ; Thu, 10 Apr 2008 11:42:55 -0700 (PDT) Received: from ashesmtp01.verizonbusiness.com (ASHESMTP01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 32C093A6AEC for ; Thu, 10 Apr 2008 11:42:55 -0700 (PDT) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007)) with ESMTP id <0JZ400C9XHC3TQ00@firewall.verizonbusiness.com> for sip@ietf.org; Thu, 10 Apr 2008 18:43:15 +0000 (GMT) Received: from dgismtp05.wcomnet.com ([127.0.0.1]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZ40022THC3U1@dgismtp05.mcilink.com> for sip@ietf.org; Thu, 10 Apr 2008 18:43:15 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZ4002FDHC02A@dgismtp05.mcilink.com> for sip@ietf.org; Thu, 10 Apr 2008 18:43:15 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 18:43:12 +0000 Date: Thu, 10 Apr 2008 18:40:58 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <47FE4AF4.4060401@cisco.com> To: Paul Kyzivat , Francois Audet Message-id: <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Sip] E.164 - who owns it Thread-index: AcibLlccjqjrFzP+RL2cgJZNogSe+wACbwGA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> X-OriginalArrivalTime: 10 Apr 2008 18:43:12.0766 (UTC) FILETIME=[BAFDC1E0:01C89B3A] Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, I don't understand a couple of your points below. Can you elaborate? tim > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, April 10, 2008 12:14 PM > To: Francois Audet > Cc: sip@ietf.org; Dan Wing > Subject: Re: [Sip] E.164 - who owns it > > Francois, > > I agree with your point entirely. > > BUT, even if I choose to advertise a sip URI (with user=phone), some of > the UASs I call may well display only the numeric portion as the > callerid. Those people in turn may then attempt to call me back using a > TEL URI, and as a result, may end up going over the PSTN, even if > originating from a sip device. (I don't know how often a PSTN > path will be chosen even if a sip path was possible, but probably more > often than we would wish.) Are you saying that use of tel:+4085551212 as opposed to sip:+4085551212;user=phone makes it more likely that the call will be routed the PSTN? If so, why would that be? > If the devices are half way smart, even if they only show the number > they will keep the entire URI in their call log, so that if I attempt a > callback via the call log it will use the whole URI. But I expect some > devices will be dumber than that. When you say "use the whole URI" do you mean in the R-URI? I'm not sure this would be desirable behavior. If the host part of the R-URI does not identify a domain for which the network serving the calling party is authoritative, then as I understand it the network serving the calling party should simply proxy the INVITE per 3263. But then how does the network serving the calling party provide originating services to its subscriber? As a practical matter I'll note that in some networks with which I am familiar, the value to be used in the host part of the R-URI is dictated by the network. > I don't know that we can do anything about it, except perhaps publish > some best practices drafts. But I expect it may be a problem > for a long > time. A "best practice" promoting the behavior described above, seems problematic. Maybe if there are networks somehow fundamentally unlike that described above (e.g., where there is no concept of originating services), it could be scoped to be applicable to them? I suppose this is a general problem with best practices - few are universally "best". > > Paul > > Francois Audet wrote: > > I'm still not sure I get it. > > > > If I present a Tel URI, and somebody uses it to reach me, > and it just happens > > that we are both using SIP as our default "Telephony" > client, then sure, you > > absolutely will be able to do whatever you want (IM, HD, etc.). > > > > The point is that if you choose to advertise a Tel URI > INSTEAD of a SIP URI, don't be > > surprised if you have people reaching you with PSTN-capabilies only. > > > > Conversely, if you choose to advertize a SIP URI ONLY, then > you may be missing out > > entirely on people calling from PSTN. > > > > - At least, that's the theory... > > > >> -----Original Message----- > >> From: Dan Wing [mailto:dwing@cisco.com] > >> Sent: Wednesday, April 09, 2008 21:20 > >> To: Audet, Francois (SC100:3055) > >> Cc: sip@ietf.org; 'Paul Kyzivat'; 'Juha Heinanen' > >> Subject: RE: [Sip] E.164 - who owns it > >> > >> > >> > >>> -----Original Message----- > >>> From: Francois Audet [mailto:audet@nortel.com] > >>> Sent: Wednesday, April 09, 2008 8:04 PM > >>> To: Dan Wing > >>> Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen > >>> Subject: RE: [Sip] E.164 - who owns it > >>> > >>> Well, you can still do video over PSTN with H.320. I still > >> view this > >>> as "telephony". > >> Sorry -- please pick something you cannot do over the PSTN. > >> Instant Messaging, presence, high-quality video (HDTV), whatever. > >> > >>> Not sure I understand the question. > >> Let me reword my previous email into a question: > >> > >> If you have a non-SIP telephony application that trunks > >> towards the PSTN, and it is configured to process tel URIs, > >> and it is asked to initiate a call that exceeds the > >> capabilities of the PSTN (instant messaging, presence, > >> HDTV-quality video, whatever you prefer) -- would it route > >> the call towards a "SIP trunk" in order to gain the ability > >> to set up that call, abort the call, or just ignore it all > >> and trunk towards the PSTN? > >> > >> An additional question (statement, actually) is: We can't > >> influence how that non-SIP telephony application provides for > >> its own identity and authentication of tel URIs. > >> > >> (This is getting me to lean more towards my email-identity > >> straw-man. With it, we can step out of this festering, > >> smelly pile of trying to get E.164 working well with SIP and > >> move to email-style SIP URIs. The IETF is capable of > >> building an end-to-end identity/authentication solution > >> around email-style SIP URIs; we have one (RFC4474) that works > >> if we prohibit SBCs and B2BUAs from modifying SDP). > >> > >> -d > >> > >> > > _______________________________________________ > > 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 sip-bounces@ietf.org Thu Apr 10 12:16:00 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8293C28C1CB; Thu, 10 Apr 2008 12:16:00 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85AA03A6AB4 for ; Thu, 10 Apr 2008 12:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[AWL=0.813, 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 Q755tkek-aYQ for ; Thu, 10 Apr 2008 12:15:56 -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 28C5B28C516 for ; Thu, 10 Apr 2008 12:15:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,637,1199682000"; d="scan'208";a="4656354" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2008 15:15:55 -0400 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 m3AJFtmI020831; Thu, 10 Apr 2008 15:15:55 -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 m3AJFtn8000370; Thu, 10 Apr 2008 19:15:55 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); Thu, 10 Apr 2008 15:15:55 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 15:15:54 -0400 Message-ID: <47FE6787.1080001@cisco.com> Date: Thu, 10 Apr 2008 15:16:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Dwight, Timothy M (Tim)" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> X-OriginalArrivalTime: 10 Apr 2008 19:15:54.0954 (UTC) FILETIME=[4C8BE2A0:01C89B3F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8243; t=1207854955; x=1208718955; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20=22Dwight,=20Timothy=20M=20(Tim)=22=20; bh=uOyEFGJlwMJI5u4Ugs03u51M+423BtiUaR717GUeRDY=; b=iy07Fo8m+sWzJ+R5R8dhJE7SWDSqHC4kAxSwGSpIhAgVsB2oD/JSYIbGdP 7BplDXC9xUZw7sP0vE/bpvpI7n7O2t2JhEgYBZTYAMU00tB1MIUp3OLua0Nt AXJE8Mf6Ep; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dwight, Timothy M (Tim) wrote: > Paul, > > I don't understand a couple of your points below. Can you elaborate? > > tim > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, April 10, 2008 12:14 PM >> To: Francois Audet >> Cc: sip@ietf.org; Dan Wing >> Subject: Re: [Sip] E.164 - who owns it >> >> Francois, >> >> I agree with your point entirely. >> >> BUT, even if I choose to advertise a sip URI (with user=phone), some > of >> the UASs I call may well display only the numeric portion as the >> callerid. Those people in turn may then attempt to call me back using > a >> TEL URI, and as a result, may end up going over the PSTN, even if >> originating from a sip device. (I don't know how often a PSTN >> path will be chosen even if a sip path was possible, but probably more > >> often than we would wish.) > > Are you saying that use of tel:+4085551212 as opposed to > sip:+4085551212;user=phone makes it more likely that the call will be > routed the PSTN? If so, why would that be? IMO if I give you sip:+4085551212@sp.com, with or without user=phone, then a call back to that URI MUST be via sip, and the 3263 rules say that it MUST be routed to domain sp.com before making any decision about how to reach something associated with the user part. If I give you tel:+4085551212, then you have total freedom regarding what protocol to use to reach me, and the path taken. You may just use an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip service, or whatever. >> If the devices are half way smart, even if they only show the number >> they will keep the entire URI in their call log, so that if I attempt > a >> callback via the call log it will use the whole URI. But I expect some > >> devices will be dumber than that. > > When you say "use the whole URI" do you mean in the R-URI? I was thinking of a device that keeps a log of *incoming* calls, so the From-URI would be appropriate. > I'm not sure > this would be desirable behavior. If the host part of the R-URI does > not identify a domain for which the network serving the calling party is > authoritative, then as I understand it the network serving the calling > party should simply proxy the INVITE per 3263. But then how does the > network serving the calling party provide originating services to its > subscriber? > > As a practical matter I'll note that in some networks with which I am > familiar, the value to be used in the host part of the R-URI is dictated > by the network. If you are originating a call from a dial string, not a URI, then I guess you can formulate the R-URI any way you want. But if the calling party is supplying a URI (e.g. one it has saved from a prior received call) then it should be used as-is. If you want some server on the originating end to do something for the outbound call, then you should put a Route header in the request identifying the server. As a practical matter, suppose you receive a call from sip:george.bush@whitehouse.gov. If you want to return that call, you have little choice but to use that as the R-URI. You can't very well send it to sip:george.bush@your-sp.com and expect the right thing to happen. So, if you received a call from sip:+12125551234@foo.com;user=phone, then IMO the caller had an expectation that callbacks would be delivered there, not to sip:+12125551234@your-sp.com. But in fact that is exactly what a lot of systems are doing. >> I don't know that we can do anything about it, except perhaps publish >> some best practices drafts. But I expect it may be a problem >> for a long >> time. > > A "best practice" promoting the behavior described above, seems > problematic. Maybe if there are networks somehow fundamentally unlike > that described above (e.g., where there is no concept of originating > services), it could be scoped to be applicable to them? I suppose this > is a general problem with best practices - few are universally "best". I think as a community we are far from agreeing on what "best practices" are. Hopefully it will eventually be sorted out. But it seems that there is a fair chance that we will never all agree on what best practices are in this regard, and will continue to be partitioned into a bunch of warring feudal communities, with tax collectors on every road. >> Paul >> >> Francois Audet wrote: >>> I'm still not sure I get it. >>> >>> If I present a Tel URI, and somebody uses it to reach me, >> and it just happens >>> that we are both using SIP as our default "Telephony" >> client, then sure, you >>> absolutely will be able to do whatever you want (IM, HD, etc.). >>> >>> The point is that if you choose to advertise a Tel URI >> INSTEAD of a SIP URI, don't be >>> surprised if you have people reaching you with PSTN-capabilies only. >>> >>> Conversely, if you choose to advertize a SIP URI ONLY, then >> you may be missing out >>> entirely on people calling from PSTN. >>> >>> - At least, that's the theory... >>> >>>> -----Original Message----- >>>> From: Dan Wing [mailto:dwing@cisco.com] >>>> Sent: Wednesday, April 09, 2008 21:20 >>>> To: Audet, Francois (SC100:3055) >>>> Cc: sip@ietf.org; 'Paul Kyzivat'; 'Juha Heinanen' >>>> Subject: RE: [Sip] E.164 - who owns it >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Francois Audet [mailto:audet@nortel.com] >>>>> Sent: Wednesday, April 09, 2008 8:04 PM >>>>> To: Dan Wing >>>>> Cc: sip@ietf.org; Paul Kyzivat; Juha Heinanen >>>>> Subject: RE: [Sip] E.164 - who owns it >>>>> >>>>> Well, you can still do video over PSTN with H.320. I still >>>> view this >>>>> as "telephony". >>>> Sorry -- please pick something you cannot do over the PSTN. >>>> Instant Messaging, presence, high-quality video (HDTV), whatever. >>>> >>>>> Not sure I understand the question. >>>> Let me reword my previous email into a question: >>>> >>>> If you have a non-SIP telephony application that trunks >>>> towards the PSTN, and it is configured to process tel URIs, >>>> and it is asked to initiate a call that exceeds the >>>> capabilities of the PSTN (instant messaging, presence, >>>> HDTV-quality video, whatever you prefer) -- would it route >>>> the call towards a "SIP trunk" in order to gain the ability >>>> to set up that call, abort the call, or just ignore it all >>>> and trunk towards the PSTN? >>>> >>>> An additional question (statement, actually) is: We can't >>>> influence how that non-SIP telephony application provides for >>>> its own identity and authentication of tel URIs. >>>> >>>> (This is getting me to lean more towards my email-identity >>>> straw-man. With it, we can step out of this festering, >>>> smelly pile of trying to get E.164 working well with SIP and >>>> move to email-style SIP URIs. The IETF is capable of >>>> building an end-to-end identity/authentication solution >>>> around email-style SIP URIs; we have one (RFC4474) that works >>>> if we prohibit SBCs and B2BUAs from modifying SDP). >>>> >>>> -d >>>> >>>> >>> _______________________________________________ >>> 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 > _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 12:17:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D271B3A6B05; Thu, 10 Apr 2008 12:17:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB273A6AEC for ; Thu, 10 Apr 2008 12:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=1.095, 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 UQTjXiQEyaYS for ; Thu, 10 Apr 2008 12:17:51 -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 BC11D3A6BA6 for ; Thu, 10 Apr 2008 12:17:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,637,1199682000"; d="scan'208";a="4656630" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2008 15:18:10 -0400 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 m3AJI9xa022070; Thu, 10 Apr 2008 15:18:09 -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 m3AJI903005568; Thu, 10 Apr 2008 19:18:09 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); Thu, 10 Apr 2008 15:18:09 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 15:18:09 -0400 Message-ID: <47FE680D.1080506@cisco.com> Date: Thu, 10 Apr 2008 15:18:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dale.Worley@comcast.net References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <091b01c89a73$123ea0f0$c5f0200a@cisco.com> <200804101751.m3AHpbfD005178@dragon.ariadne.com> In-Reply-To: <200804101751.m3AHpbfD005178@dragon.ariadne.com> X-OriginalArrivalTime: 10 Apr 2008 19:18:09.0359 (UTC) FILETIME=[9CA875F0:01C89B3F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2858; t=1207855090; x=1208719090; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=YwWjdYtvvmW+8XKwmSyTUADZoDB13JY1aan9eomZDpE=; b=UJnt984jJ2pYAvFKpY9LB1JNzeFXRbk8laZdCylXYOHr+GoNs9WB6pjx/q OJzWYTl1Yma/YdWSfw+7qsPDzkqqHzziwpCrA1K3NmG9UqsNV0cKvw23E1Y5 FFam7eQ14n; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If I understand what Dan is proposing, the result is that you get a call if the callee believes the caller owns the number, regardless of whether anyone else in the world does. Paul Dale.Worley@comcast.net wrote: > From: "Dan Wing" > > > Sorry, I don't understand. You said "sending a SIP request towards > > the E.164", by which I understand an Enum lookup. Did you mean > > "sending a SIP request towards a SIP URI which purposts to represent > > an E.164"? > > draft-wing-sip-e164-rrc-01.txt says to turn the SIP URI into a TEL URI, > and then generate a Return Routability Check (RRC) towards that TEL URI: > > "1. Strip the domain name of the From: of the incoming INVITE. This > results in a TEL URI. For example, > "sip:+14085551234@example.com;user=phone" is rewritten to > "tel:+14085551212". > > 2. Rewrite the TEL URI to a SIP URI, following the Verifier's > default routing rules. For example, if outgoing calls are sent > to the service provider example.net, then "tel:+14085551212" is > rewritten to "sip:+14085551212@example.net;user=phone". > > 3. Generate a random nonce. > > 4. Using the SIP URI constructed in step (2), construct a SIP > SUBSCRIBE message with Request-URI and To headers that use that > SIP URI, and an "Expires" header of 0. The SUBSCRIBE contains > the random nonce in its body as Content-Type application/ > return-routability-nonce. > > 5. Send the SUBSCRIBE message. This will cause the calling party to > send a NOTIFY." > > Interesting... Because the verification generated by this algorithm > is not quite what I expected from how it was described, and it is both > narrower and probably more useful than what I expected. The > verification is that "Within the Verifier's context, the routing rules > that are in effect send tel:+1234 to the given domain." This actually > doesn't say anything about ownership of E.164 numbers (other than that > E.164 numbers are the space of URIs), but it says a tremendous amount > about how requests are routed from the Verifier's context: "If I call > the given number, will I reach the given domain?" That's not useful > for validating an incoming caller based on an asserted E.164 origin > number (unless one's local E.164 routing is known to be trustable), > but it's really useful for knowing if I can call the caller back using > the asserted E.164 number. > > 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 sip-bounces@ietf.org Thu Apr 10 13:13:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A04628C107; Thu, 10 Apr 2008 13:13:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD4728C224 for ; Thu, 10 Apr 2008 13:13:18 -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.151, 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 b-3B8XFY9WBK for ; Thu, 10 Apr 2008 13:13:16 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 37F0C3A6B05 for ; Thu, 10 Apr 2008 13:13:16 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JZ400C9ALIN5Q@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Apr 2008 21:13:35 +0100 (BST) Date: Thu, 10 Apr 2008 21:13:34 +0100 From: "Elwell, John" In-reply-to: <091b01c89a73$123ea0f0$c5f0200a@cisco.com> To: Dan Wing , Dale.Worley@comcast.net, sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciaWlcnm8fafYUuQLSp54TYycPz4AAFwDiAACijzCA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <091b01c89a73$123ea0f0$c5f0200a@cisco.com> Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dan, > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: 09 April 2008 19:54 > To: Dale.Worley@comcast.net; sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > > From: "Dan Wing" > > > If those URIs included ";user=phone", there is a transitive > > > relationship between the SIP URI and the TEL URI. Without > > > ";user=phone", I agree that no meaning is supposed to > > be applied > > > to the user-part (the part to the left of the "@"). > > > > > > True. In that case, we have SIP URIs which are > > essentially aliases > > > for tel URIs. But in that case, any signing should be of the > > > fundamental tel URI, which then obviates the problem > > with an SBC that > > > translates one alias-URI into another. > > > > But the only mechanism we have to sign, RFC4474, does > not provide a > > way to sign a tel URI. > > > > OK, so we have several different URIs, sip:1234@domain;user=phone, > > which are understood to be equivalent to tel:1234 and also to each > > other, and because of that, SBCs feel free to translate > each of these > > into each other, but the signing mechanism generates > signatures which > > depend on which of these particular URIs is present. So you have to > > change either your signing mechanism to recognize the > equivalence, or > > your SBCs to stop exploiting the equivalence. > > Yes, I agree. > > > > In SIP, you accomplish something similar to the TCP > > SYN cookie by > > > sending a SIP request towards the E.164, asking them > > to sign the > > > request and return it to you. Details are in > > > draft-wing-sip-e164-rrc-01.txt and comments are welcome. > > > > > > It seems like this mechanism is at most as certain as the E.164 > > > mapping that it uses for the "reverse direction". I > > gather from the > > > Enum people there is some trouble with that. > > > > I don't understand your statement; > draft-wing-sip-e164-rrc-01.txt > > does not use ENUM, rather it uses the same routing that the SIP > > network (of proxies, B2BUAs, and SBCs) uses. > > > > Sorry, I don't understand. You said "sending a SIP request towards > > the E.164", by which I understand an Enum lookup. Did you mean > > "sending a SIP request towards a SIP URI which purposts to represent > > an E.164"? > > draft-wing-sip-e164-rrc-01.txt says to turn the SIP URI into > a TEL URI, > and then generate a Return Routability Check (RRC) towards > that TEL URI: > > "1. Strip the domain name of the From: of the incoming > INVITE. This > results in a TEL URI. For example, > "sip:+14085551234@example.com;user=phone" is rewritten to > "tel:+14085551212". > > 2. Rewrite the TEL URI to a SIP URI, following the Verifier's > default routing rules. For example, if outgoing calls are sent > to the service provider example.net, then "tel:+14085551212" is > rewritten to "sip:+14085551212@example.net;user=phone". > > 3. Generate a random nonce. > > 4. Using the SIP URI constructed in step (2), construct a SIP > SUBSCRIBE message with Request-URI and To headers that use that > SIP URI, and an "Expires" header of 0. The SUBSCRIBE contains > the random nonce in its body as Content-Type application/ > return-routability-nonce. > > 5. Send the SUBSCRIBE message. This will cause the > calling party to > send a NOTIFY." > > > Once we start thinking about that, it opens the can of > worms again, in > > that validating sip:1234@xxx;user=phone is a different > operation than > > validating sip:1234@yyy;user=phone, so we can validate only one of > > those two purportedly equivalent SIP URIs. This seems to > lead back to > > the position that assuming those two URIs are equivalent for any > > purpose is a Bad Idea, and therefore we should change the SBCs > > behavior. > > (I assume the omission of "+" in those two URIs was an accident.) > > If I receive two Invites on one day from > > (a) sip:+1234@yyy;user=phone > and > (b) sip:+1234@xxx;user=phone > > I expect that they were both originated by someone who really > does 'own' that > number. > > If I turn the SIP URL into a TEL URI (tel:+1234), and route > it using my > default routing rules, it could be routed somewhere else > (sip:+1234@zzz;user=phone), and then to somewhere else again > (sip:+1234@abcd;user=phone). But as long as it eventually > arrives at the same > place as (a) or (b) originated from -- then I am happy that > my own outbound > SIP routing thinks that (a) or (b) really do "own" the E.164 > number "+1234" -- > because that is what my SIP routing says is true. [JRE] What about the following case? Enterprise.com uses two service providers, sp1.net for incoming calls and some outgoing calls and sp2.net for other outgoing calls. It sends an INVITE request via sp2.net, which signs the E.164-based From URI. The SUBSCRIBE request is routed via sp1.net to enterprise.com, which will be unable to sign the NOTIFY request. However, if the outgoing call had gone via sp1.net there would be no problem. I am not sure whether this behaviour is a good thing or a bad thing. Of course, if enterprise.com signs and the signature survives end-to-end there is no problem and the called user gets a more useful caller ID. 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 sip-bounces@ietf.org Thu Apr 10 13:14:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D82E28C501; Thu, 10 Apr 2008 13:14:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A626A28C259 for ; Thu, 10 Apr 2008 13:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, 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 8kYsRY3uBjEP for ; Thu, 10 Apr 2008 13:14:33 -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 8104228C515 for ; Thu, 10 Apr 2008 13:14:32 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 10 Apr 2008 13:14:54 -0700 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 m3AKEsO3014789; Thu, 10 Apr 2008 13:14:54 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3AKErt0015180; Thu, 10 Apr 2008 20:14:53 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <091b01c89a73$123ea0f0$c5f0200a@cisco.com><200804101751.m3AHpbfD005178@dragon.ariadne.com> <47FE680D.1080506@cisco.com> Date: Thu, 10 Apr 2008 13:14:53 -0700 Message-ID: <00e301c89b47$89e86030$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47FE680D.1080506@cisco.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcibP6yJIHj/Mn4UTSyaWw/etz0dhwAB64hg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3835; t=1207858494; x=1208722494; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=NeR8HT6KDQd57RwQU+cX6AiBajrFjPuA3hQ0d6Fs3UM=; b=LlJh5yrXxJN1WAyUzUOY2VTirWcU/4y8hGzYdv2eusTtvtHo/v0nu2w5Ov 1NRlrX6QymGe1WHR05weNxQoAlacCghNxsNGaMFvpWAGr7yPK3R+CfW8DmOB ePAuBp7HI1; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, April 10, 2008 12:19 PM > To: Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: Re: [Sip] E.164 - who owns it > > If I understand what Dan is proposing, the result is that you > get a call > if the callee believes the caller owns the number, regardless > of whether anyone else in the world does. Right. And we know our own SIP routing is set up correctly, right? Otherwise it's broken and doesn't work for the intended purpose -- namely, sending SIP messages to their intended destination. -d > Paul > > Dale.Worley@comcast.net wrote: > > From: "Dan Wing" > > > > > Sorry, I don't understand. You said "sending a SIP > request towards > > > the E.164", by which I understand an Enum lookup. Did you mean > > > "sending a SIP request towards a SIP URI which > purposts to represent > > > an E.164"? > > > > draft-wing-sip-e164-rrc-01.txt says to turn the SIP URI > into a TEL URI, > > and then generate a Return Routability Check (RRC) > towards that TEL URI: > > > > "1. Strip the domain name of the From: of the > incoming INVITE. This > > results in a TEL URI. For example, > > "sip:+14085551234@example.com;user=phone" is rewritten to > > "tel:+14085551212". > > > > 2. Rewrite the TEL URI to a SIP URI, following the Verifier's > > default routing rules. For example, if outgoing > calls are sent > > to the service provider example.net, then > "tel:+14085551212" is > > rewritten to "sip:+14085551212@example.net;user=phone". > > > > 3. Generate a random nonce. > > > > 4. Using the SIP URI constructed in step (2), construct a SIP > > SUBSCRIBE message with Request-URI and To headers > that use that > > SIP URI, and an "Expires" header of 0. The SUBSCRIBE contains > > the random nonce in its body as Content-Type application/ > > return-routability-nonce. > > > > 5. Send the SUBSCRIBE message. This will cause the > calling party to > > send a NOTIFY." > > > > Interesting... Because the verification generated by this algorithm > > is not quite what I expected from how it was described, and > it is both > > narrower and probably more useful than what I expected. The > > verification is that "Within the Verifier's context, the > routing rules > > that are in effect send tel:+1234 to the given domain." > This actually > > doesn't say anything about ownership of E.164 numbers > (other than that > > E.164 numbers are the space of URIs), but it says a > tremendous amount > > about how requests are routed from the Verifier's context: > "If I call > > the given number, will I reach the given domain?" That's not useful > > for validating an incoming caller based on an asserted E.164 origin > > number (unless one's local E.164 routing is known to be trustable), > > but it's really useful for knowing if I can call the caller > back using > > the asserted E.164 number. > > > > 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 _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 13:21:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76D028C217; Thu, 10 Apr 2008 13:21:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C4928C217 for ; Thu, 10 Apr 2008 13:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=0.838, 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 7gJD-611xAxk for ; Thu, 10 Apr 2008 13:21:45 -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 B103628C0DC for ; Thu, 10 Apr 2008 13:21:45 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Apr 2008 13:22:07 -0700 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 m3AKM7Bu030584; Thu, 10 Apr 2008 13:22:07 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3AKM6lP021509; Thu, 10 Apr 2008 20:22:06 GMT From: "Dan Wing" To: "'Elwell, John'" , , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <091b01c89a73$123ea0f0$c5f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 10 Apr 2008 13:22:06 -0700 Message-ID: <00fe01c89b48$8c22ca60$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaWlcnm8fafYUuQLSp54TYycPz4AAFwDiAACijzCAADP2AgA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1553; t=1207858927; x=1208722927; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=1n93jMM5tHRCoKqGC3d8vzuWRkCAThI2eUP3FwrBI6g=; b=bUmX+UjOgalr4PcazkW4Dl/umIsxt46/UPcE1sK8cNwiWBgv55kixJ6OMn 58Gouh8IgkjgsZ4+9sTr0rWI+7497Tx3IT0sLsKh4uaTvNGNwrM4VitajDp4 27r5TDeHzd; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ... > [JRE] What about the following case? Enterprise.com uses two service > providers, sp1.net for incoming calls and some outgoing calls and > sp2.net for other outgoing calls. It sends an INVITE request via > sp2.net, which signs the E.164-based From URI. The SUBSCRIBE > request is > routed via sp1.net to enterprise.com, which will be unable to sign the > NOTIFY request. However, if the outgoing call had gone via > sp1.net there > would be no problem. I am not sure whether this behaviour is a good > thing or a bad thing. Here is a quick ASCII diagram of what you are describing: sp1.net-<<- / / Enterprise.com -< \ \sp2.net->>- > Of course, if enterprise.com signs and the signature survives > end-to-end there is no problem and the called user gets a more > useful caller ID. Exactly. If enterprise.com is UNABLE to create a signature, but rather its signatures are destroyed and over-written by sp1.net or sp2.net, then yes, the best that can be done is trust sp1.net and sp2.net to have Done The Right Thing. That is not too valuable to me. If that is the only value we want or need, we already have RFC4474 that provides exactly this same characteristic. draft-wing-sip-e164-rrc is an attempt to provide something stronger, so that the message arrives at Enterprise.com and they -- not their service provider(s) -- create the signature (as you said). -d _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 13:30:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB7828C0F2; Thu, 10 Apr 2008 13:30:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6DD28C522 for ; Thu, 10 Apr 2008 13:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, WHOIS_PRIVPROT=1.501] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of-C0zxA59S4 for ; Thu, 10 Apr 2008 13:30:56 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BE6203A6D01 for ; Thu, 10 Apr 2008 13:30:09 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JZ400C8ULWVS4@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Apr 2008 21:22:07 +0100 (BST) Date: Thu, 10 Apr 2008 21:22:07 +0100 From: "Elwell, John" In-reply-to: <200804101801.m3AI13DW005880@dragon.ariadne.com> To: Dale.Worley@comcast.net, sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09AC5BC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] E.164-based SIP URIs and TEL URIs as aliases Thread-Index: AcibNQjX3FmVRxDaQ5eLGmHBCmXtvgAE0UlQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> <200804101801.m3AI13DW005880@dragon.ariadne.com> Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale, > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dale.Worley@comcast.net > Sent: 10 April 2008 19:01 > To: sip@ietf.org > Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases > > > From: "Elwell, John" > > [JRE] But what about other parameters on the right hand side. For > example, is > tel:+123456789 > an alias for: > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > > I don't think so. > > And is: > sip:+123456789@provider.net;user=phone; > an alias for: > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > > I don't think so > > And is: > sip:+123456789@provider.net;user=phone;gr=abd76gd6 > an alias for: > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > Possibly, assuming by routing the first one to provider.net it > eventually gets changed to the latter and routed accordingly. > > Personally, I agree with you that these URIs are all "different". But > if we consider them to be different, any signing mechanism must > consider them to be different, and any transport mechanism must avoid > changing one of them into another. > > Previously in this discussion, people have argued that SBCs are not > behaving incorrectly when they change one of these URIs into another, > and that thus any signing mechanism must tolerate such a substitution. [JRE] I don't see how we can tolerate the dropping of the gr parameter, which would happen in a couple of cases above if the URIs concerned were treated as aliases. 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 sip-bounces@ietf.org Thu Apr 10 13:31:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5AC628C230; Thu, 10 Apr 2008 13:31:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24EBC3A6CB2 for ; Thu, 10 Apr 2008 13:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=-1.478, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, WHOIS_PRIVPROT=1.501] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ce8zxmz9Euf for ; Thu, 10 Apr 2008 13:31:02 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BE2FB28C4F9 for ; Thu, 10 Apr 2008 13:31:01 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JZ400D2RMC9DE@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Apr 2008 21:31:21 +0100 (BST) Date: Thu, 10 Apr 2008 21:31:21 +0100 From: "Elwell, John" In-reply-to: <47FE283F.7060209@cisco.com> To: Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09AC5BF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] E.164-based SIP URIs and TEL URIs as aliases Thread-Index: AcibG57auUVETr1eQtWdmPhnNWJSFwALQHyQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> <47FE283F.7060209@cisco.com> Cc: sip@ietf.org Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 10 April 2008 15:46 > To: Elwell, John > Cc: Dale.Worley@comcast.net; sip@ietf.org > Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases > > > > Elwell, John wrote: > > > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >> Behalf Of Dale.Worley@comcast.net > >> Sent: 09 April 2008 03:31 > >> To: sip@ietf.org > >> Subject: Re: [Sip] E.164 - who owns it > >> > >> > >> From: "Dan Wing" > >> > >> If those URIs included ";user=phone", there is a transitive > >> relationship between the SIP URI and the TEL URI. Without > >> ";user=phone", I agree that no meaning is supposed to > be applied > >> to the user-part (the part to the left of the "@"). > >> > >> True. In that case, we have SIP URIs which are essentially aliases > >> for tel URIs. But in that case, any signing should be of the > >> fundamental tel URI, which then obviates the problem with > an SBC that > >> translates one alias-URI into another. > > [JRE] But what about other parameters on the right hand side. For > > example, is > > tel:+123456789 > > an alias for: > > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > > > > I don't think so. > > > > And is: > > sip:+123456789@provider.net;user=phone; > > an alias for: > > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > > > > I don't think so > > > > And is: > > sip:+123456789@provider.net;user=phone;gr=abd76gd6 > > an alias for: > > sip:+123456789@example.com;user=phone;gr=abd76gd6 ? > > Possibly, assuming by routing the first one to provider.net it > > eventually gets changed to the latter and routed accordingly. > > > > You might ask whether these are valid examples. I believe they are, > > because the GRUU draft says just add a gr parameter to the > AoR, and I > > believe the user=phone parameter is part of the AoR in this case. > > IMO it is a little fuzzy whether URI parameters are actually > part of an > AOR. When adding or looking up a URI in a location service, > it is first > canonicalized by removing all URI parameters, including the "user" > parameter. As a result, both > > sip:+123456789@provider.net;user=phone > sip:+123456789@provider.net > > will route to the same place. [JRE] Really? I always thought the purpose of the user=phone parameter was to distinguish telephone number URIs from other URIs that happen to look like phone numbers. With the assertion you make above, the user=phone parameter would serve no purpose. > Its not entirely clear to me > whether the > gruu is to be constructed with the canonicalized URI or the original > one. But there seems to be nothing to prevent you from > registering once > using user=phone, and another time omitting it, or using user=ip. And > you would get the same location service entry in both cases. [JRE] That wasn't really the point I was getting at. My concern is that if user=phone can be part of a GRUU, and if SBCs see this in a Request-URI and think "oh, it's a telephone number", they might convert it to a tel URI, or change the domain part in the SIP URI and somehow contrive to drop the gr parameter. In such cases the GRUU will be corrupted and will not work. > > > > Of course, you wouldn't have a GRUU in a From header field, > so this is > > perhaps not relevant to the RFC 4474 discussion (hence the change of > > thread name), but it is germane to the issue of how a > Request URI can > > change as it is routed through intermediaries. > > I think the bottom line is that we can't just toss out the > term "alias" > as something that is well defined. I think that A can be an > alias for B > for one purpose, but not be an alias for B for some other purpose. > > In this discussion, I think two From-URIs might sometimes be > considered > aliases of one another if they result in the same callerid display to > the recipient, or if calls to both reach the same destination. [JRE] That might be so, but in the Request-URI it seems to be much more of a concern. Can anyone shed any light on what SBCs might do if a Request URI contains both user=phone and gr=xxxx parameters? Hadriel? 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 sip-bounces@ietf.org Thu Apr 10 15:24:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5F23A6C60; Thu, 10 Apr 2008 15:24:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02ACF3A6C60 for ; Thu, 10 Apr 2008 15:24:37 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=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 imOae-eSzG4P for ; Thu, 10 Apr 2008 15:24:35 -0700 (PDT) Received: from omzesmtp02a.verizonbusiness.com (omzesmtp02a.verizonbusiness.com [199.249.25.198]) by core3.amsl.com (Postfix) with ESMTP id A474B3A68D4 for ; Thu, 10 Apr 2008 15:24:35 -0700 (PDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007)) with ESMTP id <0JZ400BD4RLK7W00@firewall.verizonbusiness.com> for sip@ietf.org; Thu, 10 Apr 2008 22:24:56 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([127.0.0.1]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZ400GR2RLKZ8@dgismtp04.mcilink.com> for sip@ietf.org; Thu, 10 Apr 2008 22:24:56 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZ400H9IRLI50@dgismtp04.mcilink.com> for sip@ietf.org; Thu, 10 Apr 2008 22:24:56 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 22:24:55 +0000 Date: Thu, 10 Apr 2008 22:24:27 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <47FE6787.1080001@cisco.com> To: Paul Kyzivat Message-id: <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Sip] E.164 - who owns it Thread-index: AcibP2jNQVS5cuMZSuiMfQ+PO3rWCwAE9DyQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> X-OriginalArrivalTime: 10 Apr 2008 22:24:55.0573 (UTC) FILETIME=[B4150450:01C89B59] Cc: sip@ietf.org, Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, > > > > Are you saying that use of tel:+4085551212 as opposed to > > sip:+4085551212;user=phone makes it more likely that the call will be > > routed to the PSTN? If so, why would that be? > > IMO if I give you sip:+4085551212@sp.com, with or without user=phone, > then a call back to that URI MUST be via sip, and the 3263 rules say > that it MUST be routed to domain sp.com before making any > decision about how to reach something associated with the user part. OK, I'm fine with that. > If I give you tel:+4085551212, then you have total freedom regarding > what protocol to use to reach me, and the path taken. You may just use > an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip > service, or whatever. I see your point. In the networks with which I am familiar there is not such cleverness, though. They only know SIP and PSTN, and only use PSTN as a fallback. So in my limited world, the type of URI (sip vs. tel) does not impact the liklihood that the call will be transported via SIP. > >> If the devices are half way smart, even if they only show the number > >> they will keep the entire URI in their call log, so that if I attempt a > >> callback via the call log it will use the whole URI. But I expect some > >> devices will be dumber than that. > > > > When you say "use the whole URI" do you mean in the R-URI? > > I was thinking of a device that keeps a log of *incoming* > calls, so the From-URI would be appropriate. Yes, I understand that. I was asking if you meant that the device would put the value it extracted from the From-URI into the Request-URI of the callback. As opposed for example to putting it in the To-URI and maybe constructing a R-URI with the same user part ("dialed digits") but a different host part (identifying the network serving the calling party). I guess such a thing would be legal. > > I'm not sure > > this would be desirable behavior. If the host part of the R-URI does > > not identify a domain for which the network serving the calling party is > > authoritative, then as I understand it the network serving the calling > > party should simply proxy the INVITE per 3263. But then how does the > > network serving the calling party provide originating services to its > > subscriber? > > > > As a practical matter I'll note that in some networks with which I am > > familiar, the value to be used in the host part of the R-URI is dictated > > by the network. > > If you are originating a call from a dial string, not a URI, then I > guess you can formulate the R-URI any way you want. But if the calling > party is supplying a URI (e.g. one it has saved from a prior received > call) then it should be used as-is. Well as I noted, such a call will fail in some networks with which I am familiar. In some cases it may succeed because the network ignores or its dreaded SBCs overwrite, the host part of the R-URI. I doubt you'll find many public networks willing to allow their proxies to be used but their call servers bypassed. > If you want some server on the originating end to do something for the > outbound call, then you should put a Route header in the request > identifying the server. I see how that could work, yes. Except for the issue that many currently deployed devices do not support Route headers. > > As a practical matter, suppose you receive a call from > sip:george.bush@whitehouse.gov. If you want to return that call, you > have little choice but to use that as the R-URI. You can't very well > send it to sip:george.bush@your-sp.com and expect the right > thing to happen. Of course. But I believe the issue here is specific to URIs that have telephone numbers as the user part. I think the issue we're wrestling with is whether the semantics of the relationship between user and host part of such URIs is the same as that of "email style" URIs. I believe that it is not. In an email style URI (one whose user part is not a telephone number) the domain in the host part provides service to the user identified in the user part. In a URI whose user part is a telephone number, the domain in the host part may or may not (i.e., cannot be assumed to) provide service to the user identified in the user part. By identifying "foo.com" in the host part of a URI whose user part contains a telephone number, I am giving the network authoritative for foo.com the right to examine for purposes of routing, the user part of the URI. I am not implying that that network provides service to the user identified by the URI's user part. It might, but if it did that would be coincidental. > So, if you received a call from sip:+12125551234@foo.com;user=phone, > then IMO the caller had an expectation that callbacks would be delivered > there, not to sip:+12125551234@your-sp.com. But in fact that is exactly > what a lot of systems are doing. This has nothing to do with where the call is delivered. If we're talking about global public telephone numbers, then +12125551234 uniquely identifies an endpoint. In the absence of erroroneous configuration both calls will complete to that endpoint. The only practical difference is how they get there. > > >> I don't know that we can do anything about it, except perhaps publish > >> some best practices drafts. But I expect it may be a problem for a long > >> time. > > > > A "best practice" promoting the behavior described above, seems > > problematic. Maybe if there are networks somehow fundamentally unlike > > that described above (e.g., where there is no concept of originating > > services), it could be scoped to be applicable to them? I suppose this > > is a general problem with best practices - few are universally "best". > > I think as a community we are far from agreeing on what "best > practices" > are. Hopefully it will eventually be sorted out. But it seems that > there is a fair chance that we will never all agree on what best > practices are in this regard, and will continue to be > partitioned into a > bunch of warring feudal communities, with tax collectors on > every road. Frankly I'm missing why this is such a big deal. If a network changes sip:+12125551234@foo.com;user=phone to sip:+12125551234@your-sp.com, but the session anyway terminates to the device at which +12125551234 is registered, so what? Tim _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 15:59:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF1D3A6CF6; Thu, 10 Apr 2008 15:59:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35973A6C60 for ; Thu, 10 Apr 2008 15:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.878 X-Spam-Level: X-Spam-Status: No, score=-3.878 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, WHOIS_PRIVPROT=1.501] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM9XQMvUd7t3 for ; Thu, 10 Apr 2008 15:59:13 -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 3074C3A6CF6 for ; Thu, 10 Apr 2008 15:59:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,637,1199682000"; d="scan'208";a="4664846" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2008 18:59:33 -0400 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 m3AMxXYK011481; Thu, 10 Apr 2008 18:59:33 -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 m3AMxXoS016218; Thu, 10 Apr 2008 22:59:33 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); Thu, 10 Apr 2008 18:59:33 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 18:59:33 -0400 Message-ID: <47FE9BF1.6020004@cisco.com> Date: Thu, 10 Apr 2008 19:00:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> <47FE283F.7060209@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC5BF@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09AC5BF@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 10 Apr 2008 22:59:33.0442 (UTC) FILETIME=[8A96AA20:01C89B5E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7471; t=1207868373; x=1208732373; 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:=20E.164-based=20SIP=20URIs=20and=20TEL=20URIs=20- =20the=20purpose=20for=20user=3Dphone |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=nJ+4fNCVWQqFGpD8MoCPNCuMf5Ozw6P8d49dAk7bdRo=; b=gKFzcvmc97ebqPyNzTwORJ0U7JSKjeRCT12Lrn6tb/oMnLxgz2y7S6NyxK MYiUS8tzKeF7tgfXbdWzkORkwZ4bBA0tKvbCFh+3uudD7ZloXwc8SiOAxxe4 /6Ot557mKw; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: [Sip] E.164-based SIP URIs and TEL URIs - the purpose for user=phone X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: [snip] >>> And is: >>> sip:+123456789@provider.net;user=phone;gr=abd76gd6 >>> an alias for: >>> sip:+123456789@example.com;user=phone;gr=abd76gd6 ? >>> Possibly, assuming by routing the first one to provider.net it >>> eventually gets changed to the latter and routed accordingly. >>> >>> You might ask whether these are valid examples. I believe they are, >>> because the GRUU draft says just add a gr parameter to the >> AoR, and I >>> believe the user=phone parameter is part of the AoR in this case. >> IMO it is a little fuzzy whether URI parameters are actually >> part of an >> AOR. When adding or looking up a URI in a location service, >> it is first >> canonicalized by removing all URI parameters, including the "user" >> parameter. As a result, both >> >> sip:+123456789@provider.net;user=phone >> sip:+123456789@provider.net >> >> will route to the same place. > [JRE] Really? I always thought the purpose of the user=phone parameter > was to distinguish telephone number URIs from other URIs that happen to > look like phone numbers. With the assertion you make above, the > user=phone parameter would serve no purpose. At one point I thought that too - that the user= parameter defined alternative namespaces for the user part of the uri, within the same domain. But then the relevant portions of 3261 were pointed out to me, which contradicted that idea: 3261 Section 10.3: 5. The registrar extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form. To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings. 3261 Section 16.5 ... When accessing the location service constructed by a registrar, the Request-URI MUST first be canonicalized as described in Section 10.3 before being used as an index. The output of these mechanisms is used to construct the target set. The end result is that the user= parameter really has no significance. Section 19.1.1 says: The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it. Based on the above, its not that a given domain can have the same string represent a telephone number *and* something else. It can only do one or the other for any given string. The parameter is only an informative qualifier regarding which it is. But I don't know who it is supposed to be informing. The servers running within the domain presumably already know this. Section 16.5 (Re proxies) says: If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6). There are many circumstances in which a proxy might receive a request for a domain it is not responsible for. A firewall proxy handling outgoing calls (the way HTTP proxies handle outgoing requests) is an example of where this is likely to occur. Section 16.6 then gives the steps for request forwarding. In this case these don't change the R-URI since the target is the same as the old R-URI. The only way the parameters or the user portion of the R-URI can enter in here is in adding extra headers to the request, notably including Route headers. So the fact that this includes what seems to be a phone number could result in a Route header whose value depends on that phone number. But that just results in visiting added intermediate stops, not what the final destination is. So, the only remaining way for this parameter to influence anything is in a UAS. Section 8.2.2.1 says: However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response. If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. Apparently the UAS only must be *willing* to process the URI - there is no requirement that it *be responsible* for the domain of the R-URI. IMO that is a mistake, but it seems to be the normative justification for SBCs. So, a UAS that is willing may receive a request for any old domain. And then I guess it is free to use the user= parameter to decide that the user part of the URI is in tel format, and it then may decide to generate a *different* request to some other destination that it thinks is responsible for the phone number, and link the two requests. So apparently that is the value of the user parameter. Paul >> Its not entirely clear to me >> whether the >> gruu is to be constructed with the canonicalized URI or the original >> one. But there seems to be nothing to prevent you from >> registering once >> using user=phone, and another time omitting it, or using user=ip. And >> you would get the same location service entry in both cases. > [JRE] That wasn't really the point I was getting at. My concern is that > if user=phone can be part of a GRUU, and if SBCs see this in a > Request-URI and think "oh, it's a telephone number", they might convert > it to a tel URI, or change the domain part in the SIP URI and somehow > contrive to drop the gr parameter. In such cases the GRUU will be > corrupted and will not work. > > >> >>> Of course, you wouldn't have a GRUU in a From header field, >> so this is >>> perhaps not relevant to the RFC 4474 discussion (hence the change of >>> thread name), but it is germane to the issue of how a >> Request URI can >>> change as it is routed through intermediaries. >> I think the bottom line is that we can't just toss out the >> term "alias" >> as something that is well defined. I think that A can be an >> alias for B >> for one purpose, but not be an alias for B for some other purpose. >> >> In this discussion, I think two From-URIs might sometimes be >> considered >> aliases of one another if they result in the same callerid display to >> the recipient, or if calls to both reach the same destination. > [JRE] That might be so, but in the Request-URI it seems to be much more > of a concern. Can anyone shed any light on what SBCs might do if a > Request URI contains both user=phone and gr=xxxx parameters? Hadriel? > > 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 sip-bounces@ietf.org Thu Apr 10 16:33:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408AF3A6A61; Thu, 10 Apr 2008 16:33:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10213A6A61 for ; Thu, 10 Apr 2008 16:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[AWL=0.783, 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 n4wUSLXcsgEx for ; Thu, 10 Apr 2008 16:33:12 -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 CC9A63A6951 for ; Thu, 10 Apr 2008 16:33:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,638,1199682000"; d="scan'208";a="4667013" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2008 19:33:33 -0400 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 m3ANXX1Z026440; Thu, 10 Apr 2008 19:33:33 -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 m3ANXX1n025733; Thu, 10 Apr 2008 23:33:33 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); Thu, 10 Apr 2008 19:33:32 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 19:33:32 -0400 Message-ID: <47FEA3E9.7070404@cisco.com> Date: Thu, 10 Apr 2008 19:34:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Dwight, Timothy M (Tim)" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> X-OriginalArrivalTime: 10 Apr 2008 23:33:32.0431 (UTC) FILETIME=[49EBB1F0:01C89B63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11361; t=1207870413; x=1208734413; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20=22Dwight,=20Timothy=20M=20(Tim)=22=20; bh=LBTgZiHiajTD8o0bl7GZLDR1Z6lqBhVdxSYGU3vmcMA=; b=aKFGLnIKNXieRVRmTUPRAfcuDXm1AScLUvLBFtVnEl38VQgYqkUBfL1LbK zd1vyg03gWh/VHNAAZdWf4Z7UsDiO3R8+u86Q2uBG28TGj2MwNus9SiIjYjj AWA2ZFt9NA; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dwight, Timothy M (Tim) wrote: > Paul, > >>> Are you saying that use of tel:+4085551212 as opposed to >>> sip:+4085551212;user=phone makes it more likely that the call will > be >>> routed to the PSTN? If so, why would that be? >> IMO if I give you sip:+4085551212@sp.com, with or without user=phone, >> then a call back to that URI MUST be via sip, and the 3263 rules say >> that it MUST be routed to domain sp.com before making any >> decision about how to reach something associated with the user part. > > OK, I'm fine with that. > > >> If I give you tel:+4085551212, then you have total freedom regarding >> what protocol to use to reach me, and the path taken. You may just use > >> an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip >> service, or whatever. > > I see your point. In the networks with which I am familiar there is not > such cleverness, though. They only know SIP and PSTN, and only use PSTN > as a fallback. So in my limited world, the type of URI (sip vs. tel) > does not impact the liklihood that the call will be transported via SIP. > > >>>> If the devices are half way smart, even if they only show the > number >>>> they will keep the entire URI in their call log, so that if I > attempt a >>>> callback via the call log it will use the whole URI. But I expect > some >>>> devices will be dumber than that. >>> When you say "use the whole URI" do you mean in the R-URI? >> I was thinking of a device that keeps a log of *incoming* >> calls, so the From-URI would be appropriate. > > Yes, I understand that. I was asking if you meant that the device would > put the value it extracted from the From-URI into the Request-URI of the > callback. As opposed for example to putting it in the To-URI and maybe > constructing a R-URI with the same user part ("dialed digits") but a > different host part (identifying the network serving the calling party). > I guess such a thing would be legal. Section 8.1.1.1 of 3261 applies here: The initial Request-URI of the message SHOULD be set to the value of the URI in the To field. One notable exception is the REGISTER method; behavior for setting the Request-URI of REGISTER is given in Section 10. It may also be undesirable for privacy reasons or convenience to set these fields to the same value (especially if the originating UA expects that the Request-URI will be changed during transit). In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI. The only case in which R-URI won't equal the To-URI is if there is a preexisting route set and the first route in that set is a strict-router. In that case the To-URI will end up as the last value of the Route header. Loose routing has been defined for five years or so now. It generally ought to be supported. So in general the R-URI should equal the To-URI. In my example they would both equal what was in the From-URI of the incoming call that is now being returned. >>> I'm not sure >>> this would be desirable behavior. If the host part of the R-URI > does >>> not identify a domain for which the network serving the calling > party is >>> authoritative, then as I understand it the network serving the > calling >>> party should simply proxy the INVITE per 3263. But then how does > the >>> network serving the calling party provide originating services to > its >>> subscriber? >>> >>> As a practical matter I'll note that in some networks with which I > am >>> familiar, the value to be used in the host part of the R-URI is > dictated >>> by the network. >> If you are originating a call from a dial string, not a URI, then I >> guess you can formulate the R-URI any way you want. But if the calling >> party is supplying a URI (e.g. one it has saved from a prior received >> call) then it should be used as-is. > > Well as I noted, such a call will fail in some networks with which I am > familiar. In some cases it may succeed because the network ignores or > its dreaded SBCs overwrite, the host part of the R-URI. I doubt you'll > find many public networks willing to allow their proxies to be used but > their call servers bypassed. Their proxies don't have to be bypassed. Those proxies just become part of a preexisting route set known to the UAC and populated into the Route header. >> If you want some server on the originating end to do something for the >> outbound call, then you should put a Route header in the request >> identifying the server. > > I see how that could work, yes. Except for the issue that many > currently deployed devices do not support Route headers. Its about time they got with the program. >> As a practical matter, suppose you receive a call from >> sip:george.bush@whitehouse.gov. If you want to return that call, you >> have little choice but to use that as the R-URI. You can't very well >> send it to sip:george.bush@your-sp.com and expect the right >> thing to happen. > > Of course. But I believe the issue here is specific to URIs that have > telephone numbers as the user part. > > I think the issue we're wrestling with is whether the semantics of the > relationship between user and host part of such URIs is the same as that > of "email style" URIs. I believe that it is not. It should be the same until you get to the target domain. But I just posted another message on a closely related point that goes into this more. You might want to reply to that. And I don't see how treating them differently helps you. Won't your SP still want to provide originating services when I'm calling sip:george.bush@whitehouse.gov? How will it do so? > In an email style URI (one whose user part is not a telephone number) > the domain in the host part provides service to the user identified in > the user part. In a URI whose user part is a telephone number, the > domain in the host part may or may not (i.e., cannot be assumed to) > provide service to the user identified in the user part. I think we can/should assume that it is *claiming* responsibility, at least to the extent that return calls to this URI should pass through it, perhaps after passing through other servers. It may decide to relay the call on elsewhere, but initially it is to be assumed to be the responsible domain. As I note in my other post, proxies MUST treat it that way. > By identifying > "foo.com" in the host part of a URI whose user part contains a telephone > number, I am giving the network authoritative for foo.com the right to > examine for purposes of routing, the user part of the URI. I am not > implying that that network provides service to the user identified by > the URI's user part. It might, but if it did that would be > coincidental. That is really true for any URI. When the request reaches a server authoritative for the domain of the URI it is some sense has reached its destination - the place the stated in the URI. It is up to that server to decide if it really wants to respond, or to forward it on to some *other* *more* responsible server. There is no law that says how a server responsible for a domain is to interpret the user part. Even if the URI looks like a phone number and there is a user=phone param, it is not *obligated* to deliver the request to some place that the *caller* thinks owns that phone number. It can make its own decision. Now this may all still work, swapping domain names while leaving the user part alone. But only if it is done amongst a bunch of "consenting adult" servers that have a consistent policy about the handling of the user part. >> So, if you received a call from sip:+12125551234@foo.com;user=phone, >> then IMO the caller had an expectation that callbacks would be > delivered >> there, not to sip:+12125551234@your-sp.com. But in fact that is > exactly >> what a lot of systems are doing. > > This has nothing to do with where the call is delivered. If we're > talking about global public telephone numbers, then +12125551234 > uniquely identifies an endpoint. In the absence of erroroneous > configuration both calls will complete to that endpoint. The only > practical difference is how they get there. *You* may think that +12125551234 uniquely identifies the endpoint. But that doesn't mean that foo.com agrees with you. foo.com minted the URI with the expectation that requests would be delivered to it. You may sent it to your-sp.com *first*, but ultimately you ought to be getting it to the foo.com server with sip:+12125551234@foo.com as the R-URI. A key difference in this regard is that if you are obligated to get it to sip:+12125551234@foo.com then you won't be able to route it via the PSTN. That may be exactly what foo.com intended. >>>> I don't know that we can do anything about it, except perhaps > publish >>>> some best practices drafts. But I expect it may be a problem for a > long >>>> time. >>> A "best practice" promoting the behavior described above, seems >>> problematic. Maybe if there are networks somehow fundamentally > unlike >>> that described above (e.g., where there is no concept of originating >>> services), it could be scoped to be applicable to them? I suppose > this >>> is a general problem with best practices - few are universally > "best". >> I think as a community we are far from agreeing on what "best >> practices" >> are. Hopefully it will eventually be sorted out. But it seems that >> there is a fair chance that we will never all agree on what best >> practices are in this regard, and will continue to be >> partitioned into a >> bunch of warring feudal communities, with tax collectors on >> every road. > > Frankly I'm missing why this is such a big deal. If a network changes > sip:+12125551234@foo.com;user=phone to sip:+12125551234@your-sp.com, but > the session anyway terminates to the device at which +12125551234 is > registered, so what? Getting an e2e sip connection can be a big deal. It means I can potentially use a variety of media, rather than just voice, and I can use various call control primitives that wouldn't otherwise be available. What you want can easily be achieved if the caller starts out with a tel uri in the r-uri field. But then it has the latitude to decide which it wants to do. 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 sip-bounces@ietf.org Thu Apr 10 18:01:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2E73A69DC; Thu, 10 Apr 2008 18:01:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877ED3A69C0 for ; Thu, 10 Apr 2008 18:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_45=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 tJVFQzukmlaM for ; Thu, 10 Apr 2008 18:01:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AAF0F3A69DC for ; Thu, 10 Apr 2008 18:01:37 -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.240.5; Thu, 10 Apr 2008 21:01:31 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 10 Apr 2008 21:01:31 -0400 From: Hadriel Kaplan To: "Elwell, John" , Paul Kyzivat Date: Thu, 10 Apr 2008 21:01:33 -0400 Thread-Topic: [Sip] E.164-based SIP URIs and TEL URIs as aliases Thread-Index: AcibG57auUVETr1eQtWdmPhnNWJSFwALQHyQAAhF/uA= Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> <47FE283F.7060209@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC5BF@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D09AC5BF@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > > [JRE] That might be so, but in the Request-URI it seems to be much more > of a concern. Can anyone shed any light on what SBCs might do if a > Request URI contains both user=phone and gr=xxxx parameters? Hadriel? That's unknowable. There are over a dozen SBC vendors, according to the analysts, possibly as many as 30 depending on your definition, though many of them are only seen in specific markets or regions. Even if you could ask all of them, they wouldn't be able to answer, because it's basically highly configurable. (and my guess is it is on other SIP devices too) I know we've had a problem with it in one case where we weren't trying to prevent it from working, but in talking with some people in IETF-Philly I'm still not sure if it was specific to our config in that case, or just a problem gruu would have even with legacy true-3261 networks in general. (my guess is it's specific to SBCs, or really any b2bua, because most b2bua's replace the Contact URI, and gruu is subsequently broken... and there are a LOT more b2bua's than just SBCs) In general though, Paul wasn't far off on the bogey-man - the whole idea of an SBC is to give total control to the owner of the SBC, imo. (I just happen to think that's ok) For example my company's SBC doesn't modify the req-uri unless it's set to, which of course most everyone does the instant they install it. In my personal opinion this type of stuff can be changed by vendors or their customers through configs, and will be if it provides value, so long as it doesn't conflict with their other goals. That's why I wrote the draft-kaplan-sip-uris-change draft. All providers want calls to work, imho. -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 sip-bounces@ietf.org Thu Apr 10 19:08:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DAF3A6C4D; Thu, 10 Apr 2008 19:08:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4351A3A6C4D for ; Thu, 10 Apr 2008 19:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, J_CHICKENPOX_45=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 2UNGpVULisCy for ; Thu, 10 Apr 2008 19:08:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2BD113A6940 for ; Thu, 10 Apr 2008 19:08:48 -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.240.5; Thu, 10 Apr 2008 22:08:41 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 10 Apr 2008 22:08:41 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Dwight, Timothy M (Tim)" Date: Thu, 10 Apr 2008 22:08:45 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcibP1WhwuIYGZN8SQ6QZo8o7y2N9wAMNsqA Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> In-Reply-To: <47FE6787.1080001@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > IMO if I give you sip:+4085551212@sp.com, with or without user=phone, > then a call back to that URI MUST be via sip, and the 3263 rules say > that it MUST be routed to domain sp.com before making any decision about > how to reach something associated with the user part. Interesting. You said "if I give you... then a call *back* to that MUST be via sip". In what way do you mean "if I give you..."? Like in the From-URI of an outgoing request? Or out-of-band (e.g., on a business card)? Or both? > If you are originating a call from a dial string, not a URI, then I > guess you can formulate the R-URI any way you want. But if the calling > party is supplying a URI (e.g. one it has saved from a prior received > call) then it should be used as-is. So how are we to tell which one it was, if you can formulate a dial string any which way? (I'm confused) > If you want some server on the originating end to do something for the > outbound call, then you should put a Route header in the request > identifying the server. And I wish that would work, but in many cases it won't. For some of those cases I think it's because of bad equipment, and hopefully not a permanent problem. But the From-URI you end up getting has a host-part that is of the previous or local domain, instead of the real originating domain, and thus the Req/To-URI you end up generating later will likewise be the local or next-domain. If we could get wider vendor support for Tel-URIs (and Route headers), this problem will go away eventually... I hope. -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 sip-bounces@ietf.org Thu Apr 10 19:39:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6B53A6A11; Thu, 10 Apr 2008 19:39:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FE83A6A11 for ; Thu, 10 Apr 2008 19:39:47 -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 ccTNVi7jTm2T for ; Thu, 10 Apr 2008 19:39:46 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 038D83A683F for ; Thu, 10 Apr 2008 19:39:45 -0700 (PDT) Received: from [172.16.99.204] (account dyork [172.16.99.204] verified) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 29926878; Fri, 11 Apr 2008 02:40:06 +0000 In-Reply-To: <0ec601c89aa7$9cf46f20$c5f0200a@cisco.com> References: <20080405011409.30D205081A@romeo.rtfm.com> <0ec601c89aa7$9cf46f20$c5f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Dan York Date: Thu, 10 Apr 2008 22:40:04 -0400 To: Dan Wing X-Mailer: Apple Mail (2.753) Cc: sip@ietf.org, draft-ietf-sip-media-security-requirements@tools.ietf.org Subject: Re: [Sip] Review of draft-ietf-sip-media-security-requirements-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500679072==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1500679072== Content-Type: multipart/alternative; boundary=Apple-Mail-30--206346027 --Apple-Mail-30--206346027 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 9, 2008, at 9:10 PM, Dan Wing wrote: Dan, > >> S 4.3. >> The entire section on shared key conferencing doesn't lead to any >> requirements as far as I can tell. Does it make sense to remove >> it from this document? > > Right. It seems useful to leave it in, as mentioned at the beginning > of the section: > > The consensus on the RTPSEC mailing list was to concentrate on > unicast, point-to-point sessions. Thus, there are no requirements > related to shared key conferencing. This section is retained for > informational purposes. > > if others agree it should be removed, I can remove it. > DY> I agree that it is useful to leave the information in there, primarily to prevent people reading the document and saying "But what about shared key conferencing?". However, it does seem somewhat strange to have it there in the Call Scenarios section when there are no requirements for that particular call scenario. DY> What if you were to move it into an Appendix - perhaps into the existing Appendix B where you have already indicated that shared key conferencing is out-of-scope (this section would then elaborate on the point of why it is difficult), or perhaps into a new Appendix. My 2 cents, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free --Apple-Mail-30--206346027 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Apr 9, 2008, at 9:10 PM, Dan Wing = wrote:Dan,


S 4.3.
The entire section on shared key conferencing = doesn't lead to any
requirements as far as I = can tell. Does it make sense to remove
it from = this document?

Right.=A0 It seems useful to leave it = in, as mentioned at the beginning
of the = section:

=A0=A0 = The consensus on the RTPSEC mailing list was to concentrate = on
=A0=A0 = unicast, point-to-point sessions.=A0 Thus, there are no = requirements
=A0=A0 related to shared key = conferencing.=A0 This = section is retained for
=A0=A0 informational = purposes.

if others agree it should be removed, I can remove = it.

DY> What if you were to move it into = an Appendix - perhaps into the existing Appendix B where you have = already indicated that shared key conferencing is out-of-scope (this = section would then elaborate on the point of why it is difficult), or = perhaps into a new Appendix.

My 2 = cents,
Dan

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Build voice applications based on open = standards.





= --Apple-Mail-30--206346027-- --===============1500679072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1500679072==-- From sip-bounces@ietf.org Thu Apr 10 19:44:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12FE33A6D89; Thu, 10 Apr 2008 19:44:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578783A6CE8 for ; Thu, 10 Apr 2008 19:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 Zaw0xGskCgLo for ; Thu, 10 Apr 2008 19:44:22 -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 19BC33A6D89 for ; Thu, 10 Apr 2008 19:44:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,638,1199682000"; d="scan'208";a="4681185" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2008 22:44:43 -0400 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 m3B2ihs7032159; Thu, 10 Apr 2008 22:44:43 -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 m3B2ihFE016399; Fri, 11 Apr 2008 02:44:43 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); Thu, 10 Apr 2008 22:44:43 -0400 Received: from [10.82.216.222] ([10.82.216.222]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 22:44:43 -0400 Message-ID: <47FED0B5.2090906@cisco.com> Date: Thu, 10 Apr 2008 22:45:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> In-Reply-To: X-OriginalArrivalTime: 11 Apr 2008 02:44:43.0089 (UTC) FILETIME=[FEF73410:01C89B7D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3980; t=1207881883; x=1208745883; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=VXkVxEYQf4EycQYzWYJ3fUDs2qKqW87O3ZQAJSigZ4c=; b=JGT84/nkVquhktO2BZPWTgynSGwqjhn98dobLp2L4xZ/Riiz8ojNFir85x I6x4dWAX2z/5O9G4NMePR5/7Gaoi6M30BuBWcZrNR0ehE5uN/lw5TdO3Sl/T /V/naE4fx/; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> >> IMO if I give you sip:+4085551212@sp.com, with or without user=phone, >> then a call back to that URI MUST be via sip, and the 3263 rules say >> that it MUST be routed to domain sp.com before making any decision about >> how to reach something associated with the user part. > > Interesting. You said "if I give you... then a call *back* to that MUST be via sip". In what way do you mean "if I give you..."? Like in the From-URI of an outgoing request? Or out-of-band (e.g., on a business card)? Or both? Sorry - I wasn't clear. In this case what I had in mind (by referring to a "call back") was that I gave it to you in a From-URI. That's just one use case. A similar one would be if I gave it to you in a vcard and you called me (not *back* in this case) using the URI from that. >> If you are originating a call from a dial string, not a URI, then I >> guess you can formulate the R-URI any way you want. But if the calling >> party is supplying a URI (e.g. one it has saved from a prior received >> call) then it should be used as-is. > > So how are we to tell which one it was, if you can formulate a dial string any which way? (I'm confused) What I meant was: if you are a device with a URI that receives digits and uses them to construct a URI, rather than receiving a URI, then you can create the URI any way you want. We don't have a lot of rules about it. For instance, you could just take the digits, slap "sip:" on the front, and "@domain;user=dialstring" on the back, and it would be very explicit. But of course almost nobody does that. Or you could do the above but leave the user=dialstring off, on the agreement that it will be understood as a dialstring. Or you could use some dial plan info local to the UAC to translate the dial string into an E.164 number, and then put that into a sip: or tel: URI. How the UA decides if it is getting a dial string or a URI is up to it, and is strongly a function of its UI. In many cases this will be quite obvious. (E.g. If all it has is a number pad.) If the device is capable of full keyboard input, then it may always expect full URIs, or it may take either and distinguish based on the syntax of the text entered. >> If you want some server on the originating end to do something for the >> outbound call, then you should put a Route header in the request >> identifying the server. > > And I wish that would work, but in many cases it won't. AFAIK we are in the business of determining the valid ways of doing things. If implementations choose to do otherwise all we can do is keep encouraging. > For some of those cases I think it's because of bad equipment, and hopefully not a permanent problem. But the From-URI you end up getting has a host-part that is of the previous or local domain, instead of the real originating domain, and thus the Req/To-URI you end up generating later will likewise be the local or next-domain. If we could get wider vendor support for Tel-URIs (and Route headers), this problem will go away eventually... I hope. The problem with trying to make up for the inadequacies of the neighbors is - how do you know which ones do it right and which do it wrong? I guess you SBC guys can keep getting the business to try to solve that problem. But it really means a bunch of configuration about the idiosyncrasies of all the peers. That only works when there are a limited number of them. Paul > -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 > _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 10 20:17:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77FA3A6ABD; Thu, 10 Apr 2008 20:17:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25F73A6ABD for ; Thu, 10 Apr 2008 20:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCX5F-Tk+V5W for ; Thu, 10 Apr 2008 20:17:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EBC133A6A11 for ; Thu, 10 Apr 2008 20:17: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.240.5; Thu, 10 Apr 2008 23:17:42 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 10 Apr 2008 23:17:43 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Thu, 10 Apr 2008 23:17:45 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acibfe9QCbZPFBh6QKGT0QO2vpDTBAAAFZmw Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <47FED0B5.2090906@cisco.com> In-Reply-To: <47FED0B5.2090906@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > In this case what I had in mind (by referring to a "call back") was that > I gave it to you in a From-URI. Ah, ok. The only issue then is that when a UAC generates a request, it's not really clear how it should know when it wants things back *only* via SIP, or when it doesn't care. For example, if you make a phone call, why would your UAC use a From-URI of TEL? It would (typically) be your registered AoR, and sip:me@domain. And yet I doubt very much that most phones, or their users, really care whether people calling them *back* go through the PSTN or not to reach their SIP phone. I bet most of them have no idea they're even *using* a SIP phone. > >> If you want some server on the originating end to do something for the > >> outbound call, then you should put a Route header in the request > >> identifying the server. > > > > And I wish that would work, but in many cases it won't. > > AFAIK we are in the business of determining the valid ways of doing > things. If implementations choose to do otherwise all we can do is keep > encouraging. Absolutely. But pragmatism has its place too. (I'm not saying this is one of those times though) > The problem with trying to make up for the inadequacies of the neighbors > is - how do you know which ones do it right and which do it wrong? With some things it's part of the peering agreement (e.g., a "profile"), with some things it's based on device-specific config or vendor-profiles. But for some things it's a lowest-common-denominator: change it to what works with every device. > I guess you SBC guys can keep getting the business to try to solve that > problem. But it really means a bunch of configuration about the > idiosyncrasies of all the peers. That only works when there are a > limited number of them. Yup, and why I'm trying to get things to stop needing to be "fixed". It's not core to an SBC's value prop, and not a good long-term strategy for such. -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 sip-bounces@ietf.org Thu Apr 10 21:06:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A528428C117; Thu, 10 Apr 2008 21:06:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58803A6D51 for ; Thu, 10 Apr 2008 21:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_45=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 gpUlmdtZVRu2 for ; Thu, 10 Apr 2008 21:06:55 -0700 (PDT) Received: from omzesmtp01a.verizonbusiness.com (omzesmtp01a.verizonbusiness.com [199.249.25.195]) by core3.amsl.com (Postfix) with ESMTP id 74DA13A6C48 for ; Thu, 10 Apr 2008 21:06:55 -0700 (PDT) Received: from pmismtp06.wcomnet.com ([166.37.158.166]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007)) with ESMTP id <0JZ50069I7G48E00@firewall.verizonbusiness.com> for sip@ietf.org; Fri, 11 Apr 2008 04:07:17 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([127.0.0.1]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZ5001L67G4PL@pmismtp06.mcilink.com> for sip@ietf.org; Fri, 11 Apr 2008 04:07:16 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZ50019D7G4OA@pmismtp06.mcilink.com> for sip@ietf.org; Fri, 11 Apr 2008 04:07:16 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 04:07:16 +0000 Date: Fri, 11 Apr 2008 04:06:36 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <47FEA3E9.7070404@cisco.com> To: Paul Kyzivat Message-id: <092B2658AAB56A4D80836399A4C47031042A1E55@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Sip] E.164 - who owns it Thread-index: AcibY05VGlA4SlkqShiW5RkKlCyKogAHZQgA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> <47FEA3E9.7070404@cisco.com> X-OriginalArrivalTime: 11 Apr 2008 04:07:16.0183 (UTC) FILETIME=[873D5E70:01C89B89] Cc: sip@ietf.org, Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks, Paul. This has been a useful exchange. I agree with you that we need to be able to provide originating services to the calling party without forcing the R-URI to identify a domain for which the calling party's network is authoritative. And as you note this is mandatory to support "email style" R-URIs. Inclusion of a Route header seems like a good solution, albeit one dependent on supplier implementation. IMS offers another. On reflection I'm not sure the rule that "if I give you sip:+4085551212@sp.com, with or without user=phone, then a call back to that URI MUST be via sip" is advisable. What if there's no VoIP peering agreement between my network and the network authoritative for 'sp.com'? Which would you prefer, that the call fail or that it be routed via the PSTN? Given that there's no practical way to know each caller's preference, networks will have to implement some "reasonable" policy. To me it seems reasonable to expect that someone who identifies himself with a telephone number would not be opposed to receiving calls via the PSTN, if that's the only way they can be delivered. I'm not sure what you mean by "foo.com minted the URI with the expectation that requests would be delivered to it". I'm not sure what "minting" means, but hopefully it doesn't involve foo.com generating calls whose From-URI imbeds a telephone number for which foo.com is not responsible. "Responsibility" is a bit vague, but basically I mean that either the number is assigned to foo.com by the numbering plan authority, the number is ported to foo.com, or use of the number is authorized to foo.com by its legitimate owner (e.g., through a wholesale arrangement). The issue is that there be a "chain of custody" leading to the entity providing service to the number. Implementation of lawful intercept, for example, relies on this. tim > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 10, 2008 6:34 PM > To: Dwight, Timothy M (Tim) > Cc: sip@ietf.org; Francois Audet; Dan Wing > Subject: Re: [Sip] E.164 - who owns it > > > > Dwight, Timothy M (Tim) wrote: > > Paul, > > > >>> Are you saying that use of tel:+4085551212 as opposed to > >>> sip:+4085551212;user=phone makes it more likely that the call will > > be > >>> routed to the PSTN? If so, why would that be? > >> IMO if I give you sip:+4085551212@sp.com, with or without > user=phone, > >> then a call back to that URI MUST be via sip, and the 3263 > rules say > >> that it MUST be routed to domain sp.com before making any > >> decision about how to reach something associated with the > user part. > > > > OK, I'm fine with that. > > > > > >> If I give you tel:+4085551212, then you have total freedom > regarding > >> what protocol to use to reach me, and the path taken. You > may just use > > > >> an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip > >> service, or whatever. > > > > I see your point. In the networks with which I am familiar > there is not > > such cleverness, though. They only know SIP and PSTN, and > only use PSTN > > as a fallback. So in my limited world, the type of URI > (sip vs. tel) > > does not impact the liklihood that the call will be > transported via SIP. > > > > > >>>> If the devices are half way smart, even if they only show the > > number > >>>> they will keep the entire URI in their call log, so that if I > > attempt a > >>>> callback via the call log it will use the whole URI. But I expect > > some > >>>> devices will be dumber than that. > >>> When you say "use the whole URI" do you mean in the R-URI? > >> I was thinking of a device that keeps a log of *incoming* > >> calls, so the From-URI would be appropriate. > > > > Yes, I understand that. I was asking if you meant that the > device would > > put the value it extracted from the From-URI into the > Request-URI of the > > callback. As opposed for example to putting it in the > To-URI and maybe > > constructing a R-URI with the same user part ("dialed digits") but a > > different host part (identifying the network serving the > calling party). > > I guess such a thing would be legal. > > Section 8.1.1.1 of 3261 applies here: > > The initial Request-URI of the message SHOULD be set to > the value of > the URI in the To field. One notable exception is the REGISTER > method; behavior for setting the Request-URI of REGISTER > is given in > Section 10. It may also be undesirable for privacy reasons or > convenience to set these fields to the same value > (especially if the > originating UA expects that the Request-URI will be changed during > transit). > > In some special circumstances, the presence of a > pre-existing route > set can affect the Request-URI of the message. A > pre-existing route > set is an ordered set of URIs that identify a chain of servers, to > which a UAC will send outgoing requests that are outside > of a dialog. > Commonly, they are configured on the UA by a user or > service provider > manually, or through some other non-SIP mechanism. When > a provider > wishes to configure a UA with an outbound proxy, it is RECOMMENDED > that this be done by providing it with a pre-existing > route set with > a single URI, that of the outbound proxy. > > When a pre-existing route set is present, the procedures for > populating the Request-URI and Route header field > detailed in Section > 12.2.1.1 MUST be followed (even though there is no > dialog), using the > desired Request-URI as the remote target URI. > > The only case in which R-URI won't equal the To-URI is if there is a > preexisting route set and the first route in that set is a > strict-router. In that case the To-URI will end up as the > last value of > the Route header. > > Loose routing has been defined for five years or so now. It generally > ought to be supported. So in general the R-URI should equal > the To-URI. > In my example they would both equal what was in the From-URI of the > incoming call that is now being returned. > > >>> I'm not sure > >>> this would be desirable behavior. If the host part of the R-URI > > does > >>> not identify a domain for which the network serving the calling > > party is > >>> authoritative, then as I understand it the network serving the > > calling > >>> party should simply proxy the INVITE per 3263. But then how does > > the > >>> network serving the calling party provide originating services to > > its > >>> subscriber? > >>> > >>> As a practical matter I'll note that in some networks with which I > > am > >>> familiar, the value to be used in the host part of the R-URI is > > dictated > >>> by the network. > >> If you are originating a call from a dial string, not a > URI, then I > >> guess you can formulate the R-URI any way you want. But if > the calling > >> party is supplying a URI (e.g. one it has saved from a > prior received > >> call) then it should be used as-is. > > > > Well as I noted, such a call will fail in some networks > with which I am > > familiar. In some cases it may succeed because the network > ignores or > > its dreaded SBCs overwrite, the host part of the R-URI. I > doubt you'll > > find many public networks willing to allow their proxies to > be used but > > their call servers bypassed. > > Their proxies don't have to be bypassed. Those proxies just > become part > of a preexisting route set known to the UAC and populated > into the Route > header. > > >> If you want some server on the originating end to do > something for the > >> outbound call, then you should put a Route header in the request > >> identifying the server. > > > > I see how that could work, yes. Except for the issue that many > > currently deployed devices do not support Route headers. > > Its about time they got with the program. > > >> As a practical matter, suppose you receive a call from > >> sip:george.bush@whitehouse.gov. If you want to return that > call, you > >> have little choice but to use that as the R-URI. You can't > very well > >> send it to sip:george.bush@your-sp.com and expect the right > >> thing to happen. > > > > Of course. But I believe the issue here is specific to > URIs that have > > telephone numbers as the user part. > > > > I think the issue we're wrestling with is whether the > semantics of the > > relationship between user and host part of such URIs is the > same as that > > of "email style" URIs. I believe that it is not. > > It should be the same until you get to the target domain. > > But I just posted another message on a closely related point > that goes > into this more. You might want to reply to that. > > And I don't see how treating them differently helps you. > Won't your SP > still want to provide originating services when I'm calling > sip:george.bush@whitehouse.gov? How will it do so? > > > In an email style URI (one whose user part is not a > telephone number) > > the domain in the host part provides service to the user > identified in > > the user part. In a URI whose user part is a telephone number, the > > domain in the host part may or may not (i.e., cannot be assumed to) > > provide service to the user identified in the user part. > > I think we can/should assume that it is *claiming* responsibility, at > least to the extent that return calls to this URI should pass through > it, perhaps after passing through other servers. It may > decide to relay > the call on elsewhere, but initially it is to be assumed to be the > responsible domain. As I note in my other post, proxies MUST treat it > that way. > > > By identifying > > "foo.com" in the host part of a URI whose user part > contains a telephone > > number, I am giving the network authoritative for foo.com > the right to > > examine for purposes of routing, the user part of the URI. I am not > > implying that that network provides service to the user > identified by > > the URI's user part. It might, but if it did that would be > > coincidental. > > That is really true for any URI. When the request reaches a server > authoritative for the domain of the URI it is some sense has > reached its > destination - the place the stated in the URI. It is up to > that server > to decide if it really wants to respond, or to forward it on to some > *other* *more* responsible server. > > There is no law that says how a server responsible for a domain is to > interpret the user part. Even if the URI looks like a phone > number and > there is a user=phone param, it is not *obligated* to deliver the > request to some place that the *caller* thinks owns that > phone number. > It can make its own decision. > > Now this may all still work, swapping domain names while leaving the > user part alone. But only if it is done amongst a bunch of > "consenting > adult" servers that have a consistent policy about the > handling of the > user part. > > >> So, if you received a call from > sip:+12125551234@foo.com;user=phone, > >> then IMO the caller had an expectation that callbacks would be > > delivered > >> there, not to sip:+12125551234@your-sp.com. But in fact that is > > exactly > >> what a lot of systems are doing. > > > > This has nothing to do with where the call is delivered. If we're > > talking about global public telephone numbers, then +12125551234 > > uniquely identifies an endpoint. In the absence of erroroneous > > configuration both calls will complete to that endpoint. The only > > practical difference is how they get there. > > *You* may think that +12125551234 uniquely identifies the > endpoint. But > that doesn't mean that foo.com agrees with you. foo.com > minted the URI > with the expectation that requests would be delivered to it. > > You may sent it to your-sp.com *first*, but ultimately you > ought to be > getting it to the foo.com server with > sip:+12125551234@foo.com as the R-URI. > > A key difference in this regard is that if you are obligated > to get it > to sip:+12125551234@foo.com then you won't be able to route > it via the > PSTN. That may be exactly what foo.com intended. > > >>>> I don't know that we can do anything about it, except perhaps > > publish > >>>> some best practices drafts. But I expect it may be a > problem for a > > long > >>>> time. > >>> A "best practice" promoting the behavior described above, seems > >>> problematic. Maybe if there are networks somehow fundamentally > > unlike > >>> that described above (e.g., where there is no concept of > originating > >>> services), it could be scoped to be applicable to them? I suppose > > this > >>> is a general problem with best practices - few are universally > > "best". > >> I think as a community we are far from agreeing on what "best > >> practices" > >> are. Hopefully it will eventually be sorted out. But it > seems that > >> there is a fair chance that we will never all agree on what best > >> practices are in this regard, and will continue to be > >> partitioned into a > >> bunch of warring feudal communities, with tax collectors on > >> every road. > > > > Frankly I'm missing why this is such a big deal. If a > network changes > > sip:+12125551234@foo.com;user=phone to > sip:+12125551234@your-sp.com, but > > the session anyway terminates to the device at which +12125551234 is > > registered, so what? > > Getting an e2e sip connection can be a big deal. It means I can > potentially use a variety of media, rather than just voice, and I can > use various call control primitives that wouldn't otherwise > be available. > > What you want can easily be achieved if the caller starts out > with a tel > uri in the r-uri field. But then it has the latitude to > decide which it > wants to do. > > 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 sip-bounces@ietf.org Fri Apr 11 01:05:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA4F3A69A6; Fri, 11 Apr 2008 01:05:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2083A69A6 for ; Fri, 11 Apr 2008 01:05:49 -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.287, 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 qkRlcj46KJEs for ; Fri, 11 Apr 2008 01:05:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CB73E3A6845 for ; Fri, 11 Apr 2008 01:05:47 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3B867pv009652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 11 Apr 2008 03:06:08 -0500 Message-Id: From: Dean Willis To: "Dwight, Timothy M (Tim)" In-Reply-To: <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 11 Apr 2008 03:06:01 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, Paul Kyzivat , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 10, 2008, at 5:24 PM, Dwight, Timothy M (Tim) wrote: > > I see your point. In the networks with which I am familiar there is > not > such cleverness, though. They only know SIP and PSTN, and only use > PSTN > as a fallback. So in my limited world, the type of URI (sip vs. tel) > does not impact the liklihood that the call will be transported via > SIP. > We need an RFC 3262 for resolving Tel: URLs. I suspect it looks like: 1) Consult your configured routing information. If that fails, 2) Do an ENUM lookup. If that fails, 3) If you have a telephony routing table (like TRIP), consult that. If that fails, 4) Use your default telephony route; send it to a gateway. Or perhaps these are reorderable approaches, and each node needs something like an nsswitch.conf file to tell it which routing order to use? -- 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 sip-bounces@ietf.org Fri Apr 11 01:15:44 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47643A6898; Fri, 11 Apr 2008 01:15:44 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4223A6898 for ; Fri, 11 Apr 2008 01:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, J_CHICKENPOX_45=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 E9YiQuBocGgr for ; Fri, 11 Apr 2008 01:15:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 55D943A679C for ; Fri, 11 Apr 2008 01:15:40 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3B8G0xl009714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 11 Apr 2008 03:16:01 -0500 Message-Id: <44F0B544-AA2B-408B-AF69-FD719A9BC62A@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <47FE9BF1.6020004@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 11 Apr 2008 03:15:55 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC156@GBNTHT12009MSX.gb002.siemens.net> <47FE283F.7060209@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC5BF@GBNTHT12009MSX.gb002.siemens.net> <47FE9BF1.6020004@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, "Elwell, John" Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs - the purpose for user=phone X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 10, 2008, at 6:00 PM, Paul Kyzivat wrote: > > > At one point I thought that too - that the user= parameter defined > alternative namespaces for the user part of the uri, within the same > domain. But then the relevant portions of 3261 were pointed out to me, > which contradicted that idea: > > 3261 Section 10.3: > > 5. The registrar extracts the address-of-record from the To > header > field of the request. If the address-of-record is not valid > for the domain in the Request-URI, the registrar MUST send a > 404 (Not Found) response and skip the remaining steps. The > URI > MUST then be converted to a canonical form. To do that, all > URI parameters MUST be removed (including the user-param), > and > any escaped characters MUST be converted to their unescaped > form. The result serves as an index into the list of > bindings. > > 3261 Section 16.5 > > ... When accessing the > location service constructed by a registrar, the Request-URI MUST > first be canonicalized as described in Section 10.3 before being > used > as an index. The output of these mechanisms is used to construct > the > target set. > > The end result is that the user= parameter really has no significance. It MAY have no significance. If the UAS or proxy (not registrar!) node has access to telephony routing information (such as TRIP), then its policy MAY be to treat a user=phone URI differently by applying a different routing policy, e.g. by picking a route from TRIP. > > > Section 19.1.1 says: > > The set of valid telephone-subscriber strings is a subset of > valid user strings. The user URI parameter exists to > distinguish telephone numbers from user names that happen to > look like telephone numbers. If the user string contains a > telephone number formatted as a telephone-subscriber, the > user > parameter value "phone" SHOULD be present. Even without this > parameter, recipients of SIP and SIPS URIs MAY interpret the > pre-@ part as a telephone number if local restrictions on the > name space for user name allow it. > > Based on the above, its not that a given domain can have the same > string > represent a telephone number *and* something else. It can only do > one or > the other for any given string. The parameter is only an informative > qualifier regarding which it is. But I don't know who it is supposed > to > be informing. The servers running within the domain presumably already > know this. Of course, the UAS or proxy with telephony routing information MAY choose to apply such to a numeric looking request even without a user=phone. Knowing when to do telephony routing and when to do more SIP-like routing (RFC 3263, etc.) is a real challenge. We missed a bet by not making user=phone or tel: mandatory here. > > > Section 16.5 (Re proxies) says: > > If the domain of the Request-URI indicates a domain this element is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6). > > There are many circumstances in which a proxy might receive a > request for a domain it is not responsible for. A firewall > proxy > handling outgoing calls (the way HTTP proxies handle outgoing > requests) is an example of where this is likely to occur. > > Section 16.6 then gives the steps for request forwarding. In this case > these don't change the R-URI since the target is the same as the old > R-URI. The only way the parameters or the user portion of the R-URI > can > enter in here is in adding extra headers to the request, notably > including Route headers. So the fact that this includes what seems > to be > a phone number could result in a Route header whose value depends on > that phone number. But that just results in visiting added > intermediate > stops, not what the final destination is. > > So, the only remaining way for this parameter to influence anything is > in a UAS. It seems to me that a routing proxy could reroute the request based on numeric interpretation, and that it might choose to do numeric interpretation based on the user=phone. > > > Section 8.2.2.1 says: > > However, the Request-URI identifies the UAS that is to process the > request. If the Request-URI uses a scheme not supported by the > UAS, > it SHOULD reject the request with a 416 (Unsupported URI Scheme) > response. If the Request-URI does not identify an address that the > UAS is willing to accept requests for, it SHOULD reject the request > with a 404 (Not Found) response. > > Apparently the UAS only must be *willing* to process the URI - there > is > no requirement that it *be responsible* for the domain of the R-URI. > IMO > that is a mistake, but it seems to be the normative justification > for SBCs. Yep. > > > So, a UAS that is willing may receive a request for any old domain. > And > then I guess it is free to use the user= parameter to decide that the > user part of the URI is in tel format, and it then may decide to > generate a *different* request to some other destination that it > thinks > is responsible for the phone number, and link the two requests. > > So apparently that is the value of the user parameter. If it were used consistently within an organizational topology, I maintain that it could have utility at rerouting proxies. On the other hand, I think we should have just used tel: for all these cases. It's much cleaner. -- 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 sip-bounces@ietf.org Fri Apr 11 03:00:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C9B28C278; Fri, 11 Apr 2008 03:00:02 -0700 (PDT) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5CF5928C263; Fri, 11 Apr 2008 03:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080411100001.5CF5928C263@core3.amsl.com> Date: Fri, 11 Apr 2008 03:00:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-xcapevent-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package Author(s) : J. Urpalainen Filename : draft-ietf-sip-xcapevent-02.txt Pages : 28 Date : 2008-04-11 This document describes an "xcap-diff" SIP event package for the SIP Event Notification Framework, with the aid of which clients can receive notifications of the partial changes of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization and document updates are based on using the XCAP-Diff format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-xcapevent-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-11025103.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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-- From sip-bounces@ietf.org Fri Apr 11 04:39:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC6B28C0D8; Fri, 11 Apr 2008 04:39:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84C23A6F21 for ; Fri, 11 Apr 2008 04:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 P3Ir+SwXb-pU for ; Fri, 11 Apr 2008 04:39:18 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A91223A6F1F for ; Fri, 11 Apr 2008 04:39:17 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3BBcggI030806 for ; Fri, 11 Apr 2008 14:39:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 14:39:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 14:39:34 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 14:39:34 +0300 Message-ID: <47FF4DF1.4060008@nokia.com> Date: Fri, 11 Apr 2008 14:39:29 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: sip@ietf.org References: <20080411100001.5CF5928C263@core3.amsl.com> In-Reply-To: <20080411100001.5CF5928C263@core3.amsl.com> X-OriginalArrivalTime: 11 Apr 2008 11:39:34.0739 (UTC) FILETIME=[B7146230:01C89BC8] X-Nokia-AV: Clean Subject: Re: [Sip] I-D Action:draft-ietf-sip-xcapevent-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ext Internet-Drafts@ietf.org wrote: > 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 : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package > Author(s) : J. Urpalainen > Filename : draft-ietf-sip-xcapevent-02.txt > Pages : 28 > Date : 2008-04-11 > > This document describes an "xcap-diff" SIP event package for the SIP > Event Notification Framework, with the aid of which clients can > receive notifications of the partial changes of Extensible Markup > Language (XML) Configuration Access Protocol (XCAP) resources. The > initial synchronization and document updates are based on using the > XCAP-Diff format. > > Hi All ! I've digested all wglc comments (and hopefully got them correctly). Thanks for everybody who commented and please check that they ended up being as _good enough_. Well if not, please comment... -so the intro & basic operation got mangled a bit, probably it is now more understandable. -diff-processing parameter was not precisely enough presented, now there's some normative text also. -subscriber & notifier processing is also more accurate, though _longer_ -some examples in an appendix to describe to thing to novice implementers... In principle, there should be no "real" changes, i.e. those which should really influence implementations, though i may have added some unnecessary stuff there. br, Jari _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 06:26:00 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC72628C1DE; Fri, 11 Apr 2008 06:26:00 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B06D3A6846 for ; Fri, 11 Apr 2008 06:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.533 X-Spam-Level: X-Spam-Status: No, score=-5.533 tagged_above=-999 required=5 tests=[AWL=1.066, 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 sd38jY361ALC for ; Fri, 11 Apr 2008 06:25:58 -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 2F83628C326 for ; Fri, 11 Apr 2008 06:25:39 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2008 06:26:02 -0700 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 m3BDQ2bx019846; Fri, 11 Apr 2008 06:26:02 -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 m3BDPr5x028777; Fri, 11 Apr 2008 13:26:02 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, 11 Apr 2008 09:26:00 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 09:26:00 -0400 Message-ID: <47FF6704.6020107@cisco.com> Date: Fri, 11 Apr 2008 09:26:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <47FED0B5.2090906@cisco.com> In-Reply-To: X-OriginalArrivalTime: 11 Apr 2008 13:26:00.0595 (UTC) FILETIME=[9558AE30:01C89BD7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2555; t=1207920362; x=1208784362; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=MBFQjVfNHyPiLyxjOJgWc2ni6qDJasV8gnkO6V7vnuQ=; b=B2HU11d247UzMiRJ70e9xAGkgtZxUhDO5f+Da5slW7Q23llxtnG9NwnSHZ Nil9i8783JYg5c+h7mfarfMCNRlKtS/L5x+F+5UXxktHEY+hZqn9h5KZecNr xxup4tFV2L; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> In this case what I had in mind (by referring to a "call back") was that >> I gave it to you in a From-URI. > > Ah, ok. The only issue then is that when a UAC generates a request, it's not really clear how it should know when it wants things back *only* via SIP, or when it doesn't care. For example, if you make a phone call, why would your UAC use a From-URI of TEL? > > It would (typically) be your registered AoR, and sip:me@domain. And yet I doubt very much that most phones, or their users, really care whether people calling them *back* go through the PSTN or not to reach their SIP phone. I bet most of them have no idea they're even *using* a SIP phone. Yes, this is definitely a policy issue. And for many phones it really won't matter. In that case I think they would be best to use tel:. (Except of course that may introduce interop problems with devices that don't support tel. But those will be fixed by SBCs :-) It starts to matter when the device does more than audio. >>>> If you want some server on the originating end to do something for the >>>> outbound call, then you should put a Route header in the request >>>> identifying the server. >>> And I wish that would work, but in many cases it won't. >> AFAIK we are in the business of determining the valid ways of doing >> things. If implementations choose to do otherwise all we can do is keep >> encouraging. > > Absolutely. But pragmatism has its place too. (I'm not saying this is one of those times though) > > >> The problem with trying to make up for the inadequacies of the neighbors >> is - how do you know which ones do it right and which do it wrong? > > With some things it's part of the peering agreement (e.g., a "profile"), with some things it's based on device-specific config or vendor-profiles. But for some things it's a lowest-common-denominator: change it to what works with every device. > > >> I guess you SBC guys can keep getting the business to try to solve that >> problem. But it really means a bunch of configuration about the >> idiosyncrasies of all the peers. That only works when there are a >> limited number of them. > > Yup, and why I'm trying to get things to stop needing to be "fixed". It's not core to an SBC's value prop, and not a good long-term strategy for such. I'm really glad to hear that. And even though you are a marketing guy, I believe you. 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 sip-bounces@ietf.org Fri Apr 11 06:39:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454B63A6968; Fri, 11 Apr 2008 06:39:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2239A3A6968 for ; Fri, 11 Apr 2008 06:39:22 -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 j9qcEMc199yC for ; Fri, 11 Apr 2008 06:39:21 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 3F5AF3A68DE for ; Fri, 11 Apr 2008 06:39:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id A8CF31EC290; Fri, 11 Apr 2008 16:39:43 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntvyBPfmahtl; Fri, 11 Apr 2008 16:39:36 +0300 (EEST) Received: from taimen (h147209.gprs.dnafinland.fi [87.93.147.209]) by tutpro.com (Postfix) with ESMTP; Fri, 11 Apr 2008 16:39:36 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id A8A56AC0E5; Fri, 11 Apr 2008 16:39:30 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18431.27154.648815.968450@taimen.test.fi> Date: Fri, 11 Apr 2008 16:39:30 +0300 To: Paul Kyzivat In-Reply-To: <47FF6704.6020107@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <47FED0B5.2090906@cisco.com> <47FF6704.6020107@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat writes: > (Except of course that may introduce interop problems with devices that > don't support tel. But those will be fixed by SBCs :-) i think it is mandatory for sip phones to support tel. otherwise it is impossible to for a sip phone in another domain to 302 caller to a pstn number. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 06:44:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AFA3A6E0D; Fri, 11 Apr 2008 06:44:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B193A6E0D for ; Fri, 11 Apr 2008 06:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.255 X-Spam-Level: X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=0.744, 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 W8Web6WCjupy for ; Fri, 11 Apr 2008 06:44:33 -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 5816E3A6B1A for ; Fri, 11 Apr 2008 06:44:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,642,1199682000"; d="scan'208";a="4745953" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Apr 2008 09:44:55 -0400 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 m3BDisG1007469; Fri, 11 Apr 2008 09:44:54 -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 m3BDirqB010619; Fri, 11 Apr 2008 13:44:54 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, 11 Apr 2008 09:44:51 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 09:44:51 -0400 Message-ID: <47FF6B6E.7070508@cisco.com> Date: Fri, 11 Apr 2008 09:45:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Dwight, Timothy M (Tim)" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> <47FEA3E9.7070404@cisco.com> <092B2658AAB56A4D80836399A4C47031042A1E55@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C47031042A1E55@ASHEVS002.mcilink.com> X-OriginalArrivalTime: 11 Apr 2008 13:44:51.0394 (UTC) FILETIME=[375AEA20:01C89BDA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16376; t=1207921494; x=1208785494; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20=22Dwight,=20Timothy=20M=20(Tim)=22=20; bh=UCDVY+S8QALLaUqpAo17gWAQnyEYQb9xAiPkqlxmeJ8=; b=vOYnyqTynpOb6g2efUTN2d4Ifjw1WliHgv8ikjqsovnKHDTcRk3xuuEtB/ 4ApW4cnDFpAcmTdqHWbcLFndQnMiW+XNPUD5opKGf8Pjp9BCCWeNv0OAX1EM QaOfG9xe3p; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dwight, Timothy M (Tim) wrote: > Thanks, Paul. This has been a useful exchange. > > I agree with you that we need to be able to provide originating services > to the calling party without forcing the R-URI to identify a domain for > which the calling party's network is authoritative. And as you note > this is mandatory to support "email style" R-URIs. Inclusion of a Route > header seems like a good solution, albeit one dependent on supplier > implementation. IMS offers another. IMS *does* use Route headers for this, at least in-dialog. Its been quite awhile since I looked at IMS and I'm starting to forget. As I recall they were a bit inconsistent about whether the P-CSCF is listed in the Route header, or if the request is just sent there without. If I remember correctly the Route header isn't used for the REGISTER, But it is used subsequently. In any case, if you want to just populate your request with the correct R-URI and then send it to an outbound proxy without naming that proxy anywhere in the message, that is ok too. > On reflection I'm not sure the rule that "if I give you > sip:+4085551212@sp.com, with or without user=phone, then a call back to > that URI MUST be via sip" is advisable. What if there's no VoIP peering > agreement between my network and the network authoritative for 'sp.com'? > Which would you prefer, that the call fail or that it be routed via the > PSTN? Given that there's no practical way to know each caller's > preference, networks will have to implement some "reasonable" policy. > To me it seems reasonable to expect that someone who identifies himself > with a telephone number would not be opposed to receiving calls via the > PSTN, if that's the only way they can be delivered. I wouldn't object to "trying something else", like turning the sip uri with user=phone into a tel uri, *if* the call otherwise cannot be completed. Its then an error recovery strategy. > I'm not sure what you mean by "foo.com minted the URI with the > expectation that requests would be delivered to it". I'm not sure what > "minting" means, It just means the foo.com itself created the URI. Which indicates that it at least *believes* it can process the user part. > but hopefully it doesn't involve foo.com generating > calls whose From-URI imbeds a telephone number for which foo.com is not > responsible. AFAIK foo.com is permitted to populate the user portion of the uri with anything it wants that is syntactically valid. This is certainly true when user=phone is absent. And I think it is true if user=phone is present. All that does is make a statement about the *syntax* of the field, nothing about the ownership of a telephone number. > "Responsibility" is a bit vague, but basically I mean that > either the number is assigned to foo.com by the numbering plan > authority, the number is ported to foo.com, or use of the number is > authorized to foo.com by its legitimate owner (e.g., through a wholesale > arrangement). The issue is that there be a "chain of custody" leading > to the entity providing service to the number. Implementation of lawful > intercept, for example, relies on this. Well, absent a mechanism for signing E.164 numbers with certs that *prove* ownership there is no way to enforce that policy. And it seems far from clear that others agree with you that this is the policy that ought to exist. IMO that is a value of distinguishing tel from sip/user=phone. With sip, the supplier of the URI determines the routing. With tel, the originator of the call determines the routing. It is the desire to ignore the domain name in the sip URI that leads to your need to have this special, unenforceable, policy on responsibility. (Well, its enforceable in a legal sense with peering agreements, but that builds a closed garden.) Paul > tim > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, April 10, 2008 6:34 PM >> To: Dwight, Timothy M (Tim) >> Cc: sip@ietf.org; Francois Audet; Dan Wing >> Subject: Re: [Sip] E.164 - who owns it >> >> >> >> Dwight, Timothy M (Tim) wrote: >>> Paul, >>> >>>>> Are you saying that use of tel:+4085551212 as opposed to >>>>> sip:+4085551212;user=phone makes it more likely that the call will >>> be >>>>> routed to the PSTN? If so, why would that be? >>>> IMO if I give you sip:+4085551212@sp.com, with or without >> user=phone, >>>> then a call back to that URI MUST be via sip, and the 3263 >> rules say >>>> that it MUST be routed to domain sp.com before making any >>>> decision about how to reach something associated with the >> user part. >>> OK, I'm fine with that. >>> >>> >>>> If I give you tel:+4085551212, then you have total freedom >> regarding >>>> what protocol to use to reach me, and the path taken. You >> may just use >>>> an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip >>>> service, or whatever. >>> I see your point. In the networks with which I am familiar >> there is not >>> such cleverness, though. They only know SIP and PSTN, and >> only use PSTN >>> as a fallback. So in my limited world, the type of URI >> (sip vs. tel) >>> does not impact the liklihood that the call will be >> transported via SIP. >>> >>>>>> If the devices are half way smart, even if they only show the >>> number >>>>>> they will keep the entire URI in their call log, so that if I >>> attempt a >>>>>> callback via the call log it will use the whole URI. But I expect >>> some >>>>>> devices will be dumber than that. >>>>> When you say "use the whole URI" do you mean in the R-URI? >>>> I was thinking of a device that keeps a log of *incoming* >>>> calls, so the From-URI would be appropriate. >>> Yes, I understand that. I was asking if you meant that the >> device would >>> put the value it extracted from the From-URI into the >> Request-URI of the >>> callback. As opposed for example to putting it in the >> To-URI and maybe >>> constructing a R-URI with the same user part ("dialed digits") but a >>> different host part (identifying the network serving the >> calling party). >>> I guess such a thing would be legal. >> Section 8.1.1.1 of 3261 applies here: >> >> The initial Request-URI of the message SHOULD be set to >> the value of >> the URI in the To field. One notable exception is the REGISTER >> method; behavior for setting the Request-URI of REGISTER >> is given in >> Section 10. It may also be undesirable for privacy reasons or >> convenience to set these fields to the same value >> (especially if the >> originating UA expects that the Request-URI will be changed during >> transit). >> >> In some special circumstances, the presence of a >> pre-existing route >> set can affect the Request-URI of the message. A >> pre-existing route >> set is an ordered set of URIs that identify a chain of servers, to >> which a UAC will send outgoing requests that are outside >> of a dialog. >> Commonly, they are configured on the UA by a user or >> service provider >> manually, or through some other non-SIP mechanism. When >> a provider >> wishes to configure a UA with an outbound proxy, it is RECOMMENDED >> that this be done by providing it with a pre-existing >> route set with >> a single URI, that of the outbound proxy. >> >> When a pre-existing route set is present, the procedures for >> populating the Request-URI and Route header field >> detailed in Section >> 12.2.1.1 MUST be followed (even though there is no >> dialog), using the >> desired Request-URI as the remote target URI. >> >> The only case in which R-URI won't equal the To-URI is if there is a >> preexisting route set and the first route in that set is a >> strict-router. In that case the To-URI will end up as the >> last value of >> the Route header. >> >> Loose routing has been defined for five years or so now. It generally >> ought to be supported. So in general the R-URI should equal >> the To-URI. >> In my example they would both equal what was in the From-URI of the >> incoming call that is now being returned. >> >>>>> I'm not sure >>>>> this would be desirable behavior. If the host part of the R-URI >>> does >>>>> not identify a domain for which the network serving the calling >>> party is >>>>> authoritative, then as I understand it the network serving the >>> calling >>>>> party should simply proxy the INVITE per 3263. But then how does >>> the >>>>> network serving the calling party provide originating services to >>> its >>>>> subscriber? >>>>> >>>>> As a practical matter I'll note that in some networks with which I >>> am >>>>> familiar, the value to be used in the host part of the R-URI is >>> dictated >>>>> by the network. >>>> If you are originating a call from a dial string, not a >> URI, then I >>>> guess you can formulate the R-URI any way you want. But if >> the calling >>>> party is supplying a URI (e.g. one it has saved from a >> prior received >>>> call) then it should be used as-is. >>> Well as I noted, such a call will fail in some networks >> with which I am >>> familiar. In some cases it may succeed because the network >> ignores or >>> its dreaded SBCs overwrite, the host part of the R-URI. I >> doubt you'll >>> find many public networks willing to allow their proxies to >> be used but >>> their call servers bypassed. >> Their proxies don't have to be bypassed. Those proxies just >> become part >> of a preexisting route set known to the UAC and populated >> into the Route >> header. >> >>>> If you want some server on the originating end to do >> something for the >>>> outbound call, then you should put a Route header in the request >>>> identifying the server. >>> I see how that could work, yes. Except for the issue that many >>> currently deployed devices do not support Route headers. >> Its about time they got with the program. >> >>>> As a practical matter, suppose you receive a call from >>>> sip:george.bush@whitehouse.gov. If you want to return that >> call, you >>>> have little choice but to use that as the R-URI. You can't >> very well >>>> send it to sip:george.bush@your-sp.com and expect the right >>>> thing to happen. >>> Of course. But I believe the issue here is specific to >> URIs that have >>> telephone numbers as the user part. >>> >>> I think the issue we're wrestling with is whether the >> semantics of the >>> relationship between user and host part of such URIs is the >> same as that >>> of "email style" URIs. I believe that it is not. >> It should be the same until you get to the target domain. >> >> But I just posted another message on a closely related point >> that goes >> into this more. You might want to reply to that. >> >> And I don't see how treating them differently helps you. >> Won't your SP >> still want to provide originating services when I'm calling >> sip:george.bush@whitehouse.gov? How will it do so? >> >>> In an email style URI (one whose user part is not a >> telephone number) >>> the domain in the host part provides service to the user >> identified in >>> the user part. In a URI whose user part is a telephone number, the >>> domain in the host part may or may not (i.e., cannot be assumed to) >>> provide service to the user identified in the user part. >> I think we can/should assume that it is *claiming* responsibility, at >> least to the extent that return calls to this URI should pass through >> it, perhaps after passing through other servers. It may >> decide to relay >> the call on elsewhere, but initially it is to be assumed to be the >> responsible domain. As I note in my other post, proxies MUST treat it >> that way. >> >>> By identifying >>> "foo.com" in the host part of a URI whose user part >> contains a telephone >>> number, I am giving the network authoritative for foo.com >> the right to >>> examine for purposes of routing, the user part of the URI. I am not >>> implying that that network provides service to the user >> identified by >>> the URI's user part. It might, but if it did that would be >>> coincidental. >> That is really true for any URI. When the request reaches a server >> authoritative for the domain of the URI it is some sense has >> reached its >> destination - the place the stated in the URI. It is up to >> that server >> to decide if it really wants to respond, or to forward it on to some >> *other* *more* responsible server. >> >> There is no law that says how a server responsible for a domain is to >> interpret the user part. Even if the URI looks like a phone >> number and >> there is a user=phone param, it is not *obligated* to deliver the >> request to some place that the *caller* thinks owns that >> phone number. >> It can make its own decision. >> >> Now this may all still work, swapping domain names while leaving the >> user part alone. But only if it is done amongst a bunch of >> "consenting >> adult" servers that have a consistent policy about the >> handling of the >> user part. >> >>>> So, if you received a call from >> sip:+12125551234@foo.com;user=phone, >>>> then IMO the caller had an expectation that callbacks would be >>> delivered >>>> there, not to sip:+12125551234@your-sp.com. But in fact that is >>> exactly >>>> what a lot of systems are doing. >>> This has nothing to do with where the call is delivered. If we're >>> talking about global public telephone numbers, then +12125551234 >>> uniquely identifies an endpoint. In the absence of erroroneous >>> configuration both calls will complete to that endpoint. The only >>> practical difference is how they get there. >> *You* may think that +12125551234 uniquely identifies the >> endpoint. But >> that doesn't mean that foo.com agrees with you. foo.com >> minted the URI >> with the expectation that requests would be delivered to it. >> >> You may sent it to your-sp.com *first*, but ultimately you >> ought to be >> getting it to the foo.com server with >> sip:+12125551234@foo.com as the R-URI. >> >> A key difference in this regard is that if you are obligated >> to get it >> to sip:+12125551234@foo.com then you won't be able to route >> it via the >> PSTN. That may be exactly what foo.com intended. >> >>>>>> I don't know that we can do anything about it, except perhaps >>> publish >>>>>> some best practices drafts. But I expect it may be a >> problem for a >>> long >>>>>> time. >>>>> A "best practice" promoting the behavior described above, seems >>>>> problematic. Maybe if there are networks somehow fundamentally >>> unlike >>>>> that described above (e.g., where there is no concept of >> originating >>>>> services), it could be scoped to be applicable to them? I suppose >>> this >>>>> is a general problem with best practices - few are universally >>> "best". >>>> I think as a community we are far from agreeing on what "best >>>> practices" >>>> are. Hopefully it will eventually be sorted out. But it >> seems that >>>> there is a fair chance that we will never all agree on what best >>>> practices are in this regard, and will continue to be >>>> partitioned into a >>>> bunch of warring feudal communities, with tax collectors on >>>> every road. >>> Frankly I'm missing why this is such a big deal. If a >> network changes >>> sip:+12125551234@foo.com;user=phone to >> sip:+12125551234@your-sp.com, but >>> the session anyway terminates to the device at which +12125551234 is >>> registered, so what? >> Getting an e2e sip connection can be a big deal. It means I can >> potentially use a variety of media, rather than just voice, and I can >> use various call control primitives that wouldn't otherwise >> be available. >> >> What you want can easily be achieved if the caller starts out >> with a tel >> uri in the r-uri field. But then it has the latitude to >> decide which it >> wants to do. >> >> 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 sip-bounces@ietf.org Fri Apr 11 07:25:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAA63A6D05; Fri, 11 Apr 2008 07:25:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8EB3A6AE7 for ; Fri, 11 Apr 2008 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.713, 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 KL5tC+idmo7F for ; Fri, 11 Apr 2008 07:25:55 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 3EC083A6C80 for ; Fri, 11 Apr 2008 07:25:01 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JkKBo-0003Ww-DS; Fri, 11 Apr 2008 09:25:16 -0500 From: "Brian Rosen" To: "'Dan Wing'" , "'Elwell, John'" , , References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><091b01c89a73$123ea0f0$c5f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net> <00fe01c89b48$8c22ca60$c5f0200a@cisco.com> Date: Fri, 11 Apr 2008 10:25:17 -0400 Message-ID: <0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00fe01c89b48$8c22ca60$c5f0200a@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciaWlcnm8fafYUuQLSp54TYycPz4AAFwDiAACijzCAADP2AgAAlTB4A X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Getting back to this, the circumstance that is worried about cannot exist. Unlike in IP networks, an e.164 cannot be "dual homed". It is not possible for sp1.net and sp2.net to allow origination/termination of the same e.164 In the PSTN, a call to an e.164 always is routed to a specific service provider. The service provider can route it to one of several termination domains (at the direction of the enterprise/consumer). The enterprise can indeed be served by multiple service providers, but the e.164s would be different. On the PSTN, "who owns it" is actually fairly poorly defined. In countries where number portability is implemented, the subscriber has a right to port the number, but it's actually "owned" in nearly every sense by the carrier who currently serves it. In most non-portability countries, for all intents and purposes, the carrier owns the number. For routing purposes, the destination of the route is known by the service provider. Other service providers can learn the identity of the carrier that currently serves the number, but typically not the identity of, or the route to, the terminating domain. The advent of user ENUM could change these relationships and knowledge, but, so far, user ENUM is not widely implemented. Infrastructure ENUM attempts to fix the route issue, by providing anyone the termination domain information, while retaining the current effective ownership of the numbers by the carrier. Private ENUM leaves the relationships as they are. When an enterprise asserts that it owns a number, it doesn't. The carrier effectively owns it. What the enterprise can do is use the number as a globally unique string and then create some URIs using that string. That isn't the same thing. We need to keep that in mind. Brian -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dan Wing Sent: Thursday, April 10, 2008 4:22 PM To: 'Elwell, John'; Dale.Worley@comcast.net; sip@ietf.org Subject: Re: [Sip] E.164 - who owns it ... > [JRE] What about the following case? Enterprise.com uses two service > providers, sp1.net for incoming calls and some outgoing calls and > sp2.net for other outgoing calls. It sends an INVITE request via > sp2.net, which signs the E.164-based From URI. The SUBSCRIBE > request is > routed via sp1.net to enterprise.com, which will be unable to sign the > NOTIFY request. However, if the outgoing call had gone via > sp1.net there > would be no problem. I am not sure whether this behaviour is a good > thing or a bad thing. Here is a quick ASCII diagram of what you are describing: sp1.net-<<- / / Enterprise.com -< \ \sp2.net->>- > Of course, if enterprise.com signs and the signature survives > end-to-end there is no problem and the called user gets a more > useful caller ID. Exactly. If enterprise.com is UNABLE to create a signature, but rather its signatures are destroyed and over-written by sp1.net or sp2.net, then yes, the best that can be done is trust sp1.net and sp2.net to have Done The Right Thing. That is not too valuable to me. If that is the only value we want or need, we already have RFC4474 that provides exactly this same characteristic. draft-wing-sip-e164-rrc is an attempt to provide something stronger, so that the message arrives at Enterprise.com and they -- not their service provider(s) -- create the signature (as you said). -d _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 07:30:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EFF3A6BA0; Fri, 11 Apr 2008 07:30:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53933A695C for ; Fri, 11 Apr 2008 07:30:52 -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 W2dDrnIoNjQ4 for ; Fri, 11 Apr 2008 07:30:52 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id EDD453A6BA0 for ; Fri, 11 Apr 2008 07:30:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id D93661EC290; Fri, 11 Apr 2008 17:31:12 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GatDMdb37mlo; Fri, 11 Apr 2008 17:31:05 +0300 (EEST) Received: from taimen (h147209.gprs.dnafinland.fi [87.93.147.209]) by tutpro.com (Postfix) with ESMTP; Fri, 11 Apr 2008 17:31:05 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 883A4AC0E6; Fri, 11 Apr 2008 17:31:00 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18431.30244.255028.222026@taimen.test.fi> Date: Fri, 11 Apr 2008 17:31:00 +0300 To: "Brian Rosen" In-Reply-To: <0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <091b01c89a73$123ea0f0$c5f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net> <00fe01c89b48$8c22ca60$c5f0200a@cisco.com> <0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Brian Rosen writes: > Unlike in IP networks, an e.164 cannot be "dual homed". It is not possible > for sp1.net and sp2.net to allow origination/termination of the same > e.164. where is that stated? isn't it national policy if dual homing of e.164 numbers is allowed or not? -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 07:31:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E1C3A6DFD; Fri, 11 Apr 2008 07:31:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA81C3A6E0D for ; Fri, 11 Apr 2008 07:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 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 LKIQi-54NBoq for ; Fri, 11 Apr 2008 07:31:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 22C133A6B56 for ; Fri, 11 Apr 2008 07:31:35 -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.240.5; Fri, 11 Apr 2008 10:31:30 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 11 Apr 2008 10:31:29 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 11 Apr 2008 10:31:34 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acib14dHtnlpwOtJSH6kwWwWimPBOQABzkYQ Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <47FED0B5.2090906@cisco.com> <47FF6704.6020107@cisco.com> In-Reply-To: <47FF6704.6020107@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Yup, and why I'm trying to get things to stop needing to be "fixed". > It's not core to an SBC's value prop, and not a good long-term strategy > for such. > > I'm really glad to hear that. And even though you are a marketing guy, I > believe you. :) I resemble that remark. It doesn't take a rocket-scientist to figure out growth in SIP volume will mean growth in SBCs regardless, and having things work "out of the box" helps growth. (and that includes making SIP used for things other than phone calls) -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 sip-bounces@ietf.org Fri Apr 11 07:42:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E063A6EA5; Fri, 11 Apr 2008 07:42:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500A23A6E56 for ; Fri, 11 Apr 2008 07:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 PU8jglw2ICgh for ; Fri, 11 Apr 2008 07:41:59 -0700 (PDT) Received: from omzesmtp03a.verizonbusiness.com (omzesmtp03a.verizonbusiness.com [199.249.25.201]) by core3.amsl.com (Postfix) with ESMTP id C2A3D3A6D57 for ; Fri, 11 Apr 2008 07:41:59 -0700 (PDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0JZ600JBS0ULRC00@firewall.verizonbusiness.com> for sip@ietf.org; Fri, 11 Apr 2008 14:42:22 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([127.0.0.1]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZ6001UG0ULK7@dgismtp01.mcilink.com> for sip@ietf.org; Fri, 11 Apr 2008 14:42:22 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZ6000HH0UKSL@dgismtp01.mcilink.com> for sip@ietf.org; Fri, 11 Apr 2008 14:42:21 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 14:42:20 +0000 Date: Fri, 11 Apr 2008 14:41:23 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <47FF6B6E.7070508@cisco.com> To: Paul Kyzivat Message-id: <092B2658AAB56A4D80836399A4C47031042A2227@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Sip] E.164 - who owns it Thread-index: Acib2kNBQwanawiUS1KFEVqx27aCrAAA6mHQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> <47FEA3E9.7070404@cisco.com> <092B2658AAB56A4D80836399A4C47031042A1E55@ASHEVS002.mcilink.com> <47FF6B6E.7070508@cisco.com> X-OriginalArrivalTime: 11 Apr 2008 14:42:20.0735 (UTC) FILETIME=[3F5294F0:01C89BE2] Cc: sip@ietf.org, Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, > Dwight, Timothy M (Tim) wrote: > > Thanks, Paul. This has been a useful exchange. > > > > I agree with you that we need to be able to provide > originating services > > to the calling party without forcing the R-URI to identify > a domain for > > which the calling party's network is authoritative. And as you note > > this is mandatory to support "email style" R-URIs. > Inclusion of a Route > > header seems like a good solution, albeit one dependent on supplier > > implementation. IMS offers another. > > IMS *does* use Route headers for this, at least in-dialog. Its been > quite awhile since I looked at IMS and I'm starting to forget. As I > recall they were a bit inconsistent about whether the P-CSCF > is listed > in the Route header, or if the request is just sent there > without. If I > remember correctly the Route header isn't used for the > REGISTER, But it > is used subsequently. I guess I'm forgetting too :-) Anyway you're right, IMS does use Route headers (except in REGISTER, which is sent to the P-CSCF learned during "P-CSCF discovery"). Basically the UE gets a route list in the Service-Route header appended to the 200OK received in response to the REGISTER, and uses that list in to populate the Route header in subsequent dialog-initiating requests. > > I'm not sure what you mean by "foo.com minted the URI with the > > expectation that requests would be delivered to it". I'm > not sure what > > "minting" means, > > It just means the foo.com itself created the URI. Which > indicates that > it at least *believes* it can process the user part. > > > but hopefully it doesn't involve foo.com generating > > calls whose From-URI imbeds a telephone number for which > foo.com is not > > responsible. > > AFAIK foo.com is permitted to populate the user portion of > the uri with > anything it wants that is syntactically valid. I don't disagree that IETF may permit this. But appropriate use of numbering resources is not up to the IETF. I think it is at least bad practice to identify a session originator with a URI whose structure implies that the user part is a telephone number (user part is numeric, preceded by '+', "user=phone" parameter appended, etc.,), unless the originating network has some legitimate right to assign that number. The only reason I can think of to allow this, would be to facilitate the sort of mischief (spoofing of caller ID etc.,) that currently plagues the PSTN, and has been rightly criticized on this list. I understand that such a policy is difficult to enforce via protocol mechanisms. "appropriate use" policies, often are. Still documenting them can be of use, for example because they legitimize the punishment :-) And certainly if this discussion vectors into definition of a BCP we would want to take care that the IETF not endorse or promote antisocial practices. tim _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 08:07:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E2C3A6E7A; Fri, 11 Apr 2008 08:07:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47F93A6B98 for ; Fri, 11 Apr 2008 08:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.708, 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 zVN7Hu6V5aVt for ; Fri, 11 Apr 2008 08:07:14 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 1081C3A6C80 for ; Fri, 11 Apr 2008 08:07:14 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JkKqT-0000hi-Nz; Fri, 11 Apr 2008 10:07:17 -0500 From: "Brian Rosen" To: "'Juha Heinanen'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><091b01c89a73$123ea0f0$c5f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net><00fe01c89b48$8c22ca60$c5f0200a@cisco.com><0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com> <18431.30244.255028.222026@taimen.test.fi> Date: Fri, 11 Apr 2008 11:07:18 -0400 Message-ID: <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <18431.30244.255028.222026@taimen.test.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acib4LAhpMxjFJxbRGWYlVjjqKhYKgAA2Xrg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: sip@ietf.org, "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In theory, as with any PSTN regulation, it could be. As a practical matter, the way calls are routed, it isn't I believe. Are you aware of a country that allows it? I'd love to see the routing tables. You've got a better shot of allowing two carriers to originate a call with the same e.164. There is no error checking, or reverse routability checks in the SS7 network. However, usually carriers frown on spoofing of called party number. In all the work I've seen on numbering, including all the latest ENUM deployments, dual homed e.164s wouldn't work. That doesn't mean we couldn't make them work in ENUM/SIP land, just that the current state of the PSTN, and the ENUM deployments, doesn't allow the possibility, AFAIK. Brian -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Friday, April 11, 2008 10:31 AM To: Brian Rosen Cc: 'Dan Wing'; 'Elwell, John'; Dale.Worley@comcast.net; sip@ietf.org Subject: Re: [Sip] E.164 - who owns it Brian Rosen writes: > Unlike in IP networks, an e.164 cannot be "dual homed". It is not possible > for sp1.net and sp2.net to allow origination/termination of the same > e.164. where is that stated? isn't it national policy if dual homing of e.164 numbers is allowed or not? -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 08:13:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37B63A6E9F; Fri, 11 Apr 2008 08:13:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07AE53A6E9F for ; Fri, 11 Apr 2008 08:13:26 -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 jQVG1JU-Hw-A for ; Fri, 11 Apr 2008 08:13:25 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 1DF5E3A6E3B for ; Fri, 11 Apr 2008 08:13:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 6843E1EC290; Fri, 11 Apr 2008 18:13:47 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s41Me0USj+H2; Fri, 11 Apr 2008 18:13:40 +0300 (EEST) Received: from taimen (h147209.gprs.dnafinland.fi [87.93.147.209]) by tutpro.com (Postfix) with ESMTP; Fri, 11 Apr 2008 18:13:40 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 25F2AAC0E4; Fri, 11 Apr 2008 18:13:35 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18431.32800.21763.353306@taimen.test.fi> Date: Fri, 11 Apr 2008 18:13:36 +0300 To: "Brian Rosen" In-Reply-To: <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <091b01c89a73$123ea0f0$c5f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net> <00fe01c89b48$8c22ca60$c5f0200a@cisco.com> <0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com> <18431.30244.255028.222026@taimen.test.fi> <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Brian Rosen writes: > As a practical matter, the way calls are routed, it isn't I believe. Are > you aware of a country that allows it? I'd love to see the routing tables. > You've got a better shot of allowing two carriers to originate a call with > the same e.164. this latter thing is what i have been demanding the regulator in finland to allow. i don't think there are any technical problems in implementing it. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 08:25:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C9F3A6E0D; Fri, 11 Apr 2008 08:25:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4123A6EB3 for ; Fri, 11 Apr 2008 08:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 lX4Yi3o9ZEnH for ; Fri, 11 Apr 2008 08:25:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2883F3A6E0D for ; Fri, 11 Apr 2008 08:25: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.240.5; Fri, 11 Apr 2008 11:25:12 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 11 Apr 2008 11:25:12 -0400 From: Hadriel Kaplan To: Brian Rosen , 'Juha Heinanen' Date: Fri, 11 Apr 2008 11:25:16 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acib4LAhpMxjFJxbRGWYlVjjqKhYKgAA2XrgAACJ6DA= Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><091b01c89a73$123ea0f0$c5f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net><00fe01c89b48$8c22ca60$c5f0200a@cisco.com><0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com> <18431.30244.255028.222026@taimen.test.fi> <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> In-Reply-To: <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm not quite sure how you mean "dual-homed E.164". In IP, I think of dual-homed as simply being reachable through multiple interfaces (for a dual-homed host), or multiple BGP exit/entry points for a common prefix (for a dual-homed end network). If you're implying there is only one physical or logical path to reach a given E.164, well, you'd be wrong. :) From a SIP perspective, I think there are also in fact multiple origination and termination points for the same E.164, because I consider the PSTN/H.323/whatever to be "the end" from a SIP perspective. In other words if in SIP-land I can send a SIP Invite to one of multiple next-domains, each of which would ingress it into the PSTN, I consider them each distinct SIP termination points. But I'm not sure you mean it that way? -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, April 11, 2008 11:07 AM > To: 'Juha Heinanen' > Cc: sip@ietf.org; 'Elwell, John'; 'Dan Wing' > Subject: Re: [Sip] E.164 - who owns it > > In theory, as with any PSTN regulation, it could be. > > As a practical matter, the way calls are routed, it isn't I believe. Are > you aware of a country that allows it? I'd love to see the routing > tables. > You've got a better shot of allowing two carriers to originate a call with > the same e.164. There is no error checking, or reverse routability checks > in the SS7 network. However, usually carriers frown on spoofing of called > party number. > > In all the work I've seen on numbering, including all the latest ENUM > deployments, dual homed e.164s wouldn't work. > > That doesn't mean we couldn't make them work in ENUM/SIP land, just that > the > current state of the PSTN, and the ENUM deployments, doesn't allow the > possibility, AFAIK. > > Brian > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 08:28:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4158D3A6F43; Fri, 11 Apr 2008 08:28:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7655A3A6F37 for ; Fri, 11 Apr 2008 08:28:27 -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.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 wslgn9WF4U+S for ; Fri, 11 Apr 2008 08:28:26 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 968063A6F36 for ; Fri, 11 Apr 2008 08:28:26 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA02.westchester.pa.mail.comcast.net with comcast id CAWJ1Z0030SCNGk520PD00; Fri, 11 Apr 2008 15:28:47 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA09.westchester.pa.mail.comcast.net with comcast id CFUb1Z00702AVH03V00000; Fri, 11 Apr 2008 15:28:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=vn2G1FKP0ZZ1juGBOXUA:9 a=17cTPQhLmGcjO4EuuJ8NAJKYmIIA:4 a=YjF5NZnj_jQA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m3BFSYEA002707 for ; Fri, 11 Apr 2008 11:28:34 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m3BFSYY6002702; Fri, 11 Apr 2008 11:28:34 -0400 Date: Fri, 11 Apr 2008 11:28:34 -0400 Message-Id: <200804111528.m3BFSYY6002702@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <18431.27154.648815.968450@taimen.test.fi> (jh@tutpro.com) References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <47FED0B5.2090906@cisco.com> <47FF6704.6020107@cisco.com> <18431.27154.648815.968450@taimen.test.fi> Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: jh@tutpro.com (Juha Heinanen) i think it is mandatory for sip phones to support tel. otherwise it is impossible to for a sip phone in another domain to 302 caller to a pstn number. Well, I don't think it's *mandatory* (RFC 3261, section 7.1): SIP elements MAY support Request-URIs with schemes other than "sip" and "sips", for example the "tel" URI scheme of RFC 2806 [9]. 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 sip-bounces@ietf.org Fri Apr 11 08:32:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D113A6F43; Fri, 11 Apr 2008 08:32:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777433A6E7A for ; Fri, 11 Apr 2008 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.703, 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 yXZ3qrK7lICE for ; Fri, 11 Apr 2008 08:32:11 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 797173A6EA5 for ; Fri, 11 Apr 2008 08:32:11 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JkLEj-0003re-1F; Fri, 11 Apr 2008 10:32:21 -0500 From: "Brian Rosen" To: "'Juha Heinanen'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><091b01c89a73$123ea0f0$c5f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net><00fe01c89b48$8c22ca60$c5f0200a@cisco.com><0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com><18431.30244.255028.222026@taimen.test.fi><0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> <18431.32800.21763.353306@taimen.test.fi> Date: Fri, 11 Apr 2008 11:32:22 -0400 Message-ID: <0ac801c89be9$3e39cdc0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <18431.32800.21763.353306@taimen.test.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acib5qHWSHwVypjhRB29PezFYmCbAgAAXl7w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: sip@ietf.org, "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes, I don't think there is a technical problem. There is a trust issue, which really is the discussion we are having. It actually is possible for any carrier to determine if the carrier handing it a call is the "owner" of the TN, even if they don't do it in practice. You seem to want to break that. Seems like you need to change the actual ownership of the number to the user, and you need a way to establish a chain of trust, in order for things like CallerId to work reliably. Actually, around here, we have the opposite problem. There are certain carriers who in fact do allow spoofing of called party number. It has caused quite a bit of controversy and I expect regulation soon. In your proposals to the regulator, are you asking that ownership of a number clearly be vested in the user, and have you proposed a mechanism for how such ownership would be verified? A properly administered user enum system might do. Brian -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Friday, April 11, 2008 11:14 AM To: Brian Rosen Cc: 'Dan Wing'; 'Elwell, John'; Dale.Worley@comcast.net; sip@ietf.org Subject: RE: [Sip] E.164 - who owns it Brian Rosen writes: > As a practical matter, the way calls are routed, it isn't I believe. Are > you aware of a country that allows it? I'd love to see the routing tables. > You've got a better shot of allowing two carriers to originate a call with > the same e.164. this latter thing is what i have been demanding the regulator in finland to allow. i don't think there are any technical problems in implementing it. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 08:32:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2AD28C25C; Fri, 11 Apr 2008 08:32:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11CA28C25C for ; Fri, 11 Apr 2008 08:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 qOTWtiYgWBjy for ; Fri, 11 Apr 2008 08:32:20 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 5FF993A6E7A for ; Fri, 11 Apr 2008 08:32:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id D19641EC290; Fri, 11 Apr 2008 18:32:39 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiZmEtOnFuoh; Fri, 11 Apr 2008 18:32:32 +0300 (EEST) Received: from taimen (h147209.gprs.dnafinland.fi [87.93.147.209]) by tutpro.com (Postfix) with ESMTP; Fri, 11 Apr 2008 18:32:32 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id C6DE9AC0E4; Fri, 11 Apr 2008 18:32:28 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18431.33932.779878.941153@taimen.test.fi> Date: Fri, 11 Apr 2008 18:32:28 +0300 To: Dale.Worley@comcast.net In-Reply-To: <200804111528.m3BFSYY6002702@dragon.ariadne.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <47FED0B5.2090906@cisco.com> <47FF6704.6020107@cisco.com> <18431.27154.648815.968450@taimen.test.fi> <200804111528.m3BFSYY6002702@dragon.ariadne.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net writes: > i think it is mandatory for sip phones to support tel. otherwise it is > impossible to for a sip phone in another domain to 302 caller to a pstn > number. > > Well, I don't think it's *mandatory* (RFC 3261, section 7.1): > > SIP elements MAY support Request-URIs with schemes other than > "sip" and "sips", for example the "tel" URI scheme of RFC > 2806 [9]. i didn't mean mandatory in rfc 3261 sense, but mandatory in practice. or do you have any other suggestion how i can 302 someone to my pstn number? -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 08:41:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F473A6E8F; Fri, 11 Apr 2008 08:41:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94FF3A6E8F for ; Fri, 11 Apr 2008 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.697, 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 2QsCt3U+INwD for ; Fri, 11 Apr 2008 08:41:15 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 10D903A6E32 for ; Fri, 11 Apr 2008 08:41:15 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JkLNQ-0005R2-Vh; Fri, 11 Apr 2008 10:41:21 -0500 From: "Brian Rosen" To: "'Hadriel Kaplan'" , "'Juha Heinanen'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><091b01c89a73$123ea0f0$c5f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net><00fe01c89b48$8c22ca60$c5f0200a@cisco.com><0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com><18431.30244.255028.222026@taimen.test.fi> <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> Date: Fri, 11 Apr 2008 11:41:22 -0400 Message-ID: <0ad201c89bea$8012fe00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acib4LAhpMxjFJxbRGWYlVjjqKhYKgAA2XrgAACJ6DAAAMJ+sA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: sip@ietf.org, "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Nope. I mean you can't have two calls with the same e.164 that are originated from or terminated to different carriers. Let's say you have two carriers who serve you. Doesn't matter how they serve you or where they pick up or deliver calls. Only one of them will (should) accept a call with a particular e.164. Only one of them can deliver you a call with a particular e.164. The one carrier associated with an e.164 can deliver it to any point, or even multiple points in a subscriber network. There can be multiple physical or logical paths, but the call will be originated from or terminated to one carrier. If you have two carriers, you have two distinct sets of e.164s that they handle. Brian -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, April 11, 2008 11:25 AM To: Brian Rosen; 'Juha Heinanen' Cc: sip@ietf.org; 'Elwell, John'; 'Dan Wing' Subject: RE: [Sip] E.164 - who owns it I'm not quite sure how you mean "dual-homed E.164". In IP, I think of dual-homed as simply being reachable through multiple interfaces (for a dual-homed host), or multiple BGP exit/entry points for a common prefix (for a dual-homed end network). If you're implying there is only one physical or logical path to reach a given E.164, well, you'd be wrong. :) From a SIP perspective, I think there are also in fact multiple origination and termination points for the same E.164, because I consider the PSTN/H.323/whatever to be "the end" from a SIP perspective. In other words if in SIP-land I can send a SIP Invite to one of multiple next-domains, each of which would ingress it into the PSTN, I consider them each distinct SIP termination points. But I'm not sure you mean it that way? -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, April 11, 2008 11:07 AM > To: 'Juha Heinanen' > Cc: sip@ietf.org; 'Elwell, John'; 'Dan Wing' > Subject: Re: [Sip] E.164 - who owns it > > In theory, as with any PSTN regulation, it could be. > > As a practical matter, the way calls are routed, it isn't I believe. Are > you aware of a country that allows it? I'd love to see the routing > tables. > You've got a better shot of allowing two carriers to originate a call with > the same e.164. There is no error checking, or reverse routability checks > in the SS7 network. However, usually carriers frown on spoofing of called > party number. > > In all the work I've seen on numbering, including all the latest ENUM > deployments, dual homed e.164s wouldn't work. > > That doesn't mean we couldn't make them work in ENUM/SIP land, just that > the > current state of the PSTN, and the ENUM deployments, doesn't allow the > possibility, AFAIK. > > Brian > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 08:41:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5B13A6A51; Fri, 11 Apr 2008 08:41:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060AE3A6A51 for ; Fri, 11 Apr 2008 08:41:40 -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 U8T2VMLaxIUc for ; Fri, 11 Apr 2008 08:41:39 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 1896D3A68FF for ; Fri, 11 Apr 2008 08:41:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 222631EC290; Fri, 11 Apr 2008 18:42:02 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XjDA06+xFur; Fri, 11 Apr 2008 18:41:55 +0300 (EEST) Received: from taimen (h147209.gprs.dnafinland.fi [87.93.147.209]) by tutpro.com (Postfix) with ESMTP; Fri, 11 Apr 2008 18:41:55 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 27F4BAC0E4; Fri, 11 Apr 2008 18:41:50 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18431.34495.117978.244937@taimen.test.fi> Date: Fri, 11 Apr 2008 18:41:51 +0300 To: "Brian Rosen" In-Reply-To: <0ac801c89be9$3e39cdc0$640fa8c0@cis.neustar.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <091b01c89a73$123ea0f0$c5f0200a@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net> <00fe01c89b48$8c22ca60$c5f0200a@cisco.com> <0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com> <18431.30244.255028.222026@taimen.test.fi> <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> <18431.32800.21763.353306@taimen.test.fi> <0ac801c89be9$3e39cdc0$640fa8c0@cis.neustar.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: sip@ietf.org, "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Brian Rosen writes: > Yes, I don't think there is a technical problem. There is a trust issue, > which really is the discussion we are having. It actually is possible for > any carrier to determine if the carrier handing it a call is the "owner" of > the TN, even if they don't do it in practice. You seem to want to break > that. not at all. what i have suggested is that the number database that already exists in finland that tells which carrier currently "owns" any single number should support more than one carrier for a number. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 10:25:35 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5443A6E01; Fri, 11 Apr 2008 10:25:35 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B963A6BB6 for ; Fri, 11 Apr 2008 10:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 3V+G0eEGeN-E for ; Fri, 11 Apr 2008 10:25:33 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id E93593A67D4 for ; Fri, 11 Apr 2008 10:25:32 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.236]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JZ600J568F28C@siemenscomms.co.uk> for sip@ietf.org; Fri, 11 Apr 2008 18:25:51 +0100 (BST) Date: Fri, 11 Apr 2008 17:15:28 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF160F504E@zrc2hxm0.corp.nortel.com> To: Francois Audet , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D09AC971@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcibNVirfScPJoBPSXmPGUg6EaQU5wAAP1jAACz7iPA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <47F5EBDE.3070907@gmx.net> <0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <136d01c89b2c$b9fc5fd0$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4E5D@zrc2hxm0.corp.nortel.com> <47FE4C30.1080309@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4EBD@zrc2hxm0.corp.nortel.com> <"1ECE0E B50388174790F9694F77522CCF160F504E"@zrc2hxm0.corp.nortel.com> Cc: sip@ietf.org, Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois, Did you mean "appropriate" or "inappropriate" below? Up until that message, I liked what Francois and Paul have been saying concerning using just publishing TEL and email-style SIP URIs. It seems that E.164-based SIP URIs will still be used as aliases for email style, essentially because when somebody dials a telephone number, ENUM look-up on the TEL URI will yield an E.164-based SIP URI, and onward routing will be on that basis. But that is no reason for publishing an E.164-based SIP URI on your web site or business card. Also for many purposes the email-style should be sufficient in From, although it might cause a problem when delivered to a PSTN gateway or a device that can only display a telephone number. We can, however, also deliver a TEL URI in P-Asserted-Identity, which would solve that problem. In this way, RFC 4474 (or whatever we end up with to get around the problem of SBCs altering SDP) will never need to sign an E.164-based URI. A PSTN gateway would put an email-style SIP URI in From, identifying the gateway rather than the party on the PSTN, and the RFC 4474 signature will be sufficient for DTLS-SRTP purposes (since DTLS-SRTP is only as far as the gateway). John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: 10 April 2008 19:13 > To: Paul Kyzivat > Cc: sip@ietf.org; Dan Wing > Subject: Re: [Sip] E.164 - who owns it > > Yeah, I'd say putting sip:+14084952456@nortel.com;user=phone in From > (or anything "on-the-wire") is very appropriate. > > I don't think we are disagreeing actually. > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, April 10, 2008 11:05 > > To: Audet, Francois (SC100:3055) > > Cc: Dan Wing; sip@ietf.org; Juha Heinanen > > Subject: Re: [Sip] E.164 - who owns it > > > > > > > > Francois Audet wrote: > > > > > >>> Agreed. > > >>> > > >>> Cutting to the chase, I'd put the following on my business card: > > >>> > > >>> tel: +1-408-495-2456 > > >>> sip:audet@nortel.com > > >>> mailto:audet@nortel.com > > >> Interestingly, that doesn't indicate that you are > > reachable via sip > > >> using the numeric address. > > > > > > Yes, I did that on purpose. I don't see a point in doing it. > > > > > >> A sip caller given the tel might figure that out, but > > might not. If > > >> you had user enum, and the caller used it, then all is > > well. But if > > >> not, and if the caller just blasts the tel uri to his SP, it may > > >> figure it out, and may not. > > >> > > >> You are going to ask why the caller would use the tel > form in that > > >> case. > > >> One reason would be because the UI of the device only supports > > >> numeric input. > > > > > > So, a SIP user (or anybody young enough to prefer IM > > paradigm to phone > > > paradigm) will use sip:audet@nortel.com. > > > > > > The old luddites with a PSTN-looking phone will keep on > > dialing digits > > > on their phone. That's where the Tel URI is useful. > > > > > > The niche market for > sip:+14084952456@nortel.com;user=phone is very > > > small. Beyond people on this mailing list, I really don't see who > > > would care. I really believe that practically speaking, > > > sip:+14084952456@nortel.com;user=phone > > > is meant to be used "on-the wire" as opposed to by users. > > > > > > sip:audet@nortel.com ~= http://www.att.com > > > sip:+14084952456@nortel.com;user=phone ~= > > > http://www.att.com/gen/landing-pages?pid=3308 > > > > > > I think we are rat-holing on imaginary issues. > > > > Perhaps. The above is a bit esoteric. A more realisic issue > > is what to put in From, where at the moment you can't put > > multiple choices. So I have to choose whether to cater to the > > luddites or the young. (I'm not young, but I don't think I'm > > *quite* a luddite. Just saddled with a lot of legacy stuff I > > don't have the option of changing or am too cheap to change. > > (I *am* cheap.)) > > > > At least with P-A-I you can put both a sip and a tel. The > > alternative being explored on this list of including both in > > normal sip signaling would solve that. > > > > 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 sip-bounces@ietf.org Fri Apr 11 11:57:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B0C3A6C84; Fri, 11 Apr 2008 11:57:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712833A6BFA for ; Fri, 11 Apr 2008 11:57:26 -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.037, BAYES_00=-2.599, 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 tgS1BiWELCVO for ; Fri, 11 Apr 2008 11:57:25 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 9D1133A6C84 for ; Fri, 11 Apr 2008 11:57:25 -0700 (PDT) Received: from [172.16.3.228] ([172.16.3.228]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m3BIuQLV081123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2008 13:56:28 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> From: Ben Campbell To: Michael Thomas In-Reply-To: <47FCF4A2.9080907@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 11 Apr 2008 13:56:25 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, "Elwell, John" , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 9, 2008, at 11:53 AM, Michael Thomas wrote: >> RFC 4474 is a cross-domain authenticator. >> >> Use case: >> >> sip:JoeBob@example.com calls his voice mail provider's message >> retrieval box, sip:messages.example.net >> >> Since example.net trusts example.com's RFC 4474 assertions, the >> voicemail box at messages.example.net does not authenticate JoeBobs' >> request. Instead, it accepts on trust that example.com authenticated >> him, and plays out JoeBob's messages. >> >> This is AFAIK a valid use case for RFC 4474. >> > > It's a _valid_ use case, but is it a _real_ use case? That is, is > there > anybody out there using cross realm credentials in that way? Even > cellular isn't handled in that way because my sim is still with my > home provider even if I've roamed... They don't now (or at least should not) because they don't have the tools for it. But if we give people a tool that appears to work for this purpose, we should expect them to use it for this purpose. ( I am curious what existing PSTN voice mail systems would do if someone else called my voicemail and spoofed my caller ID). Ben. _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 17:44:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3EBA3A67DF; Fri, 11 Apr 2008 17:44:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DA63A67DF for ; Fri, 11 Apr 2008 17:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.758, 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 a3jurziwzrQJ for ; Fri, 11 Apr 2008 17:44: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 555743A677E for ; Fri, 11 Apr 2008 17:44:43 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2008 17:45:07 -0700 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 m3C0j7SN004378; Fri, 11 Apr 2008 17:45:07 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3C0j7ra008030; Sat, 12 Apr 2008 00:45:07 GMT From: "Dan Wing" To: "'Ben Campbell'" , "'Michael Thomas'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com><73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com><47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> Date: Fri, 11 Apr 2008 17:45:07 -0700 Message-ID: <020b01c89c36$748fb040$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> Thread-Index: AcicBf38DJGgL7iYRCCtiwxZnykolQAMF33Q DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=279; t=1207961107; x=1208825107; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=pKxWzfvGKQ5gw3VZluPUcHwUTF3ew/WaRG/zFb1vuDE=; b=q+hPJXdgGKNF/QhF1eM54AeSShcJhHDbZLuPW7kbtbWNM3E0ReFGVk8mJi s0mPIKvwtE2Bzkvf59bRjd6XUIZvq9GvXgqJHebDLEZYaGTElL3kCcwiAffZ HrzXW+EzoY; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, "'Elwell, John'" , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > ( I am curious what existing PSTN voice mail systems would do if > someone else called my voicemail and spoofed my caller ID). When you call your voicemail system, if it asks for a PIN, that is what someone spoofing your caller ID will get prompted with, too. -d _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 20:50:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8AD28C111; Fri, 11 Apr 2008 20:50:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD1328C115 for ; Fri, 11 Apr 2008 20:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, 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 fgQiM3evg+a7 for ; Fri, 11 Apr 2008 20:50:48 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 63EA028C10A for ; Fri, 11 Apr 2008 20:50:48 -0700 (PDT) Received: from [10.0.1.196] (adsl-68-94-38-113.dsl.rcsntx.swbell.net [68.94.38.113]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m3C3mO51052614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2008 22:48:28 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <211EA465-AE14-4517-9174-14CC9125F950@estacado.net> From: Ben Campbell To: "Dan Wing" In-Reply-To: <020b01c89c36$748fb040$c5f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 11 Apr 2008 22:48:22 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com><73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com><47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> <020b01c89c36$748fb040$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, 'Michael Thomas' , "'Elwell, John'" , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 11, 2008, at 7:45 PM, Dan Wing wrote: > >> ( I am curious what existing PSTN voice mail systems would do if >> someone else called my voicemail and spoofed my caller ID). > > When you call your voicemail system, if it asks for a PIN, that > is what someone spoofing your caller ID will get prompted with, too. Many VM systems don't (or are commonly configured not to) even ask for a PIN if they think the caller is the mailbox owner. > > > -d > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 21:01:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AABE3A698E; Fri, 11 Apr 2008 21:01:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3003A698E for ; Fri, 11 Apr 2008 21:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=0.730, 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 6xvPDBcifQ5I for ; Fri, 11 Apr 2008 21:01: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 3E5443A6904 for ; Fri, 11 Apr 2008 21:01:43 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2008 21:02:08 -0700 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 m3C428ir004804; Fri, 11 Apr 2008 21:02:08 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3C427Zh024906; Sat, 12 Apr 2008 04:02:07 GMT From: "Dan Wing" To: "'Ben Campbell'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com><73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com><47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> <020b01c89c36$748fb040$c5f0200a@cisco.com> <211EA465-AE14-4517-9174-14CC9125F950@estacado.net> Date: Fri, 11 Apr 2008 21:02:07 -0700 Message-ID: <024a01c89c51$f9f9c980$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <211EA465-AE14-4517-9174-14CC9125F950@estacado.net> Thread-Index: AcicUEbYwcJSpLikTNqU9E9uFsEfNwAAZC0w DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=565; t=1207972928; x=1208836928; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=TGaSE7QGTLKsdwubnMLzXJSMRbcprRjYKmcaSKFk1Qg=; b=ckIRdUdo6wsNyP/06TeG1K8sBGMdDs40ULbe5iHOqIlIkwdNfTyWQJ1VUq fcChfBf/826/AmDuK3pr89f5PxB1xpJf+lqDMIC/DlBW59g3JgvqeophJ9m8 ZR985g0ejyXZofIVVfh0sWItKy36Et5u4higiPD2guOu1q1stN34I=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, 'Michael Thomas' , "'Elwell, John'" , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > >> ( I am curious what existing PSTN voice mail systems would do if > >> someone else called my voicemail and spoofed my caller ID). > > > > When you call your voicemail system, if it asks for a PIN, that > > is what someone spoofing your caller ID will get prompted with, too. > > Many VM systems don't (or are commonly configured not to) > even ask for a PIN if they think the caller is the mailbox owner. Well, then you're hosed. What is your voicemail number again? I was looking for it a few minutes ago, but I must have misplaced it. -d _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 11 21:07:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0B53A6C10; Fri, 11 Apr 2008 21:07:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D36A3A6AA4 for ; Fri, 11 Apr 2008 21:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[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 E1BHQLHfcWDM for ; Fri, 11 Apr 2008 21:07:25 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 153703A6BD4 for ; Fri, 11 Apr 2008 21:07:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3C47JF08664; Sat, 12 Apr 2008 04:07:20 GMT Received: from 47.102.169.48 ([47.102.169.48]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Sat, 12 Apr 2008 04:06:50 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Fri, 11 Apr 2008 21:06:49 -0700 From: "Francois Audet" To: Dan Wing , "'Ben Campbell'" Message-ID: Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AcicUEbYwcJSpLikTNqU9E9uFsEfNwAAZC0wAAAyeUw= In-Reply-To: <024a01c89c51$f9f9c980$c5f0200a@cisco.com> Mime-version: 1.0 Cc: SIP IETF , 'Michael Thomas' , John ELWELL , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org You are correct. People are overestimating the security in PSTN. On Apr11 2008 21:02 , "Dan Wing" wrote: >>>> ( I am curious what existing PSTN voice mail systems would do if >>>> someone else called my voicemail and spoofed my caller ID). >>> >>> When you call your voicemail system, if it asks for a PIN, that >>> is what someone spoofing your caller ID will get prompted with, too. >> >> Many VM systems don't (or are commonly configured not to) >> even ask for a PIN if they think the caller is the mailbox owner. > > Well, then you're hosed. What is your voicemail number again? I > was looking for it a few minutes ago, but I must have misplaced it. > > -d > > _______________________________________________ > 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 sip-bounces@ietf.org Sat Apr 12 01:26:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696EC3A6A5D; Sat, 12 Apr 2008 01:26:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11943A6805 for ; Sat, 12 Apr 2008 01:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 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 PcTn7XPe7Caz for ; Sat, 12 Apr 2008 01:26:08 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E3CA13A6956 for ; Sat, 12 Apr 2008 01:26:07 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3C8QQsd017922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Apr 2008 03:26:27 -0500 Message-Id: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> From: Dean Willis To: "sip@ietf.org List" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 03:26:20 -0500 X-Mailer: Apple Mail (2.919.2) Cc: Cullen Jennings , Jon Peterson Subject: [Sip] Proposal to Revise RFC 4474 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We've had a lot of recent discussions about issues relating to the use of RFC 4474, and I've had a bunch of side conversations with people this week on the same topic. Here's where I think we're at: RFC 4474 is pretty good. Since it was published, we've learned more about the problem space. In the largest part, we've learned that the authors of RFC 4474 and the working group did an excellent job of analyzing the fundamental requirements for attaching forward authentication (as opposed to challenge-response) to SIP. We've also learned that the real world has some nastiness that isn't quite covered by RFC 4474, but it appears that very small adjustments to the specification could cover most or all of the cases we've discovered. I'd therefore like to propose that the working group consider the task of narrowly revising RFC 4474 to account for four specific points: 1) Revising the "what gets signed" aspect to allow modification of the SDP by the SBCs we seem to keep encountering. While it is important to verify the SDP, we now have the DTLS-SRTP framework to vouch for the authenticity of the media channel. I suggest that there not be any optionality to "what gets signed", but that the fixed set of items be revised so as to allow SBC operations, and to note the dependency on DTLS-SRTP for media authentication. 2) RFC 4474 did not consider the requirements of calls transiting gateways and the issues related to expressing identities that originate outside the Internet, specifically phone numbers delivered via caller ID. While RFC 4474 can say nothing authoritative about the phone number, it seems that it could quite reasonably say something authoritative about the gateway. We've seen several proposals for doing this using conventions for the expression of "phone" identities in the From header field. I believe that a revised RFC 4474 is the place to document such a convention and any needed extension parameters. 3) There seems to be a valid model for what I call "stacked" Identity header fields that express transitive assertions. Consider authentication domains A, B, and C, where B is a transit domain between A and C. B would be likely to trust assertions made by A, and might not know whether C is or is not equipped to evaluate assertions made by A. However,, it might be reasonable to expect that C would be able to validate assertions made by B. B might therefore choose to validate the Identity header inserted by A, and then (assuming the header authenticates) add another Identity header using its own credentials, saying in effect "B validated A's identity header and found it good". If C can validate A's Identity header directly, it would do so. If not, it could choose to rely on B's assertion. 4) There are cases, including authentication services in the UAS and authentication services in a proxy having an "outbound" relationship (pre-authenticated persistent TLS) with the UAS where, in the absence of retargeting, an Identity header field could reasonably be included in a response as an alternative to using the more cumbersome connected- identity approach with UPDATE. I expect this to be very useful in P2PSIP, but it has broader utility. So I would like to see RFC 4474 extended to allow its use in responses where it would work. -- 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 sip-bounces@ietf.org Sat Apr 12 01:59:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4F03A6CEF; Sat, 12 Apr 2008 01:59:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F6E28C112 for ; Sat, 12 Apr 2008 01:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_45=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 CP+9zbOg0YCm for ; Sat, 12 Apr 2008 01:59:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E6F893A6CF9 for ; Sat, 12 Apr 2008 01:59:50 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3C90Egt018074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 12 Apr 2008 04:00:15 -0500 Message-Id: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> From: Dean Willis To: "sip@ietf.org List" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 04:00:09 -0500 X-Mailer: Apple Mail (2.919.2) Subject: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We've realized we have a specification mutual exclusion. RFC 4474 as written precludes the insertion of an Identity header by an authentication service into a SIP message produced by a PSTN gateway. However, DTLS-SRTP as written needs such an Identity header in order to be able to verify that the media key fingerprint has not been altered by a MITM who is also attacking on the media path. We've heard a bunch of suggestions, and so far I think the best has been to adopt a convention (and possibly a new extension) for encoding the From: header field in messages coming from gateways, along with a convention for interpreting Identity headers on those messages as "asserting the identity of the gateway", instead of "asserting the telephone number". Someone suggested the idea of using a "user=phone" parameter as this indicator. I initially dismissed the idea. However, after reading Paul's recent analysis of what user=phone means (from his view, nothing), and in light of my counterexample (that the user=phone modifier can influence routing) I've reconsidered my earlier dismissal of the idea. RFC 3261 Section 19.1.1 says: The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it If we made it mandatory for a PSTN gateway to assert identities using user=phone and documented that Identity headers over an identity with a user=phone parameter do not assert the "user part" of that identity, then I think we'd have a complete solution. Corollary , we need to document that a "phone" UAS that is attached to the Internet does NOT use "user=phone" even if its user ID is a phone number and the ENUM entry for that phone number happens to point at this user ID at this UAS (or supporting domain). In other words, we'd be changing the above text to say that the user=phone does NOT distinguish between phone numbers and user names, but that it distinguishes between phone numbers on the PSTN and SIP phone numbers or user IDs. Let me restate: user=phone applies only to things that transit a PSTN gateway. So for example if Alice at +12142821376 were to call Bob at +19725199190 (and where +19725199190 terminated on a gateway in domain example.com), we might see that gateway generate an INVITE like: INVITE tel:+19725199190 SIP/2.0 From: sip:+12142821376@example.com;user=phone To: tel:+19725199190 ... The authentication service at example.com could then reasonably insert an Identity header field. Receivers of this INVITE would know that the "user=phone" modifier implies that the Identity header asserts nothing whatsoever about the user part (+12142821376) of the request, and that the Identity header proves only that the request came from a gateway authenticated by example.com. Alternatively the INVITE and TO might be populate with sip:+19725199190@example.com;user=phone , but I think it cleaner to document tel: Also alternatively, the From: might be sip:+12142821376@gateway.example.com;user=phone Note that with this approach "tel:" does not mean "on the PSTN", rather it means "in the namespace of E.164", which is an entirely different thing. It is perfectly legitimate to use tel: URIs to refer to devices that are entirely on the Internet. In fact, this might be the model used if one enum device were to call another using an E.164 number. -- 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 sip-bounces@ietf.org Sat Apr 12 02:04:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A8E3A6CE5; Sat, 12 Apr 2008 02:04:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C623A6CE5 for ; Sat, 12 Apr 2008 02:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 LeHw1Jr7jloi for ; Sat, 12 Apr 2008 02:04:43 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0255F3A69CF for ; Sat, 12 Apr 2008 02:04:42 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3C954pv018086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Apr 2008 04:05:06 -0500 Message-Id: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> From: Dean Willis To: Juha Heinanen In-Reply-To: <18431.27154.648815.968450@taimen.test.fi> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 04:04:59 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <47FED0B5.2090906@cisco.com> <47FF6704.6020107@cisco.co! m> <18431.27154.648815.968450@taimen.test.fi> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org" , Paul Kyzivat , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 11, 2008, at 8:39 AM, Juha Heinanen wrote: > Paul Kyzivat writes: > >> (Except of course that may introduce interop problems with devices >> that >> don't support tel. But those will be fixed by SBCs :-) > > i think it is mandatory for sip phones to support tel. otherwise it > is > impossible to for a sip phone in another domain to 302 caller to a > pstn > number. > I too think tel: support is critical. To refine the above, without tel: it is generally impossible to 302 a caller to a PSTN node without also specifying a route for reaching that node. If one were to redirect to sip:number@domain;user=phone, one might still reach the correct telephone, but one would be constrained to do so by using the resources at the specified domain, which might or might not present an authorization problem. The only way we have to redirect a caller to a PST node that is to be reached by the caller's best available means is to use a tel: URI. -- 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 sip-bounces@ietf.org Sat Apr 12 02:06:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3A73A6CD0; Sat, 12 Apr 2008 02:06:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD4F3A6CC2 for ; Sat, 12 Apr 2008 02:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 UqopfcMz46Av for ; Sat, 12 Apr 2008 02:06:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 39DCD3A6A89 for ; Sat, 12 Apr 2008 02:06:52 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3C978c3018096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Apr 2008 04:07:10 -0500 Message-Id: <95F6D6C1-11B9-4063-8030-500B033B59DC@softarmor.com> From: Dean Willis To: Brian Rosen In-Reply-To: <0ad201c89bea$8012fe00$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 04:07:02 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><091b01c89a73$123ea0f0$c5f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net><00fe01c89b48$8c22ca60$c5f0200a@cisco.com><0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com><18431.30244.255028.222026@taimen.test.fi> <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> <0ad201c89bea$8012fe00$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 11, 2008, at 10:41 AM, Brian Rosen wrote: > > I mean you can't have two calls with the same e.164 that are > originated from > or terminated to different carriers. > 911? -- 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 sip-bounces@ietf.org Sat Apr 12 02:17:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F9F3A698E; Sat, 12 Apr 2008 02:17:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90463A6CEF for ; Sat, 12 Apr 2008 02:17:20 -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 d9pTolijmnKx for ; Sat, 12 Apr 2008 02:17:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5774E3A68A5 for ; Sat, 12 Apr 2008 02:17:14 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3C9H0k8018161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Apr 2008 04:17:01 -0500 Message-Id: From: Dean Willis To: Ben Campbell In-Reply-To: <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 04:16:55 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, Michael Thomas , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 11, 2008, at 1:56 PM, Ben Campbell wrote: > > > ( I am curious what existing PSTN voice mail systems would do if > someone else called my voicemail and spoofed my caller ID). > Until several years ago, US voice mail systems were typically set up to not require PIN number entry when the caller ID matched the voice mail account. http://www.geek.com/t-mobile-and-verizon-voicemail-open-to-caller-id-spoofing/ After a couple of high profile message compromise cases (if I remember right, somebody used a caller-ID spoof to retrieve Paris Hilton's voice mail, or maybe it was some other celeb's voicemail after Paris lost her Sidekick and the phone book was compromised), most of the providers reset the defaults to require PIN entry. http://www.engadget.com/2005/02/20/paris-hiltons-hacked-sidekick-releases-unedited-tell-all/ http://www.computerworld.com/securitytopics/security/hacking/story/0,10801,99934,00.html I think at least one carrier has gotten a workaround in place to user caller-ID as an authenticator, but only when the call is originating from a mobile in their network and they've handled the GSM authentication themselves. -- 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 sip-bounces@ietf.org Sat Apr 12 05:00:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AFB63A6D63; Sat, 12 Apr 2008 05:00:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C1A28C1FF for ; Sat, 12 Apr 2008 05:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, 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 DsgQc+XKDvKL for ; Sat, 12 Apr 2008 05:00:26 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 145B03A6CE7 for ; Sat, 12 Apr 2008 05:00:02 -0700 (PDT) Received: from [10.0.1.196] (adsl-68-94-38-113.dsl.rcsntx.swbell.net [68.94.38.113]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m3CBx4Xh008699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 12 Apr 2008 06:59:09 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <8947F25F-7562-4BF6-A3D8-3320B13958AC@estacado.net> From: Ben Campbell To: Dean Willis In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 06:59:04 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, Michael Thomas , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 12, 2008, at 4:16 AM, Dean Willis wrote: > > I think at least one carrier has gotten a workaround in place to > user caller-ID as an authenticator, but only when the call is > originating from a mobile in their network and they've handled the > GSM authentication themselves. So to bring the conversation back to something vaguely relevant-- they've stopped trusting CallerID for interdomain (or intercarrier at least) authentication. _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 05:09:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897F828C1A5; Sat, 12 Apr 2008 05:09:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D6228C191 for ; Sat, 12 Apr 2008 05:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, 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 plz6TaQhvxvg for ; Sat, 12 Apr 2008 05:09:40 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 0F95B28C1F7 for ; Sat, 12 Apr 2008 05:09:39 -0700 (PDT) Received: from [10.0.1.196] (adsl-68-94-38-113.dsl.rcsntx.swbell.net [68.94.38.113]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m3CC8ida009776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 12 Apr 2008 07:08:48 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <1BDC23D0-CC46-4CAB-8BBC-BFCC8E95B064@estacado.net> From: Ben Campbell To: Dean Willis In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 07:08:44 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, Michael Thomas , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 12, 2008, at 4:16 AM, Dean Willis wrote: > I think at least one carrier has gotten a workaround in place to > user caller-ID as an authenticator, but only when the call is > originating from a mobile in their network and they've handled the > GSM authentication themselves. Actually, I was contemplating an argument that we should just establish a best current practice that says one should never trust a phone number, even if it includes a 4474 signature, and that we didn't need to put anything in the message to indicate that. But you've just brought up an edge case where someone could really sign a phone number and mean it, that is, if the gateway is controlled by the authenticating carrier, it could have some out of band way of knowing about said authentication. and could in fact trust the callerid with reasonable strength. Therefore, the fact that the From header contains a tel (or user=phone) URL is not sufficient to for the receiver to infer the authentication strength. _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 10:18:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445E828C153; Sat, 12 Apr 2008 10:18:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903D03A6CD4 for ; Sat, 12 Apr 2008 10:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[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 TuJ2X16onfF6 for ; Sat, 12 Apr 2008 10:18:25 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8B8973A6A33 for ; Sat, 12 Apr 2008 10:18:25 -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 m3CHIkE11912; Sat, 12 Apr 2008 17:18:46 GMT Received: from 47.102.169.166 ([47.102.169.166]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Sat, 12 Apr 2008 17:18:30 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sat, 12 Apr 2008 10:18:30 -0700 From: "Francois Audet" To: Dean Willis , Juha Heinanen Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcicwTpAmmkRIltwRXaMmouP/9Y4jg== In-Reply-To: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> Mime-version: 1.0 Cc: SIP IETF , Paul Kyzivat , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Every single endpoint that I've seen does NOT use a Tel URI per se, but rather, a Tel URI embedded in a sip URI as per RFC 3261/19.1.6. Insisting on Tel URI seems kind of out of touch with reality. On Apr12 2008 02:04 , "Dean Willis" wrote: > > On Apr 11, 2008, at 8:39 AM, Juha Heinanen wrote: >> Paul Kyzivat writes: >> >>> (Except of course that may introduce interop problems with devices >>> that >>> don't support tel. But those will be fixed by SBCs :-) >> >> i think it is mandatory for sip phones to support tel. otherwise it >> is >> impossible to for a sip phone in another domain to 302 caller to a >> pstn >> number. >> > > I too think tel: support is critical. > > To refine the above, without tel: it is generally impossible to 302 a > caller to a PSTN node without also specifying a route for reaching > that node. > > If one were to redirect to sip:number@domain;user=phone, one might > still reach the correct telephone, but one would be constrained to do > so by using the resources at the specified domain, which might or > might not present an authorization problem. > > The only way we have to redirect a caller to a PST node that is to be > reached by the caller's best available means is to use a tel: URI. > > -- > 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 sip-bounces@ietf.org Sat Apr 12 10:41:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670673A6BB8; Sat, 12 Apr 2008 10:41:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBC63A6B11 for ; Sat, 12 Apr 2008 10:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 kbIq82QlUZWx for ; Sat, 12 Apr 2008 10:41:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3E8213A6A1E for ; Sat, 12 Apr 2008 10:41:55 -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.240.5; Sat, 12 Apr 2008 13:41:52 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 12 Apr 2008 13:41:52 -0400 From: Hadriel Kaplan To: Francois Audet , Dean Willis , Juha Heinanen Date: Sat, 12 Apr 2008 13:44:42 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcicwTpAmmkRIltwRXaMmouP/9Y4jgAAvxJA Message-ID: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Francois Audet > > Every single endpoint that I've seen does NOT use a Tel URI per se, but > rather, a Tel URI embedded in a sip URI as per RFC 3261/19.1.6. Yeah, same here. And it seems like a lot of servers do too (pbx/app-servers/feature-servers/etc.), or at least their configs/tables seem to be only setup for sip URI's. -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 sip-bounces@ietf.org Sat Apr 12 11:17:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BD73A6878; Sat, 12 Apr 2008 11:17:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E643A6878 for ; Sat, 12 Apr 2008 11:17:57 -0700 (PDT) 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 5NgSKbSZtf43 for ; Sat, 12 Apr 2008 11:17:57 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D898C3A6800 for ; Sat, 12 Apr 2008 11:17:56 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3CIHoTp021456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Apr 2008 13:17:51 -0500 Message-Id: <2580A0CA-5269-4C2E-8672-38BA2E403CE1@softarmor.com> From: Dean Willis To: Ben Campbell In-Reply-To: <8947F25F-7562-4BF6-A3D8-3320B13958AC@estacado.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 13:17:45 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> <8947F25F-7562-4BF6-A3D8-3320B13958AC@estacado.net> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, Michael Thomas , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 12, 2008, at 6:59 AM, Ben Campbell wrote: > > On Apr 12, 2008, at 4:16 AM, Dean Willis wrote: >> >> I think at least one carrier has gotten a workaround in place to >> user caller-ID as an authenticator, but only when the call is >> originating from a mobile in their network and they've handled the >> GSM authentication themselves. > > So to bring the conversation back to something vaguely relevant-- > they've stopped trusting CallerID for interdomain (or intercarrier > at least) authentication. > 1) The SIP Authentication Service described in RFC 4474 is not caller- ID. It is an authentication service -- more or less, the SIP alternative to Kerberos or Radius. One might well envision it as the solution to the problem that the mobile operators have with caller ID as an authenticator, and (should mobile operators use SIP) as the interdomain authentication tool of choice. 2) The problem is still that, since it is considered "string authentication" (not caller ID), RFC 4474 cannot reasonably be used for a call originating on the PSTN. But we require RFC 4474 be used on calls that need integrity protection of their media key for the IP path (which ideally would be all calls traversing IP paths). Consequently, we can not use the full benefits of DTLS-SRTP when the UAC is a PSTN gateway. -- 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 sip-bounces@ietf.org Sat Apr 12 11:24:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D08C3A68A2; Sat, 12 Apr 2008 11:24:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6FF83A68A2 for ; Sat, 12 Apr 2008 11:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_45=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 gA6giVGA8q+3 for ; Sat, 12 Apr 2008 11:23:59 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id F19543A6800 for ; Sat, 12 Apr 2008 11:23:58 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3CINlUv021487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Apr 2008 13:23:48 -0500 Message-Id: <77025894-9EF1-4DFE-A25B-503172E2393F@softarmor.com> From: Dean Willis To: Ben Campbell In-Reply-To: <1BDC23D0-CC46-4CAB-8BBC-BFCC8E95B064@estacado.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 13:23:41 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> <1BDC23D0-CC46-4CAB-8BBC-BFCC8E95B064@estacado.net> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org, Michael Thomas , "Elwell, John" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 12, 2008, at 7:08 AM, Ben Campbell wrote: > > On Apr 12, 2008, at 4:16 AM, Dean Willis wrote: > >> I think at least one carrier has gotten a workaround in place to >> user caller-ID as an authenticator, but only when the call is >> originating from a mobile in their network and they've handled the >> GSM authentication themselves. > > Actually, I was contemplating an argument that we should just > establish a best current practice that says one should never trust a > phone number, even if it includes a 4474 signature, and that we > didn't need to put anything in the message to indicate that. But > you've just brought up an edge case where someone could really sign > a phone number and mean it, that is, if the gateway is controlled by > the authenticating carrier, it could have some out of band way of > knowing about said authentication. and could in fact trust the > callerid with reasonable strength. > > Therefore, the fact that the From header contains a tel (or > user=phone) URL is not sufficient to for the receiver to infer the > authentication strength. > > There's a much less "edge" case. It's entirely reasonable to have a phone identified by a phone number where that phone is attached to an IP network instead of the PSTN. ENUM could then be used to provide routing information to the phone. Such a phone could use strong authentication and encryption. How, based on the From field (or any other information) can we differentiate such a phone from a PSTN gateway, consequently knowing when to trust and when not to trust the user part as signed by RFC 4474? I've proposed in a separate message that "user=phone" be the differentiator -- in short, that PSTN gateways add "user=phone", and that IP attached phones not add it. The problem of course is backward compatibility. There are a few bajillion gateways out there that do not add user=phone. Consequently, were my proposal accepted, RFC 4474 could not be used with those gateways until they are repaired. I'm OK with that restriction. -- 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 sip-bounces@ietf.org Sat Apr 12 11:31:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D0D3A68DE; Sat, 12 Apr 2008 11:31:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6316A3A697A for ; Sat, 12 Apr 2008 11:31: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 ktCeNc-zEjAb for ; Sat, 12 Apr 2008 11:31:10 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 77A033A6800 for ; Sat, 12 Apr 2008 11:31:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id DC2D71EC290; Sat, 12 Apr 2008 21:31:35 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFDZ5X9SWPoV; Sat, 12 Apr 2008 21:31:29 +0300 (EEST) Received: from taimen (h130203.gprs.dnafinland.fi [87.93.130.203]) by tutpro.com (Postfix) with ESMTP; Sat, 12 Apr 2008 21:31:29 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 1141AAC06D; Sat, 12 Apr 2008 21:31:23 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18432.65531.810231.597927@taimen.test.fi> Date: Sat, 12 Apr 2008 21:31:23 +0300 To: "Francois Audet" In-Reply-To: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet writes: > Insisting on Tel URI seems kind of out of touch with reality. then PSTN is out of touch with 302. please tell me, how can i write a sip uri in my phone that redirects the caller in another domain to my cell phone? -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 11:46:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6191D3A69A6; Sat, 12 Apr 2008 11:46:43 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FCB3A69A6 for ; Sat, 12 Apr 2008 11:46:41 -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 0d-mNq2zX-Rh for ; Sat, 12 Apr 2008 11:46:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C88C83A67D7 for ; Sat, 12 Apr 2008 11:46:40 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3CIl3BP021630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Apr 2008 13:47:05 -0500 Message-Id: <8140775A-57B6-4533-9A72-B645BE1FF118@softarmor.com> From: Dean Willis To: Francois Audet In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 13:46:58 -0500 References: X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: [Sip] Restatement of redirect (or refer) to a phone number problem (was Re: E.164 - who owns it) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 12, 2008, at 12:18 PM, Francois Audet wrote: > Every single endpoint that I've seen does NOT use a Tel URI per se, > but > rather, a Tel URI embedded in a sip URI as per RFC 3261/19.1.6. > > Insisting on Tel URI seems kind of out of touch with reality. So they're functionally limited. Explain to me what you would send in a 302 response to redirect the UAS to call a certain phone number on it's own dime. I don't believe we have a way to do this, and I have always believed it to be a critical use case for real integration (and no, today's "telephony over IP" services are not really integrated, which is why Gizmo customers call Vonage customers through multiple PSTN gateways). Here's a use case: Let's say Gizmo and Vonage some day figure out how to peer at a SIP level. Assuming we maintain current billing models: Alice is a Gizmo customer. As such, she pays Gizmo per minute on calls going to the PSTN, but calls to IP destinations (which don't use Gizmo's bandwidth) are not charged to her. Calls coming from the PSTN are also not charged to her. Bob is a Vonage customer. As such, he pays Vonage per minute on calls going to the PSTN, but calls to IP destinations (which don't use Vonage's bandwidth) are not charged to him. Calls coming from the PSTN are also not charged to him. Alice calls Bob. Bob wishes to redirect Alice to call the premium telephone destination 1-900-HELP-DSK. This is an expensive service to Bob, but perhaps he thinks Alice is willing to pay for it or already has a service contract allowing her to call the service for free. If Bob wanted to pay for this call, he would proxy Alice through a Vonage gateway, but provide credentials so that the call is charged back to him. Bob does not wish to pay from his account . But in this case, let us assume that Bob does NOT want to pay for Alice's call to the help desk. The obvious way to do this is for Bob to send a 300 class response, probably a 302. But remember that Bob's system has no knowledge of Alice's PSTN routing model, and outside of a domain name, no knowledge of Gizmo's service at all. So what should go into the 302 as a Contact: header field value? It can't be "sip:+19004357375@vonage.com" or even "sip:+19004357375@vonage.com;user=phone " because Alice presumably doesn't have permission to use Vonage's gateways. Perhaps Bob's system could guess that Gizmo might understand ""sip:+19004357375@gizmo.com " or maybe ""sip:+19004357375@gizmo.com;user=phone" and use this to reach an appropriate gateway. But what if Alice gets better rates by using a local phone line on her FXO port to reach that phone number? What if, unknown to Bob, there's an ENUM entry for +19004357375 that would have allowed Alice to call that number directly over SIP instead of using a gateway at all? Similar (and perhaps less contrived) use cases can be constructed around REFER -- how doe we ask somebody in a different domain to call a PSTN destination? How do you think this should work? The only way I'm aware of that we have to express the desired semantic is to redirect the call to "tel:+19004357375" and let Alice's UA figure out how it wants to get there. -- 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 sip-bounces@ietf.org Sat Apr 12 12:00:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD1428C225; Sat, 12 Apr 2008 12:00:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD2128C21D for ; Sat, 12 Apr 2008 12:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 RFCyX8PTImBy for ; Sat, 12 Apr 2008 12:00:45 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D9A1A28C29B for ; Sat, 12 Apr 2008 12:00: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.240.5; Sat, 12 Apr 2008 15:00:04 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 12 Apr 2008 15:00:02 -0400 From: Hadriel Kaplan To: Juha Heinanen , Francois Audet Date: Sat, 12 Apr 2008 15:02:52 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acicy2V/5qRr2gIaQcKqEBmI9ZpmKwAALhHg Message-ID: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> In-Reply-To: <18432.65531.810231.597927@taimen.test.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Juha > Heinanen > > Francois Audet writes: > > > Insisting on Tel URI seems kind of out of touch with reality. > > then PSTN is out of touch with 302. please tell me, how can i write a > sip uri in my phone that redirects the caller in another domain to my > cell phone? Well a 302 with a tel may work, or may not. Alternatively you could use a sip URI in the 302. For the domain portion of that 302's contact: if you don't know a SIP-PSTN provider which will send it to your cell, then you could try setting it to your provider's domain (if you have one), or the domain which sent the request. And since a 3xx can have multiple contact URIs, you can try all these at the same time, including Tel, but I suggest making the first one the most likely to succeed, because I've been told some devices can't handle multiple contacts either (ya, it's friggin nuts - don't shoot the messenger). It's nasty, but it should work in many cases I think. (though honestly most cases I've seen just set it to sip and their provider's domain and it works... but that could easily be because I mostly only see traces from providers) -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 sip-bounces@ietf.org Sat Apr 12 12:02:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D0128C21E; Sat, 12 Apr 2008 12:02:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383EC28C0E0 for ; Sat, 12 Apr 2008 12:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 GoChBjk9XcRF for ; Sat, 12 Apr 2008 12:02:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0C0B23A68DE for ; Sat, 12 Apr 2008 12:02:46 -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.240.5; Sat, 12 Apr 2008 15:02:43 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 12 Apr 2008 15:02:43 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Dwight, Timothy M (Tim)" Date: Sat, 12 Apr 2008 15:05:33 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acib2jF5blBFT/J6TRy+RTgplo408gA6vqGg Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804082130.m38LUpUO004626@dragon.ariadne.com> <3fa401c899d4$e3ec74a0$c5f0200a@cisco.com> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> <47FEA3E9.7070404@cisco.com> <092B2658AAB56A4D80836399A4C47031042A1E55@ASHEVS002.mcilink.com> <47FF6B6E.7070508@cisco.com> In-Reply-To: <47FF6B6E.7070508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > Kyzivat > [snip] > IMO that is a value of distinguishing tel from sip/user=phone. With sip, > the supplier of the URI determines the routing. With tel, the originator > of the call determines the routing. You're implying the supplier or originator of the URI cares, or has a way to let its user determine this. Afaik, there is no button on phones for "let people call me only through sip" vs. "let people call me however they can". Most vendors assume people want the latter, I suspect. But since most or at least many devices use sip: all the time period, and most proxy/etc. vendors want calls to work because their customers do, they will route it whichever way they can to do so. A second problem is the desired behavior of using the From for later requests. Since UA's register a sip URI typically, and they use this for the From of their requests, the far-end UAS will get that From. Since the UAS would then use this URI for its address book to generate new requests later, by your earlier emails this implies that UAS only wants the request to purely stay sip. That would be ok if the original request stayed sip the entire path to the UAS, and the reverse path sometime later could also stay sip. There are actually cases where that's not going to be true, but let's assume it is for now. So imagine if the original request had a sip From but a tel req-uri. For some reason this request gets routed through the PSTN, back over SIP to the final dest UAS. If the PSTN-SIP gateway uses a tel From we're ok, but if it uses a sip From then per the desired behavior the UAS would use this sip URL in later requests and not be able to use the PSTN or whatever to get it back. That, to me, is why this desired behavior is so brittle. There are just so many times/ways a sip URL in the From or req-uri is used when it ostensibly shouldn't, that operators have little choice but to ignore it to make calls work. I think this may be fixable eventually, but I'm not quite sure how to do that and keep all the semantics you're looking for, without having calls fail in the transition period - which is a non-starter. > It is the desire to ignore the domain name in the sip URI that leads to > your need to have this special, unenforceable, policy on responsibility. > (Well, its enforceable in a legal sense with peering agreements, but > that builds a closed garden.) People don't "desire" to ignore the domain name, they "desire" to make calls work. If all UA's sent using tel URLs when they should per your definition, we probably wouldn't be having this conversation. :) -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 sip-bounces@ietf.org Sat Apr 12 12:12:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3373A6BA2; Sat, 12 Apr 2008 12:12:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C0B3A6B93 for ; Sat, 12 Apr 2008 12:12: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 GpCHL2j7Lguo for ; Sat, 12 Apr 2008 12:12:28 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 5330828C1EA for ; Sat, 12 Apr 2008 12:12:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 08F2A1EC290; Sat, 12 Apr 2008 22:12:53 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6+djTd8cP73; Sat, 12 Apr 2008 22:12:46 +0300 (EEST) Received: from taimen (h130203.gprs.dnafinland.fi [87.93.130.203]) by tutpro.com (Postfix) with ESMTP; Sat, 12 Apr 2008 22:12:46 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 61A82AC06D; Sat, 12 Apr 2008 22:12:41 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18433.2474.365305.28249@taimen.test.fi> Date: Sat, 12 Apr 2008 22:12:42 +0300 To: Hadriel Kaplan In-Reply-To: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan writes: > Alternatively you could > use a sip URI in the 302. For the domain portion of that 302's > contact: if you don't know a SIP-PSTN provider which will send it to > your cell, then you could try setting it to your provider's domain > (if you have one), or the domain which sent the request. where can i find a phone that is clever enough to use the domain of the sender of the request? and how do you tell your phone to do that? -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 12:15:40 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9F43A6ABB; Sat, 12 Apr 2008 12:15:40 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7707D3A6ADC for ; Sat, 12 Apr 2008 12:15:38 -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 DOxI-LHmTTbU for ; Sat, 12 Apr 2008 12:15:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5A4DE3A69B4 for ; Sat, 12 Apr 2008 12:15:37 -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.240.5; Sat, 12 Apr 2008 15:15:34 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 12 Apr 2008 15:15:34 -0400 From: Hadriel Kaplan To: Dean Willis , Francois Audet Date: Sat, 12 Apr 2008 15:18:22 -0400 Thread-Topic: [Sip] Restatement of redirect (or refer) to a phone number problem (was Re: E.164 - who owns it) Thread-Index: AciczZUdLdvFYU3tSEeVW8U9IldriQAA5o0g Message-ID: References: <8140775A-57B6-4533-9A72-B645BE1FF118@softarmor.com> In-Reply-To: <8140775A-57B6-4533-9A72-B645BE1FF118@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] Restatement of redirect (or refer) to a phone number problem (was Re: E.164 - who owns it) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Interesting use case. You could argue though that the same thing could happen for tel, since a proxy along the way can recurse without Alice's consent. (this use case though triggers some memory cells in my brain of something like this being used for a scam in the PSTN, where they got the terminating or originating provider to have to pay a 1-900 for calls they couldn't bill to the human callers, so of course the owners/co-conspirators of the 1-900 called themselves this way and profited... or maybe I'm remembering it wrong) -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Saturday, April 12, 2008 2:47 PM > To: Francois Audet > Cc: SIP IETF; Paul Kyzivat; Dan WING > Subject: [Sip] Restatement of redirect (or refer) to a phone number > problem (was Re: E.164 - who owns it) > > > On Apr 12, 2008, at 12:18 PM, Francois Audet wrote: > > Every single endpoint that I've seen does NOT use a Tel URI per se, > > but > > rather, a Tel URI embedded in a sip URI as per RFC 3261/19.1.6. > > > > Insisting on Tel URI seems kind of out of touch with reality. > > So they're functionally limited. > > Explain to me what you would send in a 302 response to redirect the > UAS to call a certain phone number on it's own dime. > > I don't believe we have a way to do this, and I have always believed > it to be a critical use case for real integration (and no, today's > "telephony over IP" services are not really integrated, which is why > Gizmo customers call Vonage customers through multiple PSTN gateways). > > Here's a use case: > > Let's say Gizmo and Vonage some day figure out how to peer at a SIP > level. > > Assuming we maintain current billing models: > > Alice is a Gizmo customer. As such, she pays Gizmo per minute on calls > going to the PSTN, but calls to IP destinations (which don't use > Gizmo's bandwidth) are not charged to her. Calls coming from the PSTN > are also not charged to her. > > Bob is a Vonage customer. As such, he pays Vonage per minute on calls > going to the PSTN, but calls to IP destinations (which don't use > Vonage's bandwidth) are not charged to him. Calls coming from the PSTN > are also not charged to him. > > Alice calls Bob. Bob wishes to redirect Alice to call the premium > telephone destination 1-900-HELP-DSK. This is an expensive service to > Bob, but perhaps he thinks Alice is willing to pay for it or already > has a service contract allowing her to call the service for free. > > If Bob wanted to pay for this call, he would proxy Alice through a > Vonage gateway, but provide credentials so that the call is charged > back to him. Bob does not wish to pay from his account . But in this > case, let us assume that Bob does NOT want to pay for Alice's call to > the help desk. > > The obvious way to do this is for Bob to send a 300 class response, > probably a 302. But remember that Bob's system has no knowledge of > Alice's PSTN routing model, and outside of a domain name, no knowledge > of Gizmo's service at all. > > So what should go into the 302 as a Contact: header field value? > > It can't be "sip:+19004357375@vonage.com" or even > "sip:+19004357375@vonage.com;user=phone > " because Alice presumably doesn't have permission to use Vonage's > gateways. > > Perhaps Bob's system could guess that Gizmo might understand > ""sip:+19004357375@gizmo.com > " or maybe ""sip:+19004357375@gizmo.com;user=phone" and use this to > reach an appropriate gateway. > > But what if Alice gets better rates by using a local phone line on her > FXO port to reach that phone number? > > What if, unknown to Bob, there's an ENUM entry for +19004357375 that > would have allowed Alice to call that number directly over SIP instead > of using a gateway at all? > > Similar (and perhaps less contrived) use cases can be constructed > around REFER -- how doe we ask somebody in a different domain to call > a PSTN destination? > > How do you think this should work? > > The only way I'm aware of that we have to express the desired semantic > is to redirect the call to "tel:+19004357375" and let Alice's UA > figure out how it wants to get there. > > -- > 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 _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 12:17:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4A928C225; Sat, 12 Apr 2008 12:17:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9656C3A6ABB for ; Sat, 12 Apr 2008 12:17:43 -0700 (PDT) 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 RXGs+ofF+Jsp for ; Sat, 12 Apr 2008 12:17:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B9E8E3A68E2 for ; Sat, 12 Apr 2008 12:17:42 -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.240.5; Sat, 12 Apr 2008 15:17:39 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 12 Apr 2008 15:17:39 -0400 From: Hadriel Kaplan To: Juha Heinanen Date: Sat, 12 Apr 2008 15:20:27 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acic0SUuedzwN/qTSTS/wjMYR36ejwAAOZ2w Message-ID: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> <18433.2474.365305.28249@taimen.test.fi> In-Reply-To: <18433.2474.365305.28249@taimen.test.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Saturday, April 12, 2008 3:13 PM > > Hadriel Kaplan writes: > > > Alternatively you could > > use a sip URI in the 302. For the domain portion of that 302's > > contact: if you don't know a SIP-PSTN provider which will send it to > > your cell, then you could try setting it to your provider's domain > > (if you have one), or the domain which sent the request. > > where can i find a phone that is clever enough to use the domain of the > sender of the request? and how do you tell your phone to do that? :) Open-source phones I assume. Or the SER or Asterisk or whatever could probably be programmed to do it for your phone. -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 sip-bounces@ietf.org Sat Apr 12 12:26:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC063A6C32; Sat, 12 Apr 2008 12:26:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4253A6B37 for ; Sat, 12 Apr 2008 12:26: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.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 hCIC+E67v-4N for ; Sat, 12 Apr 2008 12:26:12 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 05B6A28C274 for ; Sat, 12 Apr 2008 12:26:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 608701EC290; Sat, 12 Apr 2008 22:26:37 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x768drwGrRfD; Sat, 12 Apr 2008 22:26:29 +0300 (EEST) Received: from taimen (h130203.gprs.dnafinland.fi [87.93.130.203]) by tutpro.com (Postfix) with ESMTP; Sat, 12 Apr 2008 22:26:29 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id CAC18AC06D; Sat, 12 Apr 2008 22:26:25 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18433.3297.799014.817465@taimen.test.fi> Date: Sat, 12 Apr 2008 22:26:25 +0300 To: Hadriel Kaplan In-Reply-To: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> <18433.2474.365305.28249@taimen.test.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan writes: > Open-source phones I assume. Or the SER or Asterisk or whatever > could probably be programmed to do it for your phone. haven't seen any. sip is now about 10 years old and even such a basic thing as redirecting a caller to my cell phone is not yet possible. -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 12:30:54 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266FD3A695D; Sat, 12 Apr 2008 12:30:54 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C043A695D for ; Sat, 12 Apr 2008 12:30:52 -0700 (PDT) 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 g4XicN7n0kdn for ; Sat, 12 Apr 2008 12:30:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0BC7E3A68BD for ; Sat, 12 Apr 2008 12:30:52 -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.240.5; Sat, 12 Apr 2008 15:30:49 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 12 Apr 2008 15:30:49 -0400 From: Hadriel Kaplan To: Juha Heinanen Date: Sat, 12 Apr 2008 15:33:39 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acic0xBqe0yEVSHISUahvZ0ueyNP/gAAJaPQ Message-ID: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> <18433.2474.365305.28249@taimen.test.fi> <18433.3297.799014.817465@taimen.test.fi> In-Reply-To: <18433.3297.799014.817465@taimen.test.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Who said it wasn't possible? We're just talking about whether it's done the same way universally in practice. -hadriel > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Saturday, April 12, 2008 3:26 PM > > Hadriel Kaplan writes: > > > Open-source phones I assume. Or the SER or Asterisk or whatever > > could probably be programmed to do it for your phone. > > haven't seen any. sip is now about 10 years old and even such a basic > thing as redirecting a caller to my cell phone is not yet possible. > > -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 13:24:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D513A686E; Sat, 12 Apr 2008 13:24:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2C13A68E2 for ; Sat, 12 Apr 2008 13:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[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 aCAa1UV3xeco for ; Sat, 12 Apr 2008 13:24:54 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 59EDD3A680B for ; Sat, 12 Apr 2008 13:24:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3CKPGi09094; Sat, 12 Apr 2008 20:25:16 GMT Received: from 47.102.168.147 ([47.102.168.147]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Sat, 12 Apr 2008 20:25:16 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sat, 12 Apr 2008 13:25:15 -0700 From: "Francois Audet" To: Juha Heinanen , "Francois Audet" Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acic21D0xDhzanlhTgah0W/1ZWhMig== In-Reply-To: <18432.65531.810231.597927@taimen.test.fi> Mime-version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Every single implementation that I've see does the following: Contact: sip:+19725551212@example.com;user=phone Where example.com is the domain of the forwarding user. The SIP proxy will then route it to a PSTN if appropriate. On Apr12 2008 11:31 , "Juha Heinanen" wrote: > Francois Audet writes: > >> Insisting on Tel URI seems kind of out of touch with reality. > > then PSTN is out of touch with 302. please tell me, how can i write a > sip uri in my phone that redirects the caller in another domain to my > cell phone? > > -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 13:34:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81493A680B; Sat, 12 Apr 2008 13:34:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7F03A6800 for ; Sat, 12 Apr 2008 13:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[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 JZz80dnvOGyf for ; Sat, 12 Apr 2008 13:34:17 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id BD3DD3A680B for ; Sat, 12 Apr 2008 13:34:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3CKYdi09420; Sat, 12 Apr 2008 20:34:40 GMT Received: from 47.102.168.147 ([47.102.168.147]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Sat, 12 Apr 2008 20:34:39 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sat, 12 Apr 2008 13:34:36 -0700 From: "Francois Audet" To: Juha Heinanen , Hadriel Kaplan Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acic3J9VpSkAqDsYRWSV1AAo1sfG/Q== In-Reply-To: <18433.3297.799014.817465@taimen.test.fi> Mime-version: 1.0 Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I do it on my SIP phone all the time. I can put ANY SIP URI I want. If it's a phone number, phone will append the default domain of the phone. The other phone then INVITE the contact. The enterprise proxy looks at the phone number and then decides if it owns it (e.g., it could be another phone number of a phone in the enterprise). If it owns it, it will route the INVITE to that phone. Never goes to PSTN. If it does not own it, it will route to the appropriate PSTN gateway (based on least cost routing for outbound PSTN gateways and such). That's what happens when I forward to my cell phone. The point of this story is that when ;user=phone is used, the routing is based on the phone number. Like it or not, this is what seems to happen. In other words, it's a functional equivalent to a Tel URI. There is a reason why people do it like this. Try sending a Tel URI on the wire and see what happens with most equipment out there. On Apr12 2008 12:26 , "Juha Heinanen" wrote: > Hadriel Kaplan writes: > >> Open-source phones I assume. Or the SER or Asterisk or whatever >> could probably be programmed to do it for your phone. > > haven't seen any. sip is now about 10 years old and even such a basic > thing as redirecting a caller to my cell phone is not yet possible. > > -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 13:40:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5353A6A21; Sat, 12 Apr 2008 13:40:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BA583A68E2 for ; Sat, 12 Apr 2008 13:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 fHltzzreZFZa for ; Sat, 12 Apr 2008 13:40:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4A2F83A6A76 for ; Sat, 12 Apr 2008 13:40: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.240.5; Sat, 12 Apr 2008 16:40:02 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 12 Apr 2008 16:40:02 -0400 From: Hadriel Kaplan To: Francois Audet , Juha Heinanen Date: Sat, 12 Apr 2008 16:42:49 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acic3J9VpSkAqDsYRWSV1AAo1sfG/QAAJWwg Message-ID: References: <18433.3297.799014.817465@taimen.test.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yup, and the same thing happens at service providers too. But I think Juha is referring to how does he redirect such without having a provider/enterprise. -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Saturday, April 12, 2008 4:35 PM > To: Juha Heinanen; Hadriel Kaplan > Cc: Francois Audet; SIP IETF; Paul Kyzivat; Dan WING; Dean Willis > Subject: Re: [Sip] E.164 - who owns it > > I do it on my SIP phone all the time. > > I can put ANY SIP URI I want. > > If it's a phone number, phone will append the default domain of the phone. > > The other phone then INVITE the contact. The enterprise proxy looks at the > phone number and then decides if it owns it (e.g., it could be another > phone > number of a phone in the enterprise). If it owns it, it will route the > INVITE to that phone. Never goes to PSTN. If it does not own it, it will > route to the appropriate PSTN gateway (based on least cost routing for > outbound PSTN gateways and such). That's what happens when I forward to my > cell phone. > > The point of this story is that when ;user=phone is used, the routing is > based on the phone number. Like it or not, this is what seems to happen. > In > other words, it's a functional equivalent to a Tel URI. > > There is a reason why people do it like this. Try sending a Tel URI on the > wire and see what happens with most equipment out there. > > > On Apr12 2008 12:26 , "Juha Heinanen" wrote: > > > Hadriel Kaplan writes: > > > >> Open-source phones I assume. Or the SER or Asterisk or whatever > >> could probably be programmed to do it for your phone. > > > > haven't seen any. sip is now about 10 years old and even such a basic > > thing as redirecting a caller to my cell phone is not yet possible. > > > > -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 20:10:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC853A6B6F; Sat, 12 Apr 2008 20:10:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7C33A6AB9 for ; Sat, 12 Apr 2008 20:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[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 hSv8ss50PV2l for ; Sat, 12 Apr 2008 20:10:50 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 276393A6A33 for ; Sat, 12 Apr 2008 20:10:50 -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 m3D3ATU28023; Sun, 13 Apr 2008 03:10:30 GMT Received: from 47.102.168.154 ([47.102.168.154]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Apr 2008 03:11:11 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sat, 12 Apr 2008 20:11:11 -0700 From: "Francois Audet" To: Hadriel Kaplan , "Francois Audet" , Juha Heinanen Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acic3J9VpSkAqDsYRWSV1AAo1sfG/QAAJWwgAA20Tx4= In-Reply-To: Mime-version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Like p2psip? You still would use the domain name of the overlay, no? On Apr12 2008 13:42 , "Hadriel Kaplan" wrote: > > Yup, and the same thing happens at service providers too. > But I think Juha is referring to how does he redirect such without having a > provider/enterprise. > > -hadriel > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Saturday, April 12, 2008 4:35 PM >> To: Juha Heinanen; Hadriel Kaplan >> Cc: Francois Audet; SIP IETF; Paul Kyzivat; Dan WING; Dean Willis >> Subject: Re: [Sip] E.164 - who owns it >> >> I do it on my SIP phone all the time. >> >> I can put ANY SIP URI I want. >> >> If it's a phone number, phone will append the default domain of the phone. >> >> The other phone then INVITE the contact. The enterprise proxy looks at the >> phone number and then decides if it owns it (e.g., it could be another >> phone >> number of a phone in the enterprise). If it owns it, it will route the >> INVITE to that phone. Never goes to PSTN. If it does not own it, it will >> route to the appropriate PSTN gateway (based on least cost routing for >> outbound PSTN gateways and such). That's what happens when I forward to my >> cell phone. >> >> The point of this story is that when ;user=phone is used, the routing is >> based on the phone number. Like it or not, this is what seems to happen. >> In >> other words, it's a functional equivalent to a Tel URI. >> >> There is a reason why people do it like this. Try sending a Tel URI on the >> wire and see what happens with most equipment out there. >> >> >> On Apr12 2008 12:26 , "Juha Heinanen" wrote: >> >>> Hadriel Kaplan writes: >>> >>>> Open-source phones I assume. Or the SER or Asterisk or whatever >>>> could probably be programmed to do it for your phone. >>> >>> haven't seen any. sip is now about 10 years old and even such a basic >>> thing as redirecting a caller to my cell phone is not yet possible. >>> >>> -- juha > _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 21:02:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34AD23A692F; Sat, 12 Apr 2008 21:02:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747923A692F for ; Sat, 12 Apr 2008 21:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 jhuy7ttv2EAO for ; Sat, 12 Apr 2008 21:02: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 989073A6895 for ; Sat, 12 Apr 2008 21:02:49 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Apr 2008 21:03:17 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3D43GIf010894; Sat, 12 Apr 2008 21:03:16 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3D43GUM004518; Sun, 13 Apr 2008 04:03:16 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); Sun, 13 Apr 2008 00:03:16 -0400 Received: from [10.86.243.19] ([10.86.243.19]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Apr 2008 00:03:15 -0400 Message-ID: <4801861E.4040500@cisco.com> Date: Sun, 13 Apr 2008 00:03:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net><47F5EBDE.3070907@gmx.net><0D5F89FAC29E2C41B98A6A762007F5D0916122@GBNTHT12009MSX.gb002.siemens.net><200804082130.m38LUpUO004626@dragon.ariadne.com><3fa401c899d4$e3ec74a0$c5f0200a@cisco.com><200804090231.m392V1oX026567@dragon.ariadne.com><406b01c899f9$68c470f0$c5f0200a@cisco.com><200804091555.m39FtLa6020989@dragon.ariadne.com><091b01c89a73$123ea0f0$c5f0200a@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D09AC5B6@GBNTHT12009MSX.gb002.siemens.net><00fe01c89b48$8c22ca60$c5f0200a@cisco.com><0ab101c89bdf$df3d54d0$640fa8c0@cis.neustar.com><18431.30244.255028.222026@taimen.test.fi> <0ac401c89be5$be1eba40$640fa8c0@cis.neustar.com> <0ad201c89bea$8012fe00$640fa8c0@cis.neustar.com> <95F6D6C1-11B9-4063-8030-500B033B59DC@softarmor.com> In-Reply-To: <95F6D6C1-11B9-4063-8030-500B033B59DC@softarmor.com> X-OriginalArrivalTime: 13 Apr 2008 04:03:15.0850 (UTC) FILETIME=[4CD0F6A0:01C89D1B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=770; t=1208059396; x=1208923396; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=yhWV6/FRd4s+XafIQxwnS4/M4BbzABEyW5hbJhZAgfg=; b=RdVrMOk1DvGsFOgu7VH1q/9Sc10LCM0khB9qOi0CpDDg/LfzMk+cXpMIer hQ1dzLCMHDepR2vxFJLN0lg/Dje70BaffYAhqiIpjzc+rYS5n6RdHcMeqaM1 XDScWop0jO; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, "'Elwell, John'" , 'Dan Wing' Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Its my understanding that 911 is not an E.164 number. It can't be used in a global TEL uri. If you want to use it in a tel uri you must combine it with a context, such as tel:911;phone-context=+1 Paul Dean Willis wrote: > On Apr 11, 2008, at 10:41 AM, Brian Rosen wrote: >> I mean you can't have two calls with the same e.164 that are >> originated from >> or terminated to different carriers. >> > > 911? > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 21:24:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E821E3A6B03; Sat, 12 Apr 2008 21:24:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F7B3A6B03 for ; Sat, 12 Apr 2008 21:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.257, 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 sa3BIVV8x77e for ; Sat, 12 Apr 2008 21:24:24 -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 C81903A6AFD for ; Sat, 12 Apr 2008 21:24:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,649,1199682000"; d="scan'208";a="4922291" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2008 00:24:50 -0400 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 m3D4Oo7j001733; Sun, 13 Apr 2008 00:24:50 -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 m3D4OodY023406; Sun, 13 Apr 2008 04:24:50 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); Sun, 13 Apr 2008 00:24:50 -0400 Received: from [10.86.243.19] ([10.86.243.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Apr 2008 00:24:49 -0400 Message-ID: <48018B2A.40701@cisco.com> Date: Sun, 13 Apr 2008 00:25:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> In-Reply-To: X-OriginalArrivalTime: 13 Apr 2008 04:24:49.0715 (UTC) FILETIME=[50051830:01C89D1E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1846; t=1208060690; x=1208924690; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=SuDSgmeUhfj1FGmD4dYmVTYBxIrmGs7bUTcPZjoRjTA=; b=isxHZ87nvZBVeiL004bgn1vjjRnWMu27nlNQJtJ7gOJ139hYn1dXaSjS4d tAZOqru7mpCw72mVV4VZzpyN6aZIIS6CXakLzPbun6P8qOfshdZmdCcvc+oh aNzlTi0RLY; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , Francois Audet , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org So you are telling me that you SHOULD forward someone to your own domain to reach a phone number even when you know that your domain would not be willing to route the resulting request from the forwardee. Instead you are *counting* on the forwardee to *ignore* the domain and the 3263 routing rules and instead use its own logic to reach the number??? So in effect you are suggesting that we should revise 3263 regarding sip URIs with user=phone, and get the result widely adopted rather than get tel widely adopted. Paul Hadriel Kaplan wrote: >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Juha >> Heinanen >> >> Francois Audet writes: >> >> > Insisting on Tel URI seems kind of out of touch with reality. >> >> then PSTN is out of touch with 302. please tell me, how can i write a >> sip uri in my phone that redirects the caller in another domain to my >> cell phone? > > Well a 302 with a tel may work, or may not. Alternatively you could use a sip URI in the 302. For the domain portion of that 302's contact: if you don't know a SIP-PSTN provider which will send it to your cell, then you could try setting it to your provider's domain (if you have one), or the domain which sent the request. And since a 3xx can have multiple contact URIs, you can try all these at the same time, including Tel, but I suggest making the first one the most likely to succeed, because I've been told some devices can't handle multiple contacts either (ya, it's friggin nuts - don't shoot the messenger). > > It's nasty, but it should work in many cases I think. (though honestly most cases I've seen just set it to sip and their provider's domain and it works... but that could easily be because I mostly only see traces from providers) > > -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 sip-bounces@ietf.org Sat Apr 12 21:45:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A663D3A6A03; Sat, 12 Apr 2008 21:45:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1783A6A03 for ; Sat, 12 Apr 2008 21:45:55 -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 mqDoiGQZdNr5 for ; Sat, 12 Apr 2008 21:45:55 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 066753A68A6 for ; Sat, 12 Apr 2008 21:45:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 68E1C1EC294; Sun, 13 Apr 2008 07:46:21 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC69azvEBCvb; Sun, 13 Apr 2008 07:46:14 +0300 (EEST) Received: from taimen (h13667.gprs.dnafinland.fi [87.93.136.67]) by tutpro.com (Postfix) with ESMTP; Sun, 13 Apr 2008 07:46:14 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 30DEEAC06D; Sun, 13 Apr 2008 07:46:08 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18433.36880.176560.493458@taimen.test.fi> Date: Sun, 13 Apr 2008 07:46:08 +0300 To: Hadriel Kaplan In-Reply-To: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> <18433.2474.365305.28249@taimen.test.fi> <18433.3297.799014.817465@taimen.test.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan writes: > Who said it wasn't possible? We're just talking about whether it's > done the same way universally in practice. i meant "possible in practice using commercially available sip phones". i think it would be high time to deprecate use of tel uris in sip, because (as people indicated) they have not been implemented to the extend that one could use them in 302s? -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 21:48:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0157A3A6AFD; Sat, 12 Apr 2008 21:48:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103A23A6AFD for ; Sat, 12 Apr 2008 21:48:01 -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 geleyQTEsO5o for ; Sat, 12 Apr 2008 21:48:00 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 332543A68A6 for ; Sat, 12 Apr 2008 21:48:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id A71491EC294; Sun, 13 Apr 2008 07:48:26 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU6x0H-oIDsQ; Sun, 13 Apr 2008 07:48:20 +0300 (EEST) Received: from taimen (h13667.gprs.dnafinland.fi [87.93.136.67]) by tutpro.com (Postfix) with ESMTP; Sun, 13 Apr 2008 07:48:20 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 16AC9AC06D; Sun, 13 Apr 2008 07:48:06 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18433.36999.24069.851126@taimen.test.fi> Date: Sun, 13 Apr 2008 07:48:07 +0300 To: "Francois Audet" In-Reply-To: References: <18432.65531.810231.597927@taimen.test.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet writes: > Every single implementation that I've see does the following: > > Contact: sip:+19725551212@example.com;user=phone > > Where example.com is the domain of the forwarding user. The SIP proxy will > then route it to a PSTN if appropriate. i think you have not followed this thread. it has been pointed out that the above does no work if caller does not have the right to use pstn gateway of example.com. -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 21:51:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F263A6A0D; Sat, 12 Apr 2008 21:51:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1053A6BF7 for ; Sat, 12 Apr 2008 21:51: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 9sC6edvwyr7f for ; Sat, 12 Apr 2008 21:51:18 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 71B183A6AFD for ; Sat, 12 Apr 2008 21:51:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 1FA101EC294; Sun, 13 Apr 2008 07:51:45 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r2hDAizKlrG; Sun, 13 Apr 2008 07:51:38 +0300 (EEST) Received: from taimen (h13667.gprs.dnafinland.fi [87.93.136.67]) by tutpro.com (Postfix) with ESMTP; Sun, 13 Apr 2008 07:51:38 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id B0F33AC06D; Sun, 13 Apr 2008 07:51:32 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18433.37204.609525.45246@taimen.test.fi> Date: Sun, 13 Apr 2008 07:51:32 +0300 To: "Francois Audet" In-Reply-To: References: <18433.3297.799014.817465@taimen.test.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet writes: > There is a reason why people do it like this. Try sending a Tel URI on the > wire and see what happens with most equipment out there. if user of my proxy uses tel uri (+...) in request uri, the proxy converts it to sip using using where host part is taken from caller's from uri. openser even has a function tel2sip for that purpose. -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 21:53:43 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08233A6D3D; Sat, 12 Apr 2008 21:53:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9223A6D39 for ; Sat, 12 Apr 2008 21:53:41 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=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 am8LyU3YDl-2 for ; Sat, 12 Apr 2008 21:53:40 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id AB1283A6A0D for ; Sat, 12 Apr 2008 21:53:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 60E351EC294; Sun, 13 Apr 2008 07:54:07 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ol5uvTpQ3R2; Sun, 13 Apr 2008 07:54:00 +0300 (EEST) Received: from taimen (h13667.gprs.dnafinland.fi [87.93.136.67]) by tutpro.com (Postfix) with ESMTP; Sun, 13 Apr 2008 07:54:00 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id A4156AC06D; Sun, 13 Apr 2008 07:53:53 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18433.37345.642891.706469@taimen.test.fi> Date: Sun, 13 Apr 2008 07:53:53 +0300 To: Paul Kyzivat In-Reply-To: <48018B2A.40701@cisco.com> References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> <48018B2A.40701@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Francois Audet , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat writes: > So in effect you are suggesting that we should revise 3263 regarding sip > URIs with user=phone, and get the result widely adopted rather than get > tel widely adopted. these two are indeed the options and this wg MUST do one of them before writing more rfcs that no-one will implement. -- juha _______________________________________________ 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 sip-bounces@ietf.org Sat Apr 12 21:56:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD1F3A6A0D; Sat, 12 Apr 2008 21:56:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D633A6A0D for ; Sat, 12 Apr 2008 21:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_45=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 sq3T6nps30nq for ; Sat, 12 Apr 2008 21:56:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 61EC23A6867 for ; Sat, 12 Apr 2008 21:56:09 -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.240.5; Sun, 13 Apr 2008 00:56:07 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 00:56:07 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Sun, 13 Apr 2008 00:58:55 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcidHkFoOf1xdPWiSgm49vCFgNtq6wAAKgPA Message-ID: References: <97660754-B349-4A06-A01E-6FEF18A6F93D@softarmor.com> <18432.65531.810231.597927@taimen.test.fi> <48018B2A.40701@cisco.com> In-Reply-To: <48018B2A.40701@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org No, I very clearly said "don't shoot the messenger", but that that is what I see happening. Clearly you SHOULD use a tel URI, or the sip URI with the domain of your cell phone (if it has such). But the reality is people AREN'T doing that very often, afaict. I am in no way suggesting 3263 rules should not be followed, nor that tel uri's shouldn't be used. Juha asked how he could write a *sip* URI in a 302 to redirect to a cell phone, and I answered what he could try. I don't know why this is shocking - are you not seeing that often as well? [maybe it's just me] Don't get me wrong - I see 302's aplenty which point to a different domain as well, but in many of those cases the domain they point to is also not authoritative for the E.164 (ie, they're to transit peers). [Although with regard to 3263, I'm not sure what part of setting the contact uri to your own domain doesn't follow that. The target of that domain is reached (your proxy/pbx/whatever), and it can't route it locally because it has no such global user, so based on local policy it may determine an alternative path, typically to the PSTN.] -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Sunday, April 13, 2008 12:25 AM > To: Hadriel Kaplan > Cc: Juha Heinanen; Francois Audet; SIP IETF; Dan WING; Dean Willis > Subject: Re: [Sip] E.164 - who owns it > > So you are telling me that you SHOULD forward someone to your own domain > to reach a phone number even when you know that your domain would not be > willing to route the resulting request from the forwardee. Instead you > are *counting* on the forwardee to *ignore* the domain and the 3263 > routing rules and instead use its own logic to reach the number??? > > So in effect you are suggesting that we should revise 3263 regarding sip > URIs with user=phone, and get the result widely adopted rather than get > tel widely adopted. > > Paul > > Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Juha > >> Heinanen > >> > >> Francois Audet writes: > >> > >> > Insisting on Tel URI seems kind of out of touch with reality. > >> > >> then PSTN is out of touch with 302. please tell me, how can i write a > >> sip uri in my phone that redirects the caller in another domain to my > >> cell phone? > > > > Well a 302 with a tel may work, or may not. Alternatively you could use > a sip URI in the 302. For the domain portion of that 302's contact: if > you don't know a SIP-PSTN provider which will send it to your cell, then > you could try setting it to your provider's domain (if you have one), or > the domain which sent the request. And since a 3xx can have multiple > contact URIs, you can try all these at the same time, including Tel, but I > suggest making the first one the most likely to succeed, because I've been > told some devices can't handle multiple contacts either (ya, it's friggin > nuts - don't shoot the messenger). > > > > It's nasty, but it should work in many cases I think. (though honestly > most cases I've seen just set it to sip and their provider's domain and it > works... but that could easily be because I mostly only see traces from > providers) > > > > -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 sip-bounces@ietf.org Sat Apr 12 22:06:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E483A6B6F; Sat, 12 Apr 2008 22:06:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7549E3A6AFD for ; Sat, 12 Apr 2008 22:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 OGz0pFPXniAD for ; Sat, 12 Apr 2008 22:06:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 852083A69B7 for ; Sat, 12 Apr 2008 22:06:19 -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.240.5; Sun, 13 Apr 2008 01:06:17 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 01:06:17 -0400 From: Hadriel Kaplan To: Juha Heinanen , Francois Audet Date: Sun, 13 Apr 2008 01:09:05 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcidIZAWyroKBmCMT+6Ka1uiuESvIAAAZ7WQ Message-ID: References: <18432.65531.810231.597927@taimen.test.fi> <18433.36999.24069.851126@taimen.test.fi> In-Reply-To: <18433.36999.24069.851126@taimen.test.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Juha > Heinanen > > Francois Audet writes: > > > Every single implementation that I've see does the following: > > > > Contact: sip:+19725551212@example.com;user=phone > > > > Where example.com is the domain of the forwarding user. The SIP proxy > will > > then route it to a PSTN if appropriate. > > i think you have not followed this thread. it has been pointed out that > the above does no work if caller does not have the right to use pstn > gateway of example.com. > -- juha Sure, but the example.com proxy has rules for whether to allow such or not. If it *doesn't* want to allow it, or it has no such alternate routes, then life sometimes gets super-ugly. [again don't shoot the messenger] Some (not all) of those proxies then pass the 302 back upstream, but change the contact URI's domain to the domain they're passing it back up to. In effect they do what they do for req-uri's of requests they send. -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 sip-bounces@ietf.org Sat Apr 12 22:23:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294E728C100; Sat, 12 Apr 2008 22:23:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB323A6867 for ; Sat, 12 Apr 2008 22:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 P1Lw4t24Gy8F for ; Sat, 12 Apr 2008 22:23:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8FCE73A6A99 for ; Sat, 12 Apr 2008 22:23:00 -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.240.5; Sun, 13 Apr 2008 01:22:58 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 01:22:58 -0400 From: Hadriel Kaplan To: Juha Heinanen , Francois Audet Date: Sun, 13 Apr 2008 01:25:46 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcidIgRRnCAUDQaJTwKvQ/YvebYfswAAqKpg Message-ID: References: <18433.3297.799014.817465@taimen.test.fi> <18433.37204.609525.45246@taimen.test.fi> In-Reply-To: <18433.37204.609525.45246@taimen.test.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > > if user of my proxy uses tel uri (+...) in request uri, the proxy > converts it to sip using using where host part is taken from caller's > from uri. openser even has a function tel2sip for that purpose. Yeah, and many people do that type of thing to get around any lack of tel-uri support. (though I usually see it being set to the routed to next-domain, not the From domain, fwiw) But anyway, this leads back to the original problem. If we want a sip: req-uri to mean "only use sip", then we can't go changing tel to sip, or sip to tel, and we can't go casually using sip in From's. That would be a big change from current defacto use, afaict. -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 sip-bounces@ietf.org Sat Apr 12 22:42:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E863A6B2C; Sat, 12 Apr 2008 22:42:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97013A69A3 for ; Sat, 12 Apr 2008 22:42:55 -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 ogT5mAwqBop6 for ; Sat, 12 Apr 2008 22:42:55 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DDAF73A69B7 for ; Sat, 12 Apr 2008 22:42:54 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3D5hGO2024450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2008 00:43:18 -0500 Message-Id: <3995D068-A311-4BBA-BACC-A734B2560857@softarmor.com> From: Dean Willis To: "Francois Audet" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 13 Apr 2008 00:43:11 -0500 References: X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 12, 2008, at 3:25 PM, Francois Audet wrote: > Every single implementation that I've see does the following: > > Contact: sip:+19725551212@example.com;user=phone > > Where example.com is the domain of the forwarding user. The SIP > proxy will > then route it to a PSTN if appropriate. I think you've missed the use case. You've forwarded the call to a gateway in the domain of the called party. Since the calling party (most probably) does not have authorization to use that gateway, the likely response when they attempt INVITE to that contact is a 404. SIP, as you describe it, works just fine in a single-provider domain. That's telephony over IP, not a model for Internet communications. -- 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 sip-bounces@ietf.org Sat Apr 12 23:15:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6683A6826; Sat, 12 Apr 2008 23:15:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2B03A6784 for ; Sat, 12 Apr 2008 23:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_45=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 zZDLWbRTZ85M for ; Sat, 12 Apr 2008 23:15:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7DE773A699D for ; Sat, 12 Apr 2008 23:15:00 -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.240.5; Sun, 13 Apr 2008 02:14:58 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 02:14:56 -0400 From: Hadriel Kaplan To: Dean Willis , Francois Audet Date: Sun, 13 Apr 2008 02:17:46 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcidKT4iHdQJcywAR22OxlEN7xKJvwAAa99w Message-ID: References: <3995D068-A311-4BBA-BACC-A734B2560857@softarmor.com> In-Reply-To: <3995D068-A311-4BBA-BACC-A734B2560857@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > SIP, as you describe it, works just fine in a single-provider domain. > That's telephony over IP, not a model for Internet communications. But sending it to the PSTN is a model for Internet communications?? Look, for better or worse, we have allowed proxies to recurse on 3xx. If you set a TEL uri in the contact, the upstream proxy can decide whether to recurse on that or not. If it chooses not to, it can pass the 3xx upstream, and the *next* proxy upstream can make the same decision, and so on. Now replace "tel:" with "sip:", and add the domain of the upstream proxy, and a user=phone. It may be ugly. It may be wrong. But it's working. And it's working across domains. And it's probably working better than tel would right now, imho. So where do we go from here? Option 1) Ignore it. This may only be a minor population of the sip community; or they may fix it themselves someday; or it may not be a real problem if they keep doing what they're doing. Option 2) Figure out how to make tel more successful. Option 3) Figure out how to make sip with user=phone a true alias. Option 4) ?? -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 sip-bounces@ietf.org Sun Apr 13 08:28:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B6728C259; Sun, 13 Apr 2008 08:28:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E25A3A6B74 for ; Sun, 13 Apr 2008 08:28:48 -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=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 PEKoXG6hZy8p for ; Sun, 13 Apr 2008 08:28:47 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 031263A6CA0 for ; Sun, 13 Apr 2008 08:28:47 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E3B0A50854; Sun, 13 Apr 2008 08:31:06 -0700 (PDT) Date: Sun, 13 Apr 2008 08:31:06 -0700 From: Eric Rescorla To: Dean Willis In-Reply-To: <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080413153106.E3B0A50854@romeo.rtfm.com> Cc: "sip@ietf.org List" , Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Wed, 9 Apr 2008 23:17:38 -0500, Dean Willis wrote: > > > On Apr 9, 2008, at 11:53 AM, Michael Thomas wrote: > > > >> Now, assume JoeBob is instead named "180055511212@example.com". All > >> of the above works fine, until somebody calls into example.com's > >> PSTN gateway from a spoofed Caller-ID of "18005551212" and asks > >> said gateway to connect them to messages.example.net > >> > > > > So just don't sign it. Or sign it as @example.com. Or just tell the > > voice > > mail provider not to create voice mail boxes for users with e164@example.com > > like addresses. This really seems tenuous to me, Dean. > > I'm getting REALLY TIRED OF EXPLAINING THIS. Yeah, I know, one must > say things ten time to be heard once. But this is eleven . . . ;-) > > We need to sign it, because SRTP-DTLS relies on the signature in order > to protect the fingerprint of the media key from MITM attacks. > > In short, SRTP-DTLS requires RFC 4474 (for full function), and PSTN > interaction precludes RFC 4474. > > Something has to give. As I see it, we MUST pick at least one of the > following: > > 1) Change RFC 4474 so that it can be used with phone gateways. > 2) Change DTLS-SRTP so that it doesn't depend on RFC 4474. > 3) Decide that we can live without integrity protection of the media > key on calls transiting PSTN gateways, and document this. > > We already have a strong argument for amending RFC 4474 so that SBCs > that tweak the SDP don't break the Identity signature. If we do this, > add the "not really an identity" flag, and mod DTLS-SRTP to account > for the changes, then I think we have a full solution. Dean, I don't think that this analysis is correct. First, you claim "SRTP-DTLS requires RFC 4474 (for full function)". That's not quite correct, and I think it's worth walking through the security analysis. Let's start by looking at a simpler case, Web security. In the classic Web security case, the server has a cert and the client does not. At the completion of the TLS handshake, each side knows the following: - The client knows it has a secure connection to the server. - The server knows it has a secure connection to *someone*. There are two very important (in fact, the most common) cases where this is precisely what you want: (1) When the server does not care who the client is (for instance, in software download, where the client cares about getting an accurate copy but the server does not care who it gives copies to.) (2) When the server has some other means of authenticating the client (for instance, when you're doing e-commerce and the client authenticates via password or credit card). So, in these situations we don't ordinarily say that we're not getting "full function" but rather that this is the design goal. Now, turning to the more complicated voice case. First, the the fingerprint and RFC 4474 signature (and the RFC 4916 counterpart) plays the same role here as does the certificate in the ordinary TLS handshake, namely it provides authentication for one side of the connection. It's quite possible to have a secure connection where only one side is authenticated, so long as the authenticated side does not care about the other side's identity. And there are a number of such cases, especially in B2C settings. For instance, if I call Fidelity, I care that I'm not talking to an attacker, but they only care that they call not be hijacked, because they're going to ask me for a PIN anyway. This is more or less how all PSTN-based security works now, because you can't trust CNID. More on this later. You write: We need to sign it, because SRTP-DTLS relies on the signature in order to protect the fingerprint of the media key from MITM attacks. This isn't quite correct. As long as one side verifies the other side's identity, than MITM attacks get blocked, because an MITM attack requires replacing keys in both directions with the attacker's key. Consider the following example, in which Alice is calling Bob, but for some reason her fingerprint isn't signed: Alice Attacker Bob ---------------------------------------------------------- Fingerprint=X (unsigned) -> Fingerprint=A (unsigned) -> <- Fingerprint=Z (signed, Bob) <- Fingerprint=Z (signed, Bob) So, Bob has no reliable way of knowing Alice's identity. However, that's not sufficient to mount an MITM attack, which required that the attacker to replace Bob's key Z with his own key A. But he can't do that without replacing Bob's fingerprint, which would require the ability to sign a message from Bob [0]. Now, let's turn to the PSTN case, the simplest of which is shown in Figure 2 of draft-schwartz-sip-e164-ownership-01, namely, someone on the PSTN calls someone on IP network. As has been widely noted, there is no technical reason that the PSTN GW can't RFC 4474 sign the From line, (though it's not clear what that means from the RP's perspective), but even if the GW doesn't sign, we still have significant security properties as long as it *verifies* the called parties signature. Moreover, since the GW doesn't really know the caller's identity (because you can't trust the PSTN identity assertions) this is the best set of properties one could hope for, no matter what SIP mechanisms we create. Even if there were some mechanism by which the GW could say "I received this over the PSTN and the CNID said X", and the relying party trusted the RP not to lie, it still can't believe this assertion because the GW's information is untrustworthy. -Ekr [0] But wait, you say. In SIP we don't have any restrictions on who the call gets retargeted to, so the attacker could just send his own key with a (valid) RFC 4474 identity pointing to his real identity. This is absolutely true, and either Alice (or her UI needs) to notice this, or we need a secure retargeting mechanism, but this is a separate technical issue. The requirement right now is that the right identity shows up in Alice's display, and we get that right. _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 13 08:29:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C3628C26F; Sun, 13 Apr 2008 08:29:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACACD28C25E for ; Sun, 13 Apr 2008 08:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_45=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 Lorq-kkNvOyv for ; Sun, 13 Apr 2008 08:29:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CC4C228C26F for ; Sun, 13 Apr 2008 08:29:23 -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.240.5; Sun, 13 Apr 2008 11:29:22 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 11:29:23 -0400 From: Hadriel Kaplan To: Dean Willis , "sip@ietf.org List" Date: Sun, 13 Apr 2008 11:32:12 -0400 Thread-Topic: Signing requests [was: Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem] Thread-Index: Acice7Mvt1i0FGt7Ttu9Paf7i9j6xAA/qAnA Message-ID: References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> In-Reply-To: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Sip] Signing requests [was: Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > We've realized we have a specification mutual exclusion. > > RFC 4474 as written precludes the insertion of an Identity header by > an authentication service into a SIP message produced by a PSTN > gateway. However, DTLS-SRTP as written needs such an Identity header > in order to be able to verify that the media key fingerprint has not > been altered by a MITM who is also attacking on the media path. It's not just DTLS-SRTP fingerprints, it's non-SDP mime bodies as well. For example the body of a MESSAGE request. Middle-boxes have no need to change such bodies in transit, and we shouldn't want them to. But as it stands right now, some middle-boxes would either break the signature or need to re-sign (if possible), simply because they modify the call-id. It is debatable if changing the call-id has any real security implications for 4474, or if they're so minor that we're cutting off our nose to spite our face. -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 sip-bounces@ietf.org Sun Apr 13 09:11:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71FE28C12B; Sun, 13 Apr 2008 09:11:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABFF3A6D26 for ; Sun, 13 Apr 2008 09:11:31 -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 bWz-fNtUMHDY for ; Sun, 13 Apr 2008 09:11:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3DBA03A6CDE for ; Sun, 13 Apr 2008 09:11: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.240.5; Sun, 13 Apr 2008 12:11:29 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 12:11:29 -0400 From: Hadriel Kaplan To: Eric Rescorla , Dean Willis Date: Sun, 13 Apr 2008 12:14:18 -0400 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AcidexhV8n7/nSXkT7+/5ha/mLF/mgAAO3nQ Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> In-Reply-To: <20080413153106.E3B0A50854@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" , Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric > Rescorla > > First, you claim "SRTP-DTLS requires RFC 4474 (for full function)". > That's not quite correct, and I think it's worth walking through > the security analysis. Agreed, but I don't think he's claiming his sentence as a fully qualified truism, but rather as a short-hand for: "We need one or both of RFC 4474/4916 to be used in common practice, and to sign the SDP, because without one or both of those mechanisms being used it allows a MitM to be a DTLS-SRTP middle-man." > This isn't quite correct. As long as one side verifies the other > side's identity, than MITM attacks get blocked, because an MITM attack > requires replacing keys in both directions with the attacker's > key. Consider the following example, in which Alice is calling Bob, > but for some reason her fingerprint isn't signed: > > > Alice Attacker Bob > ---------------------------------------------------------- > Fingerprint=X (unsigned) -> > Fingerprint=A (unsigned) -> > > <- Fingerprint=Z (signed, Bob) > <- Fingerprint=Z (signed, Bob) > > So, Bob has no reliable way of knowing Alice's identity. However, > that's not sufficient to mount an MITM attack, which required that the > attacker to replace Bob's key Z with his own key A. But he can't do > that without replacing Bob's fingerprint, which would require the > ability to sign a message from Bob [0]. I don't think Dean is claiming a MitM attack is possible when 4474/4916 *is* used. At least not in the definition of "MitM attack" where one side *thinks* it's secure but it's not. Clearly a form of MitM attack can be trivially performed whereby neither side get signed requests, but still get fingerprints, but that's not a MitM attack in my book as much as it is a downgrade attack. And that form of attack can be done on your example above, very easily, but then both Alice and Bob should know their media plane isn't secure. And similar to TLS, Alice has to take care not to speak her PIN over the media plane to Bob, etc. But I think Dean's point is: if we can't get a 4474/4916 model to be useful in practice, then *neither* side will be using it in practice. We want it to be used in practice, as much as possible. But he should chime in with what he meant. :) Also, I'm not sure 4916 gives that "other direction" behavior. It signs an upstream request, from the original UAS to the UAC. It does not sign an SDP offer/answer from the UAS in the initial INVITE response, and thus does not sign the fingerprint, at least initially. And even if 4916 is subsequently used, I think (though I'm not sure), that the UAS could well send the 4916 signature in an upstream request with no SDP, thus again not be signing the fingerprint. (Although the correct thing to do may well be spelled out in Jason's draft, so maybe that's a nit) And clearly that's not a fault of DTLS-SRTP fingerprint but rather of 4474 not providing a way for responses to be signed, and is a separate topic. -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 sip-bounces@ietf.org Sun Apr 13 09:37:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AFA3A6C64; Sun, 13 Apr 2008 09:37:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8173A6C9B for ; Sun, 13 Apr 2008 09:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, J_CHICKENPOX_45=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 1nLFVOvuLJw0 for ; Sun, 13 Apr 2008 09:37:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 61A963A68FE for ; Sun, 13 Apr 2008 09:37: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.240.5; Sun, 13 Apr 2008 12:37:17 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 12:37:17 -0400 From: Hadriel Kaplan To: Dean Willis , "sip@ietf.org List" Date: Sun, 13 Apr 2008 12:40:05 -0400 Thread-Topic: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem Thread-Index: Acice7Mvt1i0FGt7Ttu9Paf7i9j6xAA/9pSw Message-ID: References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> In-Reply-To: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > RFC 3261 Section 19.1.1 says: > > The set of valid telephone-subscriber strings is a subset of > valid user strings. The user URI parameter exists to > distinguish telephone numbers from user names that happen to > look like telephone numbers. If the user string contains a > telephone number formatted as a telephone-subscriber, the user > parameter value "phone" SHOULD be present. Even without this > parameter, recipients of SIP and SIPS URIs MAY interpret the > pre-@ part as a telephone number if local restrictions on the > name space for user name allow it That last sentence is fascinating. If I read it right, it basically allows me to treat a sip URI for my domain without the user=phone as a global E.164, if I so wish. (which so happens to be fairly common in my world) Good, I feel better now. ;) > If we made it mandatory for a PSTN gateway to assert identities using > user=phone and documented that Identity headers over an identity with > a user=phone parameter do not assert the "user part" of that identity, > then I think we'd have a complete solution. > Corollary , we need to document that a "phone" UAS that is attached to > the Internet does NOT use "user=phone" even if its user ID is a phone > number and the ENUM entry for that phone number happens to point at > this user ID at this UAS (or supporting domain). There's a problem with that. There are many "phone" UAS's which are ultimately reachable over the PSTN. In fact, I would bet most of them are. If the From of a request is used to store in one's address book, for later requests, then per Paul's desired behavior that later request could only be delivered over sip, or it should fail. One would think if the original request were to be delivered by sip, then a request anytime later the other direction could as well. But that's not the case. For one, transit peering arrangements are not symmetrical, and it's totally possible that calls across providers in one direction go sip the whole way, but calls the other direction cross the PSTN or H.323 or whatever. For another, many enterprises have "PSTN fallback" abilities, so that if their SIP trunks fail for some reason, there is a PRI-type backup. But this issue is somewhat orthogonal to your proposal. And it's leading me to think that we cannot reasonably have a "if sip: then only SIP" behavior solely based on scheme, as Paul seems to feel is currently implied (I think). -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 sip-bounces@ietf.org Sun Apr 13 09:41:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397BC3A6C9B; Sun, 13 Apr 2008 09:41:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203813A69C9 for ; Sun, 13 Apr 2008 09:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 loiNbrdIljN7 for ; Sun, 13 Apr 2008 09:41:51 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 09E2B28C17C for ; Sun, 13 Apr 2008 09:41:50 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 448A521E995; Sun, 13 Apr 2008 09:42:18 -0700 (PDT) Date: Sun, 13 Apr 2008 09:42:17 -0700 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080413164218.448A521E995@kilo.rtfm.com> Cc: "sip@ietf.org List" , Michael Thomas , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Sun, 13 Apr 2008 12:14:18 -0400, Hadriel Kaplan wrote: > > side's identity, than MITM attacks get blocked, because an MITM attack > > requires replacing keys in both directions with the attacker's > > key. Consider the following example, in which Alice is calling Bob, > > but for some reason her fingerprint isn't signed: > > > > > > Alice Attacker Bob > > ---------------------------------------------------------- > > Fingerprint=X (unsigned) -> > > Fingerprint=A (unsigned) -> > > > > <- Fingerprint=Z (signed, Bob) > > <- Fingerprint=Z (signed, Bob) > > > > So, Bob has no reliable way of knowing Alice's identity. However, > > that's not sufficient to mount an MITM attack, which required that the > > attacker to replace Bob's key Z with his own key A. But he can't do > > that without replacing Bob's fingerprint, which would require the > > ability to sign a message from Bob [0]. > > I don't think Dean is claiming a MitM attack is possible when > 4474/4916 *is* used. At least not in the definition of "MitM > attack" where one side *thinks* it's secure but it's not. Clearly a > form of MitM attack can be trivially performed whereby neither side > get signed requests, but still get fingerprints, but that's not a > MitM attack in my book as much as it is a downgrade attack. And > that form of attack can be done on your example above, very easily, > but then both Alice and Bob should know their media plane isn't > secure. And similar to TLS, Alice has to take care not to speak her > PIN over the media plane to Bob, etc. > > But I think Dean's point is: if we can't get a 4474/4916 model to be > useful in practice, then *neither* side will be using it in > practice. We want it to be used in practice, as much as possible. > But he should chime in with what he meant. :) Well, I don't know what Dean is claiming, but what *I* am claiming is that MITM attacks aren't possible as long as at least one side uses 4474/4916 and the other side checks the signature. And that means that at least in the case of PSTN->SIP calls, we don't have an inherent MITM problem. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 13 10:38:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73963A6D6C; Sun, 13 Apr 2008 10:38:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F6C3A6B3C for ; Sun, 13 Apr 2008 10:38:25 -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 CgcXprhYfsAd for ; Sun, 13 Apr 2008 10:38:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F1B583A6A97 for ; Sun, 13 Apr 2008 10:38:24 -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.240.5; Sun, 13 Apr 2008 13:38:23 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 13:38:23 -0400 From: Hadriel Kaplan To: Eric Rescorla Date: Sun, 13 Apr 2008 13:41:09 -0400 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AcidhUhPT+ZpDQevQIOV1fvzYcTyQgAAPSNQ Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080413164218.448A521E995@kilo.rtfm.com> In-Reply-To: <20080413164218.448A521E995@kilo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" , Michael Thomas , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Well, I don't know what Dean is claiming, but what *I* am claiming > is that MITM attacks aren't possible as long as at least one side > uses 4474/4916 and the other side checks the signature. And that > means that at least in the case of PSTN->SIP calls, we don't > have an inherent MITM problem. Although unrelated to your general point above, the PSTN->SIP case seems a bit odd to me in practice, for two reasons: 1) What is it you expect a PSTN GW to do differently in these cases, vs. unsigned cases? Since the PSTN GW has no way to pass on strength indications on the PSTN, do you expect it to automatically terminate calls which aren't 4916 signed? Or play some announcement such as "this call is not secure"? (and do we honestly think they'd do that?) A downgrade attack is trivially possible, and leaves the PSTN GW with no idea if the called side could have actually done 4916 or not. So should it just assume if it gets a fingerprint which isn't signed then there is probably a MitM? (and also not do best-effort srtp offers) 2) You said in your email that the retargeting case is orthogonal, and that either Alice or her UI need to notice this. But if a PSTN GW is representing Alice, I don't see how that's possible. [this goes back to a previous thread] I'm not sure how a PSTN GW can know what the right domain for Bob's signature should be. The PSTN GW only knows a phone number, period. The 4916 signature may well be signed by a common trusted CA, but that really doesn't mean what it does in TLS, because there is no domain name verification possible to the PSTN GW. In other words, the GW knows it's calling +123456789, and foo.com signed rfc4916 as sip:123456789@foo.com, with a cert for foo.com. The common CA did verify foo.com is truly foo.com, but so what? The PSTN GW has no idea if the 123456789 at foo.com is the same global +123456789 that the PSTN meant to reach, or some legitimate open phone hosting service that happens to have usernames which collide with Fidelity's E.164, or even just another PSTN gateway. In other words, what stops me (bad guy), from getting an account on foo.com with that number, and redirecting calls from PSTN GW to my account? -hadriel p.s. Personally, I think it very unlikely that PSTN-based calls will use DTLS-SRTP to begin with, simply because of the cost-benefit tradeoff. But that doesn't stop me from wanting it to be possible, and more-so for 4474-type of signing to be possible for other uses. _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 13 12:30:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6123A6D95; Sun, 13 Apr 2008 12:30:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE413A6DE9 for ; Sun, 13 Apr 2008 12:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, J_CHICKENPOX_45=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 rkgNW3UUsOGq for ; Sun, 13 Apr 2008 12:30:25 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CB4653A68B6 for ; Sun, 13 Apr 2008 12:29:57 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3DJUJ2i029257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2008 14:30:21 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 13 Apr 2008 14:30:14 -0500 References: <3995D068-A311-4BBA-BACC-A734B2560857@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 13, 2008, at 1:17 AM, Hadriel Kaplan wrote: > > So where do we go from here? > Option 1) Ignore it. This may only be a minor population of the sip > community; or they may fix it themselves someday; or it may not be a > real problem if they keep doing what they're doing. > Option 2) Figure out how to make tel more successful. > Option 3) Figure out how to make sip with user=phone a true alias. > Option 4) ?? > I'm inclined to 2 or 3. As the discussion has noted, user=phone is at best a trifle underdocumented. Either 2 or 3 requires additional spec work; but at lest the problem is tractable this way. -- 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 sip-bounces@ietf.org Sun Apr 13 13:26:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274F73A68EF; Sun, 13 Apr 2008 13:26:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772FA3A6891 for ; Sun, 13 Apr 2008 13:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 PFoNnCPBriqG for ; Sun, 13 Apr 2008 13:25:56 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 920993A68EF for ; Sun, 13 Apr 2008 13:25:00 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3DKPQBC029498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2008 15:25:27 -0500 Message-Id: From: Dean Willis To: Eric Rescorla In-Reply-To: <20080413153106.E3B0A50854@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 13 Apr 2008 15:25:20 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" , Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 13, 2008, at 10:31 AM, Eric Rescorla wrote: > At Wed, 9 Apr 2008 23:17:38 -0500, >> > > Dean, > > I don't think that this analysis is correct. > That's entirely possible. Thank you for helping sort it out. > First, you claim "SRTP-DTLS requires RFC 4474 (for full function)". > That's not quite correct, and I think it's worth walking through > the security analysis. > ... background elided > Now, turning to the more complicated voice case. First, the the > fingerprint and RFC 4474 signature (and the RFC 4916 counterpart) > plays the same role here as does the certificate in the ordinary TLS > handshake, namely it provides authentication for one side of the > connection. It's quite possible to have a secure connection where only > one side is authenticated, so long as the authenticated side does not > care about the other side's identity. And there are a number of such > cases, especially in B2C settings. For instance, if I call Fidelity, I > care that I'm not talking to an attacker, but they only care that they > call not be hijacked, because they're going to ask me for a PIN > anyway. This is more or less how all PSTN-based security works > now, because you can't trust CNID. More on this later. Since the call has already been authenticated (4474 provides an "authentication service", no?) Fidelity might well NOT ask you for a pin. > > > You write: > > We need to sign it, because SRTP-DTLS relies on the signature in > order > to protect the fingerprint of the media key from MITM attacks. > > This isn't quite correct. As long as one side verifies the other > side's identity, than MITM attacks get blocked, because an MITM attack > requires replacing keys in both directions with the attacker's > key. Consider the following example, in which Alice is calling Bob, > but for some reason her fingerprint isn't signed: > > > Alice Attacker Bob > ---------------------------------------------------------- > Fingerprint=X (unsigned) -> > Fingerprint=A (unsigned) -> > > <- Fingerprint=Z (signed, Bob) > <- Fingerprint=Z (signed, Bob) > > So, Bob has no reliable way of knowing Alice's identity. However, > that's not sufficient to mount an MITM attack, which required that the > attacker to replace Bob's key Z with his own key A. But he can't do > that without replacing Bob's fingerprint, which would require the > ability to sign a message from Bob [0]. > Let's reduce this to what I see as the simplest use case: Alice calls Bob through a single domain proxy server that is also an RFC 4474 authentication service. Alice----->---PAS----->Bob Typically, Alice sends an INVITE along with key fingerprint and normal SDP, PAS slaps authenticates her and sticks on an Identity header signing her INVITE, and sends it to Bob. Bob 200s with SDP and a key fingerprint. DTLS happens, Alice and Bob compare the key presented in DTLS with the key fingerprint sent in SDP, and everybody is happy. But what if PAS were evil? Alice sends an INVITE along with key fingerprint and SDP. PAS replaces the fingerprint and SDP pointing PAS, than adds an Identity header. Bob received the INVITE, responds with a 200 OK with his own SDP and fingerprint. PAS also replaces the SDP and fingerprint in the 200 OK. Next, Alice and Bob each independently DTLS handshake with PAS, while thinking they're talking directly to each other. The call has been intercepted, and the victim's don't know. While the preceding isn't the use case for which DTLS-SRTP was built, it shows the simplest possible structure in which it can be subverted by A MITM that is abusing a position of trust. It's far more interesting to think about cases where a trust anchor hasn't turned evil. Assume a more complex case, where each of Alice and Bob have their own PAS, and an evil proxy EP sits in the middle. Alice------>PASA------EP------->PASB-----Bob Here, Alice sends an INVITE with fingerprint and PASA signs it. EP passes the request to PASB, which passes it to Bob. Bob replies with a 200 OK with fingerprint. Note that Bob's 200 OK cannot have an identity signature over that fingerprint, since RFC 4474 doesn't work on responses. PASB forwards this on to EP, which replaces the SDP and fingerprint. Alice then DTLS handshakes with EP, and is quite happy. Bob starts to handshake with EP, but since EP isn't in possession of Alice's cert, Bob detects the miskey and realizes the call has been intercepted. The protocol works against the attack, because Alice's fingerprint was integrity protected by PASA and could not be modified by EP. But let's replace Alice with a gateway. This is basically the case from 8.4 of draft-ietf-sip-dtls-framework -- "Single-Sided- Verification" done backwards, with no integrity protection on the forward channel (GW to BOB). The 8.4 case has no verification in the other direction. GW------>PASA------EP------->PASB-----Bob GW sends an INVITE containing SDP and fingerprint to PASA. Since GW is a gateway, PASA cannot add an Identity header that provides integrity protection for the fingerprint. PASA forwards the request to EP. EP replaces the SDP and fingerprint ands sends it on to PASB. PASB sends the request to Bob, who generates a 200 OK with fingerprint and SDP then sends the request back to PASB. Since this is a response, PASB cannot add an Identity header. EP then replaces the SDP and fingerprint. and sends the response on through PASA to GW. GW and Bob then each DTLS handshake with EP, and the dirty deed is done. Surely Bob could then offer connected-identity and send an UPDATE or reINVITE along with integrity protection back through the chain to A. EP could delay this or discard it, and by the time things have timed out, GW and Bob have been talking for a long time with their media intercepted. While there are a lot of ways one could precondition this thing to death, the easiest fix is to eliminate this scenario by finding a way to apply integrity protect the initial INVITE from GW. The simplest approach I can see to doing that is to tweak RFC 4474 so that it can be applied to PSTN gateways. RFC 4474 in responses would also be darned useful. > > Now, let's turn to the PSTN case, the simplest of which is shown in > Figure 2 of draft-schwartz-sip-e164-ownership-01, namely, someone on > the PSTN calls someone on IP network. As has been widely noted, there > is no technical reason that the PSTN GW can't RFC 4474 sign the From > line, (though it's not clear what that means from the RP's > perspective), but even if the GW doesn't sign, we still have > significant security properties as long as it *verifies* the called > parties signature. As noted, the called parties' response can be altered by an evil proxy in the middle, since the fingerprint in the 200 OK response isn't integrity protected by an RFC 4447 identity header (meaning there is no signature!). We can't rely on identity matching, since SIP's retargeting model is likely to throw the INVITE to just about anybody. So about all the GW can do is verify that the media key fingerprint matches the media -- but since the media key fingerprint can be altered by the attacker, the only reassurance GW has is that's it is talking securely to SOMEBODY, where SOMEBODY might be an attacker, or might be a legitimate retarget. This is kind of like using single-ended TLS to secure HTTP when there's no requirement for a match between the certificate name in the response and the AOR. It doesn't work. > Moreover, since the GW doesn't really know the > caller's identity (because you can't trust the PSTN identity > assertions) this is the best set of properties one could hope for, no > matter what SIP mechanisms we create. Even if there were some > mechanism by which the GW could say "I received this over the > PSTN and the CNID said X", and the relying party trusted the > RP not to lie, it still can't believe this assertion because > the GW's information is untrustworthy. But if we had a way to provide integrity protection over the fingerprint provided by GW, we'd be better off. This has nothing to do with identifying the original caller. I see this as an unfortunate entanglement of the identity of the caller with the identity of the party generating the fingerprint. When there is a gateway involved, these identities DO NOT MATCH, but the current framework approach assumes they do (due to its use of RFC 4474). > [0] But wait, you say. In SIP we don't have any restrictions on > who the call gets retargeted to, so the attacker could just send > his own key with a (valid) RFC 4474 identity pointing to his real > identity. This is absolutely true, and either Alice (or her UI > needs) to notice this, or we need a secure retargeting mechanism, > but this is a separate technical issue. The requirement right > now is that the right identity shows up in Alice's display, and > we get that right. > The attacker doesn't have to send an RFC 4474 Identity header, because he's attacking the response, not the request, as far as the GW is concerned. And RFC 4474 doesn't protect responses. -- 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 sip-bounces@ietf.org Sun Apr 13 15:35:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B42728C135; Sun, 13 Apr 2008 15:35:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1604728C130 for ; Sun, 13 Apr 2008 15:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.735 X-Spam-Level: X-Spam-Status: No, score=-103.735 tagged_above=-999 required=5 tests=[AWL=2.264, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 4SwVVoOYdFRY for ; Sun, 13 Apr 2008 15:35:31 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9FA4A28C1E9 for ; Sun, 13 Apr 2008 15:35:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1208126129!20765668!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 10884 invoked from network); 13 Apr 2008 22:35:30 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 13 Apr 2008 22:35:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3DMZTWw015726 for ; Sun, 13 Apr 2008 18:35:29 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3DMZNia015714 for ; Sun, 13 Apr 2008 18:35:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 13 Apr 2008 17:35:23 -0500 Message-ID: <28F05913385EAC43AF019413F674A017159DD660@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem Thread-Index: Acice7Mvt1i0FGt7Ttu9Paf7i9j6xAA/9pSwAA67XsA= References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Hadriel Kaplan" , "Dean Willis" , Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There is fall back in the circuit switched world, never mind IP over lays for enterprise. > If we made it mandatory for a PSTN gateway to assert identities using > user=phone and documented that Identity headers over an identity with > a user=phone parameter do not assert the "user part" of that identity, > then I think we'd have a complete solution. > Corollary , we need to document that a "phone" UAS that is attached to > the Internet does NOT use "user=phone" even if its user ID is a phone > number and the ENUM entry for that phone number happens to point at > this user ID at this UAS (or supporting domain). There's a problem with that. There are many "phone" UAS's which are ultimately reachable over the PSTN. In fact, I would bet most of them are. If the From of a request is used to store in one's address book, for later requests, then per Paul's desired behavior that later request could only be delivered over sip, or it should fail. One would think if the original request were to be delivered by sip, then a request anytime later the other direction could as well. But that's not the case. For one, transit peering arrangements are not symmetrical, and it's totally possible that calls across providers in one direction go sip the whole way, but calls the other direction cross the PSTN or H.323 or whatever. For another, many enterprises have "PSTN fallback" abilities, so that if their SIP trunks fail for some reason, there is a PRI-type backup. But this issue is somewhat orthogonal to your proposal. And it's leading me to think that we cannot reasonably have a "if sip: then only SIP" behavior solely based on scheme, as Paul seems to feel is currently implied (I think). -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 _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 13 16:56:00 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7413A6B2D; Sun, 13 Apr 2008 16:56:00 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46213A6ADE for ; Sun, 13 Apr 2008 16:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.232 X-Spam-Level: X-Spam-Status: No, score=-4.232 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 0zv9vbEe1ZMV for ; Sun, 13 Apr 2008 16:55:57 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7C4F23A6B2D for ; Sun, 13 Apr 2008 16:55:36 -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 m3DNtGf28049; Sun, 13 Apr 2008 23:55:16 GMT Received: from 47.102.168.204 ([47.102.168.204]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Apr 2008 23:55:59 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sun, 13 Apr 2008 16:55:58 -0700 From: "Francois Audet" To: Paul Kyzivat , Hadriel Kaplan Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcidwesuhMR/DHz+SrWUqPfOHMVPew== In-Reply-To: <48018B2A.40701@cisco.com> Mime-version: 1.0 Cc: SIP IETF , Francois Audet , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm just saying what I've seen. I'm not endorsing it by any means. I'm just saying is has a better chance of working in the real world today than putting a Tel URI on the wire. On Apr12 2008 21:25 , "Paul Kyzivat" wrote: > So you are telling me that you SHOULD forward someone to your own domain > to reach a phone number even when you know that your domain would not be > willing to route the resulting request from the forwardee. Instead you > are *counting* on the forwardee to *ignore* the domain and the 3263 > routing rules and instead use its own logic to reach the number??? > > So in effect you are suggesting that we should revise 3263 regarding sip > URIs with user=phone, and get the result widely adopted rather than get > tel widely adopted. > > Paul > > Hadriel Kaplan wrote: >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Juha >>> Heinanen >>> >>> Francois Audet writes: >>> >>>> Insisting on Tel URI seems kind of out of touch with reality. >>> >>> then PSTN is out of touch with 302. please tell me, how can i write a >>> sip uri in my phone that redirects the caller in another domain to my >>> cell phone? >> >> Well a 302 with a tel may work, or may not. Alternatively you could use a >> sip URI in the 302. For the domain portion of that 302's contact: if you >> don't know a SIP-PSTN provider which will send it to your cell, then you >> could try setting it to your provider's domain (if you have one), or the >> domain which sent the request. And since a 3xx can have multiple contact >> URIs, you can try all these at the same time, including Tel, but I suggest >> making the first one the most likely to succeed, because I've been told some >> devices can't handle multiple contacts either (ya, it's friggin nuts - don't >> shoot the messenger). >> >> It's nasty, but it should work in many cases I think. (though honestly most >> cases I've seen just set it to sip and their provider's domain and it >> works... but that could easily be because I mostly only see traces from >> providers) >> >> -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 sip-bounces@ietf.org Sun Apr 13 17:01:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE4C28C0DF; Sun, 13 Apr 2008 17:01:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD3C3A699E for ; Sun, 13 Apr 2008 17:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.482 X-Spam-Level: X-Spam-Status: No, score=-4.482 tagged_above=-999 required=5 tests=[AWL=0.050, 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 2hD64AfhFFLW for ; Sun, 13 Apr 2008 17:01:45 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 741E028C198 for ; Sun, 13 Apr 2008 17:01:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3E025117116; Mon, 14 Apr 2008 00:02:05 GMT Received: from 47.102.168.204 ([47.102.168.204]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Apr 2008 00:02:04 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sun, 13 Apr 2008 17:02:04 -0700 From: "Francois Audet" To: Juha Heinanen , "Francois Audet" Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcidwsVVCIXut6CMSQuSp6N6CC3Flg== In-Reply-To: <18433.36999.24069.851126@taimen.test.fi> Mime-version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I understand what you are saying. But I have difficulty imagining a case where the owner of the domain of the service provider or enterprise (example.com) would not be able to reach a PSTN gateway. I guess you are worried about a@a.com phoning b@b.com and b.com doesn't have a gateway but wants to forward to PSTN (and wants the originating to fork the bill). So it sends tel URI instead. Sure, but again, I doubt it will work very well. I guess you could cheat and put a.com in the SIP contact. I think there are lots of cases where the domain will be ignored anyways. Again, don't shoot the messenger: it makes sense to me to use Tel URI for this. I am just saying it may cause interop problems. Maybe that's ok, and maybe implementations will start implementing tel URI. On Apr12 2008 21:48 , "Juha Heinanen" wrote: > Francois Audet writes: > >> Every single implementation that I've see does the following: >> >> Contact: sip:+19725551212@example.com;user=phone >> >> Where example.com is the domain of the forwarding user. The SIP proxy will >> then route it to a PSTN if appropriate. > > i think you have not followed this thread. it has been pointed out that > the above does no work if caller does not have the right to use pstn > gateway of example.com. > > -- juha _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 13 18:13:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEB928C27C; Sun, 13 Apr 2008 18:13:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744BF3A6B80 for ; Sun, 13 Apr 2008 18:13:47 -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.225, 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 pWq0ufRytdKo for ; Sun, 13 Apr 2008 18:13:45 -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 468953A6BBF for ; Sun, 13 Apr 2008 18:13:45 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2008 18:14:14 -0700 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 m3E1EE85028219; Sun, 13 Apr 2008 18:14:14 -0700 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 m3E1EE43010135; Mon, 14 Apr 2008 01:14:14 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); Sun, 13 Apr 2008 21:14:14 -0400 Received: from [10.86.243.19] ([10.86.243.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Apr 2008 21:14:13 -0400 Message-ID: <4802B000.3090908@cisco.com> Date: Sun, 13 Apr 2008 21:14:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <3995D068-A311-4BBA-BACC-A734B2560857@softarmor.com> In-Reply-To: X-OriginalArrivalTime: 14 Apr 2008 01:14:13.0892 (UTC) FILETIME=[DA26BC40:01C89DCC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1349; t=1208135654; x=1208999654; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=nEuyZG1ptfxpOk9nvRwmNj1s9k6jQEJNXnqwSagAgsU=; b=RJX5GO9GZ3pBqYd5LK1NhVGwEaMZByXaz7zp/iH5LTPxAs0641vNWeijbD wTCy+WLTmilIPEBuGH9CbJz7bDRZm+LaARrHgXsqWIWl7lqhUTSiwjPuLIjG pRxt4FXQ4l; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ISTM that pieces of the specs, like tel, aren't implemented for a couple of reasons: - they are too hard to implement - there isn't enough bang for the buck - its just not understood Tel clearly isn't *hard* to implement. That rules out the first excuse, and for the second implies that there isn't perceived to be much bang at all, since the bucks are small. So I expect that either it just isn't understood, or else there is perceived to be no benefit at all. If we can demonstrate that there is value here then it seems like it should be possible to get implementors to support it. But maybe I'm being naive. Paul Dean Willis wrote: > > On Apr 13, 2008, at 1:17 AM, Hadriel Kaplan wrote: >> >> So where do we go from here? >> Option 1) Ignore it. This may only be a minor population of the sip >> community; or they may fix it themselves someday; or it may not be a >> real problem if they keep doing what they're doing. >> Option 2) Figure out how to make tel more successful. >> Option 3) Figure out how to make sip with user=phone a true alias. >> Option 4) ?? >> > > I'm inclined to 2 or 3. As the discussion has noted, user=phone is at > best a trifle underdocumented. Either 2 or 3 requires additional spec > work; but at lest the problem is tractable this way. > > -- > 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 sip-bounces@ietf.org Sun Apr 13 18:25:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A2E3A6AF3; Sun, 13 Apr 2008 18:25:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CC53A696E for ; Sun, 13 Apr 2008 18:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 rgCPJgJDF6GB for ; Sun, 13 Apr 2008 18:25:26 -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 0D14F3A6BBF for ; Sun, 13 Apr 2008 18:25:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,651,1199682000"; d="scan'208";a="4961340" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2008 21:25:54 -0400 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 m3E1PstF018494; Sun, 13 Apr 2008 21:25:54 -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 m3E1PsGu003697; Mon, 14 Apr 2008 01:25:54 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); Sun, 13 Apr 2008 21:25:54 -0400 Received: from [10.86.243.19] ([10.86.243.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Apr 2008 21:25:53 -0400 Message-ID: <4802B2BC.8010909@cisco.com> Date: Sun, 13 Apr 2008 21:26:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: In-Reply-To: X-OriginalArrivalTime: 14 Apr 2008 01:25:53.0790 (UTC) FILETIME=[7B52B1E0:01C89DCE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1918; t=1208136354; x=1209000354; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Francois=20Audet=20; bh=JSOEY8uQEp1Pk7TWjeP47dKfQHQt9aHmGQLGrDTdsUI=; b=KgMB/TLsMHdKWftzQvuGzJ6jzMBSZl7jECkPhcjC1u9sXk/xpQVo7GF/fE iMMNnW1nomiw0yJfPtCnKVzM8aSf47co9tljZTsBIvRu3RqwxIJ7TFcd4sxb Sf2ftJtQhl; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If you create a URI that know not to be valid, or don't know to be valid, you are asking for trouble. This is certainly the case with b.com constructs an a.com uri. And its also true when b.com creates a uri with the b.com domain for a phone number not belonging to b.com, and gives it to somebody who has no service relationship with b.com. This might work in some cases, but it is no basis for normative behavior. We need to specify something that can be expected to work. Paul Francois Audet wrote: > I understand what you are saying. > > But I have difficulty imagining a case where the owner of the domain of the > service provider or enterprise (example.com) would not be able to reach a > PSTN gateway. > > I guess you are worried about a@a.com phoning b@b.com and b.com doesn't have > a gateway but wants to forward to PSTN (and wants the originating to fork > the bill). So it sends tel URI instead. Sure, but again, I doubt it will > work very well. > > I guess you could cheat and put a.com in the SIP contact. I think there are > lots of cases where the domain will be ignored anyways. > > Again, don't shoot the messenger: it makes sense to me to use Tel URI for > this. I am just saying it may cause interop problems. Maybe that's ok, and > maybe implementations will start implementing tel URI. > > > On Apr12 2008 21:48 , "Juha Heinanen" wrote: > >> Francois Audet writes: >> >>> Every single implementation that I've see does the following: >>> >>> Contact: sip:+19725551212@example.com;user=phone >>> >>> Where example.com is the domain of the forwarding user. The SIP proxy will >>> then route it to a PSTN if appropriate. >> i think you have not followed this thread. it has been pointed out that >> the above does no work if caller does not have the right to use pstn >> gateway of example.com. >> >> -- juha > > _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 13 18:46:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2F13A6986; Sun, 13 Apr 2008 18:46:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428E43A6986 for ; Sun, 13 Apr 2008 18:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 M6AIX0hii+CA for ; Sun, 13 Apr 2008 18:46:18 -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 E13D93A681A for ; Sun, 13 Apr 2008 18:46:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,651,1199682000"; d="scan'208";a="4962163" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2008 21:46:46 -0400 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 m3E1kkwf023373; Sun, 13 Apr 2008 21:46:46 -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 m3E1kkET008252; Mon, 14 Apr 2008 01:46:46 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); Sun, 13 Apr 2008 21:46:46 -0400 Received: from [10.86.243.19] ([10.86.243.19]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Apr 2008 21:46:45 -0400 Message-ID: <4802B7A0.300@cisco.com> Date: Sun, 13 Apr 2008 21:47:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> In-Reply-To: X-OriginalArrivalTime: 14 Apr 2008 01:46:46.0029 (UTC) FILETIME=[65B733D0:01C89DD1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3686; t=1208137606; x=1209001606; 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]=20Thoughts=20on=20gateways,=20use r=3Dphone,=20and=20the=20Identity/DTLS-SRTP=0A=20problem |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=5oskV58GLXM/Ykhifldh+NVvuo642pDOQcEyIBNqJ8M=; b=f1kvSifuZMmZAnnHWQhjB192HLnRfNJS6WD+mu2GDz03IJMAHMshCtyMGM faebpo9r38iJLdPi2CtmlkmbMs0jO9IIZqH4tXBse0LdiQGVdZAKiUmLO3yx u9hqGIdbVF; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org List" , Dean Willis Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean >> Willis >> >> RFC 3261 Section 19.1.1 says: >> >> The set of valid telephone-subscriber strings is a subset of >> valid user strings. The user URI parameter exists to >> distinguish telephone numbers from user names that happen to >> look like telephone numbers. If the user string contains a >> telephone number formatted as a telephone-subscriber, the user >> parameter value "phone" SHOULD be present. Even without this >> parameter, recipients of SIP and SIPS URIs MAY interpret the >> pre-@ part as a telephone number if local restrictions on the >> name space for user name allow it > > That last sentence is fascinating. If I read it right, it basically allows me to treat a sip URI for my domain without the user=phone as a global E.164, if I so wish. (which so happens to be fairly common in my world) Good, I feel better now. ;) If this is news to you, then you guys really lucked out. :-) >> If we made it mandatory for a PSTN gateway to assert identities using >> user=phone and documented that Identity headers over an identity with >> a user=phone parameter do not assert the "user part" of that identity, >> then I think we'd have a complete solution. >> Corollary , we need to document that a "phone" UAS that is attached to >> the Internet does NOT use "user=phone" even if its user ID is a phone >> number and the ENUM entry for that phone number happens to point at >> this user ID at this UAS (or supporting domain). > > There's a problem with that. There are many "phone" UAS's which are ultimately reachable over the PSTN. In fact, I would bet most of them are. If the From of a request is used to store in one's address book, for later requests, then per Paul's desired behavior that later request could only be delivered over sip, or it should fail. I'm not so rigid as to think gailure is the best option. I can see the conversion from sip to tel as a heuristic to recover from failure to reach the destination via the sip URI in normal ways. It woujld require some thought to decide which particular errors would make sense to retry in this way. But I do think one ought to attempt to honor the intent of the provider of the URI. IMO 3263 is pretty clear about how a sip uri is to be routed. > One would think if the original request were to be delivered by sip, then a request anytime later the other direction could as well. But that's not the case. For one, transit peering arrangements are not symmetrical, and it's totally possible that calls across providers in one direction go sip the whole way, but calls the other direction cross the PSTN or H.323 or whatever. For another, many enterprises have "PSTN fallback" abilities, so that if their SIP trunks fail for some reason, there is a PRI-type backup. I'm not getting your point. Return routing will be based on a different URI provided by the other party. All this discussion applies to that as well. Whether reverse routing is possible is irrelevant here. > But this issue is somewhat orthogonal to your proposal. And it's leading me to think that we cannot reasonably have a "if sip: then only SIP" behavior solely based on scheme, as Paul seems to feel is currently implied (I think). Yes, I think that is implied. And subject to some possible fallback behavior I think it is a good thing, as long as we have a uri (tel) that covers the cases when that isn't the the appropriate. 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 sip-bounces@ietf.org Sun Apr 13 19:20:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7705E3A6D30; Sun, 13 Apr 2008 19:20:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6EB3A6CCE for ; Sun, 13 Apr 2008 19:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 a5NQpAYjnW1c for ; Sun, 13 Apr 2008 19:20:08 -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 9644E3A6887 for ; Sun, 13 Apr 2008 19:20:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,651,1199682000"; d="scan'208";a="4963713" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2008 22:20:35 -0400 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 m3E2KZJ1032012; Sun, 13 Apr 2008 22:20:35 -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 m3E2KZ4h028150; Mon, 14 Apr 2008 02:20:35 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); Sun, 13 Apr 2008 22:20:34 -0400 Received: from [10.86.243.19] ([10.86.243.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Apr 2008 22:20:34 -0400 Message-ID: <4802BF8D.7040602@cisco.com> Date: Sun, 13 Apr 2008 22:21:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> <47FEA3E9.7070404@cisco.com> <092B2658AAB56A4D80836399A4C47031042A1E55@ASHEVS002.mcilink.com> <47FF6B6E.7070508@cisco.com> In-Reply-To: X-OriginalArrivalTime: 14 Apr 2008 02:20:34.0670 (UTC) FILETIME=[1EE140E0:01C89DD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5065; t=1208139635; x=1209003635; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=KGZjsJakuJrKRYQrrGuJBzpPW1DqMlfh6nPtcWy5Pb4=; b=Gorl3+hpVg8Kau8FDb+qWZP46wDNzNZFFXG7bifmudMeQmbCfAjCxsLqDa IRxVRXey5wrEj/pq4lXqk1HLV43jOJvFeNgXlJpW2uHySXT7L0lGFYWVMJLA +cHrI92hvM; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> [snip] >> IMO that is a value of distinguishing tel from sip/user=phone. With sip, >> the supplier of the URI determines the routing. With tel, the originator >> of the call determines the routing. > > You're implying the supplier or originator of the URI cares, or has a way to let its user determine this. Afaik, there is no button on phones for "let people call me only through sip" vs. "let people call me however they can". Most vendors assume people want the latter, I suspect. But since most or at least many devices use sip: all the time period, and most proxy/etc. vendors want calls to work because their customers do, they will route it whichever way they can to do so. As I've said elsewhere it doesn't upset me to have pstn routing used as a fallback. But the common behavior we've been discussing has never stated the sip routing will be preferentially tried. Regarding whether the phone gives the user a way to specify this behavior: it would be an unusual user who would understand how to use such an option. But I can see how particular devices, based on their design of configuration, would decide this one way or another. Audio-only devices might just use tel all the time, since sip routing might not give them any benefit. Multimedia devices, and devices with fancy audio capabilities might choose to advertise a sip URI because there is little benefit to them otherwise. > A second problem is the desired behavior of using the From for later requests. Since UA's register a sip URI typically, and they use this for the From of their requests, the far-end UAS will get that From. Since the UAS would then use this URI for its address book to generate new requests later, by your earlier emails this implies that UAS only wants the request to purely stay sip. This does require some additional clarification. At the moment it is not legal to register a tel URI. So you must register the sip equivalent instead. There would need to be some clarification about the cases where a tel may be used with a sip phone number registration. Or else maybe it would be better to make registering a tel URI valid. I don't currently have a strong opinion on one vs the other. > That would be ok if the original request stayed sip the entire path to the UAS, > and the reverse path sometime later could also stay sip. > There are actually cases where that's not going to be true, but let's assume it > is for now. So imagine if the original request had a sip From but a tel req-uri. > For some reason this request gets routed through the PSTN, back over SIP to the > final dest UAS. If the PSTN-SIP gateway uses a tel From we're ok, but if it > uses a sip From then per the desired behavior the UAS would use this sip URL > in later requests and not be able to use the PSTN or whatever to get it back. Well, with the semantics we are trying to sort out, it would be entirely appropriate for the GW to use a tel uri for To-, From-, and R-URIs. Since the incoming call is from the PSTN it has no data to suggest that the caller can be reached any other way. I suppose it could use a sip URI identifying itself, if it *wants* to take responsibility for any return calls, but that is an unlikely scenario. > That, to me, is why this desired behavior is so brittle. There are just so > many times/ways a sip URL in the From or req-uri is used when it ostensibly > shouldn't, that operators have little choice but to ignore it to make calls work. > I think this may be fixable eventually, but I'm not quite sure how to do that > and keep all the semantics you're looking for, without having calls fail in > the transition period - which is a non-starter. > > >> It is the desire to ignore the domain name in the sip URI that leads to >> your need to have this special, unenforceable, policy on responsibility. >> (Well, its enforceable in a legal sense with peering agreements, but >> that builds a closed garden.) > > People don't "desire" to ignore the domain name, they "desire" to make calls work. If all UA's sent using tel URLs when they should per your definition, we probably wouldn't be having this conversation. :) I'm proposing what I think is a more sensible and functional arrangement if everybody followed it. Obviously everybody doesn't follow it now, we need to figure out if there is a feasible migration path. But its not like everything that should work does work today (or we wouldn't be having this conversation), so there is need to figure stuff out in any case. (My general philosophy of architecture is to first figure out when I want to be, then figure out how to get there, and finally make compromises if I can't find a way to get there. If instead you just find the easiest thing you can do, you just end up going in circles and making a hodge-podge.) 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 sip-bounces@ietf.org Sun Apr 13 19:56:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C233A6CCE; Sun, 13 Apr 2008 19:56:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356753A6CCE for ; Sun, 13 Apr 2008 19:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_45=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 F+p470foGXW4 for ; Sun, 13 Apr 2008 19:56:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 49ED53A68B0 for ; Sun, 13 Apr 2008 19:56:48 -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.240.5; Sun, 13 Apr 2008 22:56:47 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 22:56:45 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Sun, 13 Apr 2008 22:59:35 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acid1hBgsIym99KlTIuWGFdZNkfwfAAAuI9w Message-ID: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> <47FEA3E9.7070404@cisco.com> <092B2658AAB56A4D80836399A4C47031042A1E55@ASHEVS002.mcilink.com> <47FF6B6E.7070508@cisco.com> <4802BF8D.7040602@cisco.com> In-Reply-To: <4802BF8D.7040602@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > As I've said elsewhere it doesn't upset me to have pstn routing used as > a fallback. But the common behavior we've been discussing has never > stated the sip routing will be preferentially tried. Ah. Well, in my world it's not a black-white thing. I always like to think sip end-end is preferential, but there are cases due to least-cost-routing or regulatory requirements that the PSTN is used when there was a sip path. But anyway, if you think it's ok to use PSTN as a fallback for a sip: request, then I'm not sure what the problem is? I mean that effectively weakens the scheme to be basically what we have now, no? > Well, with the semantics we are trying to sort out, it would be entirely > appropriate for the GW to use a tel uri for To-, From-, and R-URIs. > Since the incoming call is from the PSTN it has no data to suggest that > the caller can be reached any other way. I suppose it could use a sip > URI identifying itself, if it *wants* to take responsibility for any > return calls, but that is an unlikely scenario. Totally, but it's not what they're doing. (some are good about this, some ain't) And Dean is currently proposing a GW uses a sip: From URI, with a user=phone, so it can be signed. But that is another of the many issue threads. :) > I'm proposing what I think is a more sensible and functional arrangement > if everybody followed it. Obviously everybody doesn't follow it now, we > need to figure out if there is a feasible migration path. But its not > like everything that should work does work today (or we wouldn't be > having this conversation), so there is need to figure stuff out in any > case. I'm trying to remember how we got on this topic, because things are working fine with-respect-to sip as a default scheme, afaik. I think it's architecturally ugly, and will cause us grief later, but I can't seem to recall what current "problem" drove this particular topic.(?) -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 sip-bounces@ietf.org Sun Apr 13 20:10:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C813A6989; Sun, 13 Apr 2008 20:10:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562BE3A6D77 for ; Sun, 13 Apr 2008 20:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XbvLNbWymzP for ; Sun, 13 Apr 2008 20:10:54 -0700 (PDT) Received: from omzesmtp03a.verizonbusiness.com (omzesmtp03a.verizonbusiness.com [199.249.25.201]) by core3.amsl.com (Postfix) with ESMTP id C6F723A6988 for ; Sun, 13 Apr 2008 20:10:53 -0700 (PDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0JZA00D8SOUY6L00@firewall.verizonbusiness.com> for sip@ietf.org; Mon, 14 Apr 2008 03:11:22 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([127.0.0.1]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZA00CHROUYQZ@dgismtp01.mcilink.com> for sip@ietf.org; Mon, 14 Apr 2008 03:11:22 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([153.39.68.168]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZA00D45OUXEP@dgismtp01.mcilink.com> for sip@ietf.org; Mon, 14 Apr 2008 03:11:22 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 03:11:21 +0000 Date: Mon, 14 Apr 2008 03:11:20 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: To: Hadriel Kaplan , Paul Kyzivat Message-id: <092B2658AAB56A4D80836399A4C47031042E3878@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Sip] E.164 - who owns it Thread-index: Acid1hBgsIym99KlTIuWGFdZNkfwfAAAuI9wAAC/E1A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BA@GBNTHT12009MSX.gb002.siemens.net> <200804090231.m392V1oX026567@dragon.ariadne.com> <406b01c899f9$68c470f0$c5f0200a@cisco.com> <200804091555.m39FtLa6020989@dragon.ariadne.com> <18428.60275.209757.845202@taimen.test.fi> <47FCF2BD.9010808@cisco.com> <1ECE0EB50388174790F9694F77522CCF160A41B0@zrc2hxm0.corp.nortel.com> <0f5c01c89ab5$0ec99870$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF035D4FC9@zrc2hxm0.corp.nortel.com> <102501c89ac2$30337230$c5f0200a@cisco.com> <1ECE0EB50388174790F9694F77522CCF160F4DC4@zrc2hxm0.corp.nortel.com> <47FE4AF4.4060401@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD531@ASHEVS002.mcilink.com> <47FE6787.1080001@cisco.com> <092B2658AAB56A4D80836399A4C47031037DD540@ASHEVS002.mcilink.com> <47FEA3E9.7070404@cisco.com> <092B2658AAB56A4D80836399A4C47031042A1E55@ASHEVS002.mcilink.com> <47FF6B6E.7070508@cisco.com> <4802BF8D.7040602@cisco.com> <"E6C 2E8958BA59A4FB960963D475F7AC30BCC01CE02"@mail.acmepacket.com> X-OriginalArrivalTime: 14 Apr 2008 03:11:21.0916 (UTC) FILETIME=[372E17C0:01C89DDD] Cc: sip@ietf.org Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > As I've said elsewhere it doesn't upset me to have pstn routing used as > > a fallback. But the common behavior we've been discussing has never > > stated the sip routing will be preferentially tried. > > Ah. Well, in my world it's not a black-white thing. I > always like to think sip end-end is preferential, but there > are cases due to least-cost-routing or regulatory > requirements that the PSTN is used when there was a sip path. > But anyway, if you think it's ok to use PSTN as a fallback > for a sip: request, then I'm not sure what the problem is? I > mean that effectively weakens the scheme to be basically what > we have now, no? Seems that way to me. Any such rule would have to allow for network policy, and there are lots of legitimate policies e.g., least cost routing and the necessity of SIP peering agreements, that would result in its not being followed. In the end this is a business issue not a technical one. tim _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 13 20:18:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C473A6DFF; Sun, 13 Apr 2008 20:18:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD4B3A6DF4 for ; Sun, 13 Apr 2008 20:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_45=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 Qqoy3PATSgFN for ; Sun, 13 Apr 2008 20:18:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 544443A6C3D for ; Sun, 13 Apr 2008 20:18: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.240.5; Sun, 13 Apr 2008 23:18:40 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 13 Apr 2008 23:18:40 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Sun, 13 Apr 2008 23:21:31 -0400 Thread-Topic: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem Thread-Index: Acid0VgubnOm1FpgSQuLkqCEqFqZqwAClHkQ Message-ID: References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> <4802B7A0.300@cisco.com> In-Reply-To: <4802B7A0.300@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" , Dean Willis Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > But I do think one ought to attempt to honor the intent of the provider > of the URI. IMO 3263 is pretty clear about how a sip uri is to be routed. Yes, but I'm not clear which part of 3263 *isn't* being honored. You set your req-uri to sip:123456789@example.com, it reaches example.com, example.com says "hmm, not one of my users, I'll consider this a telephone number, and try the SIP-trunk or PSTN or whatever". It reached the intended sip target domain (example.com). > [snipped stuff] > I'm not getting your point. Return routing will be based on a different > URI provided by the other party. All this discussion applies to that as > well. Whether reverse routing is possible is irrelevant here. Dean had said we would need to get "phones" to NOT use "user=phone", while GW's do - both using a sip: From. I had thought you were saying a sip scheme demands a SIP path be used. So my point was that just because I can get a SIP request to sip:pkyzivat@cisco.com, with a signed From of sip:123456789@acmepacket.com, and you store that in your address book, does not mean you can then 2 days later get a request to sip:123456789@acmepacket.com to stay SIP to me. It does not mean I wanted to only be reachable by SIP, and it does not mean *you* (the human) only want to reach me via SIP when you send it. That's all - just reiterating the same as before really. Nothing to see here, move along... :) -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 sip-bounces@ietf.org Sun Apr 13 21:18:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75ECB3A6989; Sun, 13 Apr 2008 21:18:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C733A696E for ; Sun, 13 Apr 2008 21:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 3vqT085wac4g for ; Sun, 13 Apr 2008 21:18:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6F4DC3A6988 for ; Sun, 13 Apr 2008 21:18: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.240.5; Mon, 14 Apr 2008 00:18:11 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 14 Apr 2008 00:18:11 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Dean Willis Date: Mon, 14 Apr 2008 00:21:01 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcidzMq/vmC/RTkTQ9e+HSbNLey6HAAFLGeQ Message-ID: References: <3995D068-A311-4BBA-BACC-A734B2560857@softarmor.com> <4802B000.3090908@cisco.com> In-Reply-To: <4802B000.3090908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > ISTM that pieces of the specs, like tel, aren't implemented for a couple > of reasons: > - they are too hard to implement > - there isn't enough bang for the buck > - its just not understood > > Tel clearly isn't *hard* to implement. That rules out the first excuse, > and for the second implies that there isn't perceived to be much bang at > all, since the bucks are small. So I expect that either it just isn't > understood, or else there is perceived to be no benefit at all. > If we can demonstrate that there is value here then it seems like it > should be possible to get implementors to support it. But maybe I'm > being naive. Well, under the "not enough bang for buck" category would be the "it sometimes fails" sub-type. I find that with many of the things in sip, because lots of equipment is already deployed, if a mechanism introduces a call failure probability it would have to have a really BIG benefit to overcome that. Using a TEL URI just isn't something that can be ignored, or negotiated. New devices introduced into an already deployed network have to work seamlessly with the legacy crap, or they don't get in. So it may well be that lots of devices are now able to handle TEL, and we'll just never know it due to this vicious cycle. :( -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 sip-bounces@ietf.org Sun Apr 13 21:27:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D3B3A6CCE; Sun, 13 Apr 2008 21:27:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3740C3A6CCE for ; Sun, 13 Apr 2008 21:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 emmXu-yz8muq for ; Sun, 13 Apr 2008 21:27:20 -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 D0C4C3A6890 for ; Sun, 13 Apr 2008 21:27:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,652,1199682000"; d="scan'208";a="4969225" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2008 00:27:49 -0400 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 m3E4RnKF022748; Mon, 14 Apr 2008 00:27:49 -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 m3E4RmtK026540; Mon, 14 Apr 2008 04:27: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, 14 Apr 2008 00:27:49 -0400 Received: from [10.86.243.19] ([10.86.243.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 00:27:48 -0400 Message-ID: <4802DD5E.3030203@cisco.com> Date: Mon, 14 Apr 2008 00:28:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> <4802B7A0.300@cisco.com> In-Reply-To: X-OriginalArrivalTime: 14 Apr 2008 04:27:48.0455 (UTC) FILETIME=[E4F86770:01C89DE7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3547; t=1208147269; x=1209011269; 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]=20Thoughts=20on=20gateways,=20use r=3Dphone,=20and=20the=20Identity/DTLS-SRTP=0A=20problem |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=91GGkI8PtjNKQrSrq5CkvJcqUhYMI4h5PZYP7Racuao=; b=hdVVIXid0FspQC6yDPq8RYFUIhvPUSuHArlyEkNgA7Wxfd62hX7rwNPPIq 9pPZfiYrQ1jGFZRem8kuHnvrRXjMNmLzA8z9b1GXrYB1/kJS3QO0X+G6D0u6 U9FSM1ioHG; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "sip@ietf.org List" , Dean Willis Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> But I do think one ought to attempt to honor the intent of the provider >> of the URI. IMO 3263 is pretty clear about how a sip uri is to be routed. > > Yes, but I'm not clear which part of 3263 *isn't* being honored. You set your req-uri to sip:123456789@example.com, it reaches example.com, example.com says "hmm, not one of my users, I'll consider this a telephone number, and try the SIP-trunk or PSTN or whatever". It reached the intended sip target domain (example.com). I have absolutely *no* problem with that, *if* it reaches example.com before being translated. That is policy business between you and your home proxy. I have a problem when it passes through foo.com which then decides this is a phone number and routes it to a GW without it ever going to example.com. And I am hearing you (I think) and others saying that is common practice and in fact necessary in many cases for calls not to fail. >> [snipped stuff] >> I'm not getting your point. Return routing will be based on a different >> URI provided by the other party. All this discussion applies to that as >> well. Whether reverse routing is possible is irrelevant here. > > Dean had said we would need to get "phones" to NOT use "user=phone", > while GW's do - both using a sip: From. That is a somewhat interesting proposal. But it does change the existing semantics of user=phone. So I hope we can keep that as a separate discussion. > I had thought you were saying > a sip scheme demands a SIP path be used. I believe it does, just as much as sips demands that a sips path be used, http demands that an http path be used, etc. If somebody gives you an http URL, do you think it is an intended usage for you to transform it into an ftp URL? It in fact may work to transform the http into an ftp URL. But if so that is a special case that can only be known to work based on extra context. In the case of sip, we might say that user=phone is provides that extra context. IMO that is still just a heuristic, not a standard behavior. If we want it to be a sanctioned standard behavior then we need to write some new specs. > So my point was that just > because I can get a SIP request to sip:pkyzivat@cisco.com, with a signed > From of sip:123456789@acmepacket.com, and you store that in your address > book, does not mean you can then 2 days later get a request to > sip:123456789@acmepacket.com to stay SIP to me. Well, there are no *guarantees*. But IMO you ought not to be using that as your From address if you *expect* callbacks to work and you don't at least *expect* that the returns will work via an all-sip path. If you don't think so, then IMO you ought to put a TEL URI in the From. > It does not mean I wanted > to only be reachable by SIP, and it does not mean *you* (the human) only > want to reach me via SIP when you send it. That's all - just reiterating > the same as before really. Nothing to see here, move along... :) I disagree. IMO this is indeed the true distinction between sip and tel. Paul > -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 > _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 13 22:13:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7072C3A6C41; Sun, 13 Apr 2008 22:13:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2393A6A00 for ; Sun, 13 Apr 2008 22:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_45=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 cnhxK+AXhP1f for ; Sun, 13 Apr 2008 22:13:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 45A803A6AF0 for ; Sun, 13 Apr 2008 22:13:36 -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.240.5; Mon, 14 Apr 2008 01:13:36 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 14 Apr 2008 01:13:37 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 14 Apr 2008 01:16:24 -0400 Thread-Topic: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem Thread-Index: Acid59Y20876j39SRVKW4obhe4YFHgAAOP6w Message-ID: References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> <4802B7A0.300@cisco.com> <4802DD5E.3030203@cisco.com> In-Reply-To: <4802DD5E.3030203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" , Dean Willis Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Hadriel Kaplan wrote: > > Yes, but I'm not clear which part of 3263 *isn't* being honored. You > set your req-uri to sip:123456789@example.com, it reaches example.com, > example.com says "hmm, not one of my users, I'll consider this a telephone > number, and try the SIP-trunk or PSTN or whatever". It reached the > intended sip target domain (example.com). > > I have absolutely *no* problem with that, *if* it reaches example.com > before being translated. That is policy business between you and your > home proxy. > > I have a problem when it passes through foo.com which then decides this > is a phone number and routes it to a GW without it ever going to > example.com. And I am hearing you (I think) and others saying that is > common practice and in fact necessary in many cases for calls not to fail. Ahhh... crap, we were talking past each other. No, it is not common usage afaik for a sip request to example.com to be shunted to the PSTN by foo.com. It may well be that's what would happen, but as far as I know it's incredibly rare for foo.com to get a request for example.com to begin with. Because afaict no one knows what "final" target domain to set for the req-uri, other than their local enterprise's or provider's, who then changes it to their next-hop domain, and so on. This works, because they're really all "routing" based on phone numbers at the end of the day. [I am ignoring the visited proxy model, because such roaming is still rare in SIP afaik] If a request for example.com were to arrive at foo.com, and it accepted it, I still think it could try it to the PSTN if example.com were a customer of foo.com's and the number was one of example.com's. (ie, if foo.com was a provider and had a pstn-fallback service for its enterprise customer example.com) But that's probably a nit? > > I had thought you were saying > > a sip scheme demands a SIP path be used. > > I believe it does, just as much as sips demands that a sips path be > used, http demands that an http path be used, etc. Interestingly, I had thought we decided sips did not carry that semantic a long time ago - if you set the req-uri to sips:123456789@example.com, and it reached example.com over TLS, example.com formed the end of that URI domain and could send it into the PSTN or whatever at will. > If somebody gives you an http URL, do you think it is an intended usage > for you to transform it into an ftp URL? > It in fact may work to transform the http into an ftp URL. But if so > that is a special case that can only be known to work based on extra > context. If someone set an http URL, I would expect it to be HTTP to the target domain of that URL. But that web server could use FTP behind the scenes to retrieve its data to feed to you over HTTP, or could use TFTP, or NFS, or any protocol of its choosing. -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 sip-bounces@ietf.org Mon Apr 14 04:44:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64DD28C2D5; Mon, 14 Apr 2008 04:44:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD8D28C2B8 for ; Mon, 14 Apr 2008 04:44:17 -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 uiF3iGJdGS3a for ; Mon, 14 Apr 2008 04:44:11 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id DBE7A28C2C6 for ; Mon, 14 Apr 2008 04:44:11 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so573356rvf.49 for ; Mon, 14 Apr 2008 04:44:42 -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:to:subject:mime-version:content-type; bh=KQm8kZ7qYRZbJ1AT/RelUX8cmzcpHxA00w/f6htr9eU=; b=kJnShQx1w7xmcRIrhVN5p9JqATpdTjSMJb6UFua614XwCQLx3AZffPxJBKrL2vOAruq4PVAcPhzfXNkdejSoYY67GEtDhU+6yzhc2R+pvX1tt+gvc9MS3jtHDXgJ8qPqRHkSdkPmObOcgjP8Ww86Hh7oMTamdwX7u4s71Z4P9/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Y/LvQjBUw+kTN/WFsm0en2DLQ7Pgk/AqrvK2ZTK2d+sVvtYEWgdWdtGZ7bgO9dTgqEsOHvA0y5Rn4CaSgchnZGzZRo2rSDSk3LgBF9Rd8wQWETBsMzMwuimgEHGdqgJwS1gYJs9ne5hL4xbqGCGnA3pHOTKGaEofhhdmvf9oIT0= Received: by 10.140.249.20 with SMTP id w20mr3265392rvh.189.1208173482255; Mon, 14 Apr 2008 04:44:42 -0700 (PDT) Received: by 10.141.97.13 with HTTP; Mon, 14 Apr 2008 04:44:42 -0700 (PDT) Message-ID: Date: Mon, 14 Apr 2008 17:14:42 +0530 From: "ajay thakur" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] SIP deployment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0968761067==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0968761067== Content-Type: multipart/alternative; boundary="----=_Part_27983_21185079.1208173482269" ------=_Part_27983_21185079.1208173482269 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I have few doubts about SIP deployment. (1) Given that NAT/firewall creates problem for SIP calls. How these problems are solved in the practical deployment. IS it by using STUN or by using SIP-alg. (2) Also i guess not all phones support STUN. How does it work. ? Any idea? Ajay ------=_Part_27983_21185079.1208173482269 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,
I have few doubts about SIP deployment.
 
(1) Given that NAT/firewall creates problem for SIP calls. How these problems
are solved in the practical deployment. IS it by using STUN or by using SIP-alg.
 
(2) Also i guess not all phones support STUN. How does it work. ?
 
Any idea?
 
 
Ajay 
------=_Part_27983_21185079.1208173482269-- --===============0968761067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0968761067==-- From sip-bounces@ietf.org Mon Apr 14 06:12:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C483A6E87; Mon, 14 Apr 2008 06:12:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7ABB3A68DD for ; Mon, 14 Apr 2008 06:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 kbMQOEq3aQUm for ; Mon, 14 Apr 2008 06:12:52 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 6E4523A6E70 for ; Mon, 14 Apr 2008 06:12:52 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id E6ACB22010E; Mon, 14 Apr 2008 06:13:22 -0700 (PDT) Date: Mon, 14 Apr 2008 06:13:22 -0700 From: Eric Rescorla To: Hadriel Kaplan In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080413164218.448A521E995@kilo.rtfm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080414131322.E6ACB22010E@kilo.rtfm.com> Cc: "sip@ietf.org List" , Michael Thomas , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Sun, 13 Apr 2008 13:41:09 -0400, Hadriel Kaplan wrote: > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > > > Well, I don't know what Dean is claiming, but what *I* am claiming > > is that MITM attacks aren't possible as long as at least one side > > uses 4474/4916 and the other side checks the signature. And that > > means that at least in the case of PSTN->SIP calls, we don't > > have an inherent MITM problem. > > Although unrelated to your general point above, the PSTN->SIP case > seems a bit odd to me in practice, for two reasons: 1) What is it > you expect a PSTN GW to do differently in these cases, vs. unsigned > cases? Since the PSTN GW has no way to pass on strength indications > on the PSTN, do you expect it to automatically terminate calls which > aren't 4916 signed? Or play some announcement such as "this call is > not secure"? (and do we honestly think they'd do that?) Well, I don't actually expect them to do either, but that's fundamentally not my problem. We're offering a higher level of security than the PSTN is. If people making calls from the PSTN want to take advantage of that, they'll need to do some ugly stuff. > A > downgrade attack is trivially possible, and leaves the PSTN GW with > no idea if the called side could have actually done 4916 or not. That's not clearly true. As I understand the situation, when this is *your* PSTN gateway, or at least has a relationship with you so that it knows where to route calls to 1234. It's quite possible it could know the capabilities of your proxy. > So > should it just assume if it gets a fingerprint which isn't signed > then there is probably a MitM? (and also not do best-effort srtp > offers) That seems to me making the best the enemy of the good. There's certainly value in unauthenticated encryption against passive attackers. > 2) You said in your email that the retargeting case is orthogonal, > and that either Alice or her UI need to notice this. But if a PSTN > GW is representing Alice, I don't see how that's possible. [this > goes back to a previous thread] I'm not sure how a PSTN GW can know > what the right domain for Bob's signature should be. The PSTN GW > only knows a phone number, period. The 4916 signature may well be > signed by a common trusted CA, but that really doesn't mean what it > does in TLS, because there is no domain name verification possible > to the PSTN GW. In other words, the GW knows it's calling > +123456789, and foo.com signed rfc4916 as sip:123456789@foo.com, > with a cert for foo.com. The common CA did verify foo.com is truly > foo.com, but so what? The PSTN GW has no idea if the 123456789 at > foo.com is the same global +123456789 that the PSTN meant to reach, > or some legitimate open phone hosting service that happens to have > usernames which collide with Fidelity's E.164, or even just another > PSTN gateway. In other words, what stops me (bad guy), from getting > an account on foo.com with that number, and redirecting calls from > PSTN GW to my account? And this has what to do with RFC 4474 or DTLS-SRTP? This is a pure routing issue: the GW needs to know what proxy to contact for phone number X. That configuration could (or could not) contain an indicator of whether 4916 is expected and what certificate should be used. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 06:27:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5657C3A6C90; Mon, 14 Apr 2008 06:27:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3CB3A6C90 for ; Mon, 14 Apr 2008 06:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.591 X-Spam-Level: X-Spam-Status: No, score=-5.591 tagged_above=-999 required=5 tests=[AWL=1.008, 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 YEj5IZfD4nfm for ; Mon, 14 Apr 2008 06:27:12 -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 863803A6B1D for ; Mon, 14 Apr 2008 06:27:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,655,1199682000"; d="scan'208";a="5007468" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Apr 2008 09:27:42 -0400 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 m3EDRg0n023599; Mon, 14 Apr 2008 09:27:42 -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 m3EDRgAF012692; Mon, 14 Apr 2008 13:27:42 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, 14 Apr 2008 09:27:42 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 09:27:42 -0400 Message-ID: <48035BEA.90301@cisco.com> Date: Mon, 14 Apr 2008 09:28:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080413164218.448A521E995@kilo.rtfm.com> <20080414131322.E6ACB22010E@kilo.rtfm.com> In-Reply-To: <20080414131322.E6ACB22010E@kilo.rtfm.com> X-OriginalArrivalTime: 14 Apr 2008 13:27:42.0124 (UTC) FILETIME=[511A06C0:01C89E33] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=811; t=1208179662; x=1209043662; 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]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Eric=20Rescorla=20; bh=cICxWi5UFp96zzxNptvOP/SWjGU7T+Bj0yeDoJ3Ggik=; b=gS2WCqNdKZNgBhvdBFyJ8gM7//mt910KKKZ3TgEZUSoQ3Oi8yNb86g4seO 0FOaboRMQfNYg/drrpcFLNx/wWOrZ8l0UTCbnhXzsMB8VGmPeGQNXPTJpWmv f12wl4rZlT; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org List" , Michael Thomas , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: [snip] > And this has what to do with RFC 4474 or DTLS-SRTP? This is a pure > routing issue: the GW needs to know what proxy to contact for phone > number X. That configuration could (or could not) contain an > indicator of whether 4916 is expected and what certificate should > be used. There's a difference between knowing a place to send the request so that it will eventually reach the right destination, and knowing the ultimate destination. There could be a *lot* of GWs, that typically are pretty dumb, and depend on some other routing element (e.g. proxy) to get the request to the right place. You seem to be saying that the GW needs to know a lot more than that to secure the call. Far from ideal. Is that right, or am I missing something? 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 sip-bounces@ietf.org Mon Apr 14 07:11:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB523A6888; Mon, 14 Apr 2008 07:11:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF09B3A6A4C for ; Mon, 14 Apr 2008 07:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 g8UH92Qg25Kl for ; Mon, 14 Apr 2008 07:10:59 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id A15C83A6E9C for ; Mon, 14 Apr 2008 07:10:51 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 3D1E1220531; Mon, 14 Apr 2008 07:11:22 -0700 (PDT) Date: Mon, 14 Apr 2008 07:11:22 -0700 From: Eric Rescorla To: Paul Kyzivat In-Reply-To: <48035BEA.90301@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080413164218.448A521E995@kilo.rtfm.com> <20080414131322.E6ACB22010E@kilo.rtfm.com> <48035BEA.90301@cisco.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080414141122.3D1E1220531@kilo.rtfm.com> Cc: "sip@ietf.org List" , Michael Thomas , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Mon, 14 Apr 2008 09:28:10 -0400, Paul Kyzivat wrote: > > > > Eric Rescorla wrote: > [snip] > > > And this has what to do with RFC 4474 or DTLS-SRTP? This is a pure > > routing issue: the GW needs to know what proxy to contact for phone > > number X. That configuration could (or could not) contain an > > indicator of whether 4916 is expected and what certificate should > > be used. > > There's a difference between knowing a place to send the request so that > it will eventually reach the right destination, and knowing the ultimate > destination. There could be a *lot* of GWs, that typically are pretty > dumb, and depend on some other routing element (e.g. proxy) to get the > request to the right place. Yep. This is a fundamental issue of integrity for SIP call routing. > You seem to be saying that the GW needs to know a lot more than that to > secure the call. Far from ideal. Is that right, or am I missing something? I agree it's far from ideal. There are two possible solutions to this sort of problem: - Some sort of authenticated history mechanism that gives the gateway confidence that the call was routed correctly - Enough UI to tell the user who *actually* answered the call. Unfortunately, the second isn't available here because of the lame PSTN UI. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 07:53:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37483A6AFF; Mon, 14 Apr 2008 07:53:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CC83A6E71 for ; Mon, 14 Apr 2008 07:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[AWL=1.216, 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 mz48j2K6sWLH for ; Mon, 14 Apr 2008 07:53:02 -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 9B94E3A6C82 for ; Mon, 14 Apr 2008 07:53:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,655,1199692800"; d="scan'208,217";a="21516741" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2008 07:53:32 -0700 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 m3EErWpO024911; Mon, 14 Apr 2008 07:53:32 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.13.8/8.13.8) with SMTP id m3EErVDk010659; Mon, 14 Apr 2008 14:53:31 GMT Message-Id: <29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> From: Cullen Jennings To: Dean Willis In-Reply-To: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 07:53:14 -0700 References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18259; t=1208184812; x=1209048812; c=relaxed/simple; s=sjdkim1004; 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=20Proposal=20to=20Revise=20RFC=204474 |Sender:=20; bh=4RigNXhmEuq/z7z4mi6Ul0BcJrbQNS+Rw6/MmN4PSbs=; b=X8OyFVjdS368/FEzIdeIIqiCLlS9kG9QzIYXW6xQ8YUzi2sIpordhKFYZ7 lKnaMMIfsx4USS4J39sPgZMmuBaDsPf3Tn9sxgCGR+QK9T/Q4YP6ybeJsZ5y fS/mP5p7mlaA2tsAAouvxJAkwcb3mujQb3UjeqT72HtXEI7xYmV9Q=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "sip@ietf.org List" , Jon Peterson Subject: Re: [Sip] Proposal to Revise RFC 4474 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0365955781==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0365955781== Content-Type: multipart/alternative; boundary=Apple-Mail-1-96844411 --Apple-Mail-1-96844411 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dean, Thanks for taking the lead here on trying to get a handle on what needs to be done. Reading your message, what strikes me is that these issues are bigger than just RFC 4474 - although in some cases changes to RFC 4474 may be part of the solution. So, I'd like to see the WG focus on is getting a crisp definition of the problem and how to solve it, rather than asking what changes to 4474 are required just yet. On Apr 12, 2008, at 1:26 AM, Dean Willis wrote: > > We've had a lot of recent discussions about issues relating to the > use of RFC 4474, and I've had a bunch of side conversations with > people this week on the same topic. > > Here's where I think we're at: > > RFC 4474 is pretty good. Since it was published, we've learned more > about the problem space. In the largest part, we've learned that the > authors of RFC 4474 and the working group did an excellent job of > analyzing the fundamental requirements for attaching forward > authentication (as opposed to challenge-response) to SIP. We've also > learned that the real world has some nastiness that isn't quite > covered by RFC 4474, but it appears that very small adjustments to > the specification could cover most or all of the cases we've > discovered. > > > I'd therefore like to propose that the working group consider the > task of narrowly revising RFC 4474 to account for four specific > points: > > 1) Revising the "what gets signed" aspect to allow modification of > the SDP by the SBCs we seem to keep encountering. While it is > important to verify the SDP, we now have the DTLS-SRTP framework to > vouch for the authenticity of the media channel. I suggest that > there not be any optionality to "what gets signed", but that the > fixed set of items be revised so as to allow SBC operations, and to > note the dependency on DTLS-SRTP for media authentication. Based on the discussion I've seen so far, the primary use case for this modification is to allow the SBC to do media steering so it can steer the RTP through a path that provides better QoS. As you say, this could be achieved by modifying the SDP and changing RFC 4474 to allow that, but there are probably some other approaches we should be considering as well, including ones that may need to be done outside of SIP. If there's consensus that this is the problem that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC chairs and figure out a process for how to evaluate the various options and get this moving forward. If this isn't the primary use case, then I think we probably need some more discussion to get a clearer idea of what the problem is. > > > 2) RFC 4474 did not consider the requirements of calls transiting > gateways and the issues related to expressing identities that > originate outside the Internet, specifically phone numbers delivered > via caller ID. While RFC 4474 can say nothing authoritative about > the phone number, it seems that it could quite reasonably say > something authoritative about the gateway. We've seen several > proposals for doing this using conventions for the expression of > "phone" identities in the From header field. I believe that a > revised RFC 4474 is the place to document such a convention and any > needed extension parameters. It seems to me that there are actually two issues here: - To have a way for the gateway to say: 'this URI corresponds to a phone number' - To have a way for receiver of the above assertion to determine whether to trust it. These are actually separable. The first function may be useful as an indicator even if we don't have a technical mechanism for enforcing it. In fact, based on the discussion in Philadelphia, there seemed to be some feeling that 'user=phone' already performed this function. So, I would encourage the WG to figure out whether that's so or not and if not, and if it is not, and we decide we need a way to do this, clearly the some WG could go construct something that did indicate this (a "userpart=e164" sip uri tag for example). The second function sees substantially more complicate, and while it might involve modifying 4474, it might be something completely external to RFC 4474 (e.g., enum, Dan's return routability draft). This seems like a much more complicated problem than a simple indicator, and I'd like to see the WG study the solution space some before trying to close on a single approach > > > 3) There seems to be a valid model for what I call "stacked" > Identity header fields that express transitive assertions. Consider > authentication domains A, B, and C, where B is a transit domain > between A and C. B would be likely to trust assertions made by A, > and might not know whether C is or is not equipped to evaluate > assertions made by A. However,, it might be reasonable to expect > that C would be able to validate assertions made by B. B might > therefore choose to validate the Identity header inserted by A, and > then (assuming the header authenticates) add another Identity header > using its own credentials, saying in effect "B validated A's > identity header and found it good". If C can validate A's Identity > header directly, it would do so. If not, it could choose to rely on > B's assertion. This transitive trust seems to be something that is used in real deployments and it would be good to have some discussions around it. That said, while there's been a fair bit of mailing list discussion, I'm not sure the requirements are. For example if C is willing go trust B, but B wants to lie, can B just remove A assertion forcing C to rely on B's assertion? How much information does C need to include about its evaluation policies? I would be looking for more consensus and understanding about what the problem before charting some work on a solution. > > > 4) There are cases, including authentication services in the UAS and > authentication services in a proxy having an "outbound" relationship > (pre-authenticated persistent TLS) with the UAS where, in the > absence of retargeting, an Identity header field could reasonably be > included in a response as an alternative to using the more > cumbersome connected-identity approach with UPDATE. I expect this > to be very useful in P2PSIP, but it has broader utility. So I would > like to see RFC 4474 extended to allow its use in responses where > it would work. > I like this idea. Once outbound is done, as you point out, it opens up some ways for a proxy to authenticate both requests and responses coming from a UA which in turn might allow Identity like assertions in response. I be keen on drafts that extended 4474 and outbound to do this, provided that outbound does not get blocked on these changes. > -- > Dean So, while all four of these points seem to be coupled with areas where we need discussion and work, I think it's a bit premature to decide that what's needed is an update to RFC 4474. Rather, I'd like to see the WG (and other WGs as required) figure out what the best technical approach is for each of these points, and if that requires changing 4474 or 3261 or anything else, we can do that. Cullen --Apple-Mail-1-96844411 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable


On Apr 12, 2008, = at 1:26 AM, Dean Willis wrote:

We've had a lot of recent = discussions about issues relating to the use of RFC 4474, and I've had a = bunch of side conversations with people this week on the same = topic.

Here's where I think we're = at:

RFC 4474 is pretty good. = Since it was published, we've learned more about the problem space. In = the largest part, we've learned that the authors of RFC 4474 and the = working group did an excellent job of analyzing the fundamental = requirements for attaching forward authentication (as opposed to = challenge-response) to SIP. We've also learned that the real world has = some nastiness that isn't quite covered by RFC 4474, but it appears that = very small adjustments to the specification could cover most or all of = the cases we've discovered.


I'd therefore like to = propose that the working group consider the task of narrowly revising = RFC 4474 to account for four specific = points:

1) Revising the "what gets = signed" aspect to allow modification of the SDP by the SBCs we seem to = keep encountering. While it is important to verify the SDP, we now have = the DTLS-SRTP framework to vouch for the authenticity of the media = channel. I suggest that there not be any optionality to "what gets = signed", but that the fixed set of items be revised so as to allow SBC = operations, and to note the dependency on DTLS-SRTP for media = authentication.

Based on = the discussion I've seen so far, the primary use case = for
this modification is to allow the SBC to do media steering so it = can
steer the RTP through a path that provides better QoS. As you = say,
this could be achieved by modifying the SDP and changing RFC = 4474 to
allow that, but there are probably some other approaches we = should be
considering as well, including ones that may need to be = done outside
of SIP. If there's consensus that this is the = problem
that needs solving, then I'll get with the SIP, SIPPING, and = MMUSIC
chairs and figure out a process for how to evaluate the = various
options and get this moving forward. If this isn't
the = primary use case, then I think we probably need some = more 
discussion to get a clearer idea of what the problem = is.




2) RFC 4474 did not = consider the requirements of calls transiting gateways and the issues = related to expressing identities that originate outside the Internet, = specifically phone numbers delivered via caller ID. While RFC 4474 can = say nothing authoritative about the phone number, it seems that it could = quite reasonably say something authoritative about the gateway. We've = seen several proposals for doing this using conventions for the = expression of "phone" identities in the =46rom header field. I believe = that a revised RFC 4474 is the place to document such a convention and = any needed extension parameters.

It seems to = me that there are actually two issues here:

- To have a way for = the gateway to say: 'this URI corresponds to
 a phone = number'
- To have a way for receiver of the above assertion to = determine
 whether to trust it.

These are actually = separable. The first function may be useful as an
indicator even if = we don't have a technical mechanism for enforcing
it. In fact, based = on the discussion in Philadelphia, there seemed to
be some feeling = that 'user=3Dphone' already performed this function.
So, I would = encourage the WG to figure out whether that's so or
not and if not, =  and if it is not, and we decide we need a way to do = this, 
clearly the some WG could go construct = something that did indicate this 
(a "userpart=3De164" = sip uri tag for example).

The second function = sees substantially more complicate, and while it
might involve = modifying 4474, it might be something completely 
external to = RFC 4474 (e.g., enum, Dan's return routability draft).
This seems = like a much more complicated problem than a simple indicator,
and I'd = like to see the WG study the solution space some before
trying to = close on a single approach



3) There seems to be a = valid model for what I call "stacked" Identity header fields that = express transitive assertions.  Consider authentication domains A, = B, and C, where B is a transit domain between A and C. B would be likely = to trust assertions made by A, and might not know whether C is or is not = equipped to evaluate assertions made by A. However,, it might be = reasonable to expect that C would be able to validate assertions made by = B. B might therefore choose to validate the Identity header inserted by = A, and then (assuming the header authenticates) add another Identity = header using its own credentials, saying in effect "B validated A's = identity header and found it good".  If C can validate A's Identity = header directly, it would do so. If not, it could choose to rely on B's = assertion.

This transitive trust seems to be = something that is used in real  
deployments and it would be = good to have some discussions around it.  
That said, while = there's been a fair bit of mailing list discussion,
I'm not sure the = requirements are. For example if C is willing go  
trust B, but = B wants to lie, can B just remove A assertion forcing C  
to = rely on B's assertion? How much information does C need = to 
include about its evaluation policies?  I would be = looking for 
more consensus and understanding about what = the problem
before charting some work on a = solution. 



4) There are cases, = including authentication services in the UAS and authentication services = in a proxy having an "outbound" relationship (pre-authenticated = persistent TLS) with the UAS where, in the absence of retargeting, an = Identity header field could reasonably be included in a response as an = alternative to using the more cumbersome connected-identity approach = with UPDATE.  I expect this to be very useful in P2PSIP, but it has = broader utility. So I would like to see RFC 4474 extended to allow its = use in  responses where it would = work.


I= like this idea. Once outbound is done, as you point out, it opens = up some  
ways for a proxy to authenticate both requests and = responses coming  
from a UA which in turn might allow Identity = like assertions in  
response. I be keen on drafts that extended = 4474 and outbound
to do this, provided that outbound does not get = blocked on these
changes.


--
Dean

So, while all four of = these points seem to be coupled with areas where
we need discussion = and work, I think it's a bit premature to decide
that what's needed = is an update to RFC 4474. Rather, I'd like to see
the WG (and other = WGs as required) figure out what the best technical
approach is for = each of these points, and if that requires changing
4474 or 3261 or = anything else, we can do that.

Cullen <with = my AD hat = on>






= --Apple-Mail-1-96844411-- --===============0365955781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0365955781==-- From sip-bounces@ietf.org Mon Apr 14 08:46:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115D828C33C; Mon, 14 Apr 2008 08:46:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C4628C338 for ; Mon, 14 Apr 2008 08:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 jojtCDBl2fGo for ; Mon, 14 Apr 2008 08:46:24 -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 3BEBC28C341 for ; Mon, 14 Apr 2008 08:45:08 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2008 08:45:38 -0700 Received: from 64-142-29-214.dsl.static.sonic.net ([10.21.125.187]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m3EFTD7w011522; Mon, 14 Apr 2008 08:29:14 -0700 Message-ID: <48037C26.80602@cisco.com> Date: Mon, 14 Apr 2008 08:45:42 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Ben Campbell References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> In-Reply-To: <29EDD1E0-C825-4C28-9A47-E44393AEC728@estacado.net> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1496; t=1208186954; x=1209050954; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Ben=20Campbell=20; bh=DP05d0OZrOkUPHRMZ5Q8HyMc/Zk1h3c3K869mn/K67U=; b=m1PjvWT+EQuzBoT9dprLYaKHj2uzLWFSCp0WpX1T+2b3G018aXHvriKIer XIdgFu7xfRsjBlSrCEzumbGjEA/43wcPYOXbSzf9kxO0+mlLEbnoNHm31Cuo iCUkF+xhB6; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: sip@ietf.org, "Elwell, John" , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ben Campbell wrote: > > On Apr 9, 2008, at 11:53 AM, Michael Thomas wrote: >>> RFC 4474 is a cross-domain authenticator. >>> >>> Use case: >>> >>> sip:JoeBob@example.com calls his voice mail provider's message >>> retrieval box, sip:messages.example.net >>> >>> Since example.net trusts example.com's RFC 4474 assertions, the >>> voicemail box at messages.example.net does not authenticate JoeBobs' >>> request. Instead, it accepts on trust that example.com authenticated >>> him, and plays out JoeBob's messages. >>> >>> This is AFAIK a valid use case for RFC 4474. >>> >> >> It's a _valid_ use case, but is it a _real_ use case? That is, is there >> anybody out there using cross realm credentials in that way? Even >> cellular isn't handled in that way because my sim is still with my >> home provider even if I've roamed... > > They don't now (or at least should not) because they don't have the > tools for it. But if we give people a tool that appears to work for > this purpose, we should expect them to use it for this purpose. In the global scope of things, that's not completely true. You can use certs and kerberos credentials cross realm theoretically, but the uptake of that seems to be pretty minimal. What the real world seems to actually think is useful is server certs and user passwords. Domain based federation of sort-of-user-based credentials seems like a *very* big stretch. Mike, not saying whether the real world is sensible _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 09:04:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296983A6CB0; Mon, 14 Apr 2008 09:04:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42713A69C3 for ; Mon, 14 Apr 2008 09:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[AWL=0.089, 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 fmZenC6JVtIh for ; Mon, 14 Apr 2008 09:04:47 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 826A03A68D0 for ; Mon, 14 Apr 2008 09:04:47 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3EG5E619725; Mon, 14 Apr 2008 16:05:14 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 11:05:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF16180415@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: AcidnNboCfNnrLDCS+2c/zZv/Ts8lQArF4jw References: <3995D068-A311-4BBA-BACC-A734B2560857@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Hadriel Kaplan" Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think that 2 is the best. Maybe a BCP level document explaining the use case you described and hope that it will encourage implementations. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, April 13, 2008 12:30 > To: Hadriel Kaplan > Cc: Audet, Francois (SC100:3055); SIP IETF; Paul Kyzivat; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > > On Apr 13, 2008, at 1:17 AM, Hadriel Kaplan wrote: > > > > So where do we go from here? > > Option 1) Ignore it. This may only be a minor population > of the sip > > community; or they may fix it themselves someday; or it may > not be a > > real problem if they keep doing what they're doing. > > Option 2) Figure out how to make tel more successful. > > Option 3) Figure out how to make sip with user=phone a true alias. > > Option 4) ?? > > > > I'm inclined to 2 or 3. As the discussion has noted, > user=phone is at best a trifle underdocumented. Either 2 or 3 > requires additional spec work; but at lest the problem is > tractable this way. > > -- > 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 sip-bounces@ietf.org Mon Apr 14 09:06:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408173A6EBE; Mon, 14 Apr 2008 09:06:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43D13A6EBD for ; Mon, 14 Apr 2008 09:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 RYvlooTWZ3Sr for ; Mon, 14 Apr 2008 09:06:36 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 22E5B3A6EAD for ; Mon, 14 Apr 2008 09:05:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3EG6O619967; Mon, 14 Apr 2008 16:06:25 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 11:06:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1618041C@zrc2hxm0.corp.nortel.com> In-reply-to: <4802B000.3090908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: AcidzN9FChtAjqcsQnKmO3vVqnAQDAAfJNoA References: <3995D068-A311-4BBA-BACC-A734B2560857@softarmor.com> <4802B000.3090908@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Dean Willis" Cc: SIP IETF , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Sunday, April 13, 2008 18:15 > To: Dean Willis > Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); SIP IETF; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > ISTM that pieces of the specs, like tel, aren't implemented > for a couple of reasons: > - they are too hard to implement > - there isn't enough bang for the buck > - its just not understood > > Tel clearly isn't *hard* to implement. That rules out the > first excuse, and for the second implies that there isn't > perceived to be much bang at all, since the bucks are small. > So I expect that either it just isn't understood, or else > there is perceived to be no benefit at all. > > If we can demonstrate that there is value here then it seems > like it should be possible to get implementors to support it. > But maybe I'm being naive. _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 09:52:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D913A6DA7; Mon, 14 Apr 2008 09:52:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4198A3A6D94 for ; Mon, 14 Apr 2008 09:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 xsiXNPqFODjZ for ; Mon, 14 Apr 2008 09:52:26 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id B72B03A6DA7 for ; Mon, 14 Apr 2008 09:52:26 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7AE045085A; Mon, 14 Apr 2008 09:54:49 -0700 (PDT) Date: Mon, 14 Apr 2008 09:54:49 -0700 From: Eric Rescorla To: Dean Willis In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080414165449.7AE045085A@romeo.rtfm.com> Cc: "sip@ietf.org List" , Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Sun, 13 Apr 2008 15:25:20 -0500, Dean Willis wrote: > On Apr 13, 2008, at 10:31 AM, Eric Rescorla wrote: > > At Wed, 9 Apr 2008 23:17:38 -0500, > > Now, turning to the more complicated voice case. First, the the > > fingerprint and RFC 4474 signature (and the RFC 4916 counterpart) > > plays the same role here as does the certificate in the ordinary TLS > > handshake, namely it provides authentication for one side of the > > connection. It's quite possible to have a secure connection where only > > one side is authenticated, so long as the authenticated side does not > > care about the other side's identity. And there are a number of such > > cases, especially in B2C settings. For instance, if I call Fidelity, I > > care that I'm not talking to an attacker, but they only care that they > > call not be hijacked, because they're going to ask me for a PIN > > anyway. This is more or less how all PSTN-based security works > > now, because you can't trust CNID. More on this later. > > Since the call has already been authenticated (4474 provides an > "authentication service", no?) Fidelity might well NOT ask you for a > pin. But that's exactly the point I'm making. Even if you *don't* RFC 4474 sign, then Fidelity can ask you for a PIN, and this is still secure. > Let's reduce this to what I see as the simplest use case: Alice calls > Bob through a single domain proxy server that is also an RFC 4474 > authentication service. > > Alice----->---PAS----->Bob > > Typically, Alice sends an INVITE along with key fingerprint and normal > SDP, PAS slaps authenticates her and sticks on an Identity header > signing her INVITE, and sends it to Bob. Bob 200s with SDP and a key > fingerprint. DTLS happens, Alice and Bob compare the key presented in > DTLS with the key fingerprint sent in SDP, and everybody is happy. > > But what if PAS were evil? I don't understand the relevance of this use case: the basic premise of DTLS-SRTP authentication (and of RFC 4474) is that the AS is trusted. I don't merely mean that we rely on them; I mean that they control the namespace. > Assume a more complex case, where each of Alice and Bob have their own > PAS, and an evil proxy EP sits in the middle. > > > Alice------>PASA------EP------->PASB-----Bob > > Here, Alice sends an INVITE with fingerprint and PASA signs it. EP > passes the request to PASB, which passes it to Bob. Bob replies with a > 200 OK with fingerprint. Note that Bob's 200 OK cannot have an > identity signature over that fingerprint, since RFC 4474 doesn't work > on responses. PASB forwards this on to EP, which replaces the SDP and > fingerprint. Alice then DTLS handshakes with EP, and is quite happy. > Bob starts to handshake with EP, but since EP isn't in possession of > Alice's cert, Bob detects the miskey and realizes the call has been > intercepted. The protocol works against the attack, because Alice's > fingerprint was integrity protected by PASA and could not be modified > by EP. Once again, I think you're thinking about this as a DTLS-SRTP issue, but that's fundamentally wrong. It's not about DTLS-SRTP at all, it's about endpoint authentication. At the completion of the SIP exchange (never mind the media) in the above example, the parties have the following information: - Bob knows he has received a call from Alice (authenticated by RFC 4474) - Alice knows she tried to call Bob and got someone, but has absolutely no idea who. If Alice wants cryptographic endpoint authentication of the called party, she needs to insist on RFC 4916. Again, this has nothing to do with DTLS-SRTP. It's just the logic of the SIP authentication framework. To see this, consider that even though Bob's UA has detected the attack and hung up the phone, Alice is still talking to EP and there is no cryptographic way for her to tell she's not talking to Bob. Now, there are multiple ways to imagine implementations handling these issues. One way is through UI. Bob's UA would be justified in putting up some sort of "caller ID verified" icon linked to the RFC 4474 info. Alice's would have have an "unverified" icon. Another way would be for Alice to instruct her UA that this call required 4916 and that it should hang up if it didn't get it. (Admittedly, this would work better if RFC 4474 could just be used with the OK). > But let's replace Alice with a gateway. This is basically the case > from 8.4 of draft-ietf-sip-dtls-framework -- "Single-Sided- > Verification" done backwards, with no integrity protection on the > forward channel (GW to BOB). The 8.4 case has no verification in the > other direction. > > > GW------>PASA------EP------->PASB-----Bob > > > GW sends an INVITE containing SDP and fingerprint to PASA. Since GW is > a gateway, PASA cannot add an Identity header that provides integrity > protection for the fingerprint. PASA forwards the request to EP. EP > replaces the SDP and fingerprint ands sends it on to PASB. PASB sends > the request to Bob, who generates a 200 OK with fingerprint and SDP > then sends the request back to PASB. Since this is a response, PASB > cannot add an Identity header. EP then replaces the SDP and > fingerprint. and sends the response on through PASA to GW. GW and Bob > then each DTLS handshake with EP, and the dirty deed is done. Where this has gone wrong is that it's not in fact single-sided autentication: it's unauthenticated communication. Neither side has required that the other side authenticate itself. So, of course it's subject to MITM attack. > Surely Bob could then offer connected-identity and send an UPDATE or > reINVITE along with integrity protection back through the chain to A. > EP could delay this or discard it, and by the time things have timed > out, GW and Bob have been talking for a long time with their media > intercepted. It's not Bob's job to enforce this. It's Alice's, or rather her UA's. It's Bob's job to do 4916, but Alice needs to check that she's talking to the right person or else no security mechanism can work. > While there are a lot of ways one could precondition this thing to > death, the easiest fix is to eliminate this scenario by finding a way > to apply integrity protect the initial INVITE from GW. The simplest > approach I can see to doing that is to tweak RFC 4474 so that it can > be applied to PSTN gateways. I have no idea what this actually means, but in any version of it I can conceive, it doesn't do anything useful. 1. If Alice really cares who she is talking to, she *must* require authentication of the person on the other end of the connection, whether by 4916, an extended 4744, S/MIME, or by some alternate mechanism (e.g., PINs over the channel). Whether or not Alice sends her ientity to the other side or not is totally irrelevant to this question, as indicated above. 2. An RFC 4474 signature from the PSTN gateway doesn't do anything useful for Bob unless Bob can trust the *identity* claimed in that signature. Again, this isn't about DTLS-SRTP, but purely about the semantics of the PSTN. Say, for the sake of argument, that Alice's GW *did* sign with +123456789@atlanta.com. This stops EP from changing the fingerprint while retaining the signature, but it just inserts its own fingerprint, changes the identity to +123456789@ep.com, which it does own, and resigns. The problem here is that Bob has no way of a priori knowing that there is any important difference between these two identities, and so he's not really doing endpoint auth. Note, however, that this is a consequence of only looking at the LHS. If Bob's UA was configured to show "Alice" for +123456789@atlanta.com and "Unknown" for +123456789@ep.com (e.g., via an address book) then this would all work fine. So, absent some way for Bob (the RP) to know which AS should be signing a given E.164 number, I don't see any useful change to RFC 4474 that helps against this class of attack. > RFC 4474 in responses would also be > darned useful. I agree with that. I'd like to just recap the basic security logic of authenticated channels. 1. If both sides require the other side to authenticate, then integrity attacks are not possible. 2. If Alice requires Bob to authenticate but not vice versa, than an attacker can pose as Alice to Bob, but cannot pose as Bob to Alice. This is *not* a MITM attack because Alice cannot be attacked, only Bob. 3. If neither side requires the other to authenticate, then you can have an MITM attack. Where I think your analysis is wrong is principally in two respects: 1. A verified attestation of a meaningless identity is not a useful form of authentication. Thus, it's useless for Bob to have a 4474 signature from the PSTN gateway unless he knows that that E.164 number can only be signed by that gateway. If he will accept as equally valid a signature from any GW (and importantly, treat those two entities as the same), then he is not in fact requiring authentication in any meaningful way. Above, you're treating as single-sided authentication cases which really are unauthenticated. 2. If you, as one side of the conversation, wish to know who you are talking to, you need to enforce it yourself. You can't get it as a side effect of offering your own credentials. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 12:04:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4465828C2E0; Mon, 14 Apr 2008 12:04:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34583A6D37 for ; Mon, 14 Apr 2008 12:04: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 WXZ-jGG+qRwf for ; Mon, 14 Apr 2008 12:04:14 -0700 (PDT) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 295533A6A95 for ; Mon, 14 Apr 2008 12:03:38 -0700 (PDT) Received: from 71-81-78-129.dhcp.stls.mo.charter.com ([71.81.78.129] helo=alan-johnstons-powerbook-g4-17.local) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JlTyJ-000Bpf-4r; Mon, 14 Apr 2008 19:04:07 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.78.129 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/GVyMdj80I77fOwrWnxHmKwGApUJD4C0k= Message-ID: <4803AAA3.5020108@sipstation.com> Date: Mon, 14 Apr 2008 14:04:03 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Eric Rescorla References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> In-Reply-To: <20080414165449.7AE045085A@romeo.rtfm.com> Cc: "sip@ietf.org List" , Michael Thomas , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ekr, Your analysis really misses the point others are making here. This isn't a call between Alice and Bob - it is a call between +12125551212 and +19725551313. If the identities of the two parties are telephony ones, then RFC 4474 does not provide the same integrity protection available to non-telephony SIP URIs, no matter how you spin it. This is because without some new mechanism and protocol, there is no difference between an identity assertion of: sip:+12125551212@provider1.com or sip:+12125551212@mitm.attackers.org However, there may be a small MitM difference. And this is a DTLS-SRTP issue since it relies on integrity protection of RFC 4474 to prevent MitM attacks, and most VoIP endpoints in the world today use telephony identities. Thanks, Alan Eric Rescorla wrote: > At Sun, 13 Apr 2008 15:25:20 -0500, > Dean Willis wrote: > >> On Apr 13, 2008, at 10:31 AM, Eric Rescorla wrote: >> >>> At Wed, 9 Apr 2008 23:17:38 -0500, >>> Now, turning to the more complicated voice case. First, the the >>> fingerprint and RFC 4474 signature (and the RFC 4916 counterpart) >>> plays the same role here as does the certificate in the ordinary TLS >>> handshake, namely it provides authentication for one side of the >>> connection. It's quite possible to have a secure connection where only >>> one side is authenticated, so long as the authenticated side does not >>> care about the other side's identity. And there are a number of such >>> cases, especially in B2C settings. For instance, if I call Fidelity, I >>> care that I'm not talking to an attacker, but they only care that they >>> call not be hijacked, because they're going to ask me for a PIN >>> anyway. This is more or less how all PSTN-based security works >>> now, because you can't trust CNID. More on this later. >>> >> Since the call has already been authenticated (4474 provides an >> "authentication service", no?) Fidelity might well NOT ask you for a >> pin. >> > > But that's exactly the point I'm making. Even if you *don't* RFC 4474 sign, > then Fidelity can ask you for a PIN, and this is still secure. > > >> Let's reduce this to what I see as the simplest use case: Alice calls >> Bob through a single domain proxy server that is also an RFC 4474 >> authentication service. >> >> Alice----->---PAS----->Bob >> >> Typically, Alice sends an INVITE along with key fingerprint and normal >> SDP, PAS slaps authenticates her and sticks on an Identity header >> signing her INVITE, and sends it to Bob. Bob 200s with SDP and a key >> fingerprint. DTLS happens, Alice and Bob compare the key presented in >> DTLS with the key fingerprint sent in SDP, and everybody is happy. >> >> But what if PAS were evil? >> > > I don't understand the relevance of this use case: the basic premise > of DTLS-SRTP authentication (and of RFC 4474) is that the AS is > trusted. I don't merely mean that we rely on them; I mean that they > control the namespace. > > > >> Assume a more complex case, where each of Alice and Bob have their own >> PAS, and an evil proxy EP sits in the middle. >> >> >> Alice------>PASA------EP------->PASB-----Bob >> >> Here, Alice sends an INVITE with fingerprint and PASA signs it. EP >> passes the request to PASB, which passes it to Bob. Bob replies with a >> 200 OK with fingerprint. Note that Bob's 200 OK cannot have an >> identity signature over that fingerprint, since RFC 4474 doesn't work >> on responses. PASB forwards this on to EP, which replaces the SDP and >> fingerprint. Alice then DTLS handshakes with EP, and is quite happy. >> Bob starts to handshake with EP, but since EP isn't in possession of >> Alice's cert, Bob detects the miskey and realizes the call has been >> intercepted. The protocol works against the attack, because Alice's >> fingerprint was integrity protected by PASA and could not be modified >> by EP. >> > > Once again, I think you're thinking about this as a DTLS-SRTP issue, > but that's fundamentally wrong. It's not about DTLS-SRTP at all, > it's about endpoint authentication. > > At the completion of the SIP exchange (never mind the media) in > the above example, the parties have the following information: > > - Bob knows he has received a call from Alice (authenticated > by RFC 4474) > - Alice knows she tried to call Bob and got someone, but has > absolutely no idea who. > > If Alice wants cryptographic endpoint authentication of the called > party, she needs to insist on RFC 4916. Again, this has nothing > to do with DTLS-SRTP. It's just the logic of the SIP authentication > framework. > > To see this, consider that even though Bob's UA has detected > the attack and hung up the phone, Alice is still talking to > EP and there is no cryptographic way for her to tell she's > not talking to Bob. > > Now, there are multiple ways to imagine implementations handling these > issues. One way is through UI. Bob's UA would be justified in putting > up some sort of "caller ID verified" icon linked to the RFC 4474 > info. Alice's would have have an "unverified" icon. Another way would > be for Alice to instruct her UA that this call required 4916 and that > it should hang up if it didn't get it. (Admittedly, this would work > better if RFC 4474 could just be used with the OK). > > > >> But let's replace Alice with a gateway. This is basically the case >> from 8.4 of draft-ietf-sip-dtls-framework -- "Single-Sided- >> Verification" done backwards, with no integrity protection on the >> forward channel (GW to BOB). The 8.4 case has no verification in the >> other direction. >> >> >> GW------>PASA------EP------->PASB-----Bob >> >> >> GW sends an INVITE containing SDP and fingerprint to PASA. Since GW is >> a gateway, PASA cannot add an Identity header that provides integrity >> protection for the fingerprint. PASA forwards the request to EP. EP >> replaces the SDP and fingerprint ands sends it on to PASB. PASB sends >> the request to Bob, who generates a 200 OK with fingerprint and SDP >> then sends the request back to PASB. Since this is a response, PASB >> cannot add an Identity header. EP then replaces the SDP and >> fingerprint. and sends the response on through PASA to GW. GW and Bob >> then each DTLS handshake with EP, and the dirty deed is done. >> > > Where this has gone wrong is that it's not in fact single-sided > autentication: it's unauthenticated communication. Neither side > has required that the other side authenticate itself. So, of > course it's subject to MITM attack. > > > >> Surely Bob could then offer connected-identity and send an UPDATE or >> reINVITE along with integrity protection back through the chain to A. >> EP could delay this or discard it, and by the time things have timed >> out, GW and Bob have been talking for a long time with their media >> intercepted. >> > > It's not Bob's job to enforce this. It's Alice's, or rather her > UA's. It's Bob's job to do 4916, but Alice needs to check that > she's talking to the right person or else no security mechanism > can work. > > > > >> While there are a lot of ways one could precondition this thing to >> death, the easiest fix is to eliminate this scenario by finding a way >> to apply integrity protect the initial INVITE from GW. The simplest >> approach I can see to doing that is to tweak RFC 4474 so that it can >> be applied to PSTN gateways. >> > > I have no idea what this actually means, but in any version of it > I can conceive, it doesn't do anything useful. > > 1. If Alice really cares who she is talking to, she *must* require > authentication of the person on the other end of the connection, > whether by 4916, an extended 4744, S/MIME, or by some alternate > mechanism (e.g., PINs over the channel). Whether or not Alice > sends her ientity to the other side or not is totally irrelevant > to this question, as indicated above. > > 2. An RFC 4474 signature from the PSTN gateway doesn't do anything > useful for Bob unless Bob can trust the *identity* claimed > in that signature. Again, this isn't about DTLS-SRTP, but > purely about the semantics of the PSTN. > > Say, for the sake of argument, that Alice's GW *did* sign > with +123456789@atlanta.com. This stops EP from changing > the fingerprint while retaining the signature, but it just > inserts its own fingerprint, changes the identity to > +123456789@ep.com, which it does own, and resigns. The > problem here is that Bob has no way of a priori knowing that > there is any important difference between these two identities, > and so he's not really doing endpoint auth. > > Note, however, that this is a consequence of only looking at > the LHS. If Bob's UA was configured to show "Alice" > for +123456789@atlanta.com and "Unknown" for +123456789@ep.com > (e.g., via an address book) then this would all work fine. > > So, absent some way for Bob (the RP) to know which AS should be > signing a given E.164 number, I don't see any useful change to > RFC 4474 that helps against this class of attack. > > > >> RFC 4474 in responses would also be >> darned useful. >> > > I agree with that. > > > I'd like to just recap the basic security logic of authenticated > channels. > > 1. If both sides require the other side to authenticate, then > integrity attacks are not possible. > 2. If Alice requires Bob to authenticate but not vice versa, > than an attacker can pose as Alice to Bob, but cannot > pose as Bob to Alice. This is *not* a MITM attack because > Alice cannot be attacked, only Bob. > 3. If neither side requires the other to authenticate, then > you can have an MITM attack. > > > Where I think your analysis is wrong is principally in two respects: > > 1. A verified attestation of a meaningless identity is not a useful > form of authentication. Thus, it's useless for Bob to have a 4474 > signature from the PSTN gateway unless he knows that that E.164 > number can only be signed by that gateway. If he will accept as > equally valid a signature from any GW (and importantly, treat those > two entities as the same), then he is not in fact requiring > authentication in any meaningful way. Above, you're treating as > single-sided authentication cases which really are unauthenticated. > > 2. If you, as one side of the conversation, wish to know who you are > talking to, you need to enforce it yourself. You can't get it as a > side effect of offering your own credentials. > > -Ekr > > > _______________________________________________ > 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 sip-bounces@ietf.org Mon Apr 14 12:27:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A7B3A6C77; Mon, 14 Apr 2008 12:27:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12D33A6BC1 for ; Mon, 14 Apr 2008 12:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 Nu6yLhgMm0Vp for ; Mon, 14 Apr 2008 12:27:25 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 04AFB3A6A8D for ; Mon, 14 Apr 2008 12:27:25 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 43FFC5081A; Mon, 14 Apr 2008 12:29:48 -0700 (PDT) Date: Mon, 14 Apr 2008 12:29:48 -0700 From: Eric Rescorla To: Alan Johnston In-Reply-To: <4803AAA3.5020108@sipstation.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> <4803AAA3.5020108@sipstation.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080414192948.43FFC5081A@romeo.rtfm.com> Cc: "sip@ietf.org List" , Michael Thomas , Dean Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Mon, 14 Apr 2008 14:04:03 -0500, Alan Johnston wrote: > Your analysis really misses the point others are making here. If you say so. > This isn't a call between Alice and Bob - it is a call between > +12125551212 and +19725551313. If the identities of the two parties are > telephony ones, then RFC 4474 does not provide the same integrity > protection available to non-telephony SIP URIs, no matter how you spin > it. This is because without some new mechanism and protocol, there is > no difference between an identity assertion of: > > sip:+12125551212@provider1.com > > or > > sip:+12125551212@mitm.attackers.org > > However, there may be a small MitM difference. And this is a DTLS-SRTP > issue since it relies on integrity protection of RFC 4474 to prevent > MitM attacks, and most VoIP endpoints in the world today use telephony > identities. Yes, I'm quite aware of the technical facts, I just believe you're misinterpreting their import. To reiterate what I said in PHL, the problem is *not* RFC 4474, but rather the attempt to infer from a SIP URI with a numeric LHS that you're in fact talking to someone with an E.164 number which matches that LHS. Which is to say, that the relevant identity is not +12125551212 but rather +12125551212@provider1.com. If you work in that space (and this of course can be hidden under UI in many cases), then you in fact do get the appropriate security properties. For calls which are coming from the PSTN, trying to go from the SIP identity back to an E.164 number is basically meaningless. No matter how strong we make our authentication infrastructure on the VoIP side, the PSTN CNID information is untrustworthy. We can't solve this problem by being extra-sure we only trust some GWs to vouch for that information, since that GW has no reasonable basis on which to base its assertion. Now, if what you're concerned with is pure VoIP calls which use E.164 numbers but don't transit the PSTN, then, yes, it's potentially meaningful to talk about going from fully qualified numeric LHS URIs to E.164 numbers. What you'd need is some mechanism for determining whether a given domain should be vouching for a given E.164 number. I've heard at least three suggestions for this: - Manual lists of E.164 -> domain mappings - Enum - draft-wing style return routability checks. I certainly think this is potentially worth pursuing, but as far as I can tell, Dean was talking about calls transiting the PSTN, where none of this stuff applies. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 12:29:35 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E03C28C109; Mon, 14 Apr 2008 12:29:35 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9057C28C109 for ; Mon, 14 Apr 2008 12:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.583 X-Spam-Level: X-Spam-Status: No, score=-5.583 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, J_CHICKENPOX_111=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 0vnIqHs1qupm for ; Mon, 14 Apr 2008 12:29:33 -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 C98D33A6BC1 for ; Mon, 14 Apr 2008 12:29:31 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2008 12:30:03 -0700 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 m3EJU2T5000499; Mon, 14 Apr 2008 12:30:02 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3EJU2Wg015047; Mon, 14 Apr 2008 19:30:02 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Dean Willis'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net><47F65345.4030600@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net><47F6716E.9080908@cisco.com><47F6C05E.2080101@cisco.com><3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com><47F6DD90.2090203@cisco.com><73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com><47FCF4A2.9080907@cisco.com><5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> Date: Mon, 14 Apr 2008 12:30:02 -0700 Message-ID: <08d501c89e65$eface4b0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcidezEUSs5ebvtTS7CcPX+ppRSiGQA6cDIQ In-Reply-To: <20080413153106.E3B0A50854@romeo.rtfm.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8018; t=1208201402; x=1209065402; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=gxAVcPLxj4dqY+CUEyztHmMoufO24Lv2Zft0gT2ZnJk=; b=hCJznMJ1CEOAajOYlGWdmkg0JznN5DDwX8Zn4Zc+x1ImMZqW9966on3saf hr0n8HIVkn65GbRofMJRxtaKFHO3LAnW7defe0YZuXWqtHq7sq/bDiy3WE+q oMN6j7aGzQ; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, 'Michael Thomas' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Sunday, April 13, 2008 8:31 AM > To: Dean Willis > Cc: sip@ietf.org List; Michael Thomas > Subject: Re: [Sip] RFC 4474 and PSTN > > At Wed, 9 Apr 2008 23:17:38 -0500, > Dean Willis wrote: > > > > > > On Apr 9, 2008, at 11:53 AM, Michael Thomas wrote: > > > > > >> Now, assume JoeBob is instead named > "180055511212@example.com". All > > >> of the above works fine, until somebody calls into > example.com's > > >> PSTN gateway from a spoofed Caller-ID of "18005551212" > and asks > > >> said gateway to connect them to messages.example.net > > >> > > > > > > So just don't sign it. Or sign it as @example.com. Or > just tell the > > > voice > > > mail provider not to create voice mail boxes for users > with e164@example.com > > > like addresses. This really seems tenuous to me, Dean. > > > > I'm getting REALLY TIRED OF EXPLAINING THIS. Yeah, I know, > one must > > say things ten time to be heard once. But this is eleven . . . ;-) > > > > We need to sign it, because SRTP-DTLS relies on the > signature in order > > to protect the fingerprint of the media key from MITM attacks. > > > > In short, SRTP-DTLS requires RFC 4474 (for full function), > and PSTN > > interaction precludes RFC 4474. > > > > Something has to give. As I see it, we MUST pick at least > one of the > > following: > > > > 1) Change RFC 4474 so that it can be used with phone gateways. > > 2) Change DTLS-SRTP so that it doesn't depend on RFC 4474. > > 3) Decide that we can live without integrity protection of > the media > > key on calls transiting PSTN gateways, and document this. > > > > We already have a strong argument for amending RFC 4474 so > that SBCs > > that tweak the SDP don't break the Identity signature. If > we do this, > > add the "not really an identity" flag, and mod DTLS-SRTP to > account > > for the changes, then I think we have a full solution. > > Dean, > > I don't think that this analysis is correct. > > First, you claim "SRTP-DTLS requires RFC 4474 (for full function)". > That's not quite correct, and I think it's worth walking through > the security analysis. > > > Let's start by looking at a simpler case, Web security. In the > classic Web security case, the server has a cert and the client > does not. At the completion of the TLS handshake, each side > knows the following: > > - The client knows it has a secure connection to the server. > - The server knows it has a secure connection to *someone*. > > There are two very important (in fact, the most common) cases > where this is precisely what you want: > > (1) When the server does not care who the client is (for instance, > in software download, where the client cares about getting > an accurate copy but the server does not care who it gives > copies to.) > (2) When the server has some other means of authenticating the > client (for instance, when you're doing e-commerce and the > client authenticates via password or credit card). > > So, in these situations we don't ordinarily say that we're not > getting "full function" but rather that this is the design > goal. > > > Now, turning to the more complicated voice case. First, the the > fingerprint and RFC 4474 signature (and the RFC 4916 counterpart) > plays the same role here as does the certificate in the ordinary TLS > handshake, namely it provides authentication for one side of the > connection. It's quite possible to have a secure connection where only > one side is authenticated, so long as the authenticated side does not > care about the other side's identity. And there are a number of such > cases, especially in B2C settings. For instance, if I call Fidelity, I > care that I'm not talking to an attacker, but they only care that they > call not be hijacked, because they're going to ask me for a PIN > anyway. This is more or less how all PSTN-based security works > now, because you can't trust CNID. More on this later. > > You write: > > We need to sign it, because SRTP-DTLS relies on the > signature in order > to protect the fingerprint of the media key from MITM attacks. > > This isn't quite correct. As long as one side verifies the other > side's identity, than MITM attacks get blocked, because an MITM attack > requires replacing keys in both directions with the attacker's > key. Consider the following example, in which Alice is calling Bob, > but for some reason her fingerprint isn't signed: > > > Alice Attacker Bob > ---------------------------------------------------------- > Fingerprint=X (unsigned) -> > Fingerprint=A (unsigned) -> > > <- Fingerprint=Z (signed, Bob) > <- Fingerprint=Z (signed, Bob) > > So, Bob has no reliable way of knowing Alice's identity. However, > that's not sufficient to mount an MITM attack, which required that the > attacker to replace Bob's key Z with his own key A. But he can't do > that without replacing Bob's fingerprint, which would require the > ability to sign a message from Bob [0]. I think this analysis is optimistic regarding Alice's behavior. Taking a less optimistic approach: As shown in your diagram, Alice generates a message that is not signed (due to misconfiguration or some other reason). Due to Alice's already-defective configuration, Alice may not expect Bob's message to be signed, and thus the attacker could simply strip Bob's signature, replace Bob's a=fingerprint, and successfully be a MitM. Furthermore, Alice cannot assume that Bob implements Connected-Identity, so Alice can't really assume that Bob *will* generate a signature at all. Or do we require Connected-Identity in the DTLS framework, and require receipt of that Connected-Identity-signed message before the call is completed (using security-preconditions, perhaps)? -d > Now, let's turn to the PSTN case, the simplest of which is shown in > Figure 2 of draft-schwartz-sip-e164-ownership-01, namely, someone on > the PSTN calls someone on IP network. As has been widely noted, there > is no technical reason that the PSTN GW can't RFC 4474 sign the From > line, (though it's not clear what that means from the RP's > perspective), but even if the GW doesn't sign, we still have > significant security properties as long as it *verifies* the called > parties signature. > > Moreover, since the GW doesn't really know the > caller's identity (because you can't trust the PSTN identity > assertions) this is the best set of properties one could hope for, no > matter what SIP mechanisms we create. Even if there were some > mechanism by which the GW could say "I received this over the > PSTN and the CNID said X", and the relying party trusted the > RP not to lie, it still can't believe this assertion because > the GW's information is untrustworthy. > > -Ekr > > > [0] But wait, you say. In SIP we don't have any restrictions on > who the call gets retargeted to, so the attacker could just send > his own key with a (valid) RFC 4474 identity pointing to his real > identity. This is absolutely true, and either Alice (or her UI > needs) to notice this, or we need a secure retargeting mechanism, > but this is a separate technical issue. The requirement right > now is that the right identity shows up in Alice's display, and > we get that right. > _______________________________________________ > 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 sip-bounces@ietf.org Mon Apr 14 12:46:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAD53A6CDD; Mon, 14 Apr 2008 12:46:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0653A67E2 for ; Mon, 14 Apr 2008 12:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_111=0.6, 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 4Zir9LhhZSDd for ; Mon, 14 Apr 2008 12:45:59 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 7C3D528C2A8 for ; Mon, 14 Apr 2008 12:45:44 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DD4A15081A; Mon, 14 Apr 2008 12:48:07 -0700 (PDT) Date: Mon, 14 Apr 2008 12:48:07 -0700 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <08d501c89e65$eface4b0$c5f0200a@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <08d501c89e65$eface4b0$c5f0200a@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080414194807.DD4A15081A@romeo.rtfm.com> Cc: sip@ietf.org, 'Michael Thomas' , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Mon, 14 Apr 2008 12:30:02 -0700, Dan Wing wrote: > > You write: > > > > We need to sign it, because SRTP-DTLS relies on the > > signature in order > > to protect the fingerprint of the media key from MITM attacks. > > > > This isn't quite correct. As long as one side verifies the other > > side's identity, than MITM attacks get blocked, because an MITM attack > > requires replacing keys in both directions with the attacker's > > key. Consider the following example, in which Alice is calling Bob, > > but for some reason her fingerprint isn't signed: > > > > > > Alice Attacker Bob > > ---------------------------------------------------------- > > Fingerprint=X (unsigned) -> > > Fingerprint=A (unsigned) -> > > > > <- Fingerprint=Z (signed, Bob) > > <- Fingerprint=Z (signed, Bob) > > > > So, Bob has no reliable way of knowing Alice's identity. However, > > that's not sufficient to mount an MITM attack, which required that the > > attacker to replace Bob's key Z with his own key A. But he can't do > > that without replacing Bob's fingerprint, which would require the > > ability to sign a message from Bob [0]. > > I think this analysis is optimistic regarding Alice's behavior. > > Taking a less optimistic approach: > > As shown in your diagram, Alice generates a message that is not > signed (due to misconfiguration or some other reason). Due to > Alice's already-defective configuration, Alice may not expect > Bob's message to be signed, and thus the attacker could > simply strip Bob's signature, replace Bob's a=fingerprint, and > successfully be a MitM. Furthermore, Alice cannot assume that > Bob implements Connected-Identity, so Alice can't really assume > that Bob *will* generate a signature at all. Or do we require > Connected-Identity in the DTLS framework, and require receipt > of that Connected-Identity-signed message before the call is > completed (using security-preconditions, perhaps)? I think you're making life much more complicated than it needs to be for the attacker. The attacker can simply pretend to be Bob, not generate a signature, and pretend he is only willing to speak RTP. There are two issues that need to be disentangled here: - What you display on your UI - What causes your UA to terminate the connection Given that at the initial deployment of this system the vast majority of users will not have any cryptographic capability of any kind, I would expect that most UAs will be willing to place or accept phone calls with at least the following sets of people (people who won't do any crypto, people who do RFC 4474 but not DTLS-SRTP, people who will do DTLS-SRTP but without RFC 4474 signatures, people who will do DTLS-SRTP with RFC 4474 signatures). The best we can expect is that the UI will clearly differentiate these three cases so the user can do something meaningful if they care. The only case where I would expect the UA to automatically drop the call is if there were some clear cryptographic failure, e.g., the fingerprints didn't match. At some point in the future once there is reasonable deployment, then it may become reasonable for users to configure their endpoints to only place or accept phone calls from people who do some level of crypto. I can imagine a number of reasonable profiles, depending on what threats you were most concerned with. But this seems clearly up to the individual deployment. That said, it's clearly the case that if you want to be able to verify the identity of the person you called, you're going to need some RFC 4474-like thing from them, whether it's 4916, 4474 w/ outbound, S/MIME, or whatever. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 12:54:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84563A6A2E; Mon, 14 Apr 2008 12:54:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616473A69FE for ; Mon, 14 Apr 2008 12:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.709, 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 BnJGiKxR-zYL for ; Mon, 14 Apr 2008 12:54:17 -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 A534D3A6A2E for ; Mon, 14 Apr 2008 12:54:17 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Apr 2008 12:54:49 -0700 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 m3EJsnR6014049; Mon, 14 Apr 2008 12:54:49 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3EJsmob021087; Mon, 14 Apr 2008 19:54:48 GMT From: "Dan Wing" To: "'ajay thakur'" , References: Date: Mon, 14 Apr 2008 12:54:48 -0700 Message-ID: <090701c89e69$65a4e840$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcieJPsrpLpv8CUnSgyigcA1Bj3PyQARBUlw In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=999; t=1208202889; x=1209066889; 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]=20SIP=20deployment |Sender:=20; bh=tqU6rDNWNj+rroKfKxT4L1bMY1petOWAUtwouAv27vk=; b=qwzdi33Wnzu8bAfInrn7IbEqC8ly4eK/F9vjwdVZOpZGLwZRrQY2aIKKpi mEXPf4eQlppAswsHNGce5bFUxYPcsmZ+SnhlvqvwMZbgTRNHUDeK3dUmU9OF ryfB+UZeIR; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] SIP deployment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of ajay thakur > Sent: Monday, April 14, 2008 4:45 AM > To: sip@ietf.org > Subject: [Sip] SIP deployment > > Hi all, > I have few doubts about SIP deployment. > > (1) Given that NAT/firewall creates problem for SIP calls. > How these problems > are solved in the practical deployment. IS it by using STUN > or by using SIP-alg. It is solved by ICE (draft-ietf-mmusic-ice), and/or SIP-ALGs in the NATs, and/or a Session Border Controller doing "hosted NAT traversal" -- depending on the environment. RFC3489 (STUN), by itself, has proven to be unsufficient as a solution by itself. Instead, the MMUSIC working group created ICE (draft-ietf-mmusic-ice) and the BEHAVE working group revised RFC3489 (draft-ietf-behave-rfc3489bis). Hope this helps, -d > (2) Also i guess not all phones support STUN. How does it work. ? > > Any idea? > > > Ajay > _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 13:00:58 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679B33A6E58; Mon, 14 Apr 2008 13:00:58 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D862C3A6ECD for ; Mon, 14 Apr 2008 13:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.903 X-Spam-Level: X-Spam-Status: No, score=-5.903 tagged_above=-999 required=5 tests=[AWL=0.696, 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 4rV9ksqS34VJ for ; Mon, 14 Apr 2008 13:00:55 -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 612753A6CCD for ; Mon, 14 Apr 2008 13:00:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,656,1199692800"; d="scan'208";a="21564753" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2008 12:59:16 -0700 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 m3EJxF9L016896; Mon, 14 Apr 2008 12:59:15 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3EJxFdS025079; Mon, 14 Apr 2008 19:59:15 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Paul Kyzivat'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net><47F65345.4030600@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net><47F6716E.9080908@cisco.com><47F6C05E.2080101@cisco.com><3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com><47F6DD90.2090203@cisco.com><73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com><47FCF4A2.9080907@cisco.com><5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com><20080413153106.E3B0A50854@romeo.rtfm.com><20080413164218.448A521E995@kilo.rtfm.com><20080414131322.E6ACB22010E@kilo.rtfm.com><48035BEA.90301@cisco.com> <20080414141122.3D1E1220531@kilo.rtfm.com> Date: Mon, 14 Apr 2008 12:59:15 -0700 Message-ID: <091c01c89e6a$049e14d0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcieOY5uaY+esdg0Sm2JkH1uPItxHQAMFd1g In-Reply-To: <20080414141122.3D1E1220531@kilo.rtfm.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=550; t=1208203155; x=1209067155; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=968unXy5kbt+AkqNksb+q7MoSvlFgZEx1DefhyrJgwA=; b=L/VsBppIuqh7IH7lVLwHsN/ku7e6OPBkR2jUfM1Q2zBBY74YBsLZjrOPke PktmKKaZHv8fe0MCMq1wHxXlwkCMYg2YAjY+KRCRVQoOBBj5whRs7+ytPkQB aaTPuBrs9P; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org, 'Michael Thomas' , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org EKR wrote: ... > I agree it's far from ideal. There are two possible solutions > to this sort of problem: > > - Some sort of authenticated history mechanism that gives the gateway > confidence that the call was routed correctly A different take on a solution (aimed at ssh and self-signed HTTP certificates) is discussed at: http://www.cs.cmu.edu/~dwendlan/perspectives/ -d > - Enough UI to tell the user who *actually* answered the call. > > Unfortunately, the second isn't available here because of the > lame PSTN UI. _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 13:02:27 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C268A3A681C; Mon, 14 Apr 2008 13:02:27 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EAD33A6CDD for ; Mon, 14 Apr 2008 13:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 bxvRVFCodeiC for ; Mon, 14 Apr 2008 13:02:24 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6D2CA3A681C for ; Mon, 14 Apr 2008 13:02:21 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DEBC25081A; Mon, 14 Apr 2008 13:04:44 -0700 (PDT) Date: Mon, 14 Apr 2008 13:04:44 -0700 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <091c01c89e6a$049e14d0$c5f0200a@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080413164218.448A521E995@kilo.rtfm.com> <20080414131322.E6ACB22010E@kilo.rtfm.com> <48035BEA.90301@cisco.com> <20080414141122.3D1E1220531@kilo.rtfm.com> <091c01c89e6a$049e14d0$c5f0200a@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080414200444.DEBC25081A@romeo.rtfm.com> Cc: sip@ietf.org, 'Paul Kyzivat' , 'Michael Thomas' , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Mon, 14 Apr 2008 12:59:15 -0700, Dan Wing wrote: > > EKR wrote: > > ... > > I agree it's far from ideal. There are two possible solutions > > to this sort of problem: > > > > - Some sort of authenticated history mechanism that gives the gateway > > confidence that the call was routed correctly > > A different take on a solution (aimed at ssh and self-signed HTTP > certificates) is discussed at: > http://www.cs.cmu.edu/~dwendlan/perspectives/ I don't see how the technique described here can plausibly work with SIP, given that they rely on probes from different locations getting the same response, which is not a requirement for SIP. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 13:08:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28843A6E3E; Mon, 14 Apr 2008 13:08:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5013A6E3E for ; Mon, 14 Apr 2008 13:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.684, 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 4O5l3g1caICS for ; Mon, 14 Apr 2008 13:08: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 9B8363A68F3 for ; Mon, 14 Apr 2008 13:08:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,656,1199692800"; d="scan'208";a="21568378" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2008 13:09:20 -0700 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 m3EK9KxW004213; Mon, 14 Apr 2008 13:09:20 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3EK9JBj005799; Mon, 14 Apr 2008 20:09:19 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net><47F65345.4030600@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net><47F6716E.9080908@cisco.com><47F6C05E.2080101@cisco.com><3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com><47F6DD90.2090203@cisco.com><73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com><47FCF4A2.9080907@cisco.com><5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com><20080413153106.E3B0A50854@romeo.rtfm.com><20080413164218.448A521E995@kilo.rtfm.com><20080414131322.E6ACB22010E@kilo.rtfm.com><48035BEA.90301@cisco.com><20080414141122.3D1E1220531@kilo.rtfm.com><091c01c89e6a$049e14d0$c5f0200a@cisco.com> <20080414200444.DEBC25081A@romeo.rtfm.com> Date: Mon, 14 Apr 2008 13:09:19 -0700 Message-ID: <093401c89e6b$6cca5db0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcieaohEEc5UXoLQRH2kwr2m1MxPzwAAGD+Q In-Reply-To: <20080414200444.DEBC25081A@romeo.rtfm.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=940; t=1208203760; x=1209067760; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=lcvr+8um//nsYe7Nqm4iksVXLocsuQrdng3acrh1Bko=; b=OpIo7Qpv8gc54gEc0BEwOIo8wVXC6H2VtwYdIMAfZSqYi17s2ZOubkriZy oLA/BcUp/vnnRPbkDQxl+eixrJxMIF4ZMH4SoQJocwW2GuqfIlLGIhsVLpGS wD57DMgU9X; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org, 'Paul Kyzivat' , 'Michael Thomas' , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > ... > > > I agree it's far from ideal. There are two possible solutions > > > to this sort of problem: > > > > > > - Some sort of authenticated history mechanism that gives > > > the gateway > > > confidence that the call was routed correctly > > > > A different take on a solution (aimed at ssh and self-signed HTTP > > certificates) is discussed at: > > http://www.cs.cmu.edu/~dwendlan/perspectives/ > > I don't see how the technique described here can plausibly work > with SIP, given that they rely on probes from different locations > getting the same response, which is not a requirement for SIP. If there is only one entity that 'owns' an identity -- which is absolutely the case with email-style URIs with SIP -- it would work. And with E.164, there should also be only one entity that 'owns' a number. If there are multiple, they are PSTN gateways and none of them own the number at all. -d _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 13:11:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CAF63A6CDD; Mon, 14 Apr 2008 13:11:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDD128C105 for ; Mon, 14 Apr 2008 13:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, J_CHICKENPOX_111=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 FR3lol7hbqUR for ; Mon, 14 Apr 2008 13:11:17 -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 8E6B83A6D1D for ; Mon, 14 Apr 2008 13:11:16 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2008 13:11:48 -0700 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 m3EKBmZY009340; Mon, 14 Apr 2008 13:11:48 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3EKBl7S007648; Mon, 14 Apr 2008 20:11:47 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net><47F65345.4030600@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net><47F6716E.9080908@cisco.com><47F6C05E.2080101@cisco.com><3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com><47F6DD90.2090203@cisco.com><73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com><47FCF4A2.9080907@cisco.com><5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com><20080413153106.E3B0A50854@romeo.rtfm.com><08d501c89e65$eface4b0$c5f0200a@cisco.com> <20080414194807.DD4A15081A@romeo.rtfm.com> Date: Mon, 14 Apr 2008 13:11:47 -0700 Message-ID: <093601c89e6b$c4e91cc0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcieaDOgEjHZjlLrToySU+QjNjdBlwAA4U7g In-Reply-To: <20080414194807.DD4A15081A@romeo.rtfm.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4076; t=1208203908; x=1209067908; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=lMCJo8vBjz3En81tOftut9ap67+cF16d4ALHZcyTtmE=; b=suQd18tVSEDRi3MwiCSvAoeJvCTSqBsey7QsIky44j8+/syN/fjRp+cfaQ eOKpptArRCPtpffZ1C1ln2qGjnHIWabApaRazSvD+9HQcMpMVNEUhJDUz58r o60+m4dWOw5Asr2/RtPA5ryLqWdd8wmysRSpIy1uuPcyr/N5AsB0g=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, 'Michael Thomas' , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org EKR wrote: > At Mon, 14 Apr 2008 12:30:02 -0700, > Dan Wing wrote: > > > You write: > > > > > > We need to sign it, because SRTP-DTLS relies on the > > > signature in order > > > to protect the fingerprint of the media key from MITM attacks. > > > > > > This isn't quite correct. As long as one side verifies the other > > > side's identity, than MITM attacks get blocked, because > an MITM attack > > > requires replacing keys in both directions with the attacker's > > > key. Consider the following example, in which Alice is > calling Bob, > > > but for some reason her fingerprint isn't signed: > > > > > > > > > Alice Attacker Bob > > > ---------------------------------------------------------- > > > Fingerprint=X (unsigned) -> > > > Fingerprint=A (unsigned) -> > > > > > > <- Fingerprint=Z (signed, Bob) > > > <- Fingerprint=Z (signed, Bob) > > > > > > So, Bob has no reliable way of knowing Alice's identity. However, > > > that's not sufficient to mount an MITM attack, which > required that the > > > attacker to replace Bob's key Z with his own key A. But > he can't do > > > that without replacing Bob's fingerprint, which would require the > > > ability to sign a message from Bob [0]. > > > > I think this analysis is optimistic regarding Alice's behavior. > > > > Taking a less optimistic approach: > > > > As shown in your diagram, Alice generates a message that is not > > signed (due to misconfiguration or some other reason). Due to > > Alice's already-defective configuration, Alice may not expect > > Bob's message to be signed, and thus the attacker could > > simply strip Bob's signature, replace Bob's a=fingerprint, and > > successfully be a MitM. Furthermore, Alice cannot assume that > > Bob implements Connected-Identity, so Alice can't really assume > > that Bob *will* generate a signature at all. Or do we require > > Connected-Identity in the DTLS framework, and require receipt > > of that Connected-Identity-signed message before the call is > > completed (using security-preconditions, perhaps)? > > I think you're making life much more complicated than it needs to be > for the attacker. The attacker can simply pretend to be Bob, not > generate a signature, and pretend he is only willing to speak RTP. > > There are two issues that need to be disentangled here: > > - What you display on your UI > - What causes your UA to terminate the connection > > Given that at the initial deployment of this system the vast majority > of users will not have any cryptographic capability of any kind, > I would expect that most UAs will be willing to place or > accept phone calls with at least the following sets of people > (people who won't do any crypto, people who do RFC 4474 but > not DTLS-SRTP, people who will do DTLS-SRTP but without > RFC 4474 signatures, people who will do DTLS-SRTP with > RFC 4474 signatures). The best we can expect is that the UI > will clearly differentiate these three cases so the user can > do something meaningful if they care. The only case where I > would expect the UA to automatically drop the call is if there > were some clear cryptographic failure, e.g., the fingerprints > didn't match. > > At some point in the future once there is reasonable deployment, > then it may become reasonable for users to configure their > endpoints to only place or accept phone calls from people who > do some level of crypto. I can imagine a number of reasonable > profiles, depending on what threats you were most concerned > with. But this seems clearly up to the individual deployment. > > That said, it's clearly the case that if you want to be able > to verify the identity of the person you called, you're going > to need some RFC 4474-like thing from them, whether it's 4916, > 4474 w/ outbound, S/MIME, or whatever. I agree with all those points. Thanks. -d _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 13:12:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249DF3A6CDD; Mon, 14 Apr 2008 13:12:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74D13A68F3 for ; Mon, 14 Apr 2008 13:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 HEQ6WRGcXVxq for ; Mon, 14 Apr 2008 13:12:53 -0700 (PDT) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 5ED9428C2A8 for ; Mon, 14 Apr 2008 13:12:52 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id BEE495081A; Mon, 14 Apr 2008 13:15:15 -0700 (PDT) Date: Mon, 14 Apr 2008 13:15:15 -0700 From: Eric Rescorla To: "Dan Wing" In-Reply-To: <093401c89e6b$6cca5db0$c5f0200a@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080413164218.448A521E995@kilo.rtfm.com> <20080414131322.E6ACB22010E@kilo.rtfm.com> <48035BEA.90301@cisco.com> <20080414141122.3D1E1220531@kilo.rtfm.com> <091c01c89e6a$049e14d0$c5f0200a@cisco.com> <20080414200444.DEBC25081A@romeo.rtfm.com> <093401c89e6b$6cca5db0$c5f0200a@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080414201515.BEE495081A@romeo.rtfm.com> Cc: sip@ietf.org, 'Paul Kyzivat' , 'Michael Thomas' , 'Dean Willis' Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At Mon, 14 Apr 2008 13:09:19 -0700, Dan Wing wrote: > > > > ... > > > > I agree it's far from ideal. There are two possible solutions > > > > to this sort of problem: > > > > > > > > - Some sort of authenticated history mechanism that gives > > > > the gateway > > > > confidence that the call was routed correctly > > > > > > A different take on a solution (aimed at ssh and self-signed HTTP > > > certificates) is discussed at: > > > http://www.cs.cmu.edu/~dwendlan/perspectives/ > > > > I don't see how the technique described here can plausibly work > > with SIP, given that they rely on probes from different locations > > getting the same response, which is not a requirement for SIP. > > If there is only one entity that 'owns' an identity -- which is > absolutely the case with email-style URIs with SIP -- it would > work. I think we're taklking past each other. There are two issues: - being able to determine whether a given entity should be able to assert "alice@example.com". Yes, one could use some technique like the one described here to do that, but we already have a technique for that, described in RFC 4474, so I don't see an advantage. - being able to determine whether the fact that my call to alice@example.com was answered by bob@example.org was OK. This can't be resolved in this way because the routing may depend on From. -Ekr _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 13:22:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2E83A681C; Mon, 14 Apr 2008 13:22:00 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13F03A680D for ; Mon, 14 Apr 2008 13:21:59 -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 iFCEHBWyAudb for ; Mon, 14 Apr 2008 13:21:58 -0700 (PDT) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with SMTP id CED1D3A681C for ; Mon, 14 Apr 2008 13:21:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: John.Hearty@Level3.com X-Msg-Ref: server-9.tower-164.messagelabs.com!1208204549!14492077!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 11206 invoked from network); 14 Apr 2008 20:22:29 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-9.tower-164.messagelabs.com with SMTP; 14 Apr 2008 20:22:29 -0000 Received: from idc1embx0001.corp.global.level3.com (idc1embx0001.corp.global.level3.com [10.1.9.76]) by f10bb8-10 (Postfix) with ESMTP id DE7D84446; Mon, 14 Apr 2008 20:22:28 +0000 (GMT) Received: from idc1embx0001.corp.global.level3.com ([10.1.9.76]) by idc1embx0001.corp.global.level3.com ([10.1.9.76]) with mapi; Mon, 14 Apr 2008 14:22:22 -0600 From: "Hearty, John" To: Eric Rescorla Date: Mon, 14 Apr 2008 14:22:21 -0600 Thread-Topic: [Sip] RFC 4474 and PSTN Thread-Index: AcieUAPCC1eWCCq9QLmZuqHBz3iFNwAGsVKQ Message-ID: <045AC4DE08796D448FAAADC939AFAE6CC903BDDA@idc1embx0001.corp.global.level3.com> References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> In-Reply-To: <20080414165449.7AE045085A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sip@ietf.org List" , Michael Thomas , Dean@core3.amsl.com, Willis Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Forgive me for jumping in very late and not understanding some of the issues, but this caught my eye: >2. An RFC 4474 signature from the PSTN gateway doesn't do anything > useful for Bob unless Bob can trust the *identity* claimed > in that signature. Again, this isn't about DTLS-SRTP, but > purely about the semantics of the PSTN. > > Say, for the sake of argument, that Alice's GW *did* sign > with +123456789@atlanta.com. This stops EP from changing > the fingerprint while retaining the signature, but it just > inserts its own fingerprint, changes the identity to > +123456789@ep.com, which it does own, and resigns. The > problem here is that Bob has no way of a priori knowing that > there is any important difference between these two identities, > and so he's not really doing endpoint auth. > > Note, however, that this is a consequence of only looking at > the LHS. If Bob's UA was configured to show "Alice" > for +123456789@atlanta.com and "Unknown" for +123456789@ep.com > (e.g., via an address book) then this would all work fine. > >So, absent some way for Bob (the RP) to know which AS should be >signing a given E.164 number, I don't see any useful change to >RFC 4474 that helps against this class of attack. Bob does know which AS to trust for any E.164 numbers. He signed up with a service provider that, from a PSTN standpoint, owns the PSTN number Bob uses for PSTN callers to reach his SIP endpoint. Bob only expects calls from the PSTN to come from that service provider. He can't trust any other GWs. So if Bob's UA is configured with the list of GWs his service provider supplied and a policy to trust only those GWs, all we need now is the proposed identifier (such as user=phone) that says to lower your trust expectations for the user part of the URI because it came from a PSTN assertion. Bob can then trust his connection is fully secured all the way to the PSTN GW but no further. 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 sip-bounces@ietf.org Mon Apr 14 13:51:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE523A6A4B; Mon, 14 Apr 2008 13:51:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4013A6A4B for ; Mon, 14 Apr 2008 13:51:01 -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 3R68ztBgAnL3 for ; Mon, 14 Apr 2008 13:51:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9DDE13A6B92 for ; Mon, 14 Apr 2008 13:51:00 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3EKp6Nf007981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2008 15:51:08 -0500 Message-Id: From: Dean Willis To: Francois Audet In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 15:51:01 -0500 References: X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 13, 2008, at 7:02 PM, Francois Audet wrote: > I understand what you are saying. > > But I have difficulty imagining a case where the owner of the domain > of the > service provider or enterprise (example.com) would not be able to > reach a > PSTN gateway. The problem is we're talking about TWO service providers, and reaching the wrong one's gateway. > > > I guess you are worried about a@a.com phoning b@b.com and b.com > doesn't have > a gateway but wants to forward to PSTN (and wants the originating to > fork > the bill). So it sends tel URI instead. Sure, but again, I doubt it > will > work very well. It has the potential to work well, whereas what we have now doesn't. > > > I guess you could cheat and put a.com in the SIP contact. I think > there are > lots of cases where the domain will be ignored anyways. > > Again, don't shoot the messenger: it makes sense to me to use Tel > URI for > this. I am just saying it may cause interop problems. Maybe that's > ok, and > maybe implementations will start implementing tel URI. I've no doubt that there will be interop problems. That's what happens when you specify something that has previously been unspecified and left to whim or caprice. -- 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 sip-bounces@ietf.org Mon Apr 14 14:08:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F226D3A6C83; Mon, 14 Apr 2008 14:08:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EF228C2A8 for ; Mon, 14 Apr 2008 14:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_45=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 nxDMG9Iwx22G for ; Mon, 14 Apr 2008 14:08:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 20F8B3A6B23 for ; Mon, 14 Apr 2008 14:08:47 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3EL8shX008054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2008 16:08:55 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 16:08:48 -0500 References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> <4802B7A0.300@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" , Paul Kyzivat Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 13, 2008, at 10:21 PM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> But I do think one ought to attempt to honor the intent of the >> provider >> of the URI. IMO 3263 is pretty clear about how a sip uri is to be >> routed. > > Yes, but I'm not clear which part of 3263 *isn't* being honored. > You set your req-uri to sip:123456789@example.com, it reaches > example.com, example.com says "hmm, not one of my users, I'll > consider this a telephone number, and try the SIP-trunk or PSTN or > whatever". It reached the intended sip target domain (example.com). > Which might also have a user "123456789", resulting in the delivery of that call to the user, rather than the phone number. -- 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 sip-bounces@ietf.org Mon Apr 14 14:33:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A368A3A6932; Mon, 14 Apr 2008 14:33:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635313A6861 for ; Mon, 14 Apr 2008 14:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=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 euDBrpCCZqEv for ; Mon, 14 Apr 2008 14:33:46 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CACD63A6932 for ; Mon, 14 Apr 2008 14:33:45 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3ELY3Pu008157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2008 16:34:05 -0500 Message-Id: From: Dean Willis To: Eric Rescorla In-Reply-To: <20080414165449.7AE045085A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 16:33:58 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" , Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 14, 2008, at 11:54 AM, Eric Rescorla wrote: > > >> Let's reduce this to what I see as the simplest use case: Alice calls >> Bob through a single domain proxy server that is also an RFC 4474 >> authentication service. >> >> Alice----->---PAS----->Bob >> >> Typically, Alice sends an INVITE along with key fingerprint and >> normal >> SDP, PAS slaps authenticates her and sticks on an Identity header >> signing her INVITE, and sends it to Bob. Bob 200s with SDP and a key >> fingerprint. DTLS happens, Alice and Bob compare the key presented in >> DTLS with the key fingerprint sent in SDP, and everybody is happy. >> >> But what if PAS were evil? > > I don't understand the relevance of this use case: the basic premise > of DTLS-SRTP authentication (and of RFC 4474) is that the AS is > trusted. I don't merely mean that we rely on them; I mean that they > control the namespace. It's there as an example on what the responsibilities of the devices are and how the protocol functions. > > > >> Assume a more complex case, where each of Alice and Bob have their >> own >> PAS, and an evil proxy EP sits in the middle. >> >> >> Alice------>PASA------EP------->PASB-----Bob >> >> Here, Alice sends an INVITE with fingerprint and PASA signs it. EP >> passes the request to PASB, which passes it to Bob. Bob replies >> with a >> 200 OK with fingerprint. Note that Bob's 200 OK cannot have an >> identity signature over that fingerprint, since RFC 4474 doesn't work >> on responses. PASB forwards this on to EP, which replaces the SDP and >> fingerprint. Alice then DTLS handshakes with EP, and is quite happy. >> Bob starts to handshake with EP, but since EP isn't in possession of >> Alice's cert, Bob detects the miskey and realizes the call has been >> intercepted. The protocol works against the attack, because Alice's >> fingerprint was integrity protected by PASA and could not be modified >> by EP. > > Once again, I think you're thinking about this as a DTLS-SRTP issue, > but that's fundamentally wrong. It's not about DTLS-SRTP at all, > it's about endpoint authentication. No, it's about using key fingerprints to determine whether or not an MITM has intercepted the media. A fingerprint in the signaling is enough to detect a MITM who operates purely on the media path. But a MITM may attack the signaling as well. We therefore integrity protect the fingerprint in the signaling using an RFC 4474 signature. If you have a fingerprint that is not integrity protected, then an MITM who influences the signaling can introduce a media relay and intercept the media. > > > At the completion of the SIP exchange (never mind the media) in > the above example, the parties have the following information: > > - Bob knows he has received a call from Alice (authenticated > by RFC 4474) > - Alice knows she tried to call Bob and got someone, but has > absolutely no idea who. I'm with you here. > > > If Alice wants cryptographic endpoint authentication of the called > party, she needs to insist on RFC 4916. Again, this has nothing > to do with DTLS-SRTP. It's just the logic of the SIP authentication > framework. Right. But that's not the problem -- can either Alice or the party she;s talking to (who may or may not be Bob) detect that an attacker has tapped the call? With a fingerprint, they can. Without a fingerprint, they can't. So if the attacker is able to influence the signaling to change the fingerprint, they can't. > > > To see this, consider that even though Bob's UA has detected > the attack and hung up the phone, Alice is still talking to > EP and there is no cryptographic way for her to tell she's > not talking to Bob. That's true. Of course, assuming we're only talking a "phone tap" and not an impostor, Bob could say "Gee Alice, it looks like we have no security on this line, so contact me by some other means" and hang up. Or Bob could employ an out-of-band mechanism to talk to Alice. > > > Now, there are multiple ways to imagine implementations handling these > issues. One way is through UI. Bob's UA would be justified in putting > up some sort of "caller ID verified" icon linked to the RFC 4474 > info. Alice's would have have an "unverified" icon. Another way would > be for Alice to instruct her UA that this call required 4916 and that > it should hang up if it didn't get it. (Admittedly, this would work > better if RFC 4474 could just be used with the OK). > > >> But let's replace Alice with a gateway. This is basically the case >> from 8.4 of draft-ietf-sip-dtls-framework -- "Single-Sided- >> Verification" done backwards, with no integrity protection on the >> forward channel (GW to BOB). The 8.4 case has no verification in the >> other direction. >> >> >> GW------>PASA------EP------->PASB-----Bob >> >> >> GW sends an INVITE containing SDP and fingerprint to PASA. Since GW >> is >> a gateway, PASA cannot add an Identity header that provides integrity >> protection for the fingerprint. PASA forwards the request to EP. EP >> replaces the SDP and fingerprint ands sends it on to PASB. PASB sends >> the request to Bob, who generates a 200 OK with fingerprint and SDP >> then sends the request back to PASB. Since this is a response, PASB >> cannot add an Identity header. EP then replaces the SDP and >> fingerprint. and sends the response on through PASA to GW. GW and Bob >> then each DTLS handshake with EP, and the dirty deed is done. > > Where this has gone wrong is that it's not in fact single-sided > autentication: it's unauthenticated communication. Neither side > has required that the other side authenticate itself. So, of > course it's subject to MITM attack. > And that's exactly the scenario we get when a call comes from a PSTN gateway, because 1) we can't RFC 4474 sign a phone identity coming through an gateway, and 2) we can't RFC 4474 sign a response. There's no authentication at either and, and consequently no way to integrity protect the key fingerprint. > >> Surely Bob could then offer connected-identity and send an UPDATE or >> reINVITE along with integrity protection back through the chain to A. >> EP could delay this or discard it, and by the time things have timed >> out, GW and Bob have been talking for a long time with their media >> intercepted. > > It's not Bob's job to enforce this. It's Alice's, or rather her > UA's. It's Bob's job to do 4916, but Alice needs to check that > she's talking to the right person or else no security mechanism > can work. The questions of "who you are talking to" and "has a 3rd party modified the signaling between you and the party you are talking to" are independent. > > >> While there are a lot of ways one could precondition this thing to >> death, the easiest fix is to eliminate this scenario by finding a way >> to apply integrity protect the initial INVITE from GW. The simplest >> approach I can see to doing that is to tweak RFC 4474 so that it can >> be applied to PSTN gateways. > > I have no idea what this actually means, but in any version of it > I can conceive, it doesn't do anything useful. One could use security preconditions with connected-identity to establish no media flow until RFC 4474 identity exchange has occurred in both directions. But it is MUCH EASIER To just allow PASA to put an Identity header on the call from the gateway. > > > 1. If Alice really cares who she is talking to, she *must* require > authentication of the person on the other end of the connection, > whether by 4916, an extended 4744, S/MIME, or by some alternate > mechanism (e.g., PINs over the channel). Whether or not Alice > sends her ientity to the other side or not is totally irrelevant > to this question, as indicated above. > > 2. An RFC 4474 signature from the PSTN gateway doesn't do anything > useful for Bob unless Bob can trust the *identity* claimed > in that signature. Again, this isn't about DTLS-SRTP, but > purely about the semantics of the PSTN. Not true. Bob's trust of the key fingerprint is based on his trust not of the identity presented in the From:, but on his trust of the identity creating the RFC 4474 Identity signature. > Say, for the sake of argument, that Alice's GW *did* sign > with +123456789@atlanta.com. This stops EP from changing > the fingerprint while retaining the signature, but it just > inserts its own fingerprint, changes the identity to > +123456789@ep.com, which it does own, and resigns. The > problem here is that Bob has no way of a priori knowing that > there is any important difference between these two identities, > and so he's not really doing endpoint auth. That presumes that Bob trusts signatures from ep.com. Does he have reason to so trust? Can he even validate the signature from ep.com? Assuming that this fools Bob into accepting the call, will Bob and Alice discover the deception when he says "Gee, Alice, normally you call me from example.com. HAve you changed to a new provider?" > > > Note, however, that this is a consequence of only looking at > the LHS. If Bob's UA was configured to show "Alice" > for +123456789@atlanta.com and "Unknown" for +123456789@ep.com > (e.g., via an address book) then this would all work fine. > > So, absent some way for Bob (the RP) to know which AS should be > signing a given E.164 number, I don't see any useful change to > RFC 4474 that helps against this class of attack. > Once again, all that Bob is really looking at here is the RHS, especially if he he's been told to ignore the LHS through some sort of flag. > >> RFC 4474 in responses would also be >> darned useful. > > I agree with that. > > > I'd like to just recap the basic security logic of authenticated > channels. > > 1. If both sides require the other side to authenticate, then > integrity attacks are not possible. > 2. If Alice requires Bob to authenticate but not vice versa, > than an attacker can pose as Alice to Bob, but cannot > pose as Bob to Alice. This is *not* a MITM attack because > Alice cannot be attacked, only Bob. > 3. If neither side requires the other to authenticate, then > you can have an MITM attack. > > > Where I think your analysis is wrong is principally in two respects: > > 1. A verified attestation of a meaningless identity is not a useful > form of authentication. Thus, it's useless for Bob to have a 4474 > signature from the PSTN gateway unless he knows that that E.164 > number can only be signed by that gateway. If he will accept as > equally valid a signature from any GW (and importantly, treat those > two entities as the same), then he is not in fact requiring > authentication in any meaningful way. Above, you're treating as > single-sided authentication cases which really are unauthenticated. > Well, if Bob accepts signatures from just any old domain, he's certainly screwed. > 2. If you, as one side of the conversation, wish to know who you are > talking to, you need to enforce it yourself. You can't get it as a > side effect of offering your own credentials. As I've repeatedly said, the problem is not in knowing who you;re talking to. It's in knowing whether somebody else is listening in. -- 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 sip-bounces@ietf.org Mon Apr 14 14:46:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE7328C380; Mon, 14 Apr 2008 14:46:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3370C28C3B4 for ; Mon, 14 Apr 2008 14:46:17 -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.247, 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 xWM5lx7i5joD for ; Mon, 14 Apr 2008 14:46:16 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E712328C37A for ; Mon, 14 Apr 2008 14:45:44 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3ELkEBe008226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2008 16:46:16 -0500 Message-Id: <20E122C9-1C60-45D1-9CAE-C20F5C006CC9@softarmor.com> From: Dean Willis To: Eric Rescorla In-Reply-To: <20080414192948.43FFC5081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 16:46:09 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> <4803AAA3.5020108@sipstation.com> <20080414192948.43FFC5081A@romeo.rtfm.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 14, 2008, at 2:29 PM, Eric Rescorla wrote: > > I certainly think this is potentially worth pursuing, but as far > as I can tell, Dean was talking about calls transiting the PSTN, > where none of this stuff applies. > I'm talking about calls coming from the PSTN and onto the Internet. For the part of the call that spans the internet, we wish to have privacy and integrity protection on the media channel. For providing privacy and integrity protection on the media channel, we have DTLS-SRTP. Privacy and integrity on the media channel are, it seems, dependent on at least integrity in the signaling channel. This is an advantage over SDES, which required both privacy and integrity in the signaling channel. RFC 4474 is used to provide integrity on the signaling channel. We've agreed that calls coming from PSTN gateways cannot initially use RFC 4474 (requiring RFC 4916). Therefore, their signaling is not initially integrity protected end-to-end (although hop-by-hop mechanisms, such as TLS, might be applied). Consequently, they are subject to MITM attacks that do not affect non-gateway calls. What we're arguing about is whether or not anything can be done about this. -- 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 sip-bounces@ietf.org Mon Apr 14 14:52:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3CC3A6E58; Mon, 14 Apr 2008 14:52:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A9A3A6AB1 for ; Mon, 14 Apr 2008 14:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 BIwji2DZ4rGx for ; Mon, 14 Apr 2008 14:52:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 552733A67F8 for ; Mon, 14 Apr 2008 14:52:03 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3ELpvEW008262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2008 16:51:58 -0500 Message-Id: From: Dean Willis To: "Hearty, John" In-Reply-To: <045AC4DE08796D448FAAADC939AFAE6CC903BDDA@idc1embx0001.corp.global.level3.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 16:51:51 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> <045AC4DE08796D448FAAADC939AFAE6CC903BDDA@idc1embx0001.corp.global.level3.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" , Dean@core3.amsl.com, Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 14, 2008, at 3:22 PM, Hearty, John wrote: > Forgive me for jumping in very late and not understanding some of > the issues, but this caught my eye: > >> 2. An RFC 4474 signature from the PSTN gateway doesn't do anything >> useful for Bob unless Bob can trust the *identity* claimed >> in that signature. Again, this isn't about DTLS-SRTP, but >> purely about the semantics of the PSTN. >> >> Say, for the sake of argument, that Alice's GW *did* sign >> with +123456789@atlanta.com. This stops EP from changing >> the fingerprint while retaining the signature, but it just >> inserts its own fingerprint, changes the identity to >> +123456789@ep.com, which it does own, and resigns. The >> problem here is that Bob has no way of a priori knowing that >> there is any important difference between these two identities, >> and so he's not really doing endpoint auth. >> >> Note, however, that this is a consequence of only looking at >> the LHS. If Bob's UA was configured to show "Alice" >> for +123456789@atlanta.com and "Unknown" for +123456789@ep.com >> (e.g., via an address book) then this would all work fine. >> >> So, absent some way for Bob (the RP) to know which AS should be >> signing a given E.164 number, I don't see any useful change to >> RFC 4474 that helps against this class of attack. > > Bob does know which AS to trust for any E.164 numbers. He signed up > with a service provider that, from a PSTN standpoint, owns the PSTN > number Bob uses for PSTN callers to reach his SIP endpoint. Bob > only expects calls from the PSTN to come from that service > provider. He can't trust any other GWs. So if Bob's UA is > configured with the list of GWs his service provider supplied and a > policy to trust only those GWs, all we need now is the proposed > identifier (such as user=phone) that says to lower your trust > expectations for the user part of the URI because it came from a > PSTN assertion. Bob can then trust his connection is fully secured > all the way to the PSTN GW but no further. Exactly. And the "stacked" Identity header approach (that I think Jon Peterson proposed) allows Bob to transitively trust other ASes which are trusted by his AS, but that Bob may have no direct relationship with. -- Deab _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 14 16:21:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6748D3A6870; Mon, 14 Apr 2008 16:21:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F523A6957 for ; Mon, 14 Apr 2008 16:21:54 -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.247, 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 XZ9-kv2pGL-P for ; Mon, 14 Apr 2008 16:21:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AF82B3A686B for ; Mon, 14 Apr 2008 16:21: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.263.0; Mon, 14 Apr 2008 19:21:55 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 14 Apr 2008 19:21:55 -0400 From: Hadriel Kaplan To: Dean Willis , Francois Audet Date: Mon, 14 Apr 2008 19:24:45 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciecUUtkh6MFg/xRk6NZ3xV7tcECwAAkpuA 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 MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > The problem is we're talking about TWO service providers, and reaching > the wrong one's gateway. I'm not sure I understand the problem. Service providers decide whether they want to send a call to the PSTN or not for another domain, and that decision is based on their peering relationship and regulatory restrictions. If the peering relationship is such that b.com will try the PSTN (e.g., because a.com pays b.com to be its provider), then it will, else not. So it's not reaching the wrong one's gateway. A.com calls b.com, b.com can forward the call to the pstn if it has that type of relationship with a.com, else it sends the 302 redirect back upstream. What's the "wrong one's" gateway? > > I guess you are worried about a@a.com phoning b@b.com and b.com > > doesn't have > > a gateway but wants to forward to PSTN (and wants the originating to > > fork > > the bill). So it sends tel URI instead. Sure, but again, I doubt it > > will > > work very well. > > It has the potential to work well, whereas what we have now doesn't. Well, it seems to be working. There's plenty of bilateral peering already happening, and the 302's seem to work across the providers. It's just that the contact URI in them is not what I would call the "right" one, but it's working. Really, in the long list of interop issues, this one's pretty low on the totem pole, imho. People are having trouble getting basic calls to work without the aid of a middle-box. That's a bit higher on the list to me. :) > > Again, don't shoot the messenger: it makes sense to me to use Tel > > URI for > > this. I am just saying it may cause interop problems. Maybe that's > > ok, and > > maybe implementations will start implementing tel URI. > > I've no doubt that there will be interop problems. That's what happens > when you specify something that has previously been unspecified and > left to whim or caprice. OK, but failing calls will not give it a high chance of being adopted. Maybe we can figure out how to get a sip: uri to work as well - there's more than one way to skin a cat, even with a potato peeler. ;) -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 sip-bounces@ietf.org Mon Apr 14 20:08:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18CE3A6940; Mon, 14 Apr 2008 20:08:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE983A6940 for ; Mon, 14 Apr 2008 20:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_45=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 TpT9m8c61Uf9 for ; Mon, 14 Apr 2008 20:08:36 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 57DDE3A68E3 for ; Mon, 14 Apr 2008 20:08:36 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3F393R6009639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2008 22:09:04 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 22:08:57 -0500 References: X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 14, 2008, at 6:24 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >> Of Dean >> Willis >> >> The problem is we're talking about TWO service providers, and >> reaching >> the wrong one's gateway. > > I'm not sure I understand the problem. Service providers decide > whether they want to send a call to the PSTN or not for another > domain, and that decision is based on their peering relationship and > regulatory restrictions. If the peering relationship is such that > b.com will try the PSTN (e.g., because a.com pays b.com to be its > provider), then it will, else not. So it's not reaching the wrong > one's gateway. A.com calls b.com, b.com can forward the call to the > pstn if it has that type of relationship with a.com, else it sends > the 302 redirect back upstream. What's the "wrong one's" gateway? > > >>> I guess you are worried about a@a.com phoning b@b.com and b.com >>> doesn't have >>> a gateway but wants to forward to PSTN (and wants the originating to >>> fork >>> the bill). So it sends tel URI instead. Sure, but again, I doubt it >>> will >>> work very well. >> >> It has the potential to work well, whereas what we have now doesn't. > > Well, it seems to be working. There's plenty of bilateral peering > already happening, and the 302's seem to work across the providers. > It's just that the contact URI in them is not what I would call the > "right" one, but it's working. I really can't see how; I can't make it work with my providers Let's revisit the problem again: Alice is a customer of provider A. Bob is a customer of provider B. Alice calls Bob. Bob wishes to forward her call to Jenny's telephone number, +445558675309. At this point, Bob and provider B don't know what gateway Alice might use to reach the PSTN, They also don't know whether reaching Jenny's phone number even requires Alice to use a gateway. What does Bob put into the Contact of a 302 he might send to Alice? I've heard several alternatives: 1) sip:+445588675309:b.com 2) sip:+445588675309:b.com; user=phone 3) sip:+445588675309:a.com 4) sip:+445588675309:b.com;user=phone 5) tel:+445588675309 So let's step through what these mean and why they each might not work. Keep in mind also that there's a very real possibility that Alice might nod NEED a gateway to reach Jenny; it's possible that Jenny's phone number is already in ENUM and is directly reachable via SIP. But this only works if Alice knows to look it up that way. 1) causes Alice to make a call to a user ID in the domain of b.com. Assuming that b figures out that this means a telephone destination, Alice probably doesn't have an account at b.com to use for placing the call. So unless B provides free SIP-to-PSTN calling, or at least provides free translation service to ENUM, she's out of luck. Of course, maybe a.com knows that when it gets a 302 back with a contact that looks like it might be a phone number, it should discard the host part and do phone number routing on the user part. That works until a.com also has user IDs that look like phone numbers. Of course, this is a direct violation of RFC 3261, which bans a.com from retargeting a request with a b.com host part. 2) is much the same as 1, except that "user=phone" provides another hint. B is no more likely to provide gateway services, but at least least if A is going to do an illegal foreign retargeting, it has a broader hint that phone number routing instead of user routing is required. 3) instructs alice to make a call in the domain of a.com. That's fine as long as sip:+445588675309:a.com routes to Jenny. Does it? It might route to somebody with user ID +445588675309, which is a perfectly valid user ID. It might also be true that Alice doesn't use a.com for her PSTN calls. Perhaps instead, she uses c.com. So to use c.com services, or do an enum lookup, she has to do an illegal retargeting. 4) is much like 3, with the added hint that a telephone-number destination is indicated. This might eliminate the accidental calling of user +445588675309, but it does nothing to resolve the question of Alice not using a.com services for PSTN gateways. There's also an open issue as to whether PSTN routing (such as an ENUM lookup) can be applied, vs requiring the call to traverse a gateway. At the very best, a.com (or Alice's UA) knows to discard the host part and do telephone routing on the user part. If Alice's UA does this, it's probably a violation of RFC 3261, as the UA itself is not responsible for the host-part of the contact. A proxy in a.com could do this translation. But what happens if Alice doesn't use a.com for routing PSTN calls? For example, I might place SIP calls using "softarmor.com", but I make my PSTN calls using "sipphone.com", so a 302 sent to me for "sip: +445588675309@softarmor.com;user=phone" will most assuredly fail. Now, if the a.com proxy knew to translate the call, that would be OK, but depending on the relationship between Alice and a.com, it might not. 5) doesn't work at all, because Alice's phone doesn't understand tel: URLs, since understanding of such was listed as a MAY in RFC 3261. But it's the only suggestion from the set that doesn't require violating a bunch of existing protocol rules. > Really, in the long list of interop issues, this one's pretty low on > the totem pole, imho. People are having trouble getting basic calls > to work without the aid of a middle-box. That's a bit higher on the > list to me. :) This is a very basic interdomain calling scenario. I'm really hoping we get more and more interdomain calls. > > > >>> Again, don't shoot the messenger: it makes sense to me to use Tel >>> URI for >>> this. I am just saying it may cause interop problems. Maybe that's >>> ok, and >>> maybe implementations will start implementing tel URI. >> >> I've no doubt that there will be interop problems. That's what >> happens >> when you specify something that has previously been unspecified and >> left to whim or caprice. > > OK, but failing calls will not give it a high chance of being > adopted. Maybe we can figure out how to get a sip: uri to work as > well - there's more than one way to skin a cat, even with a potato > peeler. ;) Failing calls that don't work now isn't much of a handicap. Changing the rules of RFC 3261 to make case 3 or 4 generally valid might also work. Fundamentally, we need a documented solution that works in the general case and doesn't conflict with MUST level rules of other RFCs we cite, unless it supercedes those RFCs. -- 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 sip-bounces@ietf.org Mon Apr 14 21:04:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6AC3A6A39; Mon, 14 Apr 2008 21:04:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE80E3A67FD for ; Mon, 14 Apr 2008 21:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_32=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 ZfHoA86Aaw-d for ; Mon, 14 Apr 2008 21:04:09 -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 A21083A6A39 for ; Mon, 14 Apr 2008 21:04:09 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2008 21:04:40 -0700 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 m3F44dhR004175; Mon, 14 Apr 2008 21:04:39 -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 m3F44dHR018516; Tue, 15 Apr 2008 04:04:39 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, 15 Apr 2008 00:04:39 -0400 Received: from [10.86.248.82] ([10.86.248.82]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 00:04:38 -0400 Message-ID: <48042970.3030909@cisco.com> Date: Tue, 15 Apr 2008 00:05:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> In-Reply-To: X-OriginalArrivalTime: 15 Apr 2008 04:04:38.0823 (UTC) FILETIME=[D3192370:01C89EAD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1529; t=1208232279; x=1209096279; c=relaxed/simple; s=sjdkim1004; 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]=20RFC=204474=20and=20PSTN |Sender:=20; bh=iD8Y+txJk+g5y1mP2Xcb+jAlAmXs1jHZpsW3U0BaN1g=; b=oizOZJszlhY9X1rWWRLu+ZzgQonQg0i4xScpb0/n+KKaZotFvmcFU5byJu sl3uneSytBtl9V6qvl3v6LthwrOHDUrpYXVzE3+7mr8Kf8/v1qxzF0VbmPK5 GHboZ09HL4LJEl2tq8LhF7pjOmSYi0f2pv7Ge2gsEci/c+Owa5dJk=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "sip@ietf.org List" , Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > On Apr 14, 2008, at 11:54 AM, Eric Rescorla wrote: >> Where I think your analysis is wrong is principally in two respects: >> >> 1. A verified attestation of a meaningless identity is not a useful >> form of authentication. Thus, it's useless for Bob to have a 4474 >> signature from the PSTN gateway unless he knows that that E.164 >> number can only be signed by that gateway. If he will accept as >> equally valid a signature from any GW (and importantly, treat those >> two entities as the same), then he is not in fact requiring >> authentication in any meaningful way. Above, you're treating as >> single-sided authentication cases which really are unauthenticated. >> > > Well, if Bob accepts signatures from just any old domain, he's > certainly screwed. How is Bob to decide who to accept signatures from? It is presumably a function of the SPs of the people who call him. So are people just to say "I'll accept ATT, Verizon, and Sprint" and leave it at that??? >> 2. If you, as one side of the conversation, wish to know who you are >> talking to, you need to enforce it yourself. You can't get it as a >> side effect of offering your own credentials. > > As I've repeatedly said, the problem is not in knowing who you;re > talking to. It's in knowing whether somebody else is listening in. I buy into this, since it is often not too hard to convince yourself of who you are talking to by voice, manner of speaking, etc. 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 sip-bounces@ietf.org Mon Apr 14 21:18:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F4B3A6CE8; Mon, 14 Apr 2008 21:18:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA963A6D50 for ; Mon, 14 Apr 2008 21:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 90bIB4+ZsfnY for ; Mon, 14 Apr 2008 21:18:09 -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 5941728C342 for ; Mon, 14 Apr 2008 21:18:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,658,1199682000"; d="scan'208";a="5128426" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2008 00:18:41 -0400 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 m3F4IfRf026294; Tue, 15 Apr 2008 00:18:41 -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 m3F4IebE010119; Tue, 15 Apr 2008 04:18:41 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); Tue, 15 Apr 2008 00:18:40 -0400 Received: from [10.86.248.82] ([10.86.248.82]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 00:18:39 -0400 Message-ID: <48042CBB.2010302@cisco.com> Date: Tue, 15 Apr 2008 00:19:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: X-OriginalArrivalTime: 15 Apr 2008 04:18:40.0021 (UTC) FILETIME=[C87DC450:01C89EAF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7610; t=1208233121; x=1209097121; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Dean=20Willis=20; bh=6S/t0Yj43Y2XR4c0eiu0cqjq3PtYBiAIB+cZ+CtPEJY=; b=Uvi/CcpgaXVYea4W/FJ5WZRSNwWFGnwV6QukNhnztvEdvv5uvigeb47JUC qpR6n0kRom1rSn8xKVnWT2HAClZOZz7Ew7K1tVJk0DOR5VOEbHnJcvuQrZ/x T1Hgg977mB; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Apr 14, 2008, at 6:24 PM, Hadriel Kaplan wrote: >> >> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >>> Dean >>> Willis >>> >>> The problem is we're talking about TWO service providers, and reaching >>> the wrong one's gateway. >> >> I'm not sure I understand the problem. Service providers decide >> whether they want to send a call to the PSTN or not for another >> domain, and that decision is based on their peering relationship and >> regulatory restrictions. If the peering relationship is such that >> b.com will try the PSTN (e.g., because a.com pays b.com to be its >> provider), then it will, else not. So it's not reaching the wrong >> one's gateway. A.com calls b.com, b.com can forward the call to the >> pstn if it has that type of relationship with a.com, else it sends the >> 302 redirect back upstream. What's the "wrong one's" gateway? >> >> >>>> I guess you are worried about a@a.com phoning b@b.com and b.com >>>> doesn't have >>>> a gateway but wants to forward to PSTN (and wants the originating to >>>> fork >>>> the bill). So it sends tel URI instead. Sure, but again, I doubt it >>>> will >>>> work very well. >>> >>> It has the potential to work well, whereas what we have now doesn't. >> >> Well, it seems to be working. There's plenty of bilateral peering >> already happening, and the 302's seem to work across the providers. >> It's just that the contact URI in them is not what I would call the >> "right" one, but it's working. > > I really can't see how; I can't make it work with my providers > > Let's revisit the problem again: > > Alice is a customer of provider A. Bob is a customer of provider B. > > Alice calls Bob. Bob wishes to forward her call to Jenny's telephone > number, +445558675309. > > At this point, Bob and provider B don't know what gateway Alice might > use to reach the PSTN, They also don't know whether reaching Jenny's > phone number even requires Alice to use a gateway. > > What does Bob put into the Contact of a 302 he might send to Alice? > > I've heard several alternatives: > > 1) sip:+445588675309:b.com > > 2) sip:+445588675309:b.com; user=phone > > 3) sip:+445588675309:a.com > > 4) sip:+445588675309:b.com;user=phone > > 5) tel:+445588675309 > > > So let's step through what these mean and why they each might not work. > Keep in mind also that there's a very real possibility that Alice might > nod NEED a gateway to reach Jenny; it's possible that Jenny's phone > number is already in ENUM and is directly reachable via SIP. But this > only works if Alice knows to look it up that way. > > 1) causes Alice to make a call to a user ID in the domain of b.com. > Assuming that b figures out that this means a telephone destination, > Alice probably doesn't have an account at b.com to use for placing the > call. So unless B provides free SIP-to-PSTN calling, or at least > provides free translation service to ENUM, she's out of luck. As another alternative, Hadriel has mentioned b.com returning a 302 when it gets the request with the phone number and its domain in the R-URI. But I don't know what uri it will put in the 302. > Of course, maybe a.com knows that when it gets a 302 back with a contact > that looks like it might be a phone number, it should discard the host > part and do phone number routing on the user part. That works until > a.com also has user IDs that look like phone numbers. Of course, this is > a direct violation of RFC 3261, which bans a.com from retargeting a > request with a b.com host part. > > 2) is much the same as 1, except that "user=phone" provides another > hint. B is no more likely to provide gateway services, but at least > least if A is going to do an illegal foreign retargeting, it has a > broader hint that phone number routing instead of user routing is required. > > 3) instructs alice to make a call in the domain of a.com. That's fine as > long as sip:+445588675309:a.com routes to Jenny. Does it? It might route > to somebody with user ID +445588675309, which is a perfectly valid user ID. > > It might also be true that Alice doesn't use a.com for her PSTN calls. > Perhaps instead, she uses c.com. So to use c.com services, or do an enum > lookup, she has to do an illegal retargeting. > > 4) is much like 3, with the added hint that a telephone-number > destination is indicated. This might eliminate the accidental calling of > user +445588675309, but it does nothing to resolve the question of Alice > not using a.com services for PSTN gateways. There's also an open issue > as to whether PSTN routing (such as an ENUM lookup) can be applied, vs > requiring the call to traverse a gateway. It won't prevent calling the user with the name that looks like a number, at least not if a.com uses a location service. That is because the basic 3261 rules say to ignore the uri params when looking up in the location service. That's all the comments I have for now. Paul > At the very best, a.com (or Alice's UA) knows to discard the host part > and do telephone routing on the user part. If Alice's UA does this, it's > probably a violation of RFC 3261, as the UA itself is not responsible > for the host-part of the contact. A proxy in a.com could do this > translation. But what happens if Alice doesn't use a.com for routing > PSTN calls? For example, I might place SIP calls using "softarmor.com", > but I make my PSTN calls using "sipphone.com", so a 302 sent to me for > "sip: +445588675309@softarmor.com;user=phone" will most assuredly fail. > Now, if the a.com proxy knew to translate the call, that would be OK, > but depending on the relationship between Alice and a.com, it might not. > > 5) doesn't work at all, because Alice's phone doesn't understand tel: > URLs, since understanding of such was listed as a MAY in RFC 3261. But > it's the only suggestion from the set that doesn't require violating a > bunch of existing protocol rules. > > > > >> Really, in the long list of interop issues, this one's pretty low on >> the totem pole, imho. People are having trouble getting basic calls >> to work without the aid of a middle-box. That's a bit higher on the >> list to me. :) > > This is a very basic interdomain calling scenario. I'm really hoping we > get more and more interdomain calls. > > >> >> >> >>>> Again, don't shoot the messenger: it makes sense to me to use Tel >>>> URI for >>>> this. I am just saying it may cause interop problems. Maybe that's >>>> ok, and >>>> maybe implementations will start implementing tel URI. >>> >>> I've no doubt that there will be interop problems. That's what happens >>> when you specify something that has previously been unspecified and >>> left to whim or caprice. >> >> OK, but failing calls will not give it a high chance of being >> adopted. Maybe we can figure out how to get a sip: uri to work as >> well - there's more than one way to skin a cat, even with a potato >> peeler. ;) > > Failing calls that don't work now isn't much of a handicap. Changing > the rules of RFC 3261 to make case 3 or 4 generally valid might also work. > > Fundamentally, we need a documented solution that works in the general > case and doesn't conflict with MUST level rules of other RFCs we cite, > unless it supercedes those RFCs. > > > -- > 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 sip-bounces@ietf.org Mon Apr 14 21:22:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3C03A6C45; Mon, 14 Apr 2008 21:22:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BF33A6BA5 for ; Mon, 14 Apr 2008 21:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 F+eU1lLyz+Vw for ; Mon, 14 Apr 2008 21:22:21 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 167F53A6A39 for ; Mon, 14 Apr 2008 21:22:21 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3F4MnN24766; Tue, 15 Apr 2008 04:22:49 GMT Received: from 47.102.169.133 ([47.102.169.133]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Apr 2008 04:22:18 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Mon, 14 Apr 2008 21:22:17 -0700 From: "Francois Audet" To: Dean Willis , Hadriel Kaplan Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciesEnS+DcsGQtMQJmsgurM/4WEog== In-Reply-To: Mime-version: 1.0 Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org You are making this more complicated than it is. See below. On Apr14 2008 20:08 , "Dean Willis" wrote: > I really can't see how; I can't make it work with my providers > > Let's revisit the problem again: > > Alice is a customer of provider A. Bob is a customer of provider B. > > Alice calls Bob. Bob wishes to forward her call to Jenny's telephone > number, +445558675309. > > At this point, Bob and provider B don't know what gateway Alice might > use to reach the PSTN, They also don't know whether reaching Jenny's > phone number even requires Alice to use a gateway. > > What does Bob put into the Contact of a 302 he might send to Alice? > > I've heard several alternatives: > > 1) sip:+445588675309:b.com > > 2) sip:+445588675309:b.com; user=phone > > 3) sip:+445588675309:a.com > > 4) sip:+445588675309:b.com;user=phone > > 5) tel:+445588675309 Bob would typically put 2, (assuming you meant sip:+445588675309@b.com;user=phone) despite the fact that 5 would be more appropriate. If B.com is not the cheapest crappiest service provider or enterprise possible, it will then recurse on it's own PSTN gateway and route the call there. I guess in theory, it's possible that it would pass the 302 back. If it did do this, then I would think that it should make the 302 usable by a.com. Passing a b.com might work (although it would probably have recursed on it already). If it doesn't have a gateway, then I guess it could change it to a Tel URI (which might then fail) or even substitute the domain with a.com and let a.com deal with it (which it may or may not). Fact is, there is no free lunch. In any case, I think 2 is the most likely. Now, if we want a service where you want Alice to be responsible for figuring out "how to get to the PSNT", then yeah, I think the Tel URI is better (but it may not work today in practice unfortunately, in which case Alice's Proxy would have to B2BUA it and much around with the contact, which would break 4474, yadi yada). > So let's step through what these mean and why they each might not > work. Keep in mind also that there's a very real possibility that > Alice might nod NEED a gateway to reach Jenny; it's possible that > Jenny's phone number is already in ENUM and is directly reachable via > SIP. But this only works if Alice knows to look it up that way. > > 1) causes Alice to make a call to a user ID in the domain of b.com. > Assuming that b figures out that this means a telephone destination, > Alice probably doesn't have an account at b.com to use for placing the > call. So unless B provides free SIP-to-PSTN calling, or at least > provides free translation service to ENUM, she's out of luck. > > Of course, maybe a.com knows that when it gets a 302 back with a > contact that looks like it might be a phone number, it should discard > the host part and do phone number routing on the user part. That works > until a.com also has user IDs that look like phone numbers. Of course, > this is a direct violation of RFC 3261, which bans a.com from > retargeting a request with a b.com host part. > > 2) is much the same as 1, except that "user=phone" provides another > hint. B is no more likely to provide gateway services, but at least > least if A is going to do an illegal foreign retargeting, it has a > broader hint that phone number routing instead of user routing is > required. > > 3) instructs alice to make a call in the domain of a.com. That's fine > as long as sip:+445588675309:a.com routes to Jenny. Does it? It might > route to somebody with user ID +445588675309, which is a perfectly > valid user ID. > > It might also be true that Alice doesn't use a.com for her PSTN calls. > Perhaps instead, she uses c.com. So to use c.com services, or do an > enum lookup, she has to do an illegal retargeting. > > 4) is much like 3, with the added hint that a telephone-number > destination is indicated. This might eliminate the accidental calling > of user +445588675309, but it does nothing to resolve the question of > Alice not using a.com services for PSTN gateways. There's also an open > issue as to whether PSTN routing (such as an ENUM lookup) can be > applied, vs requiring the call to traverse a gateway. > > At the very best, a.com (or Alice's UA) knows to discard the host part > and do telephone routing on the user part. If Alice's UA does this, > it's probably a violation of RFC 3261, as the UA itself is not > responsible for the host-part of the contact. A proxy in a.com could > do this translation. But what happens if Alice doesn't use a.com for > routing PSTN calls? For example, I might place SIP calls using > "softarmor.com", but I make my PSTN calls using "sipphone.com", so a > 302 sent to me for "sip: +445588675309@softarmor.com;user=phone" will > most assuredly fail. Now, if the a.com proxy knew to translate the > call, that would be OK, but depending on the relationship between > Alice and a.com, it might not. > > 5) doesn't work at all, because Alice's phone doesn't understand tel: > URLs, since understanding of such was listed as a MAY in RFC 3261. But > it's the only suggestion from the set that doesn't require violating a > bunch of existing protocol rules. > > > > >> Really, in the long list of interop issues, this one's pretty low on >> the totem pole, imho. People are having trouble getting basic calls >> to work without the aid of a middle-box. That's a bit higher on the >> list to me. :) > > This is a very basic interdomain calling scenario. I'm really hoping > we get more and more interdomain calls. > > >> >> >> >>>> Again, don't shoot the messenger: it makes sense to me to use Tel >>>> URI for >>>> this. I am just saying it may cause interop problems. Maybe that's >>>> ok, and >>>> maybe implementations will start implementing tel URI. >>> >>> I've no doubt that there will be interop problems. That's what >>> happens >>> when you specify something that has previously been unspecified and >>> left to whim or caprice. >> >> OK, but failing calls will not give it a high chance of being >> adopted. Maybe we can figure out how to get a sip: uri to work as >> well - there's more than one way to skin a cat, even with a potato >> peeler. ;) > > Failing calls that don't work now isn't much of a handicap. Changing > the rules of RFC 3261 to make case 3 or 4 generally valid might also > work. > > Fundamentally, we need a documented solution that works in the general > case and doesn't conflict with MUST level rules of other RFCs we cite, > unless it supercedes those RFCs. > > > -- > 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 sip-bounces@ietf.org Mon Apr 14 21:46:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD703A68DA; Mon, 14 Apr 2008 21:46:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92253A68DA for ; Mon, 14 Apr 2008 21:46:18 -0700 (PDT) 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.360, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_91=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 SEDNdOBklNzN for ; Mon, 14 Apr 2008 21:46:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 822983A6910 for ; Mon, 14 Apr 2008 21:46:17 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3F4kYsC010250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2008 23:46:35 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <48042970.3030909@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 23:46:28 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> <48042970.3030909@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" , Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 14, 2008, at 11:05 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> On Apr 14, 2008, at 11:54 AM, Eric Rescorla wrote: > >>> Where I think your analysis is wrong is principally in two respects: >>> >>> 1. A verified attestation of a meaningless identity is not a useful >>> form of authentication. Thus, it's useless for Bob to have a 4474 >>> signature from the PSTN gateway unless he knows that that E.164 >>> number can only be signed by that gateway. If he will accept as >>> equally valid a signature from any GW (and importantly, treat those >>> two entities as the same), then he is not in fact requiring >>> authentication in any meaningful way. Above, you're treating as >>> single-sided authentication cases which really are unauthenticated. >>> >> Well, if Bob accepts signatures from just any old domain, he's >> certainly screwed. > > How is Bob to decide who to accept signatures from? It is presumably > a function of the SPs of the people who call him. So are people just > to say "I'll accept ATT, Verizon, and Sprint" and leave it at that??? It comes down to contractual liability. Who do I have reason to believe I can sue if the identity has been falsified? In simplest terms, this means "somebody with whom I have a contract", either formal and personal, or informal and general. An example of the first sort is a specific contract with a service provider. An example of the second sort is an implicit contract with a root CA whose cert's are included in my commercial OS's browser distribution. Most likely, people will accept signatures from providers with whom they have contractual agreements to provide those signatures; in short, signatures from their service providers. I believe that they will also be willing to accept transitive signatures. By this I mean signatures that are initiated by some other service provider, with whom the recipient;s service provider has made contacts of mutual authentication. So if I'm an AT&T customer, I'll accept an AT&T signature. Assume you, as a Sprint customer call me. Your call goes out with a Sprint signature. Would I trust this directly? Probably not. But if AT&T and Sprint have a deal by which AT&T is also willing to add their own signature attesting to their trust of Sprint's signature, I'll trust AT&T's signature even though it is being applied to a Sprint ID. Of course, I'd personally like to see BOTH signatures preserved, since I might have an independent agreement with Sprint that AT&T is not aware of. Fewer people are likely to accept signatures of the second sort, and quite probably commercially-supplied software will not do so as a default. For example, I expect that if I buy a consumer phone from AT&T that it will treat signatures asserted by AT&T (or possibly by AT&T and other companies with whom it has contracted) differently than it will treat signatures by unrelated third parties. As a user, I'm also more likely to respect signatures from firms that I know and do business with than ones from firm's I don't. That's called "reputation". So for example, I might accept a signature from a Cisco Systems cert issued by Verisign for a call (although as a more-astute-than-average user, I might wonder if the topic of the call were unrelated to the business of Cisco Systems, for example it the caller claimed to be from my bank. But frankly, if I get a phish call from somebody who's using a Cisco Systems cert issued by Verisign, I probably have grounds for a lawsuit against Cisco anyhow. >>> 2. If you, as one side of the conversation, wish to know who you are >>> talking to, you need to enforce it yourself. You can't get it as a >>> side effect of offering your own credentials. >> As I've repeatedly said, the problem is not in knowing who you;re >> talking to. It's in knowing whether somebody else is listening in. > > I buy into this, since it is often not too hard to convince yourself > of who you are talking to by voice, manner of speaking, etc. It is also to differentiate the several levels of "who I am talking to". For example, assume I as an AT&T customer get a call from some random phone number, through a gateway operated by AT&T. I don't really need to know the identity of the calling party to deal with media security issues and apply DTLS-SRTP. All I need to know is the identity of the operator of the gateway, because I'm concerned about detecting MITMs between me and that gateway. What happens on the other side of it is outside of my control. For the typical case wherein I might rent a phone number from AT&T, where AT&T is the gateway operator of record for that phone number, all I need for SRTP-DTLS to work flawlessly (and provide full MITM control) is a signature that asserts an AT&T identity and covers the media fingerprint in the SDP. EKR is quite correct that this is NOT the general case (although it is still a case that I think needs to be solved). Let's consider a broader problem; perhaps it isn't my service provider's gateway that is sourcing the call. There might be many operators who provide an inverse-gateway service, where their PSTN users dial a fixed telephone number, enter a PIN, then enter a new destination number or use ten-key-spelling to enter my SIP username URI (example: sip:dean.willis@softarmor.com). When such a request shows up at my phone with some random signature on it, how am I to know that this is the "original" signature or whether it has been replaced by by some signaling-and-media MITM? Answer: I can't. If the source of the call (in this case a phone number) isn't cryptographically or contractually related to the domain of the signer, I have nothing to go on. So if company A provides such gateway services to Alice, and Alice calls me, but company B intercepts her INVITE and replaces SDP, fingerprints, and Identity signature with a Company B signature, and given that I have no reason to expect Alice to have used company A instead of company B, then I can't detect the attack at all. I see that Alice called me from company B. Now, I might be able to ask Alice in-band "Hey, what company did you use to call me" and check for a mismatch. This is the "gateway" equivalent of the ZRTP-style fingerprint check. But we can't really expert normal people to do this consistently. But back to "reputation:. If I think company B is a reputable gateway services provider, then I might well choose to believe their signature at least to the extent of using it to detect media-tapping MITMs, even if I didn't trust it to give me a real caller ID. It may not give me end-to-end security, but at least it lets me know if somebody between B and me has tapped the call. And this gets back to the core of the argument: As a receiver of Identity headers, having such a header from a reputable signer is useful (for media integrity checks) even if the "username" part of that identity header is explicitly not trustworthy. -- 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 sip-bounces@ietf.org Mon Apr 14 21:59:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F2E328C11C; Mon, 14 Apr 2008 21:59:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3AA3A6A61 for ; Mon, 14 Apr 2008 21:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 lDGzzfgpb0sm for ; Mon, 14 Apr 2008 21:59:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 42E2528C1D9 for ; Mon, 14 Apr 2008 21:59:52 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3F4xmAQ010307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2008 23:59:49 -0500 Message-Id: <6D836814-EA34-442F-92BE-98B58D10C2BE@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <48042CBB.2010302@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 23:59:42 -0500 References: <48042CBB.2010302@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 14, 2008, at 11:19 PM, Paul Kyzivat wrote: > > It won't prevent calling the user with the name that looks like a > number, at least not if a.com uses a location service. That is > because the basic 3261 rules say to ignore the uri params when > looking up in the location service. > I disagree. Once you've decided to use an RFC 3261 location service, what you say is probably correct. But the parameter can be used to make an earlier decision to use telephony routing INSTEAD of using an RFC 3261 location service. RFC 3261 says: > In addition to DNS and location service lookups shown in this > example, proxy servers can make flexible "routing decisions" to > decide where to send a request So DNS is clearly a different sort of lookup than "location service". ENUM is a DNS lookup, and I see no reason why "user=phone" is not a valid flag for saying "don't do location service, do ENUM or TRIP or other telephone routing instead". -- 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 sip-bounces@ietf.org Mon Apr 14 22:09:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5E13A6C5E; Mon, 14 Apr 2008 22:09:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE623A6B2F for ; Mon, 14 Apr 2008 22:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, J_CHICKENPOX_45=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 qqtSFi-woEFg for ; Mon, 14 Apr 2008 22:09:05 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 40E763A6C45 for ; Mon, 14 Apr 2008 22:09:05 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3F59XE8010389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2008 00:09:34 -0500 Message-Id: From: Dean Willis To: "Francois Audet" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 00:09:27 -0500 References: X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 14, 2008, at 11:22 PM, Francois Audet wrote: > You are making this more complicated than it is. See below. > > > On Apr14 2008 20:08 , "Dean Willis" wrote: > >> I really can't see how; I can't make it work with my providers >> >> Let's revisit the problem again: >> >> Alice is a customer of provider A. Bob is a customer of provider B. >> >> Alice calls Bob. Bob wishes to forward her call to Jenny's telephone >> number, +445558675309. >> >> At this point, Bob and provider B don't know what gateway Alice might >> use to reach the PSTN, They also don't know whether reaching Jenny's >> phone number even requires Alice to use a gateway. >> >> What does Bob put into the Contact of a 302 he might send to Alice? >> >> I've heard several alternatives: >> >> 1) sip:+445588675309:b.com >> >> 2) sip:+445588675309:b.com; user=phone >> >> 3) sip:+445588675309:a.com >> >> 4) sip:+445588675309:b.com;user=phone >> >> 5) tel:+445588675309 > Yes, I meant "@", > Bob would typically put 2, (assuming you meant > sip:+445588675309@b.com;user=phone) despite the fact that 5 would be > more > appropriate. But this one is fairly certain not to work. > If B.com is not the cheapest crappiest service provider or enterprise > possible, it will then recurse on it's own PSTN gateway and route > the call > there. Try this experiment: Fire up your Gizmo account, and have the registered UA return a 302 to a Contact of sip:+19725199190@proxy01.sipphone.com " . Now call "sip:audet@proxy01.sipphone.com" (or whatever your Gizmo ID is) from a phone that doesn't have Gizmo credentials and see if they let you make a free phone call to the PSTN. Hint: They don't. > > > I guess in theory, it's possible that it would pass the 302 back. If > it did > do this, then I would think that it should make the 302 usable by > a.com. > Passing a b.com might work (although it would probably have recursed > on it > already). If it doesn't have a gateway, then I guess it could change > it to a > Tel URI (which might then fail) or even substitute the domain with > a.com and > let a.com deal with it (which it may or may not). Fact is, there is > no free > lunch. > > In any case, I think 2 is the most likely. > > Now, if we want a service where you want Alice to be responsible for > figuring out "how to get to the PSNT", then yeah, I think the Tel > URI is > better (but it may not work today in practice unfortunately, in > which case > Alice's Proxy would have to B2BUA it and much around with the > contact, which > would break 4474, yadi yada). You make a mistake in assuming that a phone number means that Alice has to figure out how to get to the PSTN. She doesn't -- she needs to figure out how to get to the target specified by the phone number, which might or might not be on the Internet as well as the PSTN. further, she needs to figure out the "best" (and that's a local policy question) to get there, and answering this question might involve choosing between multiple gateways and connecting directly over the Internet. It might even require something as complex as starting up a VPN in order to get a connection to a corporate gateway. There is no way that the domain of the target can make this decision for her, unless the domain of the target is picking up the cost (the PSTN gateway charge) for doing so, in which a proxy-retargeting operation is arguably a better approach than a 302 response. -- 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 sip-bounces@ietf.org Mon Apr 14 22:09:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B903A6B2F; Mon, 14 Apr 2008 22:09:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B907B3A689F for ; Mon, 14 Apr 2008 22:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, J_CHICKENPOX_45=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 4G1eH8oSymuC for ; Mon, 14 Apr 2008 22:09:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9695A3A6BF9 for ; Mon, 14 Apr 2008 22:09: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.263.0; Tue, 15 Apr 2008 01:09:56 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 15 Apr 2008 01:09:56 -0400 From: Hadriel Kaplan To: Dean Willis Date: Tue, 15 Apr 2008 01:12:15 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AciepgAIVIxw2ETBT+OnCuMoXYleFgADP8Ww 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 MIME-Version: 1.0 Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > I really can't see how; I can't make it work with my providers > > Let's revisit the problem again: > > Alice is a customer of provider A. Bob is a customer of provider B. > > Alice calls Bob. Bob wishes to forward her call to Jenny's telephone > number, +445558675309. > > At this point, Bob and provider B don't know what gateway Alice might > use to reach the PSTN, They also don't know whether reaching Jenny's > phone number even requires Alice to use a gateway. > > What does Bob put into the Contact of a 302 he might send to Alice? > > I've heard several alternatives: > > 1) sip:+445588675309:b.com > 2) sip:+445588675309:b.com; user=phone > 3) sip:+445588675309:a.com > 4) sip:+445588675309:b.com;user=phone > 5) tel:+445588675309 Right, and there is no single answer to this, because different strokes for different folks. (not that there shouldn't be only one way, or that the ways should be documented - I'm just being the messenger here) Typically, Bob as a UAS puts in 1 or 2. (if one can say "typically" for a UAS redirecting to begin with) Since that's a 302 for the original transaction, it goes upstream through Bob's b.com proxy/reg, since that's how it got to Bob to begin with. One of those does a recursion, says "hmmm, not one of my users, and I won't send calls for a.com to PSTN, so time to redirect back a.com". The contact then gets either changed to 3 or 4. (I assume you have a typo in 4) OR, a.com does it when it gets a 302 back from b.com with 1 or 2 in it. So ultimately a.com is looking at 3 or 4 in a 302 redirect. And a.com will get this response before Alice does, because a.com was in the request path to get to b.com, so it's in the 302 response via path. A.com then recurses on it, to the PSTN if it doesn't have such a user. > 1) causes Alice to make a call to a user ID in the domain of b.com. > Assuming that b figures out that this means a telephone destination, > Alice probably doesn't have an account at b.com to use for placing the > call. So unless B provides free SIP-to-PSTN calling, or at least > provides free translation service to ENUM, she's out of luck. 1 and 2 never reach Alice in those forms. 3 or 4 might, but even that's debatable (it's debatable if Alice gets the 302 redirect unless both b.com and a.com can't recurse route it). > Of course, maybe a.com knows that when it gets a 302 back with a > contact that looks like it might be a phone number, it should discard > the host part and do phone number routing on the user part. That works > until a.com also has user IDs that look like phone numbers. Of course, > this is a direct violation of RFC 3261, which bans a.com from > retargeting a request with a b.com host part. A.com gets 3 or 4, with a.com in it. > 3) instructs alice to make a call in the domain of a.com. That's fine > as long as sip:+445588675309:a.com routes to Jenny. Does it? It might > route to somebody with user ID +445588675309, which is a perfectly > valid user ID. You're absolutely right that there could be a sip:+445588675309@a.com;user=phone, which b.com did not really mean. But what *exactly* do you think will happen if a.com gets tel:+445588675309 instead?? Most likely answer: a.com will immediately resolve it to sip:+445588675309@a.com;user=phone. I mean there's a reason people are calling it an "alias". If you'd like, we can make the param "user=^H^H^H^H^H^H^H^H^H^H^H". :) > It might also be true that Alice doesn't use a.com for her PSTN calls. > Perhaps instead, she uses c.com. So to use c.com services, or do an > enum lookup, she has to do an illegal retargeting. Somehow I don't think a.com or b.com care much about that. ;) > > Really, in the long list of interop issues, this one's pretty low on > > the totem pole, imho. People are having trouble getting basic calls > > to work without the aid of a middle-box. That's a bit higher on the > > list to me. :) > > This is a very basic interdomain calling scenario. I'm really hoping > we get more and more interdomain calls. Oh me too! But what I meant was there are problems getting the call from Alice to Bob working, never mind Bob redirecting to Charlie. :) -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 sip-bounces@ietf.org Mon Apr 14 22:45:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5863A6AC1; Mon, 14 Apr 2008 22:45:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4533A6768 for ; Mon, 14 Apr 2008 22:45:28 -0700 (PDT) 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 9msil9O26qJI for ; Mon, 14 Apr 2008 22:45:27 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 470EE3A6BEC for ; Mon, 14 Apr 2008 22:45:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id E65041EC294; Tue, 15 Apr 2008 08:45:50 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvd80J-OVvj9; Tue, 15 Apr 2008 08:45:43 +0300 (EEST) Received: from taimen (h141196.gprs.dnafinland.fi [87.93.141.196]) by tutpro.com (Postfix) with ESMTP; Tue, 15 Apr 2008 08:45:43 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 761B6AC06B; Tue, 15 Apr 2008 08:45:35 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18436.16640.358156.21428@taimen.test.fi> Date: Tue, 15 Apr 2008 08:45:36 +0300 To: Hadriel Kaplan In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan writes: > A.com then recurses on it, to the PSTN if it doesn't have such > a user. automatic recursion of 302 by a proxy to pstn is very dangerous. of course alice needs to get a change to decide if she want to continue to this new destination. -- juha _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 15 05:34:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E8028C2FE; Tue, 15 Apr 2008 05:34:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061043A6C69 for ; Tue, 15 Apr 2008 05:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_91=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 G8+w2JemWMAP for ; Tue, 15 Apr 2008 05:34:51 -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 4B0F33A6C22 for ; Tue, 15 Apr 2008 05:34:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,660,1199682000"; d="scan'208";a="5167807" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2008 08:35:24 -0400 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 m3FCZNWV024021; Tue, 15 Apr 2008 08:35:23 -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 m3FCZNDF023013; Tue, 15 Apr 2008 12:35:23 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, 15 Apr 2008 08:35:23 -0400 Received: from [10.86.248.82] ([10.86.248.82]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 08:35:23 -0400 Message-ID: <4804A126.9000601@cisco.com> Date: Tue, 15 Apr 2008 08:35:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D09160BB@GBNTHT12009MSX.gb002.siemens.net> <47F65345.4030600@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D095BBCD@GBNTHT12009MSX.gb002.siemens.net> <47F6716E.9080908@cisco.com> <47F6C05E.2080101@cisco.com> <3622D2B6-D09C-4596-987C-C1C161BFD176@softarmor.com> <47F6DD90.2090203@cisco.com> <73E84148-9334-4B70-8506-FF500E2EF47C@softarmor.com> <47FCF4A2.9080907@cisco.com> <5A77FEDA-9BE6-4B8A-B90C-8C5357411419@softarmor.com> <20080413153106.E3B0A50854@romeo.rtfm.com> <20080414165449.7AE045085A@romeo.rtfm.com> <48042970.3030909@cisco.com> In-Reply-To: X-OriginalArrivalTime: 15 Apr 2008 12:35:23.0460 (UTC) FILETIME=[2CB9A840:01C89EF5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8804; t=1208262923; x=1209126923; 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]=20RFC=204474=20and=20PSTN |Sender:=20 |To:=20Dean=20Willis=20; bh=Lm/RjCEN5V3Q/XhyA2sqEd1Urafsn8F5MQne1E8WI7w=; b=JsupHVCqYKC300LIOh0qwdCsnRDAlVH4M8ynPg/r+65lZ3HTbMh4eMkXbp cnNv6Marsdy2skp7cYUiNKUvWmEvKopzyME1a/26nL8hKI8VK8WSjUwPgBxE 1MSl3rWHHR; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sip@ietf.org List" , Michael Thomas Subject: Re: [Sip] RFC 4474 and PSTN X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Apr 14, 2008, at 11:05 PM, Paul Kyzivat wrote: >> >> >> Dean Willis wrote: >>> On Apr 14, 2008, at 11:54 AM, Eric Rescorla wrote: >> >>>> Where I think your analysis is wrong is principally in two respects: >>>> >>>> 1. A verified attestation of a meaningless identity is not a useful >>>> form of authentication. Thus, it's useless for Bob to have a 4474 >>>> signature from the PSTN gateway unless he knows that that E.164 >>>> number can only be signed by that gateway. If he will accept as >>>> equally valid a signature from any GW (and importantly, treat those >>>> two entities as the same), then he is not in fact requiring >>>> authentication in any meaningful way. Above, you're treating as >>>> single-sided authentication cases which really are unauthenticated. >>>> >>> Well, if Bob accepts signatures from just any old domain, he's >>> certainly screwed. >> >> How is Bob to decide who to accept signatures from? It is presumably a >> function of the SPs of the people who call him. So are people just to >> say "I'll accept ATT, Verizon, and Sprint" and leave it at that??? > > It comes down to contractual liability. Who do I have reason to believe > I can sue if the identity has been falsified? In simplest terms, this > means "somebody with whom I have a contract", either formal and > personal, or informal and general. An example of the first sort is a > specific contract with a service provider. An example of the second sort > is an implicit contract with a root CA whose cert's are included in my > commercial OS's browser distribution. > > Most likely, people will accept signatures from providers with whom they > have contractual agreements to provide those signatures; in short, > signatures from their service providers. I believe that they will also > be willing to accept transitive signatures. By this I mean signatures > that are initiated by some other service provider, with whom the > recipient;s service provider has made contacts of mutual authentication. > > So if I'm an AT&T customer, I'll accept an AT&T signature. Assume you, > as a Sprint customer call me. Your call goes out with a Sprint > signature. Would I trust this directly? Probably not. But if AT&T and > Sprint have a deal by which AT&T is also willing to add their own > signature attesting to their trust of Sprint's signature, I'll trust > AT&T's signature even though it is being applied to a Sprint ID. Of > course, I'd personally like to see BOTH signatures preserved, since I > might have an independent agreement with Sprint that AT&T is not aware of. > > Fewer people are likely to accept signatures of the second sort, and > quite probably commercially-supplied software will not do so as a > default. For example, I expect that if I buy a consumer phone from AT&T > that it will treat signatures asserted by AT&T (or possibly by AT&T and > other companies with whom it has contracted) differently than it will > treat signatures by unrelated third parties. I buy the "contractual" approach. But the logistics still seem fuzzy to me. I don't really expect that the phones are going to be presenting the identity of the signers, at least as a matter of course. The user interface will need to be much simpler than that to be useful to most people. So it would seem that the policy will need to reside in the phone or in the provider. But that raises a new set of questions about the kinds of service we would like to see possible. Personally, I don't want to be trapped into buying my phones from my service provider. I remember the way it was when the Bell system was a monopoly and you had to rent your phones from them. And of course that is pretty much the way it is with cell phones in the US. And it sucks. *Perhaps* it can be worked out in such a way tht you can buy your phone and configure it using some service that helps with the decisions and then leaves the phone to enforce them. But that requires some thought. > As a user, I'm also more likely to respect signatures from firms that I > know and do business with than ones from firm's I don't. That's called > "reputation". > > So for example, I might accept a signature from a Cisco Systems cert > issued by Verisign for a call (although as a more-astute-than-average > user, I might wonder if the topic of the call were unrelated to the > business of Cisco Systems, for example it the caller claimed to be from > my bank. But frankly, if I get a phish call from somebody who's using a > Cisco Systems cert issued by Verisign, I probably have grounds for a > lawsuit against Cisco anyhow. Ah, the Willis vs Cisco case. How deep are your pockets? >>>> 2. If you, as one side of the conversation, wish to know who you are >>>> talking to, you need to enforce it yourself. You can't get it as a >>>> side effect of offering your own credentials. >>> As I've repeatedly said, the problem is not in knowing who you;re >>> talking to. It's in knowing whether somebody else is listening in. >> >> I buy into this, since it is often not too hard to convince yourself >> of who you are talking to by voice, manner of speaking, etc. > > It is also to differentiate the several levels of "who I am talking to". > > For example, assume I as an AT&T customer get a call from some random > phone number, through a gateway operated by AT&T. I don't really need to > know the identity of the calling party to deal with media security > issues and apply DTLS-SRTP. All I need to know is the identity of the > operator of the gateway, because I'm concerned about detecting MITMs > between me and that gateway. What happens on the other side of it is > outside of my control. > > For the typical case wherein I might rent a phone number from AT&T, > where AT&T is the gateway operator of record for that phone number, all > I need for SRTP-DTLS to work flawlessly (and provide full MITM control) > is a signature that asserts an AT&T identity and covers the media > fingerprint in the SDP. > > > EKR is quite correct that this is NOT the general case (although it is > still a case that I think needs to be solved). > > Let's consider a broader problem; perhaps it isn't my service provider's > gateway that is sourcing the call. There might be many operators who > provide an inverse-gateway service, where their PSTN users dial a fixed > telephone number, enter a PIN, then enter a new destination number or > use ten-key-spelling to enter my SIP username URI (example: > sip:dean.willis@softarmor.com). > > When such a request shows up at my phone with some random signature on > it, how am I to know that this is the "original" signature or whether it > has been replaced by by some signaling-and-media MITM? Answer: I can't. > If the source of the call (in this case a phone number) isn't > cryptographically or contractually related to the domain of the signer, > I have nothing to go on. > > So if company A provides such gateway services to Alice, and Alice calls > me, but company B intercepts her INVITE and replaces SDP, fingerprints, > and Identity signature with a Company B signature, and given that I have > no reason to expect Alice to have used company A instead of company B, > then I can't detect the attack at all. I see that Alice called me from > company B. Now, I might be able to ask Alice in-band "Hey, what company > did you use to call me" and check for a mismatch. This is the "gateway" > equivalent of the ZRTP-style fingerprint check. But we can't really > expert normal people to do this consistently. > > But back to "reputation:. If I think company B is a reputable gateway > services provider, then I might well choose to believe their signature > at least to the extent of using it to detect media-tapping MITMs, even > if I didn't trust it to give me a real caller ID. It may not give me > end-to-end security, but at least it lets me know if somebody between B > and me has tapped the call. > > And this gets back to the core of the argument: As a receiver of > Identity headers, having such a header from a reputable signer is useful > (for media integrity checks) even if the "username" part of that > identity header is explicitly not trustworthy. IMO this discussion is starting to get to the heart of the issue. That is to identify the kinds of identity service that would be useful to people and that we have the possibility of providing. Both conditions are necessary: - must be useful to people (which implies it is comprehensible) - must be feasible to deliver 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 sip-bounces@ietf.org Tue Apr 15 05:38:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552B33A6C22; Tue, 15 Apr 2008 05:38:12 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2030628C194 for ; Tue, 15 Apr 2008 05:38:11 -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 Ngj40YUq28+p for ; Tue, 15 Apr 2008 05:38:10 -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 0CBE128C0EC for ; Tue, 15 Apr 2008 05:38:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,660,1199682000"; d="scan'208";a="5178118" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2008 08:38:42 -0400 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 m3FCcgRU012472; Tue, 15 Apr 2008 08:38:42 -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 m3FCcgsx025747; Tue, 15 Apr 2008 12:38:42 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); Tue, 15 Apr 2008 08:38:42 -0400 Received: from [10.86.248.82] ([10.86.248.82]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 08:38:41 -0400 Message-ID: <4804A1ED.3070701@cisco.com> Date: Tue, 15 Apr 2008 08:39:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <48042CBB.2010302@cisco.com> <6D836814-EA34-442F-92BE-98B58D10C2BE@softarmor.com> In-Reply-To: <6D836814-EA34-442F-92BE-98B58D10C2BE@softarmor.com> X-OriginalArrivalTime: 15 Apr 2008 12:38:42.0008 (UTC) FILETIME=[A311AD80:01C89EF5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1273; t=1208263122; x=1209127122; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Dean=20Willis=20; bh=ds8Vme9/gzLCnuoJeVlYIhSMp12wIo4K3rc2xlx7i/Q=; b=VEyimknOcZm0Un/Z9s8o0PwzMqkS0sobl1XlOQG8d+xLeB+THjfTmrKck2 i/lu3cMxiJE3wmeBDo1/wCXhql/njGM1X9MAHZcrdK9jk9deiQjM1p8DxSho X6bkRW4N01; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm not comfortable with this. It may be a technically valid interpretation, but I have a gut feeling that it will lead to inconsistent service. But I can't identify a specific case at the moment. Paul Dean Willis wrote: > > On Apr 14, 2008, at 11:19 PM, Paul Kyzivat wrote: >> >> It won't prevent calling the user with the name that looks like a >> number, at least not if a.com uses a location service. That is because >> the basic 3261 rules say to ignore the uri params when looking up in >> the location service. >> > > I disagree. Once you've decided to use an RFC 3261 location service, > what you say is probably correct. But the parameter can be used to make > an earlier decision to use telephony routing INSTEAD of using an RFC > 3261 location service. > > RFC 3261 says: > >> In addition to DNS and location service lookups shown in this example, >> proxy servers can make flexible "routing decisions" to decide where to >> send a request > > So DNS is clearly a different sort of lookup than "location service". > ENUM is a DNS lookup, and I see no reason why "user=phone" is not a > valid flag for saying "don't do location service, do ENUM or TRIP or > other telephone routing instead". > -- > 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 sip-bounces@ietf.org Tue Apr 15 06:00:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D79528C11E; Tue, 15 Apr 2008 06:00:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922D03A684F for ; Tue, 15 Apr 2008 06:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 8RLb-w2hOVMm for ; Tue, 15 Apr 2008 06:00:53 -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 6B46628C11E for ; Tue, 15 Apr 2008 06:00:53 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2008 06:01:26 -0700 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 m3FD1QoJ008935; Tue, 15 Apr 2008 06:01:26 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3FD1OgI029694; Tue, 15 Apr 2008 13:01:26 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, 15 Apr 2008 09:01:25 -0400 Received: from [10.86.248.82] ([10.86.248.82]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 09:01:25 -0400 Message-ID: <4804A740.3020106@cisco.com> Date: Tue, 15 Apr 2008 09:01:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: X-OriginalArrivalTime: 15 Apr 2008 13:01:25.0535 (UTC) FILETIME=[CFCB62F0:01C89EF8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6064; t=1208264486; x=1209128486; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=i4NFX2wnt4dTDOrhtigUtCHprbfOejByhJ8ga24D5cM=; b=VgmiI5USuH0jqLKVDiwwx9/PRlSWjYsZZuN/mRt/4on52b8LN8wNAOVnoo a7AmXunCplQ4uI3EeHBz46fbeqUIwesGfnfrWFYKUYe2chwQqpFHcdzKffLa yFS0JMp9/R; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIP IETF , Francois Audet , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> >> I really can't see how; I can't make it work with my providers >> >> Let's revisit the problem again: >> >> Alice is a customer of provider A. Bob is a customer of provider B. >> >> Alice calls Bob. Bob wishes to forward her call to Jenny's telephone >> number, +445558675309. >> >> At this point, Bob and provider B don't know what gateway Alice might >> use to reach the PSTN, They also don't know whether reaching Jenny's >> phone number even requires Alice to use a gateway. >> >> What does Bob put into the Contact of a 302 he might send to Alice? >> >> I've heard several alternatives: >> >> 1) sip:+445588675309:b.com >> 2) sip:+445588675309:b.com; user=phone >> 3) sip:+445588675309:a.com >> 4) sip:+445588675309:b.com;user=phone >> 5) tel:+445588675309 > > Right, and there is no single answer to this, because different strokes for different folks. (not that there shouldn't be only one way, or that the ways should be documented - I'm just being the messenger here) > > Typically, Bob as a UAS puts in 1 or 2. (if one can say "typically" for a UAS redirecting to begin with) Since that's a 302 for the original transaction, it goes upstream through Bob's b.com proxy/reg, since that's how it got to Bob to begin with. > One of those does a recursion, says "hmmm, not one of my users, and I won't send calls for a.com to PSTN, so time to redirect back a.com". The contact then gets either changed to 3 or 4. (I assume you have a typo in 4) Dean already discussed the problems with b.com attempting to construct a sip-based phone number URI in the domain of a.com. IMO its a really bad idea. > OR, a.com does it when it gets a 302 back from b.com with 1 or 2 in it. So ultimately a.com is looking at 3 or 4 in a 302 redirect. And a.com will get this response before Alice does, because a.com was in the request path to get to b.com, so it's in the 302 response via path. A.com then recurses on it, to the PSTN if it doesn't have such a user. Conversely, it seems like a bad idea for a.com to be second guessing the validity of a sip uri in the domain of b.com. How does it know that it *won't* work? And how does it know its not really important that it remain as written? After all, it is b.com's URI. At least for the moment there is nothing that I am aware of in all specs that suggests this is any more valid to do than it would be to change mailto:pkyzivat@cisco.com to mailto:pkyzivat@acmepacket.com. >> 1) causes Alice to make a call to a user ID in the domain of b.com. >> Assuming that b figures out that this means a telephone destination, >> Alice probably doesn't have an account at b.com to use for placing the >> call. So unless B provides free SIP-to-PSTN calling, or at least >> provides free translation service to ENUM, she's out of luck. > > 1 and 2 never reach Alice in those forms. 3 or 4 might, but even that's debatable (it's debatable if Alice gets the 302 redirect unless both b.com and a.com can't recurse route it). When and if it is appropriate to recurse on 3xx, vs returning it, remains an open question. I think we can assume that the policies relating to that will change over time. So we ought not assume too much. >> Of course, maybe a.com knows that when it gets a 302 back with a >> contact that looks like it might be a phone number, it should discard >> the host part and do phone number routing on the user part. That works >> until a.com also has user IDs that look like phone numbers. Of course, >> this is a direct violation of RFC 3261, which bans a.com from >> retargeting a request with a b.com host part. > > A.com gets 3 or 4, with a.com in it. > > >> 3) instructs alice to make a call in the domain of a.com. That's fine >> as long as sip:+445588675309:a.com routes to Jenny. Does it? It might >> route to somebody with user ID +445588675309, which is a perfectly >> valid user ID. > > You're absolutely right that there could be a sip:+445588675309@a.com;user=phone, which b.com did not really mean. But what *exactly* do you think will happen if a.com gets tel:+445588675309 instead?? Most likely answer: a.com will immediately resolve it to sip:+445588675309@a.com;user=phone. I mean there's a reason people are calling it an "alias". If you'd like, we can make the param "user=^H^H^H^H^H^H^H^H^H^H^H". :) The difference is that tel: really does unambiguously represent a phone number, whose target is well defined for all. Domains a.com and b.com are expected to agree on what it designates. That is not true of sip:+445588675309@a.com and sip:+445588675309@b.com. And it is, arguably, not true for those with user=phone either. >> It might also be true that Alice doesn't use a.com for her PSTN calls. >> Perhaps instead, she uses c.com. So to use c.com services, or do an >> enum lookup, she has to do an illegal retargeting. > > Somehow I don't think a.com or b.com care much about that. ;) Perhaps they don't, if they don't care about standards. But *we* care, since we are making the standards. I think we want a standard that can be used successfully without violating it. And I think we would like to make it possible for Alice to use two providers in that way - at least I do. >>> Really, in the long list of interop issues, this one's pretty low on >>> the totem pole, imho. People are having trouble getting basic calls >>> to work without the aid of a middle-box. That's a bit higher on the >>> list to me. :) >> This is a very basic interdomain calling scenario. I'm really hoping >> we get more and more interdomain calls. > > Oh me too! But what I meant was there are problems getting the call from Alice to Bob working, never mind Bob redirecting to Charlie. :) I hope we fairly quickly get to the point where anybody with sip phone can call anybody else with a sip phone, using a sip path e2e. 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 sip-bounces@ietf.org Tue Apr 15 06:48:35 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A160D3A6C3B; Tue, 15 Apr 2008 06:48:35 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262013A6CAB for ; Tue, 15 Apr 2008 06:48:34 -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 H-PRq6zz9bkn for ; Tue, 15 Apr 2008 06:48:31 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 76DDA3A6C3B for ; Tue, 15 Apr 2008 06:48:31 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3FDmxf25686; Tue, 15 Apr 2008 13:49:00 GMT Received: from 47.102.171.197 ([47.102.171.197]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Apr 2008 13:48:24 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Tue, 15 Apr 2008 06:48:22 -0700 From: "Francois Audet" To: Dean Willis , "Francois Audet" Message-ID: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acie/16JWWRv5OrZQ66nmm72oI50TA== In-Reply-To: Mime-version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Try this experiment: Fire up your Gizmo account, and have the > registered UA return a 302 to a Contact of > sip:+19725199190@proxy01.sipphone.com > " > . > > Now call "sip:audet@proxy01.sipphone.com" (or whatever your Gizmo ID > is) from a phone that doesn't have Gizmo credentials and see if they > let you make a free phone call to the PSTN. Hint: They don't. Yeah, sure, they are not there to lose money. For the type of feature you are looking at, I think a Tel URI makes more sense. I'm just pointing out with the current state of SIP phones, it probably won't work. > You make a mistake in assuming that a phone number means that Alice > has to figure out how to get to the PSTN. She doesn't -- she needs to > figure out how to get to the target specified by the phone number, > which might or might not be on the Internet as well as the PSTN. > further, she needs to figure out the "best" (and that's a local policy > question) to get there, and answering this question might involve > choosing between multiple gateways and connecting directly over the > Internet. It might even require something as complex as starting up a > VPN in order to get a connection to a corporate gateway. > > There is no way that the domain of the target can make this decision > for her, unless the domain of the target is picking up the cost (the > PSTN gateway charge) for doing so, in which a proxy-retargeting > operation is arguably a better approach than a 302 response. Again, let's recommend the Tel URI approach then. _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 15 07:02:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8C23A68CA; Tue, 15 Apr 2008 07:02:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706D93A68CA for ; Tue, 15 Apr 2008 07:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW+c+B9L2kD5 for ; Tue, 15 Apr 2008 07:02:31 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 4C1903A6768 for ; Tue, 15 Apr 2008 07:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id B1FEF1EC294; Tue, 15 Apr 2008 17:03:03 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F-eUGv3n7cZ; Tue, 15 Apr 2008 17:02:56 +0300 (EEST) Received: from taimen (h14632.gprs.dnafinland.fi [87.93.146.32]) by tutpro.com (Postfix) with ESMTP; Tue, 15 Apr 2008 17:02:56 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 0090A1E0625; Tue, 15 Apr 2008 17:02:52 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18436.46476.915571.898146@taimen.test.fi> Date: Tue, 15 Apr 2008 17:02:52 +0300 To: "Francois Audet" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet writes: > For the type of feature you are looking at, I think a Tel URI makes more > sense. I'm just pointing out with the current state of SIP phones, it > probably won't work. you are starting a new trend here. usually this wg has not worried what people have actually implemented. instead it has kept on producing countless rfc that are completely ignored by vendors. you have to face it that the only way to fix the 302 problem is to make tel uris mandatory. if there is a list of fixes to rfc3261 somewhere, please add it there. -- juha _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 15 07:10:45 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85AFC28C3B7; Tue, 15 Apr 2008 07:10:45 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F253A6D59 for ; Tue, 15 Apr 2008 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, J_CHICKENPOX_45=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 Txn5Ptx-4EQl for ; Tue, 15 Apr 2008 07:10:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CBCFF3A6A65 for ; Tue, 15 Apr 2008 07:10:02 -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.263.0; Tue, 15 Apr 2008 10:10:05 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 15 Apr 2008 10:10:06 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 15 Apr 2008 10:12:26 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acie+MchzwFfMARdSvqKCTm42xi8aQACXh/g Message-ID: References: <4804A740.3020106@cisco.com> In-Reply-To: <4804A740.3020106@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Francois Audet , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I don't disagree with what you or Dean are saying in general (though I think you'll find Tel isn't going to avoid some of the issues Dean raises - they're more issues of response recursion in general). My only point is that this is what is happening *today*, in many cases. Dean said "it's not working", and my point was "not true - it is working right now, just not how we want and therefore it may have serious issues in the future". -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, April 15, 2008 9:02 AM > To: Hadriel Kaplan > Cc: Dean Willis; Francois Audet; SIP IETF; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > > > Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> > >> I really can't see how; I can't make it work with my providers > >> > >> Let's revisit the problem again: > >> > >> Alice is a customer of provider A. Bob is a customer of provider B. > >> > >> Alice calls Bob. Bob wishes to forward her call to Jenny's telephone > >> number, +445558675309. > >> > >> At this point, Bob and provider B don't know what gateway Alice might > >> use to reach the PSTN, They also don't know whether reaching Jenny's > >> phone number even requires Alice to use a gateway. > >> > >> What does Bob put into the Contact of a 302 he might send to Alice? > >> > >> I've heard several alternatives: > >> > >> 1) sip:+445588675309:b.com > >> 2) sip:+445588675309:b.com; user=phone > >> 3) sip:+445588675309:a.com > >> 4) sip:+445588675309:b.com;user=phone > >> 5) tel:+445588675309 > > > > Right, and there is no single answer to this, because different strokes > for different folks. (not that there shouldn't be only one way, or that > the ways should be documented - I'm just being the messenger here) > > > > Typically, Bob as a UAS puts in 1 or 2. (if one can say "typically" for > a UAS redirecting to begin with) Since that's a 302 for the original > transaction, it goes upstream through Bob's b.com proxy/reg, since that's > how it got to Bob to begin with. > > > One of those does a recursion, says "hmmm, not one of my users, and I > won't send calls for a.com to PSTN, so time to redirect back a.com". The > contact then gets either changed to 3 or 4. (I assume you have a typo in > 4) > > Dean already discussed the problems with b.com attempting to construct a > sip-based phone number URI in the domain of a.com. IMO its a really bad > idea. > > > OR, a.com does it when it gets a 302 back from b.com with 1 or 2 in it. > So ultimately a.com is looking at 3 or 4 in a 302 redirect. And a.com > will get this response before Alice does, because a.com was in the request > path to get to b.com, so it's in the 302 response via path. A.com then > recurses on it, to the PSTN if it doesn't have such a user. > > Conversely, it seems like a bad idea for a.com to be second guessing the > validity of a sip uri in the domain of b.com. How does it know that it > *won't* work? And how does it know its not really important that it > remain as written? After all, it is b.com's URI. > > At least for the moment there is nothing that I am aware of in all specs > that suggests this is any more valid to do than it would be to change > mailto:pkyzivat@cisco.com to mailto:pkyzivat@acmepacket.com. > > >> 1) causes Alice to make a call to a user ID in the domain of b.com. > >> Assuming that b figures out that this means a telephone destination, > >> Alice probably doesn't have an account at b.com to use for placing the > >> call. So unless B provides free SIP-to-PSTN calling, or at least > >> provides free translation service to ENUM, she's out of luck. > > > > 1 and 2 never reach Alice in those forms. 3 or 4 might, but even that's > debatable (it's debatable if Alice gets the 302 redirect unless both b.com > and a.com can't recurse route it). > > When and if it is appropriate to recurse on 3xx, vs returning it, > remains an open question. I think we can assume that the policies > relating to that will change over time. So we ought not assume too much. > > >> Of course, maybe a.com knows that when it gets a 302 back with a > >> contact that looks like it might be a phone number, it should discard > >> the host part and do phone number routing on the user part. That works > >> until a.com also has user IDs that look like phone numbers. Of course, > >> this is a direct violation of RFC 3261, which bans a.com from > >> retargeting a request with a b.com host part. > > > > A.com gets 3 or 4, with a.com in it. > > > > > >> 3) instructs alice to make a call in the domain of a.com. That's fine > >> as long as sip:+445588675309:a.com routes to Jenny. Does it? It might > >> route to somebody with user ID +445588675309, which is a perfectly > >> valid user ID. > > > > You're absolutely right that there could be a > sip:+445588675309@a.com;user=phone, which b.com did not really mean. But > what *exactly* do you think will happen if a.com gets tel:+445588675309 > instead?? Most likely answer: a.com will immediately resolve it to > sip:+445588675309@a.com;user=phone. I mean there's a reason people are > calling it an "alias". If you'd like, we can make the param > "user=^H^H^H^H^H^H^H^H^H^H^H". :) > > The difference is that tel: really does unambiguously represent a phone > number, whose target is well defined for all. Domains a.com and b.com > are expected to agree on what it designates. > > That is not true of sip:+445588675309@a.com and sip:+445588675309@b.com. > And it is, arguably, not true for those with user=phone either. > > >> It might also be true that Alice doesn't use a.com for her PSTN calls. > >> Perhaps instead, she uses c.com. So to use c.com services, or do an > >> enum lookup, she has to do an illegal retargeting. > > > > Somehow I don't think a.com or b.com care much about that. ;) > > Perhaps they don't, if they don't care about standards. > > But *we* care, since we are making the standards. I think we want a > standard that can be used successfully without violating it. And I think > we would like to make it possible for Alice to use two providers in that > way - at least I do. > > >>> Really, in the long list of interop issues, this one's pretty low on > >>> the totem pole, imho. People are having trouble getting basic calls > >>> to work without the aid of a middle-box. That's a bit higher on the > >>> list to me. :) > >> This is a very basic interdomain calling scenario. I'm really hoping > >> we get more and more interdomain calls. > > > > Oh me too! But what I meant was there are problems getting the call > from Alice to Bob working, never mind Bob redirecting to Charlie. :) > > I hope we fairly quickly get to the point where anybody with sip phone > can call anybody else with a sip phone, using a sip path e2e. > > 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 sip-bounces@ietf.org Tue Apr 15 07:23:49 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5EB28C2FE; Tue, 15 Apr 2008 07:23:49 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06FBA28C19A for ; Tue, 15 Apr 2008 07:23:48 -0700 (PDT) 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.246, 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 7u+-+QAtBeNc for ; Tue, 15 Apr 2008 07:23:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BE3C53A6E8A for ; Tue, 15 Apr 2008 07:23:46 -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.263.0; Tue, 15 Apr 2008 10:23:49 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 15 Apr 2008 10:23:50 -0400 From: Hadriel Kaplan To: Cullen Jennings , Dean Willis Date: Tue, 15 Apr 2008 10:26:14 -0400 Thread-Topic: What 4474 signs, part-1 [was: Proposal to Revise RFC 4474] Thread-Index: AcieP0/LxeHkmxVcTcSS+BethEerDAAWDIQgAAAPP+A= Message-ID: References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> <29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , "jon.peterson@neustar.biz" Subject: [Sip] What 4474 signs, part-1 [was: Proposal to Revise RFC 4474] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Monday, April 14, 2008 10:53 AM > > Based on the discussion I've seen so far, the primary use case for > this modification is to allow the SBC to do media steering so it can > steer the RTP through a path that provides better QoS. As you say, > this could be achieved by modifying the SDP and changing RFC 4474 to > allow that, but there are probably some other approaches we should be > considering as well, including ones that may need to be done outside > of SIP. If there's consensus that this is the problem > that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC > chairs and figure out a process for how to evaluate the various > options and get this moving forward. If this isn't > the primary use case, then I think we probably need some more > discussion to get a clearer idea of what the problem is. I think there are several problems with what 4474 signs, and SDP is only one of them, so I'll break it up into separate emails. As far as I can tell, in this world there are lots of B2BUA's - and no I'm not just talking SBC's. Most of the people on this mailing list work for companies that make some form of B2BUA or other which are not SBC's. Some of those B2BUA's change things which will break 4474. Whether 4474 *should* fail in such cases is a separate but important topic. This is part-1: Signing the Call-ID. Some of those B2BUA's change the Call-ID, even though at a higher layer it's clearly the same "request". I believe RFC 4474 signs the Call-ID to provide cut-paste attack protection such that the Verifier can detect when a SIP request is being replayed. To do that, the Verifier keeps a table of received call-id's and identity header signatures with their date. If a request is received with the same identity header value for the same call-id and date (which are both signed in that identity header value's signature), then it's a replay. Clearly valid in-dialog requests will have the same call-id, but because their date and cseq values will be different, their identity header values will be unique and not detected as a replay. I think there are actually legitimate technical reasons why this wouldn't always work right, even in a fully rfc3261-compliant world. For one, the request could get forked, but end up at the same verifier. The forked requests could have unique request-uri's or Route header lists, identifying unique final targets, but the verifier would consider all but one of them a replay. Similarly, a legitimate spiral through a verifier would be detected as a replay. For another, the request could be responded to by the UAS with a 302, which triggers an upstream proxy to recurse the request again through the same verifier but a new final target, which would be detected as a replay. Lastly, I believe that if UDP transport is used, the verifier can legitimately get retransmissions of requests, using the same cseq, which it would detect as replays but may really need to pass on. (ie, non-Invite requests) Then of course there is also a world with B2BUA's. I think a legitimate argument can be made that a 4474-signed signature *shouldn't* remain valid crossing such Call-ID-changing systems, because otherwise it opens up the door for replay attacks. [note: I am only talking Call-ID's, not other fields] But there are ways of providing such replay protection *without* signing the Call-ID field value. I can suggest two alternatives: 1) Create a new header or parameter to be signed and verified, which is unique per new out-of-dialog request the UAC creates - to be added by the UAC or Authenticator before signing. Ultimately, I believe the Call-ID was signed because it was an already existing header - it was very convenient. However, if 4474 fails to be usable in many cases were we think it should work, then it's very *inconvenient*. 2) Mandate that UAC's _STOP_ using IP Addresses in Call-ID's, with whatever new response code and mechanics we need to make that transition. If we were to re-create SIP today, I would argue for this to the end. If we want middle-boxes like SBC's to stop changing things we don't want them to change, stop putting things in which their owners feel compelled to change. This obviously can't be avoided for some things, but the Call-ID is one of my pet peeves because it didn't have to be one of them. Note that Option 2 would only work for SBC's really, not other B2BUA's who change it because they think they need to or really do need to for other reasons. And it would have a serious problem of needing some installed SBC's to be upgraded, whereas option 1 above would have a greater chance of working today. So my preference is Option 1. But doing Option 2 will also solve a lot of other problems in the future, so my real preference is to do BOTH. (Option 1 for 4474, Option 2 for general practice) -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 sip-bounces@ietf.org Tue Apr 15 07:49:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798353A6C85; Tue, 15 Apr 2008 07:49:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097133A6D27 for ; Tue, 15 Apr 2008 07:49: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 2K2UeuhS-Uun for ; Tue, 15 Apr 2008 07:49:01 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by core3.amsl.com (Postfix) with ESMTP id 623163A6C85 for ; Tue, 15 Apr 2008 07:49:01 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id v27so218911ele.14 for ; Tue, 15 Apr 2008 07:49:34 -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:to:subject:mime-version:content-type; bh=sGCHeQUgV7pb6Dhndu6ZazT5dyiTKUsUVpeZNlcs/D8=; b=GNtsBKn7eEV0uO2Kj0taUwwDqYMs4yvByoYBAPzdpy1GpdHW7HeSLDCzJ4oisF8hfy/PUKICO8aosJBASSN0tLeyz6FXpBsVRirswvcFxIhOb70n18GEGGrR6jN6/qpfOp8ccA4b69AYMeeRwJhvjpfidlk8mRkh23W4Md7DXZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=LhFWylJ57+oczsBueJ2f3mm2ZDQphqJIbfKSLH2zmypAmFVqtwS4CyrRb/MhW8NLPDcu2kdeiyhzYOz144dYzcHys8gmlhDCOqHFgclTyLzfcIHnhTDmDPOzu3111vTLvnHXGbRQwfI3u0KP1jxo7SO+YVUrsJJQ8aopJSGQmaA= Received: by 10.114.133.1 with SMTP id g1mr4970827wad.217.1208270973566; Tue, 15 Apr 2008 07:49:33 -0700 (PDT) Received: by 10.114.176.13 with HTTP; Tue, 15 Apr 2008 07:49:33 -0700 (PDT) Message-ID: <1ac609990804150749v3fd07aa8ye19ce4a21be397d6@mail.gmail.com> Date: Tue, 15 Apr 2008 20:19:33 +0530 From: "Aditya Sehgal" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] Invite without offer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0137515877==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0137515877== Content-Type: multipart/alternative; boundary="----=_Part_8705_18720861.1208270973562" ------=_Part_8705_18720861.1208270973562 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, Is there any practical situation where in an Invite will contain no SDP. Lets say A calls B. My understanding (albeit limited) of the RFC makes me believe that 200 OK is sent out when B will pick up the phone. Now assuming, the Initial Invite contained no offer (and 100 rel is not supported),the first offer is then sent out at 200 OK .If the return ACK is either dropped in the IP cloud or is delayed, with no media established, the call is essentially useless. So, is there any situation where it makes sense for a UE to send an Invite without an Offer. Please correct me if my assumptions are wrong. Thanks & Regards, Aditya Sehgal -- Don't take life too seriously....Nobody comes out alive anyway ------=_Part_8705_18720861.1208270973562 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,
Is there any practical situation where in an Invite will contain no SDP.
Lets say A calls B.
My understanding (albeit limited) of the RFC makes me believe that 200 OK is sent out when B will pick up the phone. Now assuming, the Initial Invite contained no offer (and 100 rel is not supported),the first offer is then sent out at 200 OK .If the return ACK is either dropped in the IP cloud or is delayed, with no media established, the call is essentially useless.

So, is there any situation where it makes sense for a UE to send an Invite without an Offer.

Please correct me if my assumptions are wrong.

Thanks & Regards,
Aditya Sehgal

--
Don't take life too seriously....Nobody comes out alive anyway ------=_Part_8705_18720861.1208270973562-- --===============0137515877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0137515877==-- From sip-bounces@ietf.org Tue Apr 15 08:01:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384793A6EFB; Tue, 15 Apr 2008 08:01:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A6428C40A for ; Tue, 15 Apr 2008 08:01:58 -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 MybW30sC5nwW for ; Tue, 15 Apr 2008 08:01:56 -0700 (PDT) Received: from server83.appriver.com (server83e.appriver.com [72.32.151.53]) by core3.amsl.com (Postfix) with ESMTP id 66D5228C525 for ; Tue, 15 Apr 2008 08:00:42 -0700 (PDT) Received: by server83.appriver.com (CommuniGate Pro PIPE 5.2.0) with PIPE id 83347432; Tue, 15 Apr 2008 10:01:12 -0500 Received: from [216.168.161.154] (HELO mailgwy2.vipcalling.corp) by server83.appriver.com (CommuniGate Pro SMTP 5.2.0) with SMTP id 83347376; Tue, 15 Apr 2008 10:01:02 -0500 Received: from SERVER719C.VIPCALLING.CORP ([216.168.161.157]) by mailgwy2.vipcalling.corp (SMSSMTP 4.1.15.47) with SMTP id M2008041511010505890 ; Tue, 15 Apr 2008 11:01:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 11:01:04 -0400 Message-ID: <8B16DA248459064EA348331D3C78B98E77C914@SERVER719C.VIPCALLING.CORP> In-Reply-To: <1ac609990804150749v3fd07aa8ye19ce4a21be397d6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Invite without offer Thread-Index: AcifCBRcCJSBY+m4ShaJNPOAxC43dAAAKaIg References: <1ac609990804150749v3fd07aa8ye19ce4a21be397d6@mail.gmail.com> From: "Manpreet Singh" To: "Aditya Sehgal" , X-Policy: GLOBAL X-Policy: GLOBAL X-Primary: msingh@ibasis.net X-Note: This Email was scanned by AppRiver SecureTide X-GBUdb-Analysis: 0, 216.168.161.154, Ugly c=0.979365 p=-0.952274 Source White X-Signature-Violations: 0-0-0-8191-c X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-Note: User Rule Hits: X-Note: Global Rule Hits: 73 74 120 X-Note: Mail Class: VALID Subject: Re: [Sip] Invite without offer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1678437441==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1678437441== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89F09.876A803D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89F09.876A803D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable usually clients would do this to know the far end full list of capabilities before they send their own offer. although this can be done via OPTIONS, but not everyone supports it and this is the other way of doing it. the media might be delayed but the 200OK is re-transmitted so it should connect fairly quickly. for this reason clients which do this, end up doing 100rel to avoid these kind of situations =20 M =20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Aditya Sehgal Sent: Tuesday, April 15, 2008 10:50 AM To: sip@ietf.org Subject: [Sip] Invite without offer Hi all, Is there any practical situation where in an Invite will contain no SDP. Lets say A calls B.=20 My understanding (albeit limited) of the RFC makes me believe that 200 OK is sent out when B will pick up the phone. Now assuming, the Initial Invite contained no offer (and 100 rel is not supported),the first offer is then sent out at 200 OK .If the return ACK is either dropped in the IP cloud or is delayed, with no media established, the call is essentially useless. So, is there any situation where it makes sense for a UE to send an Invite without an Offer. Please correct me if my assumptions are wrong. Thanks & Regards, Aditya Sehgal --=20 Don't take life too seriously....Nobody comes out alive anyway=20 ------_=_NextPart_001_01C89F09.876A803D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
usually clients would do this to know the far = end full list=20 of capabilities before they send their own offer. although this can be = done via=20 OPTIONS, but not everyone supports it and this is the other way of doing = it. the=20 media might be delayed but the 200OK is re-transmitted so it should = connect=20 fairly quickly. for this reason clients which do this, end up doing = 100rel to=20 avoid these kind of situations
 
M
 
 
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Aditya=20 Sehgal
Sent: Tuesday, April 15, 2008 10:50 AM
To:=20 sip@ietf.org
Subject: [Sip] Invite without = offer

Hi all,
Is there any practical situation where in an = Invite will=20 contain no SDP.
Lets say A calls B.
My understanding (albeit = limited) of=20 the RFC makes me believe that 200 OK is sent out when B will pick up the = phone.=20 Now assuming, the Initial Invite contained no offer (and 100 rel is not=20 supported),the first offer is then sent out at 200 OK .If the return ACK = is=20 either dropped in the IP cloud or is delayed, with no media established, = the=20 call is essentially useless.

So, is there any situation where it = makes=20 sense for a UE to send an Invite without an Offer.

Please correct = me if=20 my assumptions are wrong.

Thanks & Regards,
Aditya = Sehgal
--
Don't take life too seriously....Nobody comes out = alive=20 anyway ------_=_NextPart_001_01C89F09.876A803D-- --===============1678437441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1678437441==-- From sip-bounces@ietf.org Tue Apr 15 08:03:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CDF28C303; Tue, 15 Apr 2008 08:03:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27893A6F03 for ; Tue, 15 Apr 2008 08:03:37 -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.243, 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 u6SxVdBApmiO for ; Tue, 15 Apr 2008 08:03:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7477D3A6A2F for ; Tue, 15 Apr 2008 08:03:32 -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.263.0; Tue, 15 Apr 2008 11:03:35 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 15 Apr 2008 11:03:36 -0400 From: Hadriel Kaplan To: Aditya Sehgal , "sip@ietf.org" Date: Tue, 15 Apr 2008 11:05:59 -0400 Thread-Topic: [Sip] Invite without offer Thread-Index: AcifCAm+fyFgJemrS1GsKrxgI86IyAAAQU9A Message-ID: References: <1ac609990804150749v3fd07aa8ye19ce4a21be397d6@mail.gmail.com> In-Reply-To: <1ac609990804150749v3fd07aa8ye19ce4a21be397d6@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Sip] Invite without offer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0372013712==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0372013712== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC30BCFCE6C6Emailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC30BCFCE6C6Emailacmepacke_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your question is more appropriate for the SIP Implementers list methinks: s= ip-implementors@lists.cs.columbia.edu (see https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors) But anyway, yes there are situations where an Invite will contain no SDP, a= nd you MUST support receiving such - many systems send such offerless Invit= es. But when you send Invites, I would strongly recommend you send it with= an SDP offer unless it is actually technically impossible for you to do so= , because many systems can't handle receiving one without it and will simpl= y fail your request. -hadriel ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Adity= a Sehgal Sent: Tuesday, April 15, 2008 10:50 AM To: sip@ietf.org Subject: [Sip] Invite without offer Hi all, Is there any practical situation where in an Invite will contain no SDP. Lets say A calls B. My understanding (albeit limited) of the RFC makes me believe that 200 OK i= s sent out when B will pick up the phone. Now assuming, the Initial Invite = contained no offer (and 100 rel is not supported),the first offer is then s= ent out at 200 OK .If the return ACK is either dropped in the IP cloud or i= s delayed, with no media established, the call is essentially useless. So, is there any situation where it makes sense for a UE to send an Invite = without an Offer. Please correct me if my assumptions are wrong. Thanks & Regards, Aditya Sehgal -- Don't take life too seriously....Nobody comes out alive anyway --_000_E6C2E8958BA59A4FB960963D475F7AC30BCFCE6C6Emailacmepacke_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Your question is more appropriate for = the SIP Implementers list methinks: sip-implementor= s@lists.cs.columbia.edu

(see https://lists.cs.columbia.edu/mai= lman/listinfo/sip-implementors)

 

But anyway, yes there are situations w= here an Invite will contain no SDP, and you MUST support receiving such – = many systems send such offerless Invites.  But when you send Invites, I wou= ld strongly recommend you send it with a= n SDP offer unless it is actually technically impossible for you to do so, becaus= e many systems can’t handle receiving one without it and will simply fa= il your request. 

 

-hadriel

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Aditya Sehgal
Sent: Tuesday, April 15, 200= 8 10:50 AM
To: sip@ietf.org
Subject: [Sip] Invite withou= t offer

 

Hi all,
Is there any practical situation where in an Invite will contain no SDP. Lets say A calls B.
My understanding (albeit limited) of the RFC makes me believe that 200 OK i= s sent out when B will pick up the phone. Now assuming, the Initial Invite contained no offer (and 100 rel is not supported),the first offer is then s= ent out at 200 OK .If the return ACK is either dropped in the IP cloud or is delayed, with no media established, the call is essentially useless.

So, is there any situation where it makes sense for a UE to send an Invite without an Offer.

Please correct me if my assumptions are wrong.

Thanks & Regards,
Aditya Sehgal

--
Don't take life too seriously....Nobody comes out alive anyway <= /span>

--_000_E6C2E8958BA59A4FB960963D475F7AC30BCFCE6C6Emailacmepacke_-- --===============0372013712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0372013712==-- From sip-bounces@ietf.org Tue Apr 15 08:24:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C833A6BA0; Tue, 15 Apr 2008 08:24:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8523A696B for ; Tue, 15 Apr 2008 08:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=1.178, 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 1KM8AMEZEmLI for ; Tue, 15 Apr 2008 08:24:48 -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 803C33A6BA0 for ; Tue, 15 Apr 2008 08:24:48 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2008 08:25:22 -0700 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 m3FFPMX4001059; Tue, 15 Apr 2008 08:25:22 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m3FFPLEU019696; Tue, 15 Apr 2008 15:25:21 GMT From: Cullen Jennings To: Dean Willis In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 08:25:03 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=871; t=1208273122; x=1209137122; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=73X3clI7xR594JYb+AsAi8I4bPzhC5OIt2h6B3udbWU=; b=eaZDutvaH/cV20Qif/qw2RmZScGB8QEoiy/xBVY7XdgjWHV/IVWqoxpzi7 g7blCXs1Op35c+Qfk6cB0UNRyNMm2zdMDuWbd1nReFVmI6E266k4qlgocj5E O4EkHyO2qq; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIP IETF , Francois Audet , Dan WING , Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 14, 2008, at 8:08 PM, Dean Willis wrote: > Let's revisit the problem again: > > Alice is a customer of provider A. Bob is a customer of provider B. > > Alice calls Bob. Bob wishes to forward her call to Jenny's telephone > number, +445558675309. Dean, few question about requirements that I think change the solution ... Assuming the call to Jenny is not free, does Bob want to pay for the call to Jenny or does Bob want Alice to pay for it? Does Bob want to hide from Alice the fact that the call was forwarded. Often people forward their business phone to their mobile phone but don't want to reveal to callers either their mobile phone number or the fact that they are not really at their business phone. I'm also wondering if this thread would be better dealt with in the BLISS WG. 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 sip-bounces@ietf.org Tue Apr 15 09:01:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAB728C263; Tue, 15 Apr 2008 09:01:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6776B3A6EF7 for ; Tue, 15 Apr 2008 09:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.073, 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 yF9RvG9bfQql for ; Tue, 15 Apr 2008 09:01:24 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 8E1CD3A6B2A for ; Tue, 15 Apr 2008 09:00:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3FG18f19666; Tue, 15 Apr 2008 16:01:09 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 11:01:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: Acie+MchzwFfMARdSvqKCTm42xi8aQACXh/gAAPeb5A= References: <4804A740.3020106@cisco.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" Cc: SIP IETF , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yeah, exactly. Dean says "not working" but it is working in most scenarios. It just doesn't work that well if everybody is trying to offload the responsibility of providing the PSTN gateway to others. I have no problem with us recommending Tel URI usage for this, and hoping that implementations will catch-up. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Tuesday, April 15, 2008 07:12 > To: Paul Kyzivat > Cc: Dean Willis; Audet, Francois (SC100:3055); SIP IETF; Dan WING > Subject: RE: [Sip] E.164 - who owns it > > > I don't disagree with what you or Dean are saying in general > (though I think you'll find Tel isn't going to avoid some of > the issues Dean raises - they're more issues of response > recursion in general). My only point is that this is what is > happening *today*, in many cases. Dean said "it's not > working", and my point was "not true - it is working right > now, just not how we want and therefore it may have serious > issues in the future". > > -hadriel > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, April 15, 2008 9:02 AM > > To: Hadriel Kaplan > > Cc: Dean Willis; Francois Audet; SIP IETF; Dan WING > > Subject: Re: [Sip] E.164 - who owns it > > > > > > > > Hadriel Kaplan wrote: > > >> -----Original Message----- > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> > > >> I really can't see how; I can't make it work with my providers > > >> > > >> Let's revisit the problem again: > > >> > > >> Alice is a customer of provider A. Bob is a customer of > provider B. > > >> > > >> Alice calls Bob. Bob wishes to forward her call to Jenny's > > >> telephone number, +445558675309. > > >> > > >> At this point, Bob and provider B don't know what gateway Alice > > >> might use to reach the PSTN, They also don't know > whether reaching > > >> Jenny's phone number even requires Alice to use a gateway. > > >> > > >> What does Bob put into the Contact of a 302 he might > send to Alice? > > >> > > >> I've heard several alternatives: > > >> > > >> 1) sip:+445588675309:b.com > > >> 2) sip:+445588675309:b.com; user=phone > > >> 3) sip:+445588675309:a.com > > >> 4) sip:+445588675309:b.com;user=phone > > >> 5) tel:+445588675309 > > > > > > Right, and there is no single answer to this, because different > > > strokes > > for different folks. (not that there shouldn't be only one way, or > > that the ways should be documented - I'm just being the messenger > > here) > > > > > > Typically, Bob as a UAS puts in 1 or 2. (if one can say > "typically" > > > for > > a UAS redirecting to begin with) Since that's a 302 for > the original > > transaction, it goes upstream through Bob's b.com proxy/reg, since > > that's how it got to Bob to begin with. > > > > > One of those does a recursion, says "hmmm, not one of my > users, and > > > I > > won't send calls for a.com to PSTN, so time to redirect > back a.com". > > The contact then gets either changed to 3 or 4. (I assume > you have a > > typo in > > 4) > > > > Dean already discussed the problems with b.com attempting > to construct > > a sip-based phone number URI in the domain of a.com. IMO > its a really > > bad idea. > > > > > OR, a.com does it when it gets a 302 back from b.com with > 1 or 2 in it. > > So ultimately a.com is looking at 3 or 4 in a 302 redirect. > And a.com > > will get this response before Alice does, because a.com was in the > > request path to get to b.com, so it's in the 302 response > via path. > > A.com then recurses on it, to the PSTN if it doesn't have > such a user. > > > > Conversely, it seems like a bad idea for a.com to be second > guessing > > the validity of a sip uri in the domain of b.com. How does it know > > that it > > *won't* work? And how does it know its not really important that it > > remain as written? After all, it is b.com's URI. > > > > At least for the moment there is nothing that I am aware of in all > > specs that suggests this is any more valid to do than it > would be to > > change mailto:pkyzivat@cisco.com to mailto:pkyzivat@acmepacket.com. > > > > >> 1) causes Alice to make a call to a user ID in the > domain of b.com. > > >> Assuming that b figures out that this means a telephone > > >> destination, Alice probably doesn't have an account at > b.com to use > > >> for placing the call. So unless B provides free SIP-to-PSTN > > >> calling, or at least provides free translation service > to ENUM, she's out of luck. > > > > > > 1 and 2 never reach Alice in those forms. 3 or 4 might, but even > > > that's > > debatable (it's debatable if Alice gets the 302 redirect > unless both > > b.com and a.com can't recurse route it). > > > > When and if it is appropriate to recurse on 3xx, vs returning it, > > remains an open question. I think we can assume that the policies > > relating to that will change over time. So we ought not > assume too much. > > > > >> Of course, maybe a.com knows that when it gets a 302 back with a > > >> contact that looks like it might be a phone number, it should > > >> discard the host part and do phone number routing on the > user part. > > >> That works until a.com also has user IDs that look like phone > > >> numbers. Of course, this is a direct violation of RFC > 3261, which > > >> bans a.com from retargeting a request with a b.com host part. > > > > > > A.com gets 3 or 4, with a.com in it. > > > > > > > > >> 3) instructs alice to make a call in the domain of a.com. That's > > >> fine as long as sip:+445588675309:a.com routes to Jenny. > Does it? > > >> It might route to somebody with user ID +445588675309, > which is a > > >> perfectly valid user ID. > > > > > > You're absolutely right that there could be a > > sip:+445588675309@a.com;user=phone, which b.com did not > really mean. > > But what *exactly* do you think will happen if a.com gets > > tel:+445588675309 instead?? Most likely answer: a.com will > > immediately resolve it to > sip:+445588675309@a.com;user=phone. I mean > > there's a reason people are calling it an "alias". If > you'd like, we > > can make the param "user=^H^H^H^H^H^H^H^H^H^H^H". :) > > > > The difference is that tel: really does unambiguously represent a > > phone number, whose target is well defined for all. Domains > a.com and > > b.com are expected to agree on what it designates. > > > > That is not true of sip:+445588675309@a.com and > sip:+445588675309@b.com. > > And it is, arguably, not true for those with user=phone either. > > > > >> It might also be true that Alice doesn't use a.com for > her PSTN calls. > > >> Perhaps instead, she uses c.com. So to use c.com > services, or do an > > >> enum lookup, she has to do an illegal retargeting. > > > > > > Somehow I don't think a.com or b.com care much about that. ;) > > > > Perhaps they don't, if they don't care about standards. > > > > But *we* care, since we are making the standards. I think we want a > > standard that can be used successfully without violating it. And I > > think we would like to make it possible for Alice to use > two providers > > in that way - at least I do. > > > > >>> Really, in the long list of interop issues, this one's > pretty low > > >>> on the totem pole, imho. People are having trouble > getting basic > > >>> calls to work without the aid of a middle-box. That's a bit > > >>> higher on the list to me. :) > > >> This is a very basic interdomain calling scenario. I'm really > > >> hoping we get more and more interdomain calls. > > > > > > Oh me too! But what I meant was there are problems > getting the call > > from Alice to Bob working, never mind Bob redirecting to Charlie. :) > > > > I hope we fairly quickly get to the point where anybody > with sip phone > > can call anybody else with a sip phone, using a sip path e2e. > > > > 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 sip-bounces@ietf.org Tue Apr 15 09:20:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DFB3A6F05; Tue, 15 Apr 2008 09:20:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636033A6BF5 for ; Tue, 15 Apr 2008 09:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 txFNmBTG9nbO for ; Tue, 15 Apr 2008 09:20:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EB18628C263 for ; Tue, 15 Apr 2008 09:20:05 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3FGJa88017508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2008 11:19:37 -0500 Message-Id: <7EC96E52-68BC-434F-8C47-20D5C835411D@softarmor.com> From: Dean Willis To: jh@tutpro.com (Juha Heinanen) In-Reply-To: <18436.46476.915571.898146@taimen.test.fi> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 11:19:31 -0500 References: <18436.46476.915571.898146@taimen.test.fi> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 15, 2008, at 9:02 AM, Juha Heinanen wrote: > Francois Audet writes: > >> For the type of feature you are looking at, I think a Tel URI makes >> more >> sense. I'm just pointing out with the current state of SIP phones, it >> probably won't work. > > you are starting a new trend here. usually this wg has not worried > what > people have actually implemented. instead it has kept on producing > countless rfc that are completely ignored by vendors. > > you have to face it that the only way to fix the 302 problem is to > make > tel uris mandatory. if there is a list of fixes to rfc3261 somewhere, > please add it there. I'm initially attempted to agree. But do we need tel: URI support in a node that perhaps just does IM? That just does presence? Perhaps we do, if we see tel: routing and locating as becoming critical tools for the internet. Personally, I'm not sure this was what we had in mind when thinking about the locator/identifier issue. -- 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 sip-bounces@ietf.org Tue Apr 15 09:25:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E016428C3E9; Tue, 15 Apr 2008 09:25:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFB328C447 for ; Tue, 15 Apr 2008 09:25:50 -0700 (PDT) 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 QWagjBPCl8xS for ; Tue, 15 Apr 2008 09:25:49 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 4733928C3EA for ; Tue, 15 Apr 2008 09:25:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id E34C11EC2A9; Tue, 15 Apr 2008 19:25:39 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyhzjYqr38YY; Tue, 15 Apr 2008 19:25:33 +0300 (EEST) Received: from taimen (h14632.gprs.dnafinland.fi [87.93.146.32]) by tutpro.com (Postfix) with ESMTP; Tue, 15 Apr 2008 19:25:33 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 0419BAC08A; Tue, 15 Apr 2008 19:25:29 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18436.55033.527353.741622@taimen.test.fi> Date: Tue, 15 Apr 2008 19:25:29 +0300 To: Dean Willis In-Reply-To: <7EC96E52-68BC-434F-8C47-20D5C835411D@softarmor.com> References: <18436.46476.915571.898146@taimen.test.fi> <7EC96E52-68BC-434F-8C47-20D5C835411D@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis writes: > But do we need tel: URI support in a node that perhaps just does IM? > That just does presence? i can imagine a mobile operator that supports im and presence via a "pstn" gw. -- juha _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 15 09:28:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7049428C311; Tue, 15 Apr 2008 09:28:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D78C3A67A6 for ; Tue, 15 Apr 2008 09:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 IkR9FD-SJGFz for ; Tue, 15 Apr 2008 09:28:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3515B28C311 for ; Tue, 15 Apr 2008 09:28:29 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3FGStW8017656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2008 11:28:56 -0500 Message-Id: From: Dean Willis To: Cullen Jennings In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 11:28:49 -0500 References: X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Francois Audet , Dan WING , Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 15, 2008, at 10:25 AM, Cullen Jennings wrote: > > On Apr 14, 2008, at 8:08 PM, Dean Willis wrote: >> Let's revisit the problem again: >> >> Alice is a customer of provider A. Bob is a customer of provider B. >> >> Alice calls Bob. Bob wishes to forward her call to Jenny's telephone >> number, +445558675309. > > Dean, few question about requirements that I think change the > solution ... > > Assuming the call to Jenny is not free, does Bob want to pay for the > call to Jenny or does Bob want Alice to pay for it? In my original stated use case, Bob doesn't want to pay for it himself, and neither does Bob's service provider. If Alice wants to pay for it, that's OK with Bob. If she can get it free, that's OK with him too. > > Does Bob want to hide from Alice the fact that the call was > forwarded. Often people forward their business phone to their mobile > phone but don't want to reveal to callers either their mobile phone > number or the fact that they are not really at their business phone. I did not explicitly state this, but the general model here would be for Alice to know that the call is being forwarded and where it is being forwarded to. Since she presumably has to pay the bill (or make a lowest-cost routing decision), she needs this information. For the purpose of the call we're talking about, she might as well get connected with Bob and then get a REFER from him. > I'm also wondering if this thread would be better dealt with in the > BLISS WG. Perhaps. but I'm thinking that this thread is digging some very fundamental brokenness with how we've specified and implemented SIP, deep in the heart of the RFC 3261 series. -- 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 sip-bounces@ietf.org Tue Apr 15 09:32:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEAEF3A6C07; Tue, 15 Apr 2008 09:32:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0259C3A6B74 for ; Tue, 15 Apr 2008 09:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.970, 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 EYB0EXfNFdol for ; Tue, 15 Apr 2008 09:32:07 -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 1E0F53A6A30 for ; Tue, 15 Apr 2008 09:32:07 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2008 09:32:40 -0700 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 m3FGWeT3010334; Tue, 15 Apr 2008 09:32:40 -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 m3FGWdw6001360; Tue, 15 Apr 2008 16:32:40 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, 15 Apr 2008 12:32:35 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 12:32:35 -0400 Message-ID: <4804D8BF.6090400@cisco.com> Date: Tue, 15 Apr 2008 12:33:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <18436.46476.915571.898146@taimen.test.fi> <7EC96E52-68BC-434F-8C47-20D5C835411D@softarmor.com> In-Reply-To: <7EC96E52-68BC-434F-8C47-20D5C835411D@softarmor.com> X-OriginalArrivalTime: 15 Apr 2008 16:32:35.0264 (UTC) FILETIME=[4F8A9C00:01C89F16] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1156; t=1208277160; x=1209141160; c=relaxed/simple; s=sjdkim1004; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=KavTnNjCSLOognr2W3LPLy5f4obNX2aQAa3ixEXJIB8=; b=liG2To5ZU/M2mR5qJ97stJlRX6MYN+h5CL8QFWL1JpBKmw7yeRsqvLXdS4 NmC2wIBsmhwRW9cN5P1CuVw3hjFfsLV9BvGT2fC1vzP8NP3D3pEAm7wZFBOU wH2Ia2oN9foOkQ8q35XYIpaUlSIKsMSy+xTGOLUjkkoPh3R0eEC3M=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Apr 15, 2008, at 9:02 AM, Juha Heinanen wrote: >> Francois Audet writes: >> >>> For the type of feature you are looking at, I think a Tel URI makes more >>> sense. I'm just pointing out with the current state of SIP phones, it >>> probably won't work. >> >> you are starting a new trend here. usually this wg has not worried what >> people have actually implemented. instead it has kept on producing >> countless rfc that are completely ignored by vendors. >> >> you have to face it that the only way to fix the 302 problem is to make >> tel uris mandatory. if there is a list of fixes to rfc3261 somewhere, >> please add it there. > > > I'm initially attempted to agree. > > But do we need tel: URI support in a node that perhaps just does IM? > That just does presence? > > Perhaps we do, if we see tel: routing and locating as becoming critical > tools for the internet. Personally, I'm not sure this was what we had in > mind when thinking about the locator/identifier issue. Don't we want interop between IM and SMS? If so, then you want IM devices to support tel URIs. 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 sip-bounces@ietf.org Tue Apr 15 09:32:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A963A6B74; Tue, 15 Apr 2008 09:32:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF753A6AD7 for ; Tue, 15 Apr 2008 09:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 FvM4keVItvPO for ; Tue, 15 Apr 2008 09:32:46 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A0A7C28C3A6 for ; Tue, 15 Apr 2008 09:32:46 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3FGXBtN017720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2008 11:33:12 -0500 Message-Id: <37F3966E-9759-464B-A254-2FA14836834C@softarmor.com> From: Dean Willis To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 11:33:05 -0500 References: <4804A740.3020106@cisco.com> <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 15, 2008, at 11:01 AM, Francois Audet wrote: > Dean says "not working" but it is working in most scenarios. > It just doesn't work that well if everybody is trying to offload the > responsibility of providing the PSTN gateway to others. Doesn't work for me with any of the providers to whose services I have access. Of course, most of the providers just do replicated telephone services over SIP. The user has no idea about the protocol involved, and the functions mirror what that user would have received from a class 5 switch or PBX. Fact, most of the provider systems never issue a 302 at all, and this is partly why. > I have no problem with us recommending Tel URI usage for this, and > hoping that implementations will catch-up. Same here. -- 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 sip-bounces@ietf.org Tue Apr 15 09:38:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91ED28C419; Tue, 15 Apr 2008 09:38:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDE528C3D1 for ; Tue, 15 Apr 2008 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 MQUIwnWelU3l for ; Tue, 15 Apr 2008 09:38:27 -0700 (PDT) Received: from tutpro.com (sip.tutpro.com [192.98.100.10]) by core3.amsl.com (Postfix) with ESMTP id 129BD28C134 for ; Tue, 15 Apr 2008 09:38:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 19BE81EC2A9; Tue, 15 Apr 2008 19:39:00 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7FnMtVB9Z90; Tue, 15 Apr 2008 19:38:50 +0300 (EEST) Received: from taimen (h14632.gprs.dnafinland.fi [87.93.146.32]) by tutpro.com (Postfix) with ESMTP; Tue, 15 Apr 2008 19:38:50 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 0C603AC06E; Tue, 15 Apr 2008 19:38:45 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18436.55830.5373.302414@taimen.test.fi> Date: Tue, 15 Apr 2008 19:38:46 +0300 To: Dean Willis In-Reply-To: <37F3966E-9759-464B-A254-2FA14836834C@softarmor.com> References: <4804A740.3020106@cisco.com> <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> <37F3966E-9759-464B-A254-2FA14836834C@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis writes: > > I have no problem with us recommending Tel URI usage for this, and > > hoping that implementations will catch-up. > > Same here. "recommending" is not enough. support for tel uris must be made mandatory. as i said, if there is a somewhere an rfc3261 bug list, this belongs there. -- juha _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 15 09:52:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4733A6C60; Tue, 15 Apr 2008 09:52:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4663A6A2F for ; Tue, 15 Apr 2008 09:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.934, 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 kjGGD3zTc3AE for ; Tue, 15 Apr 2008 09:51:58 -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 4386A3A6BE5 for ; Tue, 15 Apr 2008 09:51:58 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2008 09:52:31 -0700 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 m3FGqVMI022330; Tue, 15 Apr 2008 09:52:31 -0700 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 m3FGqVhC007627; Tue, 15 Apr 2008 16:52:31 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, 15 Apr 2008 12:52:31 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 12:52:30 -0400 Message-ID: <4804DD6A.3080908@cisco.com> Date: Tue, 15 Apr 2008 12:52:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: X-OriginalArrivalTime: 15 Apr 2008 16:52:30.0761 (UTC) FILETIME=[181CF990:01C89F19] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1147; t=1208278351; x=1209142351; c=relaxed/simple; s=sjdkim1004; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=Yk8gXHo7RBJa3qh6e6UIw9dfgKVoI6g1mBe8i3MOP9c=; b=NTJwCGSmmZPlLCsIL5pSl0lfLXaonPUBKMn5PBF16VvhpTt1uxZVq44VSL ff4G+rgSdN3mp9j8kU0AmkBPo+ZKWwp+EvYfiMACXbCOxXimncko9rxfauWX a9Z6HiOosE5uZssR9sAAR2BzDfn+xIr5VZJsR1lzLv50KLmPnf6UE=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Cullen Jennings , SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Apr 15, 2008, at 10:25 AM, Cullen Jennings wrote: >> >> I'm also wondering if this thread would be better dealt with in the >> BLISS WG. > > Perhaps. but I'm thinking that this thread is digging some very > fundamental brokenness with how we've specified and implemented SIP, > deep in the heart of the RFC 3261 series. There is a relationship with Bliss here, but its complicated. Here we are simply taking "features" as use cases for investigating the adequacy of the fundamental mechanisms of SIP. We aren't so concerned with the details of those features. So IMO this is a sip problem. OTOH, if all the features we are using for use cases are totally bogus, then maybe we are doing work to no useful purpose. This is a matter of whether you think work should be driven from the bottom up or the top down. IMO there is no single answer to that. Some things need to be driven from the bottom up because there will be no demand for a feature until it has been demonstrated to be useful. In other cases top down is the way to get real world feedback into the system. 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 sip-bounces@ietf.org Tue Apr 15 10:32:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A5128C34C; Tue, 15 Apr 2008 10:32:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073D528C34C for ; Tue, 15 Apr 2008 10:32:56 -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.371, 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 Gruab4dprGKo for ; Tue, 15 Apr 2008 10:32:54 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C57B63A6B45 for ; Tue, 15 Apr 2008 10:32:53 -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 m3FHWc013865; Tue, 15 Apr 2008 17:32:38 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 12:33:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1627C06C@zrc2hxm0.corp.nortel.com> In-reply-to: <18436.55830.5373.302414@taimen.test.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: AcifFzbz8FT4g30kStSLfinyNGPoAAAACKRQ References: <4804A740.3020106@cisco.com> <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> <37F3966E-9759-464B-A254-2FA14836834C@softarmor.com> <18436.55830.5373.302414@taimen.test.fi> From: "Francois Audet" To: "Juha Heinanen" , "Dean Willis" Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm not sure about that. It's not because it's mandatory that people implement it (TLS, TCP, SIPS, to name a few). I think we need instead to explain it is necessary, and what doest it mean to various components (i.e., UACs, UASs, and Proxies). For example: - UACs MUST support Tel URIs (and use whatever proxy they have available to route requests to Tel URIs). Example, recurse on 302. - UAs (not sure there are many problems here). - Proxies. Need to be able to route on Tel URI. If they don't recurse, need to pass 302 with Tel Contact. If they recurse, need to act on it. Also, we need to warn people on improper usages of Tel URI (stupid UA pet tricks). For example, don't use Tel URIs in Contacts other than 3XX. In other words, this is not just as simple adding "must support Tel URI" in RFC 3261. > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Tuesday, April 15, 2008 09:39 > To: Dean Willis > Cc: Audet, Francois (SC100:3055); SIP IETF; Paul Kyzivat; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > Dean Willis writes: > > > > I have no problem with us recommending Tel URI usage for > this, and > > hoping that implementations will catch-up. > > > > Same here. > > "recommending" is not enough. support for tel uris must be > made mandatory. as i said, if there is a somewhere an > rfc3261 bug list, this belongs there. > > -- juha > _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 15 11:24:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B221628C1EC; Tue, 15 Apr 2008 11:24:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1A83A6DB5 for ; Tue, 15 Apr 2008 11:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 scYz3Lutz4eX for ; Tue, 15 Apr 2008 11:24:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2AC083A6818 for ; Tue, 15 Apr 2008 11:24:06 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3FIOYno018605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2008 13:24:36 -0500 Message-Id: <3A5E2D8E-339F-4BF6-A85F-5870D522F28D@softarmor.com> From: Dean Willis To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1627C06C@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 13:24:29 -0500 References: <4804A740.3020106@cisco.com> <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> <37F3966E-9759-464B-A254-2FA14836834C@softarmor.com> <18436.55830.5373.302414@taimen.test.fi> <1ECE0EB50388174790F9694F77522CCF1627C06C@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 15, 2008, at 12:33 PM, Francois Audet wrote: > I'm not sure about that. > > It's not because it's mandatory that people implement it (TLS, TCP, > SIPS, to name a few). > I think we need instead to explain it is necessary, and what doest > it mean to various components (i.e., UACs, UASs, and Proxies). > > For example: > > - UACs MUST support Tel URIs (and use whatever proxy they have > available to route requests to Tel URIs). Example, recurse on 302. They don't necessarily have to use a proxy; they might have their own telephony routing tables, be able to make ENUM lookups, etc. AS I've said, we need an RFC 3263 for tel: URIs if we expect people to use tel: > > > - UAs (not sure there are many problems here). UAS might need to be able to return a Tel contact in a 302 if they issue 302 at all. -- 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 sip-bounces@ietf.org Tue Apr 15 11:44:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D708C3A6E00; Tue, 15 Apr 2008 11:44:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A963A6D65 for ; Tue, 15 Apr 2008 11:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 oJZsb7+MNXDR for ; Tue, 15 Apr 2008 11:44:04 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0300B3A69CD for ; Tue, 15 Apr 2008 11: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.263.0; Tue, 15 Apr 2008 14:44:07 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 15 Apr 2008 14:44:07 -0400 From: Hadriel Kaplan To: Francois Audet , Juha Heinanen , Dean Willis Date: Tue, 15 Apr 2008 14:46:31 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcifFzbz8FT4g30kStSLfinyNGPoAAAACKRQAAOS7aA= Message-ID: References: <4804A740.3020106@cisco.com> <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> <37F3966E-9759-464B-A254-2FA14836834C@softarmor.com> <18436.55830.5373.302414@taimen.test.fi> <1ECE0EB50388174790F9694F77522CCF1627C06C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1627C06C@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I totally agree. They need strong beneficial reasons, not mandates. (ie, the carrot, not the stick, or maybe both) But we also need to figure out how to do this without making calls fail if they start/try actually using Tel. Otherwise no one will. -hadriel > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Francois Audet > Sent: Tuesday, April 15, 2008 1:33 PM > To: Juha Heinanen; Dean Willis > Cc: SIP IETF; Paul Kyzivat; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > I'm not sure about that. > > It's not because it's mandatory that people implement it (TLS, TCP, SIPS, > to name a few). > I think we need instead to explain it is necessary, and what doest it mean > to various components (i.e., UACs, UASs, and Proxies). > > For example: > > - UACs MUST support Tel URIs (and use whatever proxy they have > available to route requests to Tel URIs). Example, recurse on 302. > > - UAs (not sure there are many problems here). > > - Proxies. Need to be able to route on Tel URI. If they don't > recurse, need to pass 302 with Tel Contact. If they recurse, need > to act on it. > > Also, we need to warn people on improper usages of Tel URI (stupid > UA pet tricks). For example, don't use Tel URIs in Contacts other than > 3XX. > > In other words, this is not just as simple adding "must support > Tel URI" in RFC 3261. > > > > -----Original Message----- > > From: Juha Heinanen [mailto:jh@tutpro.com] > > Sent: Tuesday, April 15, 2008 09:39 > > To: Dean Willis > > Cc: Audet, Francois (SC100:3055); SIP IETF; Paul Kyzivat; Dan WING > > Subject: Re: [Sip] E.164 - who owns it > > > > Dean Willis writes: > > > > > > I have no problem with us recommending Tel URI usage for > > this, and > > hoping that implementations will catch-up. > > > > > > Same here. > > > > "recommending" is not enough. support for tel uris must be > > made mandatory. as i said, if there is a somewhere an > > rfc3261 bug list, this belongs there. > > > > -- juha > > > _______________________________________________ > 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 sip-bounces@ietf.org Tue Apr 15 14:28:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9031F28C444; Tue, 15 Apr 2008 14:28:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0101728C444 for ; Tue, 15 Apr 2008 14:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.666, 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 O6dAiJsyiXfi for ; Tue, 15 Apr 2008 14:28:18 -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 7BCCC28C433 for ; Tue, 15 Apr 2008 14:28:18 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2008 14:28:52 -0700 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 m3FLSqaO031434; Tue, 15 Apr 2008 14:28:52 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3FLSpfN010689; Tue, 15 Apr 2008 21:28:52 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <20080405011409.30D205081A@romeo.rtfm.com><0ec601c89aa7$9cf46f20$c5f0200a@cisco.com> <20080410030551.10CE7219C03@kilo.rtfm.com> Date: Tue, 15 Apr 2008 14:28:51 -0700 Message-ID: <007801c89f3f$b38bf8b0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aciat8l65L8/2Rz9SjGqnl7WELJ/gABY+QSg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080410030551.10CE7219C03@kilo.rtfm.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8530; t=1208294932; x=1209158932; 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]=20Review=20of=20draft-ietf-sip-me dia-security-requirements-04 |Sender:=20; bh=veyZFMAEbWAftY81DKk1fLnVQGzAPGe0Ek0lKORMRCg=; b=a/tdHDjaK0KdKVqEazTePftV3k0w52XCLuRy2XC/s7Tnhfh2MUktHN32LE CxUpxNS71aljYZ3LO9ghiEiEXGY6/BMVtQUlJsj6NhMJOncpz8kD5zxdM+p7 3zV6umhcIcFwDglXYZ8UU4l0ZemIAFli2BlWYEhGAezs7Aplr633o=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sip@ietf.org, draft-ietf-sip-media-security-requirements@tools.ietf.org Subject: Re: [Sip] Review of draft-ietf-sip-media-security-requirements-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: ... > > > S 4.3. > > > The entire section on shared key conferencing doesn't lead to any > > > requirements as far as I can tell. Does it make sense to remove > > > it from this document? > > > > Right. It seems useful to leave it in, as mentioned at the > > beginning of the section: > > > > The consensus on the RTPSEC mailing list was to concentrate on > > unicast, point-to-point sessions. Thus, there are no > requirements > > related to shared key conferencing. This section is retained for > > informational purposes. > > > > if others agree it should be removed, I can remove it. > > I've got no real problem with leaving it in, I just wanted > to note it. I moved it into Appendix B, which Dan York suggested. That accomplishes the goal of documenting the decision and clearly making the discussion text non-normative. > > > S 5.3. > > > R-OTHER-SIGNALING: > > > A solution SHOULD be able to negotiate keys for > > > SRTP sessions > > > created via different call signaling protocols > > > (e.g., between > > > Jabber, SIP, H.323, MGCP). > > > > > > This is not discussed anywhere in the document. I wonder > > > if it makes > > > sense to remove it. > > > > I know that my employer's products interwork between SIP > > and MGCP (and > > our proprietary SCCP) with SRTP today -- all using Security > > Descriptions. > > > > I know we have a need to meet this requirement with anything that > > replaces our Security Descriptions implementations. I expect others > > do, too. > > > > Would adding motivating text (in a new subsection 4.xxx) be > > useful? I had assumed the need was self-evident. > > As a matter of form, I think it would be good to have a section > with motivating text. Ok. I added a new section to justify R-OTHER-SIGNALING: 4.8. Interworking with Other Signaling Protocols The discussion in this section relates to the requirement R-OTHER- SIGNALING. In many environments, some devices are signaled with protocols other than SIP which do not share SIP's offer/answer model (e.g., [H.248.1] or do not utilize SDP (e.g., H.323). In other environments, both endpoints may be SIP, but may use different key management systems (e.g., one uses MIKEY-RSA, the other MIKEY-RSA-R). In these environments, it is desirable to have SRTP -- rather than RTP -- between the two endpoints. It is always possible, although undesirable, to interwork those disparate signaling systems or disparate key management systems by decrypting and re-encrypting each SRTP packet in a device in the middle of the network (often the same device performing the signaling interworking). This is undesirable due to the cost and increased attack area, as such an SRTP/SRTP interworking device is a valuable attack target. At the time of this writing, interworking is considered important. Interworking without decryption/encryption of the SRTP, while useful, is not yet deemed critical because the scale of such SRTP deployments is, to date, relatively small. and a new section to justify R-CERTS (based on comments I received from another reviewer): 4.9. Certificates The discussion in this section relates to R-CERTS. On the Internet and on some private networks, obtaining certificates issued by a certificate authority can be difficult or expensive, and requires peers to trust the issuing certificate authority. For these reasons, it is important that authentication mechanisms that utilize certificates not rely exclusively on such CA-issued certificates, but to also allow self-signed certificates. By allowing the use of such self-signed certificates, an out-of-band mechanism (e.g., manual configuration) can be used to trust a peer's certificate. Here are the other requirements in the document which do not have text to motivate the requirements. Which of these -- or perhaps all of them? -- should have additional text written: R-RTP-VALID: If SRTP key negotiation is performed over the media path (i.e., using the same UDP/TCP ports as media packets), the key negotiation packets MUST NOT pass the RTP validity check defined in Appendix A.1 of [RFC3550]. R-NEGOTIATE: The media security key management protocol MUST allow a SIP User Agent to negotiate media security parameters for each individual session. R-PFS: The media security key management protocol MUST be able to support perfect forward secrecy. R-COMPUTE: The media security key management protocol MUST support offering additional SRTP cipher suites without incurring significant computational expense. R-DOS: The media security key management protocol SHOULD NOT introduce new denial of service vulnerabilities (e.g., the protocol should not request the endpoint to perform CPU-intensive operations without the client being able to validate or authorize the request). R-EXISTING: The media security key management protocol SHOULD allow endpoints to authenticate using pre-existing cryptographic credentials, e.g., certificates or pre-shared keys. R-AGILITY: The media security key management protocol MUST provide crypto- agility, i.e., the ability to adapt to evolving cryptography and security requirements (update of cryptographic algorithms without substantial disruption to deployed implementations) R-DOWNGRADE: The media security key management protocol MUST protect cipher suite negotiation against downgrading attacks. R-ALLOW-RTP: A solution SHOULD be described which allows RTP media to be received by the calling party until SRTP has been negotiated with the answerer, after which SRTP is preferred over RTP. Related to this, the two requirements R-ASSOC and R-FIPS have in-line justifications (rather than a discussion in a separate section). This was done because they are relatively short, but for style reasons (and because some of the newer motivational text is now quite short) we could move those justifications out of Section 5 (requirements) and into section 4 (call scenarios and requirements considerations). I don't care much either way. ... > > Thanks. I don't know where that text came from (it isn't my wording > > but it was in my original -00). Changed to: > > > > DTLS-SRTP > > PFS is provided if the negotiated cipher suite > > uses ephemeral > > keys (e.g., Diffie-Hellman (DH_RSA from [RFC4346]) > > or Elliptic > > Curve Diffie-Hellman [RFC4492]). > > s/DH_RSA/DHE_RSA/. DH_RSA means static keys. Thanks, fixed. > > > S A.1.13.3. > > > It's probably important to indicate that it is desirable to have > > > the profile be RTP/SAVP when SRTP is used. That's a disadvantage > > > of media path probing, for instance. I don't think that comes > > > across clearly here. > > > > There is a disadvantage with RTP/SAVP as the profile, as > > well, mentioned at > > the beginning of that section -- just prior to the list of candidate > > techniques. > > > > This section is titled Best Effort Encryption, and RTP/SAVP > > is not a candidate > > technique to provide best effort encryption -- RTP/SAVP > > causes a call to fail > > to complete if any of the remote forks or targets (during > > retargeting) rejects > > the call because they don't understand that profile. This > > is discussed at the > > beginning of that section, in order to justify why we need > > best effort > > encryption -- so that we can deploy SRTP without a priori > > knowledge of the > > called party's deployment of RTP/SAVP-capable endpoints at > > that particular moment. > > So, maybe I just misunderstood the situation: I had thought that > with the new media cap stuff one would offer both RTP/SAVP and > RTP/AVP, so you would get best effort. Am I confused? We do -- but the SDP capability negotiation does not put RTP/SAVP on the "m=" line (which is where the profile is indicated). Rather, SDP capability negotiation puts the RTP/SAVP profile into an "a=" line. -d _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 15 14:29:53 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D03E28C3D8; Tue, 15 Apr 2008 14:29:53 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458B43A680E for ; Tue, 15 Apr 2008 14:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 YzJDvSbs5sr7 for ; Tue, 15 Apr 2008 14:29:50 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3214D28C3D8 for ; Tue, 15 Apr 2008 14:29:50 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JZD0069FYENQP@siemenscomms.co.uk> for sip@ietf.org; Tue, 15 Apr 2008 22:30:23 +0100 (BST) Date: Tue, 15 Apr 2008 22:30:21 +0100 From: "Elwell, John" In-reply-to: <18436.55830.5373.302414@taimen.test.fi> To: Juha Heinanen , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0A08923@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcifF/rC0oD5akduQWit9CScyc6H0gAJ5ogQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4804A740.3020106@cisco.com> <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> <37F3966E-9759-464B-A254-2FA14836834C@softarmor.com> <18436.55830.5373.302414@taimen.test.fi> Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Juha, In fact, it is probably a combination, e.g., mandating on receipt and recommending on send. One thing that perhaps should be mandatory is being able to handle tel received in a 302. Sending tel in a 302 should not be more than a recommendation. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Juha Heinanen > Sent: 15 April 2008 17:39 > To: Dean Willis > Cc: SIP IETF; Francois Audet; Paul Kyzivat; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > Dean Willis writes: > > > > I have no problem with us recommending Tel URI usage for > this, and > > > hoping that implementations will catch-up. > > > > Same here. > > "recommending" is not enough. support for tel uris must be made > mandatory. as i said, if there is a somewhere an rfc3261 bug > list, this > belongs there. > > -- juha > _______________________________________________ > 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 sip-bounces@ietf.org Tue Apr 15 22:06:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466FD3A6A7E; Tue, 15 Apr 2008 22:06:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6393A6A7E for ; Tue, 15 Apr 2008 22:06:14 -0700 (PDT) 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 1pFXSHiszbkk for ; Tue, 15 Apr 2008 22:06:13 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 198713A6A51 for ; Tue, 15 Apr 2008 22:06:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 4FA441EC2A9; Wed, 16 Apr 2008 08:06:46 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6Iigvf0-j58; Wed, 16 Apr 2008 08:06:39 +0300 (EEST) Received: from taimen (h143213.gprs.dnafinland.fi [87.93.143.213]) by tutpro.com (Postfix) with ESMTP; Wed, 16 Apr 2008 08:06:39 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id D6C2FAC10F; Wed, 16 Apr 2008 08:06:32 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18437.35160.188336.813510@taimen.test.fi> Date: Wed, 16 Apr 2008 08:06:32 +0300 To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0A08923@GBNTHT12009MSX.gb002.siemens.net> References: <4804A740.3020106@cisco.com> <1ECE0EB50388174790F9694F77522CCF1627BD3F@zrc2hxm0.corp.nortel.com> <37F3966E-9759-464B-A254-2FA14836834C@softarmor.com> <18436.55830.5373.302414@taimen.test.fi> <0D5F89FAC29E2C41B98A6A762007F5D0A08923@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John writes: > In fact, it is probably a combination, e.g., mandating on receipt and > recommending on send. One thing that perhaps should be mandatory is > being able to handle tel received in a 302. Sending tel in a 302 should > not be more than a recommendation. fine, juha _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 15 22:18:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E373A6BDD; Tue, 15 Apr 2008 22:18:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F983A6B87 for ; Tue, 15 Apr 2008 22:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 Ilv6zNU8SXcA for ; Tue, 15 Apr 2008 22:18:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 325133A6885 for ; Tue, 15 Apr 2008 22:18:27 -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.263.0; Wed, 16 Apr 2008 01:18:31 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 16 Apr 2008 01:18:29 -0400 From: Hadriel Kaplan To: Cullen Jennings , Dean Willis Date: Wed, 16 Apr 2008 01:19:52 -0400 Thread-Topic: What 4474 signs part-2 [was: Proposal to Revise RFC 4474] Thread-Index: AcieP0/LxeHkmxVcTcSS+BethEerDAAWDIQgACpzRAA= Message-ID: References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> <29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , "jon.peterson@neustar.biz" Subject: [Sip] What 4474 signs part-2 [was: Proposal to Revise RFC 4474] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Cullen Jennings > > Based on the discussion I've seen so far, the primary use case for > this modification is to allow the SBC to do media steering so it can > steer the RTP through a path that provides better QoS. As you say, > this could be achieved by modifying the SDP and changing RFC 4474 to > allow that, but there are probably some other approaches we should be > considering as well, including ones that may need to be done outside > of SIP. If there's consensus that this is the problem > that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC > chairs and figure out a process for how to evaluate the various > options and get this moving forward. If this isn't > the primary use case, then I think we probably need some more > discussion to get a clearer idea of what the problem is. Part 2 of this series: Signing the Contact URI. I believe 4474 signs the Contact URI to prevent malicious attackers from intercepting a signed request and replacing the Contact in order to receive all later requests/responses. Or at least that's how I read rfc4474's reason for it: The Contact header field is included to tie the Identity header to a particular user agent instance that generated the request. Were an active attacker to intercept a request containing an Identity header, and cut-and-paste the Identity header field into its own request (reusing the From, To, Contact, Date, and Call-ID fields that appear in the original message), the attacker would not be eligible to receive SIP requests from the called user agent, since those requests are routed to the URI identified in the Contact header field. However, the Contact header is only included in dialog-forming requests, so it does not provide this protection in all cases. While I appreciate the desire, I don't see how signing the Contact actually accomplishes this goal in many cases. A malicious attacker can easily insert Via and Record-Route headers, to get any subsequent in-dialog requests/responses. This is in fact what the non-MitM baiting attack described in draft-kaplan-sip-baiting-attack-02 does. But there is potential for a Contact URI to be used for out-of-dialog requests, for example in later REFERs and certain Conference applications, which is what triggered the need for GRUU's. In that sense signing it may be valuable. Unfortunately that contradicts the goals of certain middle-boxes, and figuring out if those middle-boxes are changing it for malicious vs. legitimate reasons is an impossible task. Note that not signing the contact does not hurt the strength of the signed request directly (because the Record-Route issue already weakened that), but hurts the validity of the Contact for use in future out-of-dialog requests from the UAS. The question then is what exactly is harmed if a malicious attacker inserts itself in the Contact for such use-cases. If a later REFER or conference INVITE is sent to the attacker instead of the correct UA, it will only succeed in transferring or joining the call if it actually reaches the right UA. Certainly the attacker could pretend to be the correct UA, and thus either perform full impersonation, or simply view SIP signaling which it otherwise might not get to. However this form of attack is far less likely and less fruitful than those available to attackers by simply inserting Record-Routes as done in the baiting attack for the original request, and can be detected by RFC4916-type upstream signing in response to the REFER or conference INVITE. Therefore, I propose a straw-man: Allow the authenticating signer and/or the UAC to choose whether to sign the Contact URI, by having it add an Identity-Info param such as "no=contact". The inclusion of this param means the signature does not include the Contact addr-spec. The Identity-Info header is itself not signed, but that won't matter because if an attacker adds this but the signature did include the contact, it will invalidate the signature, and vice-versa if an attacker removes it. This weakens things as described earlier, but it's up to the originator to decide if they're ok with that. (A better-than-nothing approach) Regardless, I suggest we strongly recommend in any update to RFC 4474 that GRUU's be used for signed Contact URI's. When the Contact is a GRUU using the domain name instead of the UAC's host address, there is less need for middle-boxes to change the Contact. It is often changed to hide host-specific information, and with a GRUU that can be avoided. (it won't go away completely, but it increases the odds of success if it is still signed) -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 sip-bounces@ietf.org Tue Apr 15 22:30:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078933A6865; Tue, 15 Apr 2008 22:30:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5435A3A6921 for ; Tue, 15 Apr 2008 22:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rwjIh+Pz0Il for ; Tue, 15 Apr 2008 22:30:27 -0700 (PDT) Received: from kc-msxproto1.kc.umkc.edu (kc-msxproto1.kc.umkc.edu [134.193.143.167]) by core3.amsl.com (Postfix) with ESMTP id 7A67628C110 for ; Tue, 15 Apr 2008 22:30:09 -0700 (PDT) X-Received-From-Address: 134.193.32.11 X-Envelope-From: Ambreen.Haleem@umkc.edu X-Envelope-To: sip@ietf.org Importance: normal Priority: normal Received: from KC-MSX1.kc.umkc.edu ([134.193.32.11]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 00:30:43 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 00:30:43 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP based VoIP in cellular network thread-index: AcifgwPa6d/b8cH8S7SrXFkYfpDW/w== From: "Haleem, Ambreen \(UMKC-Student\)" To: X-OriginalArrivalTime: 16 Apr 2008 05:30:44.0091 (UTC) FILETIME=[04403CB0:01C89F83] Subject: [Sip] SIP based VoIP in cellular network X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I'm doing MS in computer science and wants to do thesis on SIP based VoIP in cellular networks. The problem area I had selected is the overhead involved in SIP based VoIP, with and without compression, number of calls, and context transfers in the case of handoffs. I wanted opinion around this topic, how useful this would be and if anyone can give me directions as how to go about it. Regards, Ambreen Haleem M.S. Computer Science Candidate School of Computing and EngineeringUniversity of Missouri, Kansas City _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 16 02:54:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C12A28C495; Wed, 16 Apr 2008 02:54:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11B228C49B for ; Wed, 16 Apr 2008 02:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv4L7UUMVsaG for ; Wed, 16 Apr 2008 02:54:10 -0700 (PDT) Received: from gws03.hcl.in (gws03.mail.hcl.in [203.105.186.19]) by core3.amsl.com (Postfix) with ESMTP id 675E828C471 for ; Wed, 16 Apr 2008 02:54:09 -0700 (PDT) Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 86C7F37C16F for ; Wed, 16 Apr 2008 15:24:41 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTP id 4746237C046for ; Wed, 16 Apr 2008 15:24:41 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 15:24:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 15:27:36 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC604371125@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding SDP 'M' Line Thread-Index: AcifqExcTmR844HTR0eRCbA4m5S0PQ== From: "Jayantheesh Srimushnam" To: X-OriginalArrivalTime: 16 Apr 2008 09:54:40.0988 (UTC) FILETIME=[E3C6F1C0:01C89FA7] X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-17.5383 TC:1F TRN:51 TV:5.0.1023(15852.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [Sip] Question regarding SDP 'M' Line X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0435925575==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0435925575== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89FA7.E1061D07" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89FA7.E1061D07 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 While adding a new media stream is it MUST to add a new 'M' line in the SDP or existing 'M' line can be replaced with the new one=2E=20 Please go through the below specified example and clarify me which is the correct way of implementing?=20 =20 Example 1: =3D=3D=3D=3D=3D=3D=3D=3D =20 Initial INVITE: =20 m=3Daudio 7100 RTP/AVP 0 101 a=3Drtcp:7101 a=3Dsendonly a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:101 telephone-event/8000 =20 Re-Invite: =20 m=3Dimage 20112 udptl t38 a=3DT38FaxVersion:0 a=3DT38MaxBitRate:1440 =20 Example 2: =3D=3D=3D=3D=3D=3D=3D=3D =20 Initial INVITE: =20 m=3Daudio 7100 RTP/AVP 0 101 a=3Drtcp:7101 a=3Dsendonly a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:101 telephone-event/8000 =20 Re-Invite: =20 m=3Daudio 7100 RTP/AVP 0 101 a=3Drtcp:7101 a=3Dsendonly a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:101 telephone-event/8000 m=3Dimage 5080 udptl t38 c=3DIN IP4 10=2E101=2E210=2E30 a=3DT38FaxVersion:0 =20 Thanks, Jayantheesh DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C89FA7.E1061D07 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

While adding a new media stream is= it MUST to add a new ‘M’ line in the SDP or existing ‘M’= line can be replaced with the new one=2E

Please go through the below= specified example and clarify me which is the correct way of implementing?=

 

Example= 1:

=3D=3D=3D=3D=3D=3D=3D= =3D

 

Initial= INVITE:

 

m=3Daudio 7100 RTP/AVP 0= 101

a= =3Drtcp:7101

a= =3Dsendonly

a=3Drtpmap:0= PCMU/8000

a=3Drtpmap:101= telephone-event/8000

 

Re-Invite:

 

m=3Dimage 20112 udptl= t38

a= =3DT38FaxVersion:0

a= =3DT38MaxBitRate:1440

 

Example= 2:

=3D=3D=3D=3D=3D=3D=3D= =3D

 

Initial= INVITE:

 

m=3Daudio 7100 RTP/AVP 0= 101

a= =3Drtcp:7101

a= =3Dsendonly

a=3Drtpmap:0= PCMU/8000

a=3Drtpmap:101= telephone-event/8000

 

Re-Invite:

 

m=3Daudio 7100 RTP/AVP 0= 101

a= =3Drtcp:7101

a= =3Dsendonly

a=3Drtpmap:0= PCMU/8000

a=3Drtpmap:101= telephone-event/8000

m=3Dimage 5080 udptl= t38

c=3DIN IP4 10=2E101=2E210= =2E30

a= =3DT38FaxVersion:0

 

Thanks,

Jayantheesh

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C89FA7.E1061D07-- --===============0435925575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0435925575==-- From sip-bounces@ietf.org Wed Apr 16 05:47:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593E628C1A9; Wed, 16 Apr 2008 05:47:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0956F28C15E for ; Wed, 16 Apr 2008 05:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.63 X-Spam-Level: * X-Spam-Status: No, score=1.63 tagged_above=-999 required=5 tests=[AWL=2.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 K03HzCeu-WdP for ; Wed, 16 Apr 2008 05:46:56 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [61.144.161.53]) by core3.amsl.com (Postfix) with ESMTP id 798793A6F6F for ; Wed, 16 Apr 2008 05:46:54 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZF00F7O4URNP@szxga01-in.huawei.com> for sip@ietf.org; Wed, 16 Apr 2008 20:47:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZF00DTE4UQHO@szxga01-in.huawei.com> for sip@ietf.org; Wed, 16 Apr 2008 20:47:15 +0800 (CST) Received: from h00114432 ([10.85.28.244]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JZF009QX4UNNH@szxml04-in.huawei.com> for sip@ietf.org; Wed, 16 Apr 2008 20:47:14 +0800 (CST) Date: Wed, 16 Apr 2008 20:47:12 +0800 From: "Guangwu.He" In-reply-to: <66E8AEE9980BB44CA5FCAD39EBA56AC604371125@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> To: 'Jayantheesh Srimushnam' , sip@ietf.org Message-id: <002a01c89fbf$fd9ddb50$f41c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcifqExcTmR844HTR0eRCbA4m5S0PQAFq5OA Subject: Re: [Sip] Question regarding SDP 'M' Line X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0640820978==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0640820978== Content-type: multipart/alternative; boundary="Boundary_(ID_FE70stzNrWZ+LU//vmyn0A)" This is a multi-part message in MIME format. --Boundary_(ID_FE70stzNrWZ+LU//vmyn0A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT see my comments inline. Thanks & Regards, Guangwu.He ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jayantheesh Srimushnam Sent: Wednesday, April 16, 2008 5:58 PM To: sip@ietf.org Subject: [Sip] Question regarding SDP 'M' Line Hi All, While adding a new media stream is it MUST to add a new 'M' line in the SDP or existing 'M' line can be replaced with the new one. Please go through the below specified example and clarify me which is the correct way of implementing? Example 1: ======== Initial INVITE: m=audio 7100 RTP/AVP 0 101 a=rtcp:7101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 Re-Invite: m=image 20112 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:1440 [Guangwu]:the example is wrong;RFC3264 8.1 New media streams are created by new additional media descriptions below the existing ones, or by reusing the "slot" used by an old media stream which had been disabled by setting its port to zero. in you example 1,the port is not zero; Example 2: ======== Initial INVITE: m=audio 7100 RTP/AVP 0 101 a=rtcp:7101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 Re-Invite: m=audio 7100 RTP/AVP 0 101 a=rtcp:7101 a=sendonly a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 m=image 5080 udptl t38 c=IN IP4 10.101.210.30 a=T38FaxVersion:0 Thanks, Jayantheesh DISCLAIMER: ---------------------------------------------------------------------------- ------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------- ------------------------------------------- --Boundary_(ID_FE70stzNrWZ+LU//vmyn0A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
see my comments inline.
 
Thanks & Regards,

Guangwu.He


-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jayantheesh Srimushnam
Sent: Wednesday, April 16, 2008 5:58 PM
To: sip@ietf.org
Subject: [Sip] Question regarding SDP 'M' Line

Hi All,

 

While adding a new media stream is it MUST to add a new ‘M’ line in the SDP or existing ‘M’ line can be replaced with the new one.

Please go through the below specified example and clarify me which is the correct way of implementing?

 

Example 1:

========

 

Initial INVITE:

 

m=audio 7100 RTP/AVP 0 101

a=rtcp:7101

a=sendonly

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

 

Re-Invite:

 

m=image 20112 udptl t38

a=T38FaxVersion:0

a=T38MaxBitRate:1440

 

[Guangwu]:the example is wrong;RFC3264 8.1

New media streams are created by new additional media descriptions
below the existing ones, or by reusing the "slot" used by an old
media stream which had been disabled by setting its port to zero.

in you example 1,the port is not zero;

 

Example 2:

========

 

Initial INVITE:

 

m=audio 7100 RTP/AVP 0 101

a=rtcp:7101

a=sendonly

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

 

Re-Invite:

 

m=audio 7100 RTP/AVP 0 101

a=rtcp:7101

a=sendonly

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

m=image 5080 udptl t38

c=IN IP4 10.101.210.30

a=T38FaxVersion:0  

 

Thanks,

Jayantheesh

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------
--Boundary_(ID_FE70stzNrWZ+LU//vmyn0A)-- --===============0640820978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0640820978==-- From sip-bounces@ietf.org Wed Apr 16 06:26:02 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8493A6A6D; Wed, 16 Apr 2008 06:26:02 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61DA3A67F3 for ; Wed, 16 Apr 2008 06:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 DozzsO+eqk2M for ; Wed, 16 Apr 2008 06:25:59 -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 3AC883A6864 for ; Wed, 16 Apr 2008 06:25:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,664,1199682000"; d="scan'208";a="5272774" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2008 09:26:34 -0400 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 m3GDQYWS030932; Wed, 16 Apr 2008 09:26:34 -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 m3GDQYme022567; Wed, 16 Apr 2008 13:26:34 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, 16 Apr 2008 09:26:34 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 09:26:33 -0400 Message-ID: <4805FEA7.9020306@cisco.com> Date: Wed, 16 Apr 2008 09:27:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Guangwu.He" References: <002a01c89fbf$fd9ddb50$f41c550a@china.huawei.com> In-Reply-To: <002a01c89fbf$fd9ddb50$f41c550a@china.huawei.com> X-OriginalArrivalTime: 16 Apr 2008 13:26:33.0873 (UTC) FILETIME=[7D3F4010:01C89FC5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4943; t=1208352394; x=1209216394; 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]=20Question=20regarding=20SDP=20'M '=20Line |Sender:=20 |To:=20=22Guangwu.He=22=20; bh=C69rLeA6G+6NRB33q/0AQsLtD+hdQA1gB2/vja1h6cI=; b=cO01WzqHOAIow0Xrw9FP1UI3SFTYvHvtaeT1cisPY8Cl+mHz8Z4bkVfgVJ bDaeC6kJvzeYWiKJjSKfMWAQdmwXClFTFAaoRcP9iSrgAIvdI28hjGyMcOP1 Wr4Hnuck95; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Question regarding SDP 'M' Line X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This probably should have been posted to sip-implementors, and certainly = not cross-posted to both sip and sipping. I'm replying here only because = there has been one reply here. I can't remember where right now, but somewhere there has been a = clarification to the point that Guangwu raises. I believe it is now = considered ok to reuse an existing and active m-line for a different = media type. Its illogical not to allow that. Since you could do it by first doing an = o/a to set the port to zero, and then another to reuse the line with the = zero port, why waste the bandwidth and processing to exchange those = meaningless messages? Paul Guangwu.He wrote: > see my comments inline. > = > Thanks & Regards, > = > Guangwu.He > = > = > -------------------------------------------------------------------------= ------------------------------------------------------------ > This e-mail and its attachments contain confidential information from = > HUAWEI, which > is intended only for the person or entity whose address is listed above. = > Any use of the > information contained herein in any way (including, but not limited to, = > total or partial > disclosure, reproduction, or dissemination) by persons other than the = > intended > recipient(s) is prohibited. If you receive this e-mail in error, please = > notify the sender by > phone or email immediately and delete it! > = > ---------------------------------------------------------------------= --- > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On > Behalf Of *Jayantheesh Srimushnam > *Sent:* Wednesday, April 16, 2008 5:58 PM > *To:* sip@ietf.org > *Subject:* [Sip] Question regarding SDP 'M' Line > = > Hi All, > = > = > = > While adding a new media stream is it MUST to add a new =91M=92 line = in > the SDP or existing =91M=92 line can be replaced with the new one. > = > Please go through the below specified example and clarify me which > is the correct way of implementing? > = > = > = > Example 1: > = > =3D=3D=3D=3D=3D=3D=3D=3D > = > = > = > Initial INVITE: > = > = > = > m=3Daudio 7100 RTP/AVP 0 101 > = > a=3Drtcp:7101 > = > a=3Dsendonly > = > a=3Drtpmap:0 PCMU/8000 > = > a=3Drtpmap:101 telephone-event/8000 > = > = > = > Re-Invite: > = > = > = > m=3Dimage 20112 udptl t38 > = > a=3DT38FaxVersion:0 > = > a=3DT38MaxBitRate:1440 > = > = > = > *[Guangwu]:the example is wrong;RFC3264 8.1* > = > *New media streams are created by new additional media descriptions > below the existing ones, or by reusing the "slot" used by an old > media stream which had been disabled by setting its port to zero. > * > = > *in you example 1,the port is not zero;* > = > ** = > = > Example 2: > = > =3D=3D=3D=3D=3D=3D=3D=3D > = > = > = > Initial INVITE: > = > = > = > m=3Daudio 7100 RTP/AVP 0 101 > = > a=3Drtcp:7101 > = > a=3Dsendonly > = > a=3Drtpmap:0 PCMU/8000 > = > a=3Drtpmap:101 telephone-event/8000 > = > = > = > Re-Invite: > = > = > = > m=3Daudio 7100 RTP/AVP 0 101 > = > a=3Drtcp:7101 > = > a=3Dsendonly > = > a=3Drtpmap:0 PCMU/8000 > = > a=3Drtpmap:101 telephone-event/8000 > = > m=3Dimage 5080 udptl t38 > = > c=3DIN IP4 10.101.210.30 > = > a=3DT38FaxVersion:0* * = > = > = > = > Thanks, > = > Jayantheesh > = > DISCLAIMER: > ---------------------------------------------------------------------= -------------------------------------------------- > = > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > = > ---------------------------------------------------------------------= -------------------------------------------------- > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > 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 sip-bounces@ietf.org Wed Apr 16 08:34:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A38528C229; Wed, 16 Apr 2008 08:34:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5FD3A6C7F for ; Wed, 16 Apr 2008 08:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.359, 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 vlTEzdTz0aO1 for ; Wed, 16 Apr 2008 08:34:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 4E8873A6C0B for ; Wed, 16 Apr 2008 08:34:11 -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 m3GFXkF12471; Wed, 16 Apr 2008 15:33:46 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 10:34:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF162B9446@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: AcietukuydPGX6kJSH+X+zTCShRh9gBIEv5Q References: From: "Francois Audet" To: "Dean Willis" Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hey, here is another idea. Alice calls Bob. Bob sends IM to Alice saying "Call me on my cell phone at +14085551212". _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 16 15:20:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111403A6994; Wed, 16 Apr 2008 15:20:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61643A6994 for ; Wed, 16 Apr 2008 15:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 3DfypO1y6GUU for ; Wed, 16 Apr 2008 15:20:38 -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 3D5613A67D7 for ; Wed, 16 Apr 2008 15:20:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,666,1199692800"; d="scan'208";a="22124710" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2008 15:21:14 -0700 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 m3GMLFvW029747; Wed, 16 Apr 2008 15:21:15 -0700 Received: from [128.107.147.122] (dhcp-128-107-147-122.cisco.com [128.107.147.122]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3GMLE8n002418; Wed, 16 Apr 2008 22:21:14 GMT Message-ID: <48067BDA.4050000@cisco.com> Date: Wed, 16 Apr 2008 15:21:14 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6118; t=1208384475; x=1209248475; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20Re=3A=20[Sip]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=11cmw0wf4z8Avvf91mD7Ukz6cIzHuZ8QcAlqzaKTkQE=; b=dA8l0CAcZyRjERqhHfRzOBlWX3kUtPt9eZYoHvCwuYi3V+vjfpJBUzB2Wr /YkTDODV0FrTUUKBDszSX0j3deH9TxagXJcrQStuDiNbCN5V66FbId9M8mPF NOrZJ3m4deDhsDkGWkNkgLKX5tR7+H6klpuspjyyS/riFEafBqZ2U=; Authentication-Results: sj-dkim-1; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP IETF , Francois Audet , Dan WING , Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > What does Bob put into the Contact of a 302 he might send to Alice? > > I've heard several alternatives: > > 1) sip:+445588675309:b.com > > 2) sip:+445588675309:b.com; user=phone > > 3) sip:+445588675309:a.com > > 4) sip:+445588675309:b.com;user=phone > > 5) tel:+445588675309 The presence of user=phone and a valid E.164 number in the user part seems like a pretty strong hint so I wonder if the following might work as a pragmatic, if not exactly elegant, way forward: allow proxies and the UAC to treat cases 2 and 4 as if the URI is equivalent to 5 in the sense that they can do ENUM query on the E.164 number and they can even rewrite the domain part and expect the URI to identify the same entity. This doesn't prevent a.com from recursing when really Alice's UA would have liked to use another provider for gateway services but then neither does using a tel: URI. We'd also want to start pushing support for tel:, of course. Thanks, Anders > > > So let's step through what these mean and why they each might not > work. Keep in mind also that there's a very real possibility that > Alice might nod NEED a gateway to reach Jenny; it's possible that > Jenny's phone number is already in ENUM and is directly reachable via > SIP. But this only works if Alice knows to look it up that way. > > 1) causes Alice to make a call to a user ID in the domain of b.com. > Assuming that b figures out that this means a telephone destination, > Alice probably doesn't have an account at b.com to use for placing the > call. So unless B provides free SIP-to-PSTN calling, or at least > provides free translation service to ENUM, she's out of luck. > > Of course, maybe a.com knows that when it gets a 302 back with a > contact that looks like it might be a phone number, it should discard > the host part and do phone number routing on the user part. That works > until a.com also has user IDs that look like phone numbers. Of course, > this is a direct violation of RFC 3261, which bans a.com from > retargeting a request with a b.com host part. > > 2) is much the same as 1, except that "user=phone" provides another > hint. B is no more likely to provide gateway services, but at least > least if A is going to do an illegal foreign retargeting, it has a > broader hint that phone number routing instead of user routing is > required. > > 3) instructs alice to make a call in the domain of a.com. That's fine > as long as sip:+445588675309:a.com routes to Jenny. Does it? It might > route to somebody with user ID +445588675309, which is a perfectly > valid user ID. > > It might also be true that Alice doesn't use a.com for her PSTN calls. > Perhaps instead, she uses c.com. So to use c.com services, or do an > enum lookup, she has to do an illegal retargeting. > > 4) is much like 3, with the added hint that a telephone-number > destination is indicated. This might eliminate the accidental calling > of user +445588675309, but it does nothing to resolve the question of > Alice not using a.com services for PSTN gateways. There's also an open > issue as to whether PSTN routing (such as an ENUM lookup) can be > applied, vs requiring the call to traverse a gateway. > > At the very best, a.com (or Alice's UA) knows to discard the host part > and do telephone routing on the user part. If Alice's UA does this, > it's probably a violation of RFC 3261, as the UA itself is not > responsible for the host-part of the contact. A proxy in a.com could > do this translation. But what happens if Alice doesn't use a.com for > routing PSTN calls? For example, I might place SIP calls using > "softarmor.com", but I make my PSTN calls using "sipphone.com", so a > 302 sent to me for "sip: +445588675309@softarmor.com;user=phone" will > most assuredly fail. Now, if the a.com proxy knew to translate the > call, that would be OK, but depending on the relationship between > Alice and a.com, it might not. > > 5) doesn't work at all, because Alice's phone doesn't understand tel: > URLs, since understanding of such was listed as a MAY in RFC 3261. But > it's the only suggestion from the set that doesn't require violating a > bunch of existing protocol rules. > > > > >> Really, in the long list of interop issues, this one's pretty low on >> the totem pole, imho. People are having trouble getting basic calls >> to work without the aid of a middle-box. That's a bit higher on the >> list to me. :) > > This is a very basic interdomain calling scenario. I'm really hoping > we get more and more interdomain calls. > > >> >> >>>> Again, don't shoot the messenger: it makes sense to me to use Tel >>>> URI for >>>> this. I am just saying it may cause interop problems. Maybe that's >>>> ok, and >>>> maybe implementations will start implementing tel URI. >>> I've no doubt that there will be interop problems. That's what >>> happens >>> when you specify something that has previously been unspecified and >>> left to whim or caprice. >> OK, but failing calls will not give it a high chance of being >> adopted. Maybe we can figure out how to get a sip: uri to work as >> well - there's more than one way to skin a cat, even with a potato >> peeler. ;) > > Failing calls that don't work now isn't much of a handicap. Changing > the rules of RFC 3261 to make case 3 or 4 generally valid might also > work. > > Fundamentally, we need a documented solution that works in the general > case and doesn't conflict with MUST level rules of other RFCs we cite, > unless it supercedes those RFCs. > > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 16 15:24:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D954A28C167; Wed, 16 Apr 2008 15:24:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178A23A66B4 for ; Wed, 16 Apr 2008 15:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.049, 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 ybpNHMozewK0 for ; Wed, 16 Apr 2008 15:24:01 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 7CAE33A6896 for ; Wed, 16 Apr 2008 15:24:01 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3GMOXr27893; Wed, 16 Apr 2008 22:24:34 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 17:24:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> In-reply-to: <48067BDA.4050000@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: AcigEDNexSZSdAGoS2qijmWNSIGBewAAFXfw References: <48067BDA.4050000@cisco.com> From: "Francois Audet" To: "Anders Kristensen" , "Dean Willis" Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org That's kind of what I was also saying. PS: what's the difference between 2 and 4? > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Wednesday, April 16, 2008 15:21 > To: Dean Willis > Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); > Paul Kyzivat; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > > > Dean Willis wrote: > > What does Bob put into the Contact of a 302 he might send to Alice? > > > > I've heard several alternatives: > > > > 1) sip:+445588675309:b.com > > > > 2) sip:+445588675309:b.com; user=phone > > > > 3) sip:+445588675309:a.com > > > > 4) sip:+445588675309:b.com;user=phone > > > > 5) tel:+445588675309 > > The presence of user=phone and a valid E.164 number in the > user part seems like a pretty strong hint so I wonder if the > following might work as a pragmatic, if not exactly elegant, > way forward: allow proxies and the UAC to treat cases 2 and 4 > as if the URI is equivalent to 5 in the sense that they can > do ENUM query on the E.164 number and they can even rewrite > the domain part and expect the URI to identify the same entity. > > This doesn't prevent a.com from recursing when really Alice's > UA would have liked to use another provider for gateway > services but then neither does using a tel: URI. > > We'd also want to start pushing support for tel:, of course. > > Thanks, > Anders > > > > > > > So let's step through what these mean and why they each might not > > work. Keep in mind also that there's a very real possibility that > > Alice might nod NEED a gateway to reach Jenny; it's possible that > > Jenny's phone number is already in ENUM and is directly > reachable via > > SIP. But this only works if Alice knows to look it up that way. > > > > 1) causes Alice to make a call to a user ID in the domain > of b.com. > > Assuming that b figures out that this means a telephone > destination, > > Alice probably doesn't have an account at b.com to use for > placing the > > call. So unless B provides free SIP-to-PSTN calling, or at least > > provides free translation service to ENUM, she's out of luck. > > > > Of course, maybe a.com knows that when it gets a 302 back with a > > contact that looks like it might be a phone number, it > should discard > > the host part and do phone number routing on the user part. > That works > > until a.com also has user IDs that look like phone numbers. > Of course, > > this is a direct violation of RFC 3261, which bans a.com from > > retargeting a request with a b.com host part. > > > > 2) is much the same as 1, except that "user=phone" provides another > > hint. B is no more likely to provide gateway services, but at least > > least if A is going to do an illegal foreign retargeting, it has a > > broader hint that phone number routing instead of user routing is > > required. > > > > 3) instructs alice to make a call in the domain of a.com. > That's fine > > as long as sip:+445588675309:a.com routes to Jenny. Does > it? It might > > route to somebody with user ID +445588675309, which is a perfectly > > valid user ID. > > > > It might also be true that Alice doesn't use a.com for her > PSTN calls. > > Perhaps instead, she uses c.com. So to use c.com services, or do an > > enum lookup, she has to do an illegal retargeting. > > > > 4) is much like 3, with the added hint that a telephone-number > > destination is indicated. This might eliminate the > accidental calling > > of user +445588675309, but it does nothing to resolve the > question of > > Alice not using a.com services for PSTN gateways. There's > also an open > > issue as to whether PSTN routing (such as an ENUM lookup) can be > > applied, vs requiring the call to traverse a gateway. > > > > At the very best, a.com (or Alice's UA) knows to discard > the host part > > and do telephone routing on the user part. If Alice's UA does this, > > it's probably a violation of RFC 3261, as the UA itself is not > > responsible for the host-part of the contact. A proxy in > a.com could > > do this translation. But what happens if Alice doesn't use > a.com for > > routing PSTN calls? For example, I might place SIP calls using > > "softarmor.com", but I make my PSTN calls using "sipphone.com", so a > > 302 sent to me for "sip: > +445588675309@softarmor.com;user=phone" will > > most assuredly fail. Now, if the a.com proxy knew to translate the > > call, that would be OK, but depending on the relationship between > > Alice and a.com, it might not. > > > > 5) doesn't work at all, because Alice's phone doesn't > understand tel: > > URLs, since understanding of such was listed as a MAY in > RFC 3261. But > > it's the only suggestion from the set that doesn't require > violating a > > bunch of existing protocol rules. > > > > > > > > > >> Really, in the long list of interop issues, this one's > pretty low on > >> the totem pole, imho. People are having trouble getting > basic calls > >> to work without the aid of a middle-box. That's a bit > higher on the > >> list to me. :) > > > > This is a very basic interdomain calling scenario. I'm > really hoping > > we get more and more interdomain calls. > > > > > >> > >> > >>>> Again, don't shoot the messenger: it makes sense to me > to use Tel > >>>> URI for this. I am just saying it may cause interop > problems. Maybe > >>>> that's ok, and maybe implementations will start implementing tel > >>>> URI. > >>> I've no doubt that there will be interop problems. That's what > >>> happens when you specify something that has previously been > >>> unspecified and left to whim or caprice. > >> OK, but failing calls will not give it a high chance of being > >> adopted. Maybe we can figure out how to get a sip: uri to work as > >> well - there's more than one way to skin a cat, even with a potato > >> peeler. ;) > > > > Failing calls that don't work now isn't much of a handicap. > Changing > > the rules of RFC 3261 to make case 3 or 4 generally valid > might also > > work. > > > > Fundamentally, we need a documented solution that works in > the general > > case and doesn't conflict with MUST level rules of other > RFCs we cite, > > unless it supercedes those RFCs. > > > > > > -- > > 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 > > > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 16 15:37:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C413A6F6C; Wed, 16 Apr 2008 15:37:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE7D3A6D25 for ; Wed, 16 Apr 2008 15:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=0.600, 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 f0KHm0W-p8uN for ; Wed, 16 Apr 2008 15:37:53 -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 9CB043A6CEF for ; Wed, 16 Apr 2008 15:37:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,666,1199682000"; d="scan'208";a="5311764" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2008 18:38:29 -0400 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 m3GMcTc2024334; Wed, 16 Apr 2008 18:38:29 -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 m3GMcWYn004506; Wed, 16 Apr 2008 22:38:32 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); Wed, 16 Apr 2008 18:38:29 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 18:38:29 -0400 Message-ID: <48068001.2030302@cisco.com> Date: Wed, 16 Apr 2008 18:38:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 16 Apr 2008 22:38:29.0064 (UTC) FILETIME=[97706480:01C8A012] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7410; t=1208385509; x=1209249509; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Francois=20Audet=20; bh=jOxRpA69NoqsIhnecl7h9vyVxWbivVZKycrFhsydH+U=; b=C1c2owL1W/4NoapQ8RjjXZVboWQp/DpH8FsFjp5EhejmBo1zhy3Uox7iJL x5UoCuT/NCIVpT6MGy52JbW4AuXNRMgST/5k01DtpnozBchdy70Srwe6AEfN 927zU44vJH; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP IETF , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois Audet wrote: > That's kind of what I was also saying. > > PS: what's the difference between 2 and 4? I think 4 is a typo and was presumably intended to be 4) sip:+445588675309:a.com;user=phone It is already the case that a.com may treat 3,4 & 5 alike if it wishes. And b.com may treate 1,2 & 5 alike if it wishes. The question is whether a.com may treat 1&2 like 5, or if b.com may treat 3&4 like 5. Apparently some are saying that user=phone is license to ignore the domain. But that just raises the question of why one would insert a domain along with a parameter that says to ignore it. Makes no sense to me. Paul >> -----Original Message----- >> From: Anders Kristensen [mailto:andersk@cisco.com] >> Sent: Wednesday, April 16, 2008 15:21 >> To: Dean Willis >> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); >> Paul Kyzivat; Dan WING >> Subject: Re: [Sip] E.164 - who owns it >> >> >> >> Dean Willis wrote: >>> What does Bob put into the Contact of a 302 he might send to Alice? >>> >>> I've heard several alternatives: >>> >>> 1) sip:+445588675309:b.com >>> >>> 2) sip:+445588675309:b.com; user=phone >>> >>> 3) sip:+445588675309:a.com >>> >>> 4) sip:+445588675309:b.com;user=phone >>> >>> 5) tel:+445588675309 >> The presence of user=phone and a valid E.164 number in the >> user part seems like a pretty strong hint so I wonder if the >> following might work as a pragmatic, if not exactly elegant, >> way forward: allow proxies and the UAC to treat cases 2 and 4 >> as if the URI is equivalent to 5 in the sense that they can >> do ENUM query on the E.164 number and they can even rewrite >> the domain part and expect the URI to identify the same entity. >> >> This doesn't prevent a.com from recursing when really Alice's >> UA would have liked to use another provider for gateway >> services but then neither does using a tel: URI. >> >> We'd also want to start pushing support for tel:, of course. >> >> Thanks, >> Anders >> >>> >>> So let's step through what these mean and why they each might not >>> work. Keep in mind also that there's a very real possibility that >>> Alice might nod NEED a gateway to reach Jenny; it's possible that >>> Jenny's phone number is already in ENUM and is directly >> reachable via >>> SIP. But this only works if Alice knows to look it up that way. >>> >>> 1) causes Alice to make a call to a user ID in the domain >> of b.com. >>> Assuming that b figures out that this means a telephone >> destination, >>> Alice probably doesn't have an account at b.com to use for >> placing the >>> call. So unless B provides free SIP-to-PSTN calling, or at least >>> provides free translation service to ENUM, she's out of luck. >>> >>> Of course, maybe a.com knows that when it gets a 302 back with a >>> contact that looks like it might be a phone number, it >> should discard >>> the host part and do phone number routing on the user part. >> That works >>> until a.com also has user IDs that look like phone numbers. >> Of course, >>> this is a direct violation of RFC 3261, which bans a.com from >>> retargeting a request with a b.com host part. >>> >>> 2) is much the same as 1, except that "user=phone" provides another >>> hint. B is no more likely to provide gateway services, but at least >>> least if A is going to do an illegal foreign retargeting, it has a >>> broader hint that phone number routing instead of user routing is >>> required. >>> >>> 3) instructs alice to make a call in the domain of a.com. >> That's fine >>> as long as sip:+445588675309:a.com routes to Jenny. Does >> it? It might >>> route to somebody with user ID +445588675309, which is a perfectly >>> valid user ID. >>> >>> It might also be true that Alice doesn't use a.com for her >> PSTN calls. >>> Perhaps instead, she uses c.com. So to use c.com services, or do an >>> enum lookup, she has to do an illegal retargeting. >>> >>> 4) is much like 3, with the added hint that a telephone-number >>> destination is indicated. This might eliminate the >> accidental calling >>> of user +445588675309, but it does nothing to resolve the >> question of >>> Alice not using a.com services for PSTN gateways. There's >> also an open >>> issue as to whether PSTN routing (such as an ENUM lookup) can be >>> applied, vs requiring the call to traverse a gateway. >>> >>> At the very best, a.com (or Alice's UA) knows to discard >> the host part >>> and do telephone routing on the user part. If Alice's UA does this, >>> it's probably a violation of RFC 3261, as the UA itself is not >>> responsible for the host-part of the contact. A proxy in >> a.com could >>> do this translation. But what happens if Alice doesn't use >> a.com for >>> routing PSTN calls? For example, I might place SIP calls using >>> "softarmor.com", but I make my PSTN calls using "sipphone.com", so a >>> 302 sent to me for "sip: >> +445588675309@softarmor.com;user=phone" will >>> most assuredly fail. Now, if the a.com proxy knew to translate the >>> call, that would be OK, but depending on the relationship between >>> Alice and a.com, it might not. >>> >>> 5) doesn't work at all, because Alice's phone doesn't >> understand tel: >>> URLs, since understanding of such was listed as a MAY in >> RFC 3261. But >>> it's the only suggestion from the set that doesn't require >> violating a >>> bunch of existing protocol rules. >>> >>> >>> >>> >>>> Really, in the long list of interop issues, this one's >> pretty low on >>>> the totem pole, imho. People are having trouble getting >> basic calls >>>> to work without the aid of a middle-box. That's a bit >> higher on the >>>> list to me. :) >>> This is a very basic interdomain calling scenario. I'm >> really hoping >>> we get more and more interdomain calls. >>> >>> >>>> >>>>>> Again, don't shoot the messenger: it makes sense to me >> to use Tel >>>>>> URI for this. I am just saying it may cause interop >> problems. Maybe >>>>>> that's ok, and maybe implementations will start implementing tel >>>>>> URI. >>>>> I've no doubt that there will be interop problems. That's what >>>>> happens when you specify something that has previously been >>>>> unspecified and left to whim or caprice. >>>> OK, but failing calls will not give it a high chance of being >>>> adopted. Maybe we can figure out how to get a sip: uri to work as >>>> well - there's more than one way to skin a cat, even with a potato >>>> peeler. ;) >>> Failing calls that don't work now isn't much of a handicap. >> Changing >>> the rules of RFC 3261 to make case 3 or 4 generally valid >> might also >>> work. >>> >>> Fundamentally, we need a documented solution that works in >> the general >>> case and doesn't conflict with MUST level rules of other >> RFCs we cite, >>> unless it supercedes those RFCs. >>> >>> >>> -- >>> 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 >>> > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 16 16:02:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3283F3A6D02; Wed, 16 Apr 2008 16:02:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B9E3A6D75 for ; Wed, 16 Apr 2008 16:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.409 X-Spam-Level: X-Spam-Status: No, score=-5.409 tagged_above=-999 required=5 tests=[AWL=0.590, 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 D-W+-52r8-AI for ; Wed, 16 Apr 2008 16:02:47 -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 9C7653A6AAE for ; Wed, 16 Apr 2008 16:02:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,666,1199692800"; d="scan'208";a="22134931" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2008 16:03:22 -0700 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 m3GN3JJn019309; Wed, 16 Apr 2008 16:03:19 -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 m3GN3JZh008378; Wed, 16 Apr 2008 23:03:19 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, 16 Apr 2008 19:03:18 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 19:03:18 -0400 Message-ID: <480685D3.3000308@cisco.com> Date: Wed, 16 Apr 2008 19:03:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> In-Reply-To: <48068001.2030302@cisco.com> X-OriginalArrivalTime: 16 Apr 2008 23:03:18.0408 (UTC) FILETIME=[0F284080:01C8A016] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9502; t=1208386999; x=1209250999; c=relaxed/simple; s=sjdkim1004; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=PXPR3Pz4rcZy4Ss8vJJRxzO95UaQf9zOsa4aRNF/iQw=; b=e7qWwUvULvahtZed65gMjIb0PlxmbULjcDZDeFIZVKf+UQFTICU3y9uLd1 V16ujHDBjXVQG1Hl7RJkJtJSL2bCd47v/Wdp3kHyGM1qoDq6Ei41GByEXf34 co6o8K0CPewzvp6MVFYM02nk5d2YUcp3y4jQMmH/+xjCBJTnoub+g=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP IETF , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org replying to myself - another thought: Paul Kyzivat wrote: > > Francois Audet wrote: >> That's kind of what I was also saying. >> >> PS: what's the difference between 2 and 4? > > I think 4 is a typo and was presumably intended to be > > 4) sip:+445588675309:a.com;user=phone > > It is already the case that a.com may treat 3,4 & 5 alike if it wishes. > And b.com may treate 1,2 & 5 alike if it wishes. > > The question is whether a.com may treat 1&2 like 5, or if b.com may > treat 3&4 like 5. > > Apparently some are saying that user=phone is license to ignore the > domain. But that just raises the question of why one would insert a > domain along with a parameter that says to ignore it. Makes no sense to me. This would make *some* sense to me if the semantics were: 1) you MAY route to this domain following 3263 procedures with expectation that it will work. 2) if you are unable to do that (say because you don't have a sip path at all, or don't have a path to the domain in the URI) then you may treat it as a tel URI and route it any way that works for you. But it seems that in many of the use cases that have been presented in this thread it is actually the case that if the recipient routes to the domain in the URI the request *won't* work. That makes absolutely no sense to me. In that case TEL seems clearly the right way. Now Hadriel has made a case that it is the SBC's job to fix this up. So when the URL exits the domain in which it will work, then the SBC should fix it up with the domain it is going into. I guess that could make sense if that SBC was acting as an agent of *both* domains. But typically it is only acting as an agent of one domain. An SBC acting for b.com has no business changing the domain of the URL to a.com, since doing so is (or isn't) a policy of a.com. A way around that is to say that if the URI contains b.com, then an SBC acting for b.com, when it knows it won't honor that, can change it to a TEL URI when it exits the domain. It then may well go through another SBC acting for a.com as it enters the a.com domain. That SBC could change the TEL URI to an a.com URI if that will be handled correctly within the a.com domain. Paul > Paul > >>> -----Original Message----- >>> From: Anders Kristensen [mailto:andersk@cisco.com] >>> Sent: Wednesday, April 16, 2008 15:21 >>> To: Dean Willis >>> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); >>> Paul Kyzivat; Dan WING >>> Subject: Re: [Sip] E.164 - who owns it >>> >>> >>> >>> Dean Willis wrote: >>>> What does Bob put into the Contact of a 302 he might send to Alice? >>>> >>>> I've heard several alternatives: >>>> >>>> 1) sip:+445588675309:b.com >>>> >>>> 2) sip:+445588675309:b.com; user=phone >>>> >>>> 3) sip:+445588675309:a.com >>>> >>>> 4) sip:+445588675309:b.com;user=phone >>>> >>>> 5) tel:+445588675309 >>> The presence of user=phone and a valid E.164 number in the >>> user part seems like a pretty strong hint so I wonder if the >>> following might work as a pragmatic, if not exactly elegant, >>> way forward: allow proxies and the UAC to treat cases 2 and 4 >>> as if the URI is equivalent to 5 in the sense that they can >>> do ENUM query on the E.164 number and they can even rewrite >>> the domain part and expect the URI to identify the same entity. >>> >>> This doesn't prevent a.com from recursing when really Alice's >>> UA would have liked to use another provider for gateway >>> services but then neither does using a tel: URI. >>> >>> We'd also want to start pushing support for tel:, of course. >>> >>> Thanks, >>> Anders >>> >>>> So let's step through what these mean and why they each might not >>>> work. Keep in mind also that there's a very real possibility that >>>> Alice might nod NEED a gateway to reach Jenny; it's possible that >>>> Jenny's phone number is already in ENUM and is directly >>> reachable via >>>> SIP. But this only works if Alice knows to look it up that way. >>>> >>>> 1) causes Alice to make a call to a user ID in the domain >>> of b.com. >>>> Assuming that b figures out that this means a telephone >>> destination, >>>> Alice probably doesn't have an account at b.com to use for >>> placing the >>>> call. So unless B provides free SIP-to-PSTN calling, or at least >>>> provides free translation service to ENUM, she's out of luck. >>>> >>>> Of course, maybe a.com knows that when it gets a 302 back with a >>>> contact that looks like it might be a phone number, it >>> should discard >>>> the host part and do phone number routing on the user part. >>> That works >>>> until a.com also has user IDs that look like phone numbers. >>> Of course, >>>> this is a direct violation of RFC 3261, which bans a.com from >>>> retargeting a request with a b.com host part. >>>> >>>> 2) is much the same as 1, except that "user=phone" provides another >>>> hint. B is no more likely to provide gateway services, but at least >>>> least if A is going to do an illegal foreign retargeting, it has a >>>> broader hint that phone number routing instead of user routing is >>>> required. >>>> >>>> 3) instructs alice to make a call in the domain of a.com. >>> That's fine >>>> as long as sip:+445588675309:a.com routes to Jenny. Does >>> it? It might >>>> route to somebody with user ID +445588675309, which is a perfectly >>>> valid user ID. >>>> >>>> It might also be true that Alice doesn't use a.com for her >>> PSTN calls. >>>> Perhaps instead, she uses c.com. So to use c.com services, or do an >>>> enum lookup, she has to do an illegal retargeting. >>>> >>>> 4) is much like 3, with the added hint that a telephone-number >>>> destination is indicated. This might eliminate the >>> accidental calling >>>> of user +445588675309, but it does nothing to resolve the >>> question of >>>> Alice not using a.com services for PSTN gateways. There's >>> also an open >>>> issue as to whether PSTN routing (such as an ENUM lookup) can be >>>> applied, vs requiring the call to traverse a gateway. >>>> >>>> At the very best, a.com (or Alice's UA) knows to discard >>> the host part >>>> and do telephone routing on the user part. If Alice's UA does this, >>>> it's probably a violation of RFC 3261, as the UA itself is not >>>> responsible for the host-part of the contact. A proxy in >>> a.com could >>>> do this translation. But what happens if Alice doesn't use >>> a.com for >>>> routing PSTN calls? For example, I might place SIP calls using >>>> "softarmor.com", but I make my PSTN calls using "sipphone.com", so a >>>> 302 sent to me for "sip: >>> +445588675309@softarmor.com;user=phone" will >>>> most assuredly fail. Now, if the a.com proxy knew to translate the >>>> call, that would be OK, but depending on the relationship between >>>> Alice and a.com, it might not. >>>> >>>> 5) doesn't work at all, because Alice's phone doesn't >>> understand tel: >>>> URLs, since understanding of such was listed as a MAY in >>> RFC 3261. But >>>> it's the only suggestion from the set that doesn't require >>> violating a >>>> bunch of existing protocol rules. >>>> >>>> >>>> >>>> >>>>> Really, in the long list of interop issues, this one's >>> pretty low on >>>>> the totem pole, imho. People are having trouble getting >>> basic calls >>>>> to work without the aid of a middle-box. That's a bit >>> higher on the >>>>> list to me. :) >>>> This is a very basic interdomain calling scenario. I'm >>> really hoping >>>> we get more and more interdomain calls. >>>> >>>> >>>>>>> Again, don't shoot the messenger: it makes sense to me >>> to use Tel >>>>>>> URI for this. I am just saying it may cause interop >>> problems. Maybe >>>>>>> that's ok, and maybe implementations will start implementing tel >>>>>>> URI. >>>>>> I've no doubt that there will be interop problems. That's what >>>>>> happens when you specify something that has previously been >>>>>> unspecified and left to whim or caprice. >>>>> OK, but failing calls will not give it a high chance of being >>>>> adopted. Maybe we can figure out how to get a sip: uri to work as >>>>> well - there's more than one way to skin a cat, even with a potato >>>>> peeler. ;) >>>> Failing calls that don't work now isn't much of a handicap. >>> Changing >>>> the rules of RFC 3261 to make case 3 or 4 generally valid >>> might also >>>> work. >>>> >>>> Fundamentally, we need a documented solution that works in >>> the general >>>> case and doesn't conflict with MUST level rules of other >>> RFCs we cite, >>>> unless it supercedes those RFCs. >>>> >>>> >>>> -- >>>> 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 >>>> > _______________________________________________ > 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 sip-bounces@ietf.org Wed Apr 16 16:36:47 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E44528C4C8; Wed, 16 Apr 2008 16:36:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE7728C490 for ; Wed, 16 Apr 2008 16:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_45=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 CNTpe2mPKkuT for ; Wed, 16 Apr 2008 16:36:40 -0700 (PDT) Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by core3.amsl.com (Postfix) with ESMTP id 6D7B828C4A3 for ; Wed, 16 Apr 2008 16:35:09 -0700 (PDT) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipai.vtcif.telstra.com.au with ESMTP; 17 Apr 2008 09:35:45 +1000 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 7742D1DADF for ; Thu, 17 Apr 2008 09:35:44 +1000 (EST) Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA15137 for ; Thu, 17 Apr 2008 09:35:44 +1000 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2952.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Apr 2008 09:35:37 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Apr 2008 09:35:35 +1000 Message-ID: <903E4F74808D4F4B93635C9D9183EBAC0337D094@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <480685D3.3000308@cisco.com> Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcigFjH+8hIM6piYTtqocKOniEGocwAA0CJg References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com><48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> From: "Robins, Ellen" To: "SIP IETF" X-OriginalArrivalTime: 16 Apr 2008 23:35:37.0444 (UTC) FILETIME=[92E9AA40:01C8A01A] Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi everyone, On the subject of E.164 discussion is there a universal preffix or list of registered preffixes to signify VoIP call. For example, the same E.164 Mobile or PSTN services numbers can be used for dialling Video or Voice Call over IP. Scenario: Alice has her Mobile service number but would like to receive a call instead of Mobile on her PC SIP Soft Client. Are there a preffix XYZ that would indicates to network that this call shall be routed via Gateway to IP Client instead of Mobile ? Thanks and kind regards / Ellen Robins ViG Technology Manager Services Enablers Wireless Engineering & Operations Telstra Operations Telstra Corporation Limited Ph 03 8627 8981 Mob 0428 309 250 Fax 03 9620 7864 Mail ellen.robins@team.telstra.com The information contained in this email message may be confidential. If you are not the intended recipient, any use of, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify me by reply email and then delete the message. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, 17 April 2008 9:04 AM To: Francois Audet Cc: SIP IETF; Dan WING; Dean Willis Subject: Re: [Sip] E.164 - who owns it replying to myself - another thought: Paul Kyzivat wrote: > > Francois Audet wrote: >> That's kind of what I was also saying. >> >> PS: what's the difference between 2 and 4? > > I think 4 is a typo and was presumably intended to be > > 4) sip:+445588675309:a.com;user=phone > > It is already the case that a.com may treat 3,4 & 5 alike if it wishes. > And b.com may treate 1,2 & 5 alike if it wishes. > > The question is whether a.com may treat 1&2 like 5, or if b.com may > treat 3&4 like 5. > > Apparently some are saying that user=phone is license to ignore the > domain. But that just raises the question of why one would insert a > domain along with a parameter that says to ignore it. Makes no sense to me. This would make *some* sense to me if the semantics were: 1) you MAY route to this domain following 3263 procedures with expectation that it will work. 2) if you are unable to do that (say because you don't have a sip path at all, or don't have a path to the domain in the URI) then you may treat it as a tel URI and route it any way that works for you. But it seems that in many of the use cases that have been presented in this thread it is actually the case that if the recipient routes to the domain in the URI the request *won't* work. That makes absolutely no sense to me. In that case TEL seems clearly the right way. Now Hadriel has made a case that it is the SBC's job to fix this up. So when the URL exits the domain in which it will work, then the SBC should fix it up with the domain it is going into. I guess that could make sense if that SBC was acting as an agent of *both* domains. But typically it is only acting as an agent of one domain. An SBC acting for b.com has no business changing the domain of the URL to a.com, since doing so is (or isn't) a policy of a.com. A way around that is to say that if the URI contains b.com, then an SBC acting for b.com, when it knows it won't honor that, can change it to a TEL URI when it exits the domain. It then may well go through another SBC acting for a.com as it enters the a.com domain. That SBC could change the TEL URI to an a.com URI if that will be handled correctly within the a.com domain. Paul > Paul > >>> -----Original Message----- >>> From: Anders Kristensen [mailto:andersk@cisco.com] >>> Sent: Wednesday, April 16, 2008 15:21 >>> To: Dean Willis >>> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); Paul >>> Kyzivat; Dan WING >>> Subject: Re: [Sip] E.164 - who owns it >>> >>> >>> >>> Dean Willis wrote: >>>> What does Bob put into the Contact of a 302 he might send to Alice? >>>> >>>> I've heard several alternatives: >>>> >>>> 1) sip:+445588675309:b.com >>>> >>>> 2) sip:+445588675309:b.com; user=phone >>>> >>>> 3) sip:+445588675309:a.com >>>> >>>> 4) sip:+445588675309:b.com;user=phone >>>> >>>> 5) tel:+445588675309 >>> The presence of user=phone and a valid E.164 number in the user part >>> seems like a pretty strong hint so I wonder if the following might >>> work as a pragmatic, if not exactly elegant, way forward: allow >>> proxies and the UAC to treat cases 2 and 4 as if the URI is >>> equivalent to 5 in the sense that they can do ENUM query on the >>> E.164 number and they can even rewrite the domain part and expect >>> the URI to identify the same entity. >>> >>> This doesn't prevent a.com from recursing when really Alice's UA >>> would have liked to use another provider for gateway services but >>> then neither does using a tel: URI. >>> >>> We'd also want to start pushing support for tel:, of course. >>> >>> Thanks, >>> Anders >>> >>>> So let's step through what these mean and why they each might not >>>> work. Keep in mind also that there's a very real possibility that >>>> Alice might nod NEED a gateway to reach Jenny; it's possible that >>>> Jenny's phone number is already in ENUM and is directly >>> reachable via >>>> SIP. But this only works if Alice knows to look it up that way. >>>> >>>> 1) causes Alice to make a call to a user ID in the domain >>> of b.com. >>>> Assuming that b figures out that this means a telephone >>> destination, >>>> Alice probably doesn't have an account at b.com to use for >>> placing the >>>> call. So unless B provides free SIP-to-PSTN calling, or at least >>>> provides free translation service to ENUM, she's out of luck. >>>> >>>> Of course, maybe a.com knows that when it gets a 302 back with a >>>> contact that looks like it might be a phone number, it >>> should discard >>>> the host part and do phone number routing on the user part. >>> That works >>>> until a.com also has user IDs that look like phone numbers. >>> Of course, >>>> this is a direct violation of RFC 3261, which bans a.com from >>>> retargeting a request with a b.com host part. >>>> >>>> 2) is much the same as 1, except that "user=phone" provides another >>>> hint. B is no more likely to provide gateway services, but at least >>>> least if A is going to do an illegal foreign retargeting, it has a >>>> broader hint that phone number routing instead of user routing is >>>> required. >>>> >>>> 3) instructs alice to make a call in the domain of a.com. >>> That's fine >>>> as long as sip:+445588675309:a.com routes to Jenny. Does >>> it? It might >>>> route to somebody with user ID +445588675309, which is a perfectly >>>> valid user ID. >>>> >>>> It might also be true that Alice doesn't use a.com for her >>> PSTN calls. >>>> Perhaps instead, she uses c.com. So to use c.com services, or do an >>>> enum lookup, she has to do an illegal retargeting. >>>> >>>> 4) is much like 3, with the added hint that a telephone-number >>>> destination is indicated. This might eliminate the >>> accidental calling >>>> of user +445588675309, but it does nothing to resolve the >>> question of >>>> Alice not using a.com services for PSTN gateways. There's >>> also an open >>>> issue as to whether PSTN routing (such as an ENUM lookup) can be >>>> applied, vs requiring the call to traverse a gateway. >>>> >>>> At the very best, a.com (or Alice's UA) knows to discard >>> the host part >>>> and do telephone routing on the user part. If Alice's UA does this, >>>> it's probably a violation of RFC 3261, as the UA itself is not >>>> responsible for the host-part of the contact. A proxy in >>> a.com could >>>> do this translation. But what happens if Alice doesn't use >>> a.com for >>>> routing PSTN calls? For example, I might place SIP calls using >>>> "softarmor.com", but I make my PSTN calls using "sipphone.com", so >>>> a >>>> 302 sent to me for "sip: >>> +445588675309@softarmor.com;user=phone" will >>>> most assuredly fail. Now, if the a.com proxy knew to translate the >>>> call, that would be OK, but depending on the relationship between >>>> Alice and a.com, it might not. >>>> >>>> 5) doesn't work at all, because Alice's phone doesn't >>> understand tel: >>>> URLs, since understanding of such was listed as a MAY in >>> RFC 3261. But >>>> it's the only suggestion from the set that doesn't require >>> violating a >>>> bunch of existing protocol rules. >>>> >>>> >>>> >>>> >>>>> Really, in the long list of interop issues, this one's >>> pretty low on >>>>> the totem pole, imho. People are having trouble getting >>> basic calls >>>>> to work without the aid of a middle-box. That's a bit >>> higher on the >>>>> list to me. :) >>>> This is a very basic interdomain calling scenario. I'm >>> really hoping >>>> we get more and more interdomain calls. >>>> >>>> >>>>>>> Again, don't shoot the messenger: it makes sense to me >>> to use Tel >>>>>>> URI for this. I am just saying it may cause interop >>> problems. Maybe >>>>>>> that's ok, and maybe implementations will start implementing tel >>>>>>> URI. >>>>>> I've no doubt that there will be interop problems. That's what >>>>>> happens when you specify something that has previously been >>>>>> unspecified and left to whim or caprice. >>>>> OK, but failing calls will not give it a high chance of being >>>>> adopted. Maybe we can figure out how to get a sip: uri to work as >>>>> well - there's more than one way to skin a cat, even with a potato >>>>> peeler. ;) >>>> Failing calls that don't work now isn't much of a handicap. >>> Changing >>>> the rules of RFC 3261 to make case 3 or 4 generally valid >>> might also >>>> work. >>>> >>>> Fundamentally, we need a documented solution that works in >>> the general >>>> case and doesn't conflict with MUST level rules of other >>> RFCs we cite, >>>> unless it supercedes those RFCs. >>>> >>>> >>>> -- >>>> 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 >>>> > _______________________________________________ > 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 sip-bounces@ietf.org Wed Apr 16 16:49:00 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73073A6EFF; Wed, 16 Apr 2008 16:49:00 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBB23A6CB8 for ; Wed, 16 Apr 2008 16:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.047, 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 0D7tTuQRW-mx for ; Wed, 16 Apr 2008 16:48:57 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 665D63A6D02 for ; Wed, 16 Apr 2008 16:48: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 m3GNnTL23180; Wed, 16 Apr 2008 23:49:30 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 18:49:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1630F1FD@zrc2hxm0.corp.nortel.com> In-reply-to: <48068001.2030302@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: AcigEpzYLo2SGeMRTvez2Y1kbEq3uQACa9MA References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: SIP IETF , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think the idea is that if you provide a phone number, then there are alternate ways to reach it than using the domain. Not sure there is much we can do about this. It's a consequence of having this type of dualing addressing spaces. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, April 16, 2008 15:39 > To: Audet, Francois (SC100:3055) > Cc: Anders Kristensen; Dean Willis; Hadriel Kaplan; SIP IETF; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > > > Francois Audet wrote: > > That's kind of what I was also saying. > > > > PS: what's the difference between 2 and 4? > > I think 4 is a typo and was presumably intended to be > > 4) sip:+445588675309:a.com;user=phone > > It is already the case that a.com may treat 3,4 & 5 alike if > it wishes. > And b.com may treate 1,2 & 5 alike if it wishes. > > The question is whether a.com may treat 1&2 like 5, or if > b.com may treat 3&4 like 5. > > Apparently some are saying that user=phone is license to > ignore the domain. But that just raises the question of why > one would insert a domain along with a parameter that says to > ignore it. Makes no sense to me. > > Paul > > >> -----Original Message----- > >> From: Anders Kristensen [mailto:andersk@cisco.com] > >> Sent: Wednesday, April 16, 2008 15:21 > >> To: Dean Willis > >> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); Paul > >> Kyzivat; Dan WING > >> Subject: Re: [Sip] E.164 - who owns it > >> > >> > >> > >> Dean Willis wrote: > >>> What does Bob put into the Contact of a 302 he might send > to Alice? > >>> > >>> I've heard several alternatives: > >>> > >>> 1) sip:+445588675309:b.com > >>> > >>> 2) sip:+445588675309:b.com; user=phone > >>> > >>> 3) sip:+445588675309:a.com > >>> > >>> 4) sip:+445588675309:b.com;user=phone > >>> > >>> 5) tel:+445588675309 > >> The presence of user=phone and a valid E.164 number in the > user part > >> seems like a pretty strong hint so I wonder if the following might > >> work as a pragmatic, if not exactly elegant, way forward: allow > >> proxies and the UAC to treat cases 2 and 4 as if the URI is > >> equivalent to 5 in the sense that they can do ENUM query > on the E.164 > >> number and they can even rewrite the domain part and > expect the URI > >> to identify the same entity. > >> > >> This doesn't prevent a.com from recursing when really Alice's UA > >> would have liked to use another provider for gateway services but > >> then neither does using a tel: URI. > >> > >> We'd also want to start pushing support for tel:, of course. > >> > >> Thanks, > >> Anders > >> > >>> > >>> So let's step through what these mean and why they each might not > >>> work. Keep in mind also that there's a very real possibility that > >>> Alice might nod NEED a gateway to reach Jenny; it's possible that > >>> Jenny's phone number is already in ENUM and is directly > >> reachable via > >>> SIP. But this only works if Alice knows to look it up that way. > >>> > >>> 1) causes Alice to make a call to a user ID in the domain > >> of b.com. > >>> Assuming that b figures out that this means a telephone > >> destination, > >>> Alice probably doesn't have an account at b.com to use for > >> placing the > >>> call. So unless B provides free SIP-to-PSTN calling, or at least > >>> provides free translation service to ENUM, she's out of luck. > >>> > >>> Of course, maybe a.com knows that when it gets a 302 back with a > >>> contact that looks like it might be a phone number, it > >> should discard > >>> the host part and do phone number routing on the user part. > >> That works > >>> until a.com also has user IDs that look like phone numbers. > >> Of course, > >>> this is a direct violation of RFC 3261, which bans a.com from > >>> retargeting a request with a b.com host part. > >>> > >>> 2) is much the same as 1, except that "user=phone" > provides another > >>> hint. B is no more likely to provide gateway services, > but at least > >>> least if A is going to do an illegal foreign retargeting, > it has a > >>> broader hint that phone number routing instead of user routing is > >>> required. > >>> > >>> 3) instructs alice to make a call in the domain of a.com. > >> That's fine > >>> as long as sip:+445588675309:a.com routes to Jenny. Does > >> it? It might > >>> route to somebody with user ID +445588675309, which is a > perfectly > >>> valid user ID. > >>> > >>> It might also be true that Alice doesn't use a.com for her > >> PSTN calls. > >>> Perhaps instead, she uses c.com. So to use c.com > services, or do an > >>> enum lookup, she has to do an illegal retargeting. > >>> > >>> 4) is much like 3, with the added hint that a telephone-number > >>> destination is indicated. This might eliminate the > >> accidental calling > >>> of user +445588675309, but it does nothing to resolve the > >> question of > >>> Alice not using a.com services for PSTN gateways. There's > >> also an open > >>> issue as to whether PSTN routing (such as an ENUM lookup) can be > >>> applied, vs requiring the call to traverse a gateway. > >>> > >>> At the very best, a.com (or Alice's UA) knows to discard > >> the host part > >>> and do telephone routing on the user part. If Alice's UA > does this, > >>> it's probably a violation of RFC 3261, as the UA itself is not > >>> responsible for the host-part of the contact. A proxy in > >> a.com could > >>> do this translation. But what happens if Alice doesn't use > >> a.com for > >>> routing PSTN calls? For example, I might place SIP calls using > >>> "softarmor.com", but I make my PSTN calls using > "sipphone.com", so a > >>> 302 sent to me for "sip: > >> +445588675309@softarmor.com;user=phone" will > >>> most assuredly fail. Now, if the a.com proxy knew to > translate the > >>> call, that would be OK, but depending on the relationship between > >>> Alice and a.com, it might not. > >>> > >>> 5) doesn't work at all, because Alice's phone doesn't > >> understand tel: > >>> URLs, since understanding of such was listed as a MAY in > >> RFC 3261. But > >>> it's the only suggestion from the set that doesn't require > >> violating a > >>> bunch of existing protocol rules. > >>> > >>> > >>> > >>> > >>>> Really, in the long list of interop issues, this one's > >> pretty low on > >>>> the totem pole, imho. People are having trouble getting > >> basic calls > >>>> to work without the aid of a middle-box. That's a bit > >> higher on the > >>>> list to me. :) > >>> This is a very basic interdomain calling scenario. I'm > >> really hoping > >>> we get more and more interdomain calls. > >>> > >>> > >>>> > >>>>>> Again, don't shoot the messenger: it makes sense to me > >> to use Tel > >>>>>> URI for this. I am just saying it may cause interop > >> problems. Maybe > >>>>>> that's ok, and maybe implementations will start > implementing tel > >>>>>> URI. > >>>>> I've no doubt that there will be interop problems. That's what > >>>>> happens when you specify something that has previously been > >>>>> unspecified and left to whim or caprice. > >>>> OK, but failing calls will not give it a high chance of being > >>>> adopted. Maybe we can figure out how to get a sip: uri > to work as > >>>> well - there's more than one way to skin a cat, even > with a potato > >>>> peeler. ;) > >>> Failing calls that don't work now isn't much of a handicap. > >> Changing > >>> the rules of RFC 3261 to make case 3 or 4 generally valid > >> might also > >>> work. > >>> > >>> Fundamentally, we need a documented solution that works in > >> the general > >>> case and doesn't conflict with MUST level rules of other > >> RFCs we cite, > >>> unless it supercedes those RFCs. > >>> > >>> > >>> -- > >>> 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 > >>> > > > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 16 16:50:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0CE3A6CB8; Wed, 16 Apr 2008 16:50:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D881728C1D5 for ; Wed, 16 Apr 2008 16:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.046, 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 flroOOMOpYhB for ; Wed, 16 Apr 2008 16:50:35 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id CCFE128C490 for ; Wed, 16 Apr 2008 16:50:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3GNoor03809; Wed, 16 Apr 2008 23:50:50 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 18:50:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1630F207@zrc2hxm0.corp.nortel.com> In-reply-to: <480685D3.3000308@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: AcigFhW8fM2gvzfCRH6op1aYiOV3LwABpPUw References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: SIP IETF , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is starting to smell like BCP material actually. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, April 16, 2008 16:04 > To: Audet, Francois (SC100:3055) > Cc: SIP IETF; Dan WING; Dean Willis > Subject: Re: [Sip] E.164 - who owns it > > replying to myself - another thought: > > Paul Kyzivat wrote: > > > > Francois Audet wrote: > >> That's kind of what I was also saying. > >> > >> PS: what's the difference between 2 and 4? > > > > I think 4 is a typo and was presumably intended to be > > > > 4) sip:+445588675309:a.com;user=phone > > > > It is already the case that a.com may treat 3,4 & 5 alike > if it wishes. > > And b.com may treate 1,2 & 5 alike if it wishes. > > > > The question is whether a.com may treat 1&2 like 5, or if b.com may > > treat 3&4 like 5. > > > > Apparently some are saying that user=phone is license to ignore the > > domain. But that just raises the question of why one would insert a > > domain along with a parameter that says to ignore it. Makes > no sense to me. > > This would make *some* sense to me if the semantics were: > > 1) you MAY route to this domain following 3263 procedures > with expectation that it will work. > > 2) if you are unable to do that (say because you don't have a > sip path at all, or don't have a path to the domain in the > URI) then you may treat it as a tel URI and route it any way > that works for you. > > But it seems that in many of the use cases that have been > presented in this thread it is actually the case that if the > recipient routes to the domain in the URI the request *won't* > work. That makes absolutely no sense to me. In that case TEL > seems clearly the right way. > > Now Hadriel has made a case that it is the SBC's job to fix > this up. So when the URL exits the domain in which it will > work, then the SBC should fix it up with the domain it is > going into. I guess that could make sense if that SBC was > acting as an agent of *both* domains. But typically it is > only acting as an agent of one domain. An SBC acting for > b.com has no business changing the domain of the URL to > a.com, since doing so is (or isn't) a policy of a.com. > > A way around that is to say that if the URI contains b.com, > then an SBC acting for b.com, when it knows it won't honor > that, can change it to a TEL URI when it exits the domain. It > then may well go through another SBC acting for a.com as it > enters the a.com domain. That SBC could change the TEL URI to > an a.com URI if that will be handled correctly within the > a.com domain. > > Paul > > > Paul > > > >>> -----Original Message----- > >>> From: Anders Kristensen [mailto:andersk@cisco.com] > >>> Sent: Wednesday, April 16, 2008 15:21 > >>> To: Dean Willis > >>> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); Paul > >>> Kyzivat; Dan WING > >>> Subject: Re: [Sip] E.164 - who owns it > >>> > >>> > >>> > >>> Dean Willis wrote: > >>>> What does Bob put into the Contact of a 302 he might > send to Alice? > >>>> > >>>> I've heard several alternatives: > >>>> > >>>> 1) sip:+445588675309:b.com > >>>> > >>>> 2) sip:+445588675309:b.com; user=phone > >>>> > >>>> 3) sip:+445588675309:a.com > >>>> > >>>> 4) sip:+445588675309:b.com;user=phone > >>>> > >>>> 5) tel:+445588675309 > >>> The presence of user=phone and a valid E.164 number in > the user part > >>> seems like a pretty strong hint so I wonder if the > following might > >>> work as a pragmatic, if not exactly elegant, way forward: allow > >>> proxies and the UAC to treat cases 2 and 4 as if the URI is > >>> equivalent to 5 in the sense that they can do ENUM query on the > >>> E.164 number and they can even rewrite the domain part and expect > >>> the URI to identify the same entity. > >>> > >>> This doesn't prevent a.com from recursing when really Alice's UA > >>> would have liked to use another provider for gateway services but > >>> then neither does using a tel: URI. > >>> > >>> We'd also want to start pushing support for tel:, of course. > >>> > >>> Thanks, > >>> Anders > >>> > >>>> So let's step through what these mean and why they each > might not > >>>> work. Keep in mind also that there's a very real > possibility that > >>>> Alice might nod NEED a gateway to reach Jenny; it's > possible that > >>>> Jenny's phone number is already in ENUM and is directly > >>> reachable via > >>>> SIP. But this only works if Alice knows to look it up that way. > >>>> > >>>> 1) causes Alice to make a call to a user ID in the domain > >>> of b.com. > >>>> Assuming that b figures out that this means a telephone > >>> destination, > >>>> Alice probably doesn't have an account at b.com to use for > >>> placing the > >>>> call. So unless B provides free SIP-to-PSTN calling, or at least > >>>> provides free translation service to ENUM, she's out of luck. > >>>> > >>>> Of course, maybe a.com knows that when it gets a 302 back with a > >>>> contact that looks like it might be a phone number, it > >>> should discard > >>>> the host part and do phone number routing on the user part. > >>> That works > >>>> until a.com also has user IDs that look like phone numbers. > >>> Of course, > >>>> this is a direct violation of RFC 3261, which bans a.com from > >>>> retargeting a request with a b.com host part. > >>>> > >>>> 2) is much the same as 1, except that "user=phone" > provides another > >>>> hint. B is no more likely to provide gateway services, > but at least > >>>> least if A is going to do an illegal foreign > retargeting, it has a > >>>> broader hint that phone number routing instead of user > routing is > >>>> required. > >>>> > >>>> 3) instructs alice to make a call in the domain of a.com. > >>> That's fine > >>>> as long as sip:+445588675309:a.com routes to Jenny. Does > >>> it? It might > >>>> route to somebody with user ID +445588675309, which is a > perfectly > >>>> valid user ID. > >>>> > >>>> It might also be true that Alice doesn't use a.com for her > >>> PSTN calls. > >>>> Perhaps instead, she uses c.com. So to use c.com > services, or do an > >>>> enum lookup, she has to do an illegal retargeting. > >>>> > >>>> 4) is much like 3, with the added hint that a telephone-number > >>>> destination is indicated. This might eliminate the > >>> accidental calling > >>>> of user +445588675309, but it does nothing to resolve the > >>> question of > >>>> Alice not using a.com services for PSTN gateways. There's > >>> also an open > >>>> issue as to whether PSTN routing (such as an ENUM lookup) can be > >>>> applied, vs requiring the call to traverse a gateway. > >>>> > >>>> At the very best, a.com (or Alice's UA) knows to discard > >>> the host part > >>>> and do telephone routing on the user part. If Alice's UA > does this, > >>>> it's probably a violation of RFC 3261, as the UA itself is not > >>>> responsible for the host-part of the contact. A proxy in > >>> a.com could > >>>> do this translation. But what happens if Alice doesn't use > >>> a.com for > >>>> routing PSTN calls? For example, I might place SIP calls using > >>>> "softarmor.com", but I make my PSTN calls using > "sipphone.com", so > >>>> a > >>>> 302 sent to me for "sip: > >>> +445588675309@softarmor.com;user=phone" will > >>>> most assuredly fail. Now, if the a.com proxy knew to > translate the > >>>> call, that would be OK, but depending on the > relationship between > >>>> Alice and a.com, it might not. > >>>> > >>>> 5) doesn't work at all, because Alice's phone doesn't > >>> understand tel: > >>>> URLs, since understanding of such was listed as a MAY in > >>> RFC 3261. But > >>>> it's the only suggestion from the set that doesn't require > >>> violating a > >>>> bunch of existing protocol rules. > >>>> > >>>> > >>>> > >>>> > >>>>> Really, in the long list of interop issues, this one's > >>> pretty low on > >>>>> the totem pole, imho. People are having trouble getting > >>> basic calls > >>>>> to work without the aid of a middle-box. That's a bit > >>> higher on the > >>>>> list to me. :) > >>>> This is a very basic interdomain calling scenario. I'm > >>> really hoping > >>>> we get more and more interdomain calls. > >>>> > >>>> > >>>>>>> Again, don't shoot the messenger: it makes sense to me > >>> to use Tel > >>>>>>> URI for this. I am just saying it may cause interop > >>> problems. Maybe > >>>>>>> that's ok, and maybe implementations will start > implementing tel > >>>>>>> URI. > >>>>>> I've no doubt that there will be interop problems. That's what > >>>>>> happens when you specify something that has previously been > >>>>>> unspecified and left to whim or caprice. > >>>>> OK, but failing calls will not give it a high chance of being > >>>>> adopted. Maybe we can figure out how to get a sip: uri > to work as > >>>>> well - there's more than one way to skin a cat, even > with a potato > >>>>> peeler. ;) > >>>> Failing calls that don't work now isn't much of a handicap. > >>> Changing > >>>> the rules of RFC 3261 to make case 3 or 4 generally valid > >>> might also > >>>> work. > >>>> > >>>> Fundamentally, we need a documented solution that works in > >>> the general > >>>> case and doesn't conflict with MUST level rules of other > >>> RFCs we cite, > >>>> unless it supercedes those RFCs. > >>>> > >>>> > >>>> -- > >>>> 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 > >>>> > > _______________________________________________ > > 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 sip-bounces@ietf.org Wed Apr 16 18:59:32 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A066228C4E4; Wed, 16 Apr 2008 18:59:32 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DCE28C4E5 for ; Wed, 16 Apr 2008 18:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_45=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 5OxwIdaBtLBe for ; Wed, 16 Apr 2008 18:59:30 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B051628C4E4 for ; Wed, 16 Apr 2008 18:59:30 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3H1xXV1030834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2008 20:59:34 -0500 Message-Id: <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> From: Dean Willis To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 20:59:27 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 16, 2008, at 5:24 PM, Francois Audet wrote: > That's kind of what I was also saying. > > PS: what's the difference between 2 and 4? > the difference is a typo on my part. Should be: 1) sip:+445588675309@b.com 2) sip:+445588675309@b.com; user=phone 3) sip:+445588675309@a.com 4) sip:+445588675309@a.com;user=phone 5) tel:+445588675309 so the difference between 2 and 4 is the domain part of the Contact: header field's URI value in the 302. First case is that the constructed URI is in the terminating domain, which works only if the terminating domain is willing to provide PSTN service to Alice. This is just a business case problem -- which, IMHO, makes it intractable in some cases. Sure, most of the cases we see today have Alice and Bob in the same domain, so it works fine intradomain. Second case is that the constructed URI is in the originating domain, which works only if a) it guesses the URI construction correctly, and b) Alice has access to the PSTN through that domain. Both A and B can be mediated by Alice or the a.com proxy "understanding" what this sort of response means and then figuring it how to transform the URI to something they can route. If Alice doesn't use a.com for PSTN service and the a.com proxy recurses, it is certain to fail -- but that's between Alice and a.com. One might make the argument that a UA or recursing proxy should "know" that if it sees a 302 Contact URI with a domain part equal to that of the sender's and a "user=phone" modifier, that a redirection to PSTN has been requested. It;s been proposed that we use #5: if tel: is known to be supported, and #4 if it isn't. That's actually quite doable by adding a SIP extension tag for "tel" to the Supported field of the request. How about: A node generating a redirect-to-PSTN in the caller's domain MUST use a tel: URI if the request contains a "tel" option tag, and SHOULD use a "number@sourcedomain;user=phone" construction if the request does not contain such a tag. -- Dean, who cannot type. _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 16 19:04:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2945D28C4A7; Wed, 16 Apr 2008 19:04:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB4228C4BA for ; Wed, 16 Apr 2008 19:04: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 cIxp4OP8Xktu for ; Wed, 16 Apr 2008 19:04:31 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9AD133A6A58 for ; Wed, 16 Apr 2008 19:04:31 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3H256LV030890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2008 21:05:07 -0500 Message-Id: From: Dean Willis To: "Robins, Ellen" In-Reply-To: <903E4F74808D4F4B93635C9D9183EBAC0337D094@WSMSG2103V.srv.dir.telstra.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 21:05:00 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com><48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> <903E4F74808D4F4B93635C9D9183EBAC0337D094@WSMSG2103V.srv.dir.telstra.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 16, 2008, at 6:35 PM, Robins, Ellen wrote: > Hi everyone, > On the subject of E.164 discussion is there a universal preffix or > list > of registered preffixes to signify VoIP call. > For example, the same E.164 Mobile or PSTN services numbers can be > used > for dialling Video or Voice Call over IP. > Scenario: Alice has her Mobile service number but would like to > receive > a call instead of Mobile on her PC SIP Soft Client. > Are there a preffix XYZ that would indicates to network that this call > shall be routed via Gateway to IP Client instead of Mobile ? No, there is to my knowledge no such prefix. In fact, such an approach is contraindicated by use cases: One might envision a dual-mode phone that registers the same number concurrently via mobile protocols and SIP. Callers from the mobile or PSTN world would probably reach it via mobile, and callers from the Internet would reach it via SIP. But even that isn't cut-and-dried, since a phone-switch or pbx somewhere on the route between a mobile caller and the dual-mode phone might do a least- cost path determination and decide to gateway the call to SIP for the remainder of the path. Even more confusingly, there are scenarios where several such translations might occur. -- 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 sip-bounces@ietf.org Wed Apr 16 19:14:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C29728C4CF; Wed, 16 Apr 2008 19:14:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B9D28C4DF for ; Wed, 16 Apr 2008 19:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 5G3TeNRJ3tSC for ; Wed, 16 Apr 2008 19:14:15 -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 3783C28C4CF for ; Wed, 16 Apr 2008 19:14:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,668,1199682000"; d="scan'208";a="5321179" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2008 22:14:51 -0400 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 m3H2EpqM029435; Wed, 16 Apr 2008 22:14:51 -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 m3H2EpGc025575; Thu, 17 Apr 2008 02:14:51 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, 16 Apr 2008 22:14:51 -0400 Received: from [10.82.248.250] ([10.82.248.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 22:14:50 -0400 Message-ID: <4806B2B7.9090604@cisco.com> Date: Wed, 16 Apr 2008 22:15:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Francois Audet References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F207@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1630F207@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 17 Apr 2008 02:14:50.0637 (UTC) FILETIME=[D10F3BD0:01C8A030] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10641; t=1208398491; x=1209262491; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Francois=20Audet=20; bh=K2K4nD4vG02zPQOeS+R8d+EVk3BreSuymYLaixc93KI=; b=oRDSzBYiSEHtUGG3Rs1yEH+6thyA/TaN/qoQup1G7wgbabJwDA7Gb2/Uhh ztpzUjRNH+S+ovm12NMLrymhhM9x6E2nwW+g0Q3Cv9stcN/m+dJQTtPNf35I jSuVpax6DT; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Francois, I agree much of what I wrote below does sound like a candidate for a BCP. But I think it is still a bit premature to write one. At the moment I think it is just use cases we are playing with to explore the solution space. Paul Francois Audet wrote: > This is starting to smell like BCP material actually. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, April 16, 2008 16:04 >> To: Audet, Francois (SC100:3055) >> Cc: SIP IETF; Dan WING; Dean Willis >> Subject: Re: [Sip] E.164 - who owns it >> >> replying to myself - another thought: >> >> Paul Kyzivat wrote: >>> Francois Audet wrote: >>>> That's kind of what I was also saying. >>>> >>>> PS: what's the difference between 2 and 4? >>> I think 4 is a typo and was presumably intended to be >>> >>> 4) sip:+445588675309:a.com;user=phone >>> >>> It is already the case that a.com may treat 3,4 & 5 alike >> if it wishes. >>> And b.com may treate 1,2 & 5 alike if it wishes. >>> >>> The question is whether a.com may treat 1&2 like 5, or if b.com may >>> treat 3&4 like 5. >>> >>> Apparently some are saying that user=phone is license to ignore the >>> domain. But that just raises the question of why one would insert a >>> domain along with a parameter that says to ignore it. Makes >> no sense to me. >> >> This would make *some* sense to me if the semantics were: >> >> 1) you MAY route to this domain following 3263 procedures >> with expectation that it will work. >> >> 2) if you are unable to do that (say because you don't have a >> sip path at all, or don't have a path to the domain in the >> URI) then you may treat it as a tel URI and route it any way >> that works for you. >> >> But it seems that in many of the use cases that have been >> presented in this thread it is actually the case that if the >> recipient routes to the domain in the URI the request *won't* >> work. That makes absolutely no sense to me. In that case TEL >> seems clearly the right way. >> >> Now Hadriel has made a case that it is the SBC's job to fix >> this up. So when the URL exits the domain in which it will >> work, then the SBC should fix it up with the domain it is >> going into. I guess that could make sense if that SBC was >> acting as an agent of *both* domains. But typically it is >> only acting as an agent of one domain. An SBC acting for >> b.com has no business changing the domain of the URL to >> a.com, since doing so is (or isn't) a policy of a.com. >> >> A way around that is to say that if the URI contains b.com, >> then an SBC acting for b.com, when it knows it won't honor >> that, can change it to a TEL URI when it exits the domain. It >> then may well go through another SBC acting for a.com as it >> enters the a.com domain. That SBC could change the TEL URI to >> an a.com URI if that will be handled correctly within the >> a.com domain. >> >> Paul >> >>> Paul >>> >>>>> -----Original Message----- >>>>> From: Anders Kristensen [mailto:andersk@cisco.com] >>>>> Sent: Wednesday, April 16, 2008 15:21 >>>>> To: Dean Willis >>>>> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); Paul >>>>> Kyzivat; Dan WING >>>>> Subject: Re: [Sip] E.164 - who owns it >>>>> >>>>> >>>>> >>>>> Dean Willis wrote: >>>>>> What does Bob put into the Contact of a 302 he might >> send to Alice? >>>>>> I've heard several alternatives: >>>>>> >>>>>> 1) sip:+445588675309:b.com >>>>>> >>>>>> 2) sip:+445588675309:b.com; user=phone >>>>>> >>>>>> 3) sip:+445588675309:a.com >>>>>> >>>>>> 4) sip:+445588675309:b.com;user=phone >>>>>> >>>>>> 5) tel:+445588675309 >>>>> The presence of user=phone and a valid E.164 number in >> the user part >>>>> seems like a pretty strong hint so I wonder if the >> following might >>>>> work as a pragmatic, if not exactly elegant, way forward: allow >>>>> proxies and the UAC to treat cases 2 and 4 as if the URI is >>>>> equivalent to 5 in the sense that they can do ENUM query on the >>>>> E.164 number and they can even rewrite the domain part and expect >>>>> the URI to identify the same entity. >>>>> >>>>> This doesn't prevent a.com from recursing when really Alice's UA >>>>> would have liked to use another provider for gateway services but >>>>> then neither does using a tel: URI. >>>>> >>>>> We'd also want to start pushing support for tel:, of course. >>>>> >>>>> Thanks, >>>>> Anders >>>>> >>>>>> So let's step through what these mean and why they each >> might not >>>>>> work. Keep in mind also that there's a very real >> possibility that >>>>>> Alice might nod NEED a gateway to reach Jenny; it's >> possible that >>>>>> Jenny's phone number is already in ENUM and is directly >>>>> reachable via >>>>>> SIP. But this only works if Alice knows to look it up that way. >>>>>> >>>>>> 1) causes Alice to make a call to a user ID in the domain >>>>> of b.com. >>>>>> Assuming that b figures out that this means a telephone >>>>> destination, >>>>>> Alice probably doesn't have an account at b.com to use for >>>>> placing the >>>>>> call. So unless B provides free SIP-to-PSTN calling, or at least >>>>>> provides free translation service to ENUM, she's out of luck. >>>>>> >>>>>> Of course, maybe a.com knows that when it gets a 302 back with a >>>>>> contact that looks like it might be a phone number, it >>>>> should discard >>>>>> the host part and do phone number routing on the user part. >>>>> That works >>>>>> until a.com also has user IDs that look like phone numbers. >>>>> Of course, >>>>>> this is a direct violation of RFC 3261, which bans a.com from >>>>>> retargeting a request with a b.com host part. >>>>>> >>>>>> 2) is much the same as 1, except that "user=phone" >> provides another >>>>>> hint. B is no more likely to provide gateway services, >> but at least >>>>>> least if A is going to do an illegal foreign >> retargeting, it has a >>>>>> broader hint that phone number routing instead of user >> routing is >>>>>> required. >>>>>> >>>>>> 3) instructs alice to make a call in the domain of a.com. >>>>> That's fine >>>>>> as long as sip:+445588675309:a.com routes to Jenny. Does >>>>> it? It might >>>>>> route to somebody with user ID +445588675309, which is a >> perfectly >>>>>> valid user ID. >>>>>> >>>>>> It might also be true that Alice doesn't use a.com for her >>>>> PSTN calls. >>>>>> Perhaps instead, she uses c.com. So to use c.com >> services, or do an >>>>>> enum lookup, she has to do an illegal retargeting. >>>>>> >>>>>> 4) is much like 3, with the added hint that a telephone-number >>>>>> destination is indicated. This might eliminate the >>>>> accidental calling >>>>>> of user +445588675309, but it does nothing to resolve the >>>>> question of >>>>>> Alice not using a.com services for PSTN gateways. There's >>>>> also an open >>>>>> issue as to whether PSTN routing (such as an ENUM lookup) can be >>>>>> applied, vs requiring the call to traverse a gateway. >>>>>> >>>>>> At the very best, a.com (or Alice's UA) knows to discard >>>>> the host part >>>>>> and do telephone routing on the user part. If Alice's UA >> does this, >>>>>> it's probably a violation of RFC 3261, as the UA itself is not >>>>>> responsible for the host-part of the contact. A proxy in >>>>> a.com could >>>>>> do this translation. But what happens if Alice doesn't use >>>>> a.com for >>>>>> routing PSTN calls? For example, I might place SIP calls using >>>>>> "softarmor.com", but I make my PSTN calls using >> "sipphone.com", so >>>>>> a >>>>>> 302 sent to me for "sip: >>>>> +445588675309@softarmor.com;user=phone" will >>>>>> most assuredly fail. Now, if the a.com proxy knew to >> translate the >>>>>> call, that would be OK, but depending on the >> relationship between >>>>>> Alice and a.com, it might not. >>>>>> >>>>>> 5) doesn't work at all, because Alice's phone doesn't >>>>> understand tel: >>>>>> URLs, since understanding of such was listed as a MAY in >>>>> RFC 3261. But >>>>>> it's the only suggestion from the set that doesn't require >>>>> violating a >>>>>> bunch of existing protocol rules. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Really, in the long list of interop issues, this one's >>>>> pretty low on >>>>>>> the totem pole, imho. People are having trouble getting >>>>> basic calls >>>>>>> to work without the aid of a middle-box. That's a bit >>>>> higher on the >>>>>>> list to me. :) >>>>>> This is a very basic interdomain calling scenario. I'm >>>>> really hoping >>>>>> we get more and more interdomain calls. >>>>>> >>>>>> >>>>>>>>> Again, don't shoot the messenger: it makes sense to me >>>>> to use Tel >>>>>>>>> URI for this. I am just saying it may cause interop >>>>> problems. Maybe >>>>>>>>> that's ok, and maybe implementations will start >> implementing tel >>>>>>>>> URI. >>>>>>>> I've no doubt that there will be interop problems. That's what >>>>>>>> happens when you specify something that has previously been >>>>>>>> unspecified and left to whim or caprice. >>>>>>> OK, but failing calls will not give it a high chance of being >>>>>>> adopted. Maybe we can figure out how to get a sip: uri >> to work as >>>>>>> well - there's more than one way to skin a cat, even >> with a potato >>>>>>> peeler. ;) >>>>>> Failing calls that don't work now isn't much of a handicap. >>>>> Changing >>>>>> the rules of RFC 3261 to make case 3 or 4 generally valid >>>>> might also >>>>>> work. >>>>>> >>>>>> Fundamentally, we need a documented solution that works in >>>>> the general >>>>>> case and doesn't conflict with MUST level rules of other >>>>> RFCs we cite, >>>>>> unless it supercedes those RFCs. >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>> _______________________________________________ >>> 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 sip-bounces@ietf.org Wed Apr 16 21:24:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB013A692F; Wed, 16 Apr 2008 21:24:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9470C3A692F for ; Wed, 16 Apr 2008 21:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 BrIfT6qQUWBD for ; Wed, 16 Apr 2008 21:24:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5E03A3A67D5 for ; Wed, 16 Apr 2008 21:24: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.263.0; Thu, 17 Apr 2008 00:24:17 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 17 Apr 2008 00:24:15 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Francois Audet Date: Thu, 17 Apr 2008 00:24:36 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcigFgdz2F5DgZwMT560307wBNyJ3wAKoRrw Message-ID: References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> In-Reply-To: <480685D3.3000308@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > Now Hadriel has made a case that it is the SBC's job to fix this up. Hmm... I don't seem to recall saying that at all! Something has to do it, but it by no means has to be an SBC. It could, for example, be the same proxy that decided it could not resolve it locally and to pass the 302 upstream. > So > when the URL exits the domain in which it will work, then the SBC should > fix it up with the domain it is going into. I guess that could make > sense if that SBC was acting as an agent of *both* domains. But > typically it is only acting as an agent of one domain. An SBC acting for > b.com has no business changing the domain of the URL to a.com, since > doing so is (or isn't) a policy of a.com. On the contrary, one could argue a.com has no business changing b.com's domain to a.com, but I see nothing wrong with b.com changing the domain to a.com. Don't get me wrong - the whole thing sucks, but from a "who's business is it" perspective I think it's b.com's. Otherwise you're essentially arguing that b.com cannot retarget requests to a.com either. What's "wrong" is for a.com to retarget requests addressed to b.com to itself instead. > A way around that is to say that if the URI contains b.com, then an SBC > acting for b.com, when it knows it won't honor that, can change it to a > TEL URI when it exits the domain. It then may well go through another > SBC acting for a.com as it enters the a.com domain. That SBC could > change the TEL URI to an a.com URI if that will be handled correctly > within the a.com domain. Funny enough I've seen a case where that exactly happens. It seemed crazy to me though. -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 sip-bounces@ietf.org Wed Apr 16 23:25:37 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430353A69BC; Wed, 16 Apr 2008 23:25:37 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3827B3A6917 for ; Wed, 16 Apr 2008 23:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 Qf01o-WFzbVV for ; Wed, 16 Apr 2008 23:25:35 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id EAB183A6FBA for ; Wed, 16 Apr 2008 23:25:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 2B0241EC2A9; Thu, 17 Apr 2008 09:25:38 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo-4cBJaRDKA; Thu, 17 Apr 2008 09:25:31 +0300 (EEST) Received: from taimen (h150176.gprs.dnafinland.fi [87.93.150.176]) by tutpro.com (Postfix) with ESMTP; Thu, 17 Apr 2008 09:25:31 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 4B018AC08A; Thu, 17 Apr 2008 09:25:26 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18438.60758.275751.157480@taimen.test.fi> Date: Thu, 17 Apr 2008 09:25:26 +0300 To: Dean Willis In-Reply-To: References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> <903E4F74808D4F4B93635C9D9183EBAC0337D094@WSMSG2103V.srv.dir.telstra.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , "Robins, Ellen" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis writes: > Callers from the mobile or PSTN world would probably reach it via > mobile, and callers from the Internet would reach it via SIP. a civilized mobile operator would, before routing the call anywhere, make an enum query and act accordingly. -- juha _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 17 07:18:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1C328C4E8; Thu, 17 Apr 2008 07:18:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A8428C4E7 for ; Thu, 17 Apr 2008 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.419 X-Spam-Level: X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[AWL=0.580, 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 yYuQB22175uP for ; Thu, 17 Apr 2008 07:18:22 -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 BC01128C4E8 for ; Thu, 17 Apr 2008 07:18:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,671,1199682000"; d="scan'208";a="5391016" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2008 10:18:58 -0400 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 m3HEIvNI011818; Thu, 17 Apr 2008 10:18:57 -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 m3HEIvxw003240; Thu, 17 Apr 2008 14:18:57 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); Thu, 17 Apr 2008 10:18:57 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Apr 2008 10:18:57 -0400 Message-ID: <48075C6F.6000206@cisco.com> Date: Thu, 17 Apr 2008 10:19:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> In-Reply-To: X-OriginalArrivalTime: 17 Apr 2008 14:18:57.0127 (UTC) FILETIME=[F92F7F70:01C8A095] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3760; t=1208441937; x=1209305937; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=0E4aUBcGpMhS0H46/u1FTQxCviwnzTYNEMTIWz02dtE=; b=JXlBRPPv4sLtCTUTBWTgWk6DfVp0VmwzAgijXqz/HL83THXozt70d2Bio+ 0joQadRLNhedqFdMebrZcw9pwgXWykGIdWVRJB7112Jkp6xCl2ewDQ/PO2ia fpt9U42y4F; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP IETF , Francois Audet , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> >> Now Hadriel has made a case that it is the SBC's job to fix this up. > > Hmm... I don't seem to recall saying that at all! Something has to do it, but it by no means has to be an SBC. It could, for example, be the same proxy that decided it could not resolve it locally and to pass the 302 upstream. OK, *something* has to do it. In *some* cases a proxy could do it. But in many cases only a UA is allowed to do it. For instance changing the From URI. If we are arguing that some middlebox is supposed to make this problem go away generally, then it will have to be a middlebox that is a UA, hence a B2BUA. Ones that perform that sort of role are generally called SBCs. >> So >> when the URL exits the domain in which it will work, then the SBC should >> fix it up with the domain it is going into. I guess that could make >> sense if that SBC was acting as an agent of *both* domains. But >> typically it is only acting as an agent of one domain. An SBC acting for >> b.com has no business changing the domain of the URL to a.com, since >> doing so is (or isn't) a policy of a.com. > > On the contrary, one could argue a.com has no business changing b.com's domain to a.com, but I see nothing wrong with b.com changing the domain to a.com. Don't get me wrong - the whole thing sucks, but from a "who's business is it" perspective I think it's b.com's. Otherwise you're essentially arguing that b.com cannot retarget requests to a.com either. What's "wrong" is for a.com to retarget requests addressed to b.com to itself instead. Maybe I need to state my point better. Depending on the type of box and the header that is being modified, a box acting for b.com may indeed be permitted to replace a b.com URL with some other URL, even an a.com URL. (In fact it doesn't matter what the domains of the two urls are, it may be able to do it.) What is a problem is for b.com to *fabricate* an a.com URL to insert. b.com in in general not privy to the policies governing the construction of urls in the a.com domain, and so has no business constructing one. And that is what is happening if b.com "changes the domain to a.com" in the URL. >> A way around that is to say that if the URI contains b.com, then an SBC >> acting for b.com, when it knows it won't honor that, can change it to a >> TEL URI when it exits the domain. It then may well go through another >> SBC acting for a.com as it enters the a.com domain. That SBC could >> change the TEL URI to an a.com URI if that will be handled correctly >> within the a.com domain. > > Funny enough I've seen a case where that exactly happens. It seemed crazy to me though. Its not at all crazy. What it means is that b.com is converting one of its own URLs, whose semantics it understands, into a url with standardized semantics. Then a.com is converting a url with standardized semantics into a url in the a.com domain, whose semantics *it* understands. The alternative is to declare any sip URI with user=phone has standardized semantics, and that all domains must support that form. Or, every box making the conversion must understand the policies of both sides. It seems that most are now agreeing that tel URIs would be the right way to exchange phone numbers, but are concerned with backward compatibility to all those devices that purportedly don't support them. The migration is eased of we assume that SBCs (which seem to be everywhere anyway) can do the fixup for those that don't support it. And over time the fixups could be eliminated. 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 sip-bounces@ietf.org Thu Apr 17 07:33:04 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF4B3A6BEB; Thu, 17 Apr 2008 07:33:04 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83A328C10D for ; Thu, 17 Apr 2008 07:33:03 -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 3LgpVKv3DkD2 for ; Thu, 17 Apr 2008 07:33:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E37E43A6917 for ; Thu, 17 Apr 2008 07:33:02 -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.263.0; Thu, 17 Apr 2008 10:33:10 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 17 Apr 2008 10:33:10 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Thu, 17 Apr 2008 10:33:31 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acigle0ppSUMhBcLTqOQnZq/eSuwOQAASuZQ Message-ID: References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> <48075C6F.6000206@cisco.com> In-Reply-To: <48075C6F.6000206@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Francois Audet , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Hadriel Kaplan wrote: > > > >> A way around that is to say that if the URI contains b.com, then an SBC > >> acting for b.com, when it knows it won't honor that, can change it to a > >> TEL URI when it exits the domain. It then may well go through another > >> SBC acting for a.com as it enters the a.com domain. That SBC could > >> change the TEL URI to an a.com URI if that will be handled correctly > >> within the a.com domain. > > > > Funny enough I've seen a case where that exactly happens. It seemed > > crazy to me though. > > Its not at all crazy. Sorry, I should have been clearer - it seemed crazy to me because the two SBC's were connected with a direct fiber, and all responses upstream from b.com were going nowhere but a.com. :) -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 sip-bounces@ietf.org Thu Apr 17 07:56:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD84128C506; Thu, 17 Apr 2008 07:56:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B7428C272 for ; Thu, 17 Apr 2008 07:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=0.870, 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 Pasm9qqhHKEJ for ; Thu, 17 Apr 2008 07:56:15 -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 948583A6DD7 for ; Thu, 17 Apr 2008 07:55:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,671,1199682000"; d="scan'208";a="5385591" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2008 10:56:12 -0400 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 m3HEuCv1016945; Thu, 17 Apr 2008 10:56:12 -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 m3HEuCXW026835; Thu, 17 Apr 2008 14:56:12 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); Thu, 17 Apr 2008 10:56:12 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Apr 2008 10:56:11 -0400 Message-ID: <4807652A.1070906@cisco.com> Date: Thu, 17 Apr 2008 10:56:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hadriel Kaplan References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <48068001.2030302@cisco.com> <480685D3.3000308@cisco.com> <48075C6F.6000206@cisco.com> In-Reply-To: X-OriginalArrivalTime: 17 Apr 2008 14:56:11.0879 (UTC) FILETIME=[2D339770:01C8A09B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1020; t=1208444172; x=1209308172; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=xMPYUd2MD0jijxOrDWN5cMinsWsbpuTeP8n7R4buGJo=; b=XAoMUjpHRKcAH4mH0T3INn+HYKKsOGg1InCYUSJanCGHfprbpilbJ6bqj9 tTH5S/BlARfM1dAp01wyGdNlcnbkl4PSJFOPW1YgCIESSX1IL4ACXFo5FK6d HerQPmcyCQ; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , Francois Audet , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> Hadriel Kaplan wrote: >>>> A way around that is to say that if the URI contains b.com, then an SBC >>>> acting for b.com, when it knows it won't honor that, can change it to a >>>> TEL URI when it exits the domain. It then may well go through another >>>> SBC acting for a.com as it enters the a.com domain. That SBC could >>>> change the TEL URI to an a.com URI if that will be handled correctly >>>> within the a.com domain. >>> Funny enough I've seen a case where that exactly happens. It seemed >>> crazy to me though. >> Its not at all crazy. > > Sorry, I should have been clearer - it seemed crazy to me because the two SBC's were connected with a direct fiber, and all responses upstream from b.com were going nowhere but a.com. :) If the fiber was a trunk connecting two peers then I don't think it is crazy. It seems preferable to hard coding the peer's policy. 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 sip-bounces@ietf.org Thu Apr 17 17:27:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A199C3A692A; Thu, 17 Apr 2008 17:27:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC173A6DCA for ; Thu, 17 Apr 2008 17:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[J_CHICKENPOX_21=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 EB+XffmDXiLF for ; Thu, 17 Apr 2008 17:27: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 1BE763A692A for ; Thu, 17 Apr 2008 17:27:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,674,1199692800"; d="scan'208";a="11320391" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 17 Apr 2008 17:27:32 -0700 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 m3I0RXMn014922; Thu, 17 Apr 2008 17:27:33 -0700 Received: from [128.107.147.122] (dhcp-128-107-147-122.cisco.com [128.107.147.122]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3I0RXgm024249; Fri, 18 Apr 2008 00:27:33 GMT Message-ID: <4807EAF3.4070205@cisco.com> Date: Thu, 17 Apr 2008 17:27:31 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> In-Reply-To: <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=693; t=1208478453; x=1209342453; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20Re=3A=20[Sip]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=Gez3iDVaVYsVNoJZiXIKmuQbFBlgQ/GzoCnriUrzfxU=; b=tzjWBWGnigRiHAcI9jD4LgyXmAtHYhug8Z5xZ7lbHDILFoRoPZ0Mr3DkgU nfADGTM5j/5e0PpwxxaIBKxEMMh0lzB4fs3oj+OD8WTt9w7xH/JgA/U52er/ LErH6kRCoe0/phWsyPDpkmVH5XXI6GwPPIpaKDyM0hsEoDRB+EC2A=; Authentication-Results: sj-dkim-1; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP IETF , Francois Audet , Dan WING , Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > It;s been proposed that we use #5: if tel: is known to be supported, and > #4 if it isn't. That's actually quite doable by adding a SIP extension > tag for "tel" to the Supported field of the request. > > How about: A node generating a redirect-to-PSTN in the caller's domain > MUST use a tel: URI if the request contains a "tel" option tag, and > SHOULD use a "number@sourcedomain;user=phone" construction if the > request does not contain such a tag. Proxies can't muck with Supported headers so I'm not sure how this helps if it's a proxy in the caller's domain (as opposed to the UAC itself) that understands and acts on tel: URIs. Anders _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 17 18:52:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BEAA3A6BB8; Thu, 17 Apr 2008 18:52:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB34A3A6BB8 for ; Thu, 17 Apr 2008 18:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[J_CHICKENPOX_21=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 wN2tuGkl5dyd for ; Thu, 17 Apr 2008 18:52:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E49A63A699E for ; Thu, 17 Apr 2008 18:52:14 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3I1q7oQ013438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Apr 2008 20:52:09 -0500 Message-Id: From: Dean Willis To: Anders Kristensen In-Reply-To: <4807EAF3.4070205@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 17 Apr 2008 20:52:02 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Francois Audet , Dan WING , Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 17, 2008, at 7:27 PM, Anders Kristensen wrote: > > > Dean Willis wrote: >> It;s been proposed that we use #5: if tel: is known to be >> supported, and #4 if it isn't. That's actually quite doable by >> adding a SIP extension tag for "tel" to the Supported field of the >> request. >> How about: A node generating a redirect-to-PSTN in the caller's >> domain MUST use a tel: URI if the request contains a "tel" option >> tag, and SHOULD use a "number@sourcedomain;user=phone" construction >> if the request does not contain such a tag. > > Proxies can't muck with Supported headers so I'm not sure how this > helps if it's a proxy in the caller's domain (as opposed to the UAC > itself) that understands and acts on tel: URIs. So assume the UAC does not support "tel" and the UAS's domain is not going to pay to send the call to the PSTN -- the redirecting node ends up doing what it would do now, which is assume that tel isn't supported, and make its best SIP guess at a SIP rewrite in the UAC's domain. Proxies that recurse on 302 responses should be taken out and burned anyhow. It's just a tragically stupid thing to do in most cases. In the scenarios we're talking about, which probably involve a transition from a "no charge" IP call to a potentially very expensive (like, up to $25 a minute for some premium services) PSTN call, the user REALLY needs to be able to make a decision. So the limitation you've noted doesn't bother me at all. -- 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 sip-bounces@ietf.org Fri Apr 18 01:16:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86FE3A68EF; Fri, 18 Apr 2008 01:16:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61383A6A36 for ; Fri, 18 Apr 2008 01:16:08 -0700 (PDT) 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 TdRQ+VsXhLlu for ; Fri, 18 Apr 2008 01:16: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 432CB3A6A44 for ; Fri, 18 Apr 2008 01:15:47 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JZI0094AHMAR8@siemenscomms.co.uk> for sip@ietf.org; Fri, 18 Apr 2008 09:15:46 +0100 (BST) Date: Fri, 18 Apr 2008 09:15:49 +0100 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , Cullen Jennings , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0A09244@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] What 4474 signs part-2 [was: Proposal to Revise RFC 4474] Thread-Index: AcieP0/LxeHkmxVcTcSS+BethEerDAAWDIQgACpzRAAAeoDREA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> <29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> Cc: SIP IETF , jon.peterson@neustar.biz Subject: Re: [Sip] What 4474 signs part-2 [was: Proposal to Revise RFC 4474] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 16 April 2008 06:20 > To: Cullen Jennings; Dean Willis > Cc: SIP IETF; jon.peterson@neustar.biz > Subject: [Sip] What 4474 signs part-2 [was: Proposal to > Revise RFC 4474] > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Cullen Jennings > > > > Based on the discussion I've seen so far, the primary use case for > > this modification is to allow the SBC to do media steering so it can > > steer the RTP through a path that provides better QoS. As you say, > > this could be achieved by modifying the SDP and changing RFC 4474 to > > allow that, but there are probably some other approaches we > should be > > considering as well, including ones that may need to be done outside > > of SIP. If there's consensus that this is the problem > > that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC > > chairs and figure out a process for how to evaluate the various > > options and get this moving forward. If this isn't > > the primary use case, then I think we probably need some more > > discussion to get a clearer idea of what the problem is. > > Part 2 of this series: Signing the Contact URI. > > I believe 4474 signs the Contact URI to prevent malicious > attackers from intercepting a signed request and replacing > the Contact in order to receive all later requests/responses. > Or at least that's how I read rfc4474's reason for it: > > The Contact header field is included to tie the Identity > header to a > particular user agent instance that generated the request. Were an > active attacker to intercept a request containing an > Identity header, > and cut-and-paste the Identity header field into its own request > (reusing the From, To, Contact, Date, and Call-ID fields > that appear > in the original message), the attacker would not be eligible to > receive SIP requests from the called user agent, since > those requests > are routed to the URI identified in the Contact header field. > However, the Contact header is only included in dialog-forming > requests, so it does not provide this protection in all cases. > > While I appreciate the desire, I don't see how signing the > Contact actually accomplishes this goal in many cases. A > malicious attacker can easily insert Via and Record-Route > headers, to get any subsequent in-dialog requests/responses. > This is in fact what the non-MitM baiting attack described in > draft-kaplan-sip-baiting-attack-02 does. > > But there is potential for a Contact URI to be used for > out-of-dialog requests, for example in later REFERs and > certain Conference applications, which is what triggered the > need for GRUU's. In that sense signing it may be valuable. > Unfortunately that contradicts the goals of certain > middle-boxes, and figuring out if those middle-boxes are > changing it for malicious vs. legitimate reasons is an > impossible task. > > Note that not signing the contact does not hurt the strength > of the signed request directly (because the Record-Route > issue already weakened that), but hurts the validity of the > Contact for use in future out-of-dialog requests from the > UAS. The question then is what exactly is harmed if a > malicious attacker inserts itself in the Contact for such > use-cases. If a later REFER or conference INVITE is sent to > the attacker instead of the correct UA, it will only succeed > in transferring or joining the call if it actually reaches > the right UA. Certainly the attacker could pretend to be the > correct UA, and thus either perform full impersonation, or > simply view SIP signaling which it otherwise might not get to. > > However this form of attack is far less likely and less > fruitful than those available to attackers by simply > inserting Record-Routes as done in the baiting attack for the > original request, and can be detected by RFC4916-type > upstream signing in response to the REFER or conference INVITE. > > Therefore, I propose a straw-man: > Allow the authenticating signer and/or the UAC to choose > whether to sign the Contact URI, by having it add an > Identity-Info param such as "no=contact". The inclusion of > this param means the signature does not include the Contact > addr-spec. The Identity-Info header is itself not signed, > but that won't matter because if an attacker adds this but > the signature did include the contact, it will invalidate the > signature, and vice-versa if an attacker removes it. This > weakens things as described earlier, but it's up to the > originator to decide if they're ok with that. (A > better-than-nothing approach) > > Regardless, I suggest we strongly recommend in any update to > RFC 4474 that GRUU's be used for signed Contact URI's. When > the Contact is a GRUU using the domain name instead of the > UAC's host address, there is less need for middle-boxes to > change the Contact. It is often changed to hide > host-specific information, and with a GRUU that can be > avoided. (it won't go away completely, but it increases the > odds of success if it is still signed) [JRE] I am trying to figure out how things will work if a middlebox rewrites a GRUU. Consider this scenario. A sends GRUU1 to B in a dialog-forming request. Middlebox M rewrites the GRUU1 to GRUU2, so B receives GRUU2. B sends GRUU2 to C. B closes the dialog with A. C sends a new request to GRUU2, which I presume would be constructed so that the request reaches M. Is it certain that M will have retained the necessary state to map GRUU2 to GRUU1? In other words, how does M ensure that the lifetime of GRUU2 matches the lifetime of GRUU1? 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 sip-bounces@ietf.org Fri Apr 18 01:16:36 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7533A6A44; Fri, 18 Apr 2008 01:16:36 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF323A6A2D for ; Fri, 18 Apr 2008 01:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 uDhP0qQUNMc0 for ; Fri, 18 Apr 2008 01:16: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 5D0523A6A62 for ; Fri, 18 Apr 2008 01:16:16 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JZI0095IHN3R8@siemenscomms.co.uk> for sip@ietf.org; Fri, 18 Apr 2008 09:16:16 +0100 (BST) Date: Fri, 18 Apr 2008 09:16:19 +0100 From: "Elwell, John" In-reply-to: To: Hadriel Kaplan , Cullen Jennings , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0A09245@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] What 4474 signs, part-1 [was: Proposal to Revise RFC 4474] Thread-Index: AcieP0/LxeHkmxVcTcSS+BethEerDAAWDIQgAAAPP+AApSxjwA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> <29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> Cc: SIP IETF , jon.peterson@neustar.biz Subject: Re: [Sip] What 4474 signs, part-1 [was: Proposal to Revise RFC 4474] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org A good analysis. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 15 April 2008 15:26 > To: Cullen Jennings; Dean Willis > Cc: SIP IETF; jon.peterson@neustar.biz > Subject: [Sip] What 4474 signs, part-1 [was: Proposal to > Revise RFC 4474] > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > Cullen Jennings > > Sent: Monday, April 14, 2008 10:53 AM > > > > Based on the discussion I've seen so far, the primary use case for > > this modification is to allow the SBC to do media steering so it can > > steer the RTP through a path that provides better QoS. As you say, > > this could be achieved by modifying the SDP and changing RFC 4474 to > > allow that, but there are probably some other approaches we > should be > > considering as well, including ones that may need to be done outside > > of SIP. If there's consensus that this is the problem > > that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC > > chairs and figure out a process for how to evaluate the various > > options and get this moving forward. If this isn't > > the primary use case, then I think we probably need some more > > discussion to get a clearer idea of what the problem is. > > I think there are several problems with what 4474 signs, and > SDP is only one of them, so I'll break it up into separate > emails. As far as I can tell, in this world there are lots > of B2BUA's - and no I'm not just talking SBC's. Most of the > people on this mailing list work for companies that make some > form of B2BUA or other which are not SBC's. Some of those > B2BUA's change things which will break 4474. Whether 4474 > *should* fail in such cases is a separate but important topic. > > This is part-1: Signing the Call-ID. Some of those B2BUA's > change the Call-ID, even though at a higher layer it's > clearly the same "request". > > I believe RFC 4474 signs the Call-ID to provide cut-paste > attack protection such that the Verifier can detect when a > SIP request is being replayed. To do that, the Verifier > keeps a table of received call-id's and identity header > signatures with their date. If a request is received with > the same identity header value for the same call-id and date > (which are both signed in that identity header value's > signature), then it's a replay. Clearly valid in-dialog > requests will have the same call-id, but because their date > and cseq values will be different, their identity header > values will be unique and not detected as a replay. > > I think there are actually legitimate technical reasons why > this wouldn't always work right, even in a fully > rfc3261-compliant world. For one, the request could get > forked, but end up at the same verifier. The forked requests > could have unique request-uri's or Route header lists, > identifying unique final targets, but the verifier would > consider all but one of them a replay. Similarly, a > legitimate spiral through a verifier would be detected as a > replay. For another, the request could be responded to by > the UAS with a 302, which triggers an upstream proxy to > recurse the request again through the same verifier but a new > final target, which would be detected as a replay. Lastly, I > believe that if UDP transport is used, the verifier can > legitimately get retransmissions of requests, using the same > cseq, which it would detect as replays but may really need to > pass on. (ie, non-Invite requests) > > Then of course there is also a world with B2BUA's. I think a > legitimate argument can be made that a 4474-signed signature > *shouldn't* remain valid crossing such Call-ID-changing > systems, because otherwise it opens up the door for replay > attacks. [note: I am only talking Call-ID's, not other fields] > > But there are ways of providing such replay protection > *without* signing the Call-ID field value. I can suggest two > alternatives: > > 1) Create a new header or parameter to be signed and > verified, which is unique per new out-of-dialog request the > UAC creates - to be added by the UAC or Authenticator before > signing. Ultimately, I believe the Call-ID was signed > because it was an already existing header - it was very > convenient. However, if 4474 fails to be usable in many > cases were we think it should work, then it's very *inconvenient*. > > 2) Mandate that UAC's _STOP_ using IP Addresses in Call-ID's, > with whatever new response code and mechanics we need to make > that transition. If we were to re-create SIP today, I would > argue for this to the end. If we want middle-boxes like > SBC's to stop changing things we don't want them to change, > stop putting things in which their owners feel compelled to > change. This obviously can't be avoided for some things, but > the Call-ID is one of my pet peeves because it didn't have to > be one of them. > > Note that Option 2 would only work for SBC's really, not > other B2BUA's who change it because they think they need to > or really do need to for other reasons. And it would have a > serious problem of needing some installed SBC's to be > upgraded, whereas option 1 above would have a greater chance > of working today. So my preference is Option 1. But doing > Option 2 will also solve a lot of other problems in the > future, so my real preference is to do BOTH. (Option 1 for > 4474, Option 2 for general practice) > > -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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 18 05:00:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1682928C103; Fri, 18 Apr 2008 05:00:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBFB28C103 for ; Fri, 18 Apr 2008 05:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=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 rXbhjoMaCF6H for ; Fri, 18 Apr 2008 05:00:05 -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 0E6973A6C2A for ; Fri, 18 Apr 2008 05:00:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,677,1199682000"; d="scan'208";a="5523261" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Apr 2008 07:59:57 -0400 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 m3IBxvTs022681; Fri, 18 Apr 2008 07:59:57 -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 m3IBxvS6023507; Fri, 18 Apr 2008 11:59:57 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); Fri, 18 Apr 2008 07:59:57 -0400 Received: from [10.86.240.137] ([10.86.240.137]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 07:59:57 -0400 Message-ID: <48088D5B.9020501@cisco.com> Date: Fri, 18 Apr 2008 08:00:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> In-Reply-To: X-OriginalArrivalTime: 18 Apr 2008 11:59:57.0288 (UTC) FILETIME=[B8AACE80:01C8A14B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1086; t=1208519997; x=1209383997; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Dean=20Willis=20; bh=oVMMSWkE15MbDVznwsESOwO985PXYcNvhME/K3SIe7k=; b=CJEMHt721NjP08728lO5lPo/InZUqTO0DT503F2lEU2AV/KOtEXBXd0gsS 8NsjSqW7TK1ZeKu+iOnW8N97gOJadTuC9VFGUBR2yRwsFbeqQAeks3yNZbXf oUTBimUM1z; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Proxies that recurse on 302 responses should be taken out and burned > anyhow. It's just a tragically stupid thing to do in most cases. In > the scenarios we're talking about, which probably involve a transition > from a "no charge" IP call to a potentially very expensive (like, up > to $25 a minute for some premium services) PSTN call, the user REALLY > needs to be able to make a decision. This doesn't bother me. If this happens I'm just going to refuse to pay the bill, with the argument that "I never called that number". So this is a feature. IMO if a proxy was already forking, or prepared to fork, then recursing on 3xx is not making things any worse. Also, you are assuming that the recursion is happening in the calling domain. It may well be happening in the called domain, which may want to hide the 3xx response from the calling domain. > So the limitation you've noted doesn't bother me at all. Why should we need Supported:tel before tel can be used? Its already supposed to be supported. 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 sip-bounces@ietf.org Fri Apr 18 05:22:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227683A6B9E; Fri, 18 Apr 2008 05:22:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA5A3A6A6E for ; Fri, 18 Apr 2008 05:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 V+ouRGZSdZyU for ; Fri, 18 Apr 2008 05:22:47 -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 8C7333A6C2A for ; Fri, 18 Apr 2008 05:22:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,677,1199682000"; d="scan'208";a="5535266" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2008 08:22:47 -0400 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 m3ICMloU021140; Fri, 18 Apr 2008 08:22:47 -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 m3ICMkfv000980; Fri, 18 Apr 2008 12:22:47 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); Fri, 18 Apr 2008 08:22:39 -0400 Received: from [10.86.240.137] ([10.86.240.137]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 08:22:38 -0400 Message-ID: <480892AC.5080101@cisco.com> Date: Fri, 18 Apr 2008 08:23:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Elwell, John" References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> <29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0A09244@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0A09244@GBNTHT12009MSX.gb002.siemens.net> X-OriginalArrivalTime: 18 Apr 2008 12:22:38.0616 (UTC) FILETIME=[E414F980:01C8A14E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7484; t=1208521367; x=1209385367; 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]=20What=204474=20signs=20part-2=20 [was=3A=20Proposal=20to=20Revise=20RFC=204474] |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=qy/upRsgBHhfQrmXf8vuABUHmgH5IxVeNN3YKv+qzvI=; b=MA0qvi7Yo5KJI4djp0yDLucX8Q/gSAEscwmHY8u/HigwX64gSQP6WGF+9Q AIWHEXsBFMsEXlv9Dz9c9/OZGE6I2LQOU0SQiJSSusIurL0/5Jpk9IwGwvHL vbcIcX3C5i; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Cullen Jennings , SIP IETF , jon.peterson@neustar.biz, Dean Willis Subject: Re: [Sip] What 4474 signs part-2 [was: Proposal to Revise RFC 4474] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John, There are a number of cases (e.g. IMS) where once gruus are used a b2bua will be in exactly the situation you describe. So its not an idle question. For reasonable features to work, the b2bua will need have the ability to make the translation for out of dialog requests. And it will need to do so for a period of time that is hard to predict. When the original gruu was a permanent one, the translation should be supported for as long as the AOR the gruu was based on remains valid, which could be months or years. For temporary gruus its impossible to guess. Often the period may be relatively short, but there is no way to know how long. The safest way to ensure that this will work wold be to generate the new gruu so it contains an encrypted form of the original gruu. There of course may be cases where its goal to limit the lifetime. For instance if a call was anonymous it is probably good to limit the lifetime of the gruu to the duration of the original dialog. But such special cases need to be considered very carefully. Paul Elwell, John wrote: > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: 16 April 2008 06:20 >> To: Cullen Jennings; Dean Willis >> Cc: SIP IETF; jon.peterson@neustar.biz >> Subject: [Sip] What 4474 signs part-2 [was: Proposal to >> Revise RFC 4474] >> >> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of >>> Cullen Jennings >>> >>> Based on the discussion I've seen so far, the primary use case for >>> this modification is to allow the SBC to do media steering so it can >>> steer the RTP through a path that provides better QoS. As you say, >>> this could be achieved by modifying the SDP and changing RFC 4474 to >>> allow that, but there are probably some other approaches we >> should be >>> considering as well, including ones that may need to be done outside >>> of SIP. If there's consensus that this is the problem >>> that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC >>> chairs and figure out a process for how to evaluate the various >>> options and get this moving forward. If this isn't >>> the primary use case, then I think we probably need some more >>> discussion to get a clearer idea of what the problem is. >> Part 2 of this series: Signing the Contact URI. >> >> I believe 4474 signs the Contact URI to prevent malicious >> attackers from intercepting a signed request and replacing >> the Contact in order to receive all later requests/responses. >> Or at least that's how I read rfc4474's reason for it: >> >> The Contact header field is included to tie the Identity >> header to a >> particular user agent instance that generated the request. Were an >> active attacker to intercept a request containing an >> Identity header, >> and cut-and-paste the Identity header field into its own request >> (reusing the From, To, Contact, Date, and Call-ID fields >> that appear >> in the original message), the attacker would not be eligible to >> receive SIP requests from the called user agent, since >> those requests >> are routed to the URI identified in the Contact header field. >> However, the Contact header is only included in dialog-forming >> requests, so it does not provide this protection in all cases. >> >> While I appreciate the desire, I don't see how signing the >> Contact actually accomplishes this goal in many cases. A >> malicious attacker can easily insert Via and Record-Route >> headers, to get any subsequent in-dialog requests/responses. >> This is in fact what the non-MitM baiting attack described in >> draft-kaplan-sip-baiting-attack-02 does. >> >> But there is potential for a Contact URI to be used for >> out-of-dialog requests, for example in later REFERs and >> certain Conference applications, which is what triggered the >> need for GRUU's. In that sense signing it may be valuable. >> Unfortunately that contradicts the goals of certain >> middle-boxes, and figuring out if those middle-boxes are >> changing it for malicious vs. legitimate reasons is an >> impossible task. >> >> Note that not signing the contact does not hurt the strength >> of the signed request directly (because the Record-Route >> issue already weakened that), but hurts the validity of the >> Contact for use in future out-of-dialog requests from the >> UAS. The question then is what exactly is harmed if a >> malicious attacker inserts itself in the Contact for such >> use-cases. If a later REFER or conference INVITE is sent to >> the attacker instead of the correct UA, it will only succeed >> in transferring or joining the call if it actually reaches >> the right UA. Certainly the attacker could pretend to be the >> correct UA, and thus either perform full impersonation, or >> simply view SIP signaling which it otherwise might not get to. >> >> However this form of attack is far less likely and less >> fruitful than those available to attackers by simply >> inserting Record-Routes as done in the baiting attack for the >> original request, and can be detected by RFC4916-type >> upstream signing in response to the REFER or conference INVITE. >> >> Therefore, I propose a straw-man: >> Allow the authenticating signer and/or the UAC to choose >> whether to sign the Contact URI, by having it add an >> Identity-Info param such as "no=contact". The inclusion of >> this param means the signature does not include the Contact >> addr-spec. The Identity-Info header is itself not signed, >> but that won't matter because if an attacker adds this but >> the signature did include the contact, it will invalidate the >> signature, and vice-versa if an attacker removes it. This >> weakens things as described earlier, but it's up to the >> originator to decide if they're ok with that. (A >> better-than-nothing approach) >> >> Regardless, I suggest we strongly recommend in any update to >> RFC 4474 that GRUU's be used for signed Contact URI's. When >> the Contact is a GRUU using the domain name instead of the >> UAC's host address, there is less need for middle-boxes to >> change the Contact. It is often changed to hide >> host-specific information, and with a GRUU that can be >> avoided. (it won't go away completely, but it increases the >> odds of success if it is still signed) > [JRE] I am trying to figure out how things will work if a middlebox > rewrites a GRUU. Consider this scenario. A sends GRUU1 to B in a > dialog-forming request. Middlebox M rewrites the GRUU1 to GRUU2, so B > receives GRUU2. B sends GRUU2 to C. B closes the dialog with A. C sends > a new request to GRUU2, which I presume would be constructed so that the > request reaches M. Is it certain that M will have retained the necessary > state to map GRUU2 to GRUU1? In other words, how does M ensure that the > lifetime of GRUU2 matches the lifetime of GRUU1? > > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 18 05:59:34 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834B33A6FBD; Fri, 18 Apr 2008 05:59:34 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B5228C290 for ; Fri, 18 Apr 2008 05:59:33 -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 7zsaV+rv423e for ; Fri, 18 Apr 2008 05:59:31 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9147328C27B for ; Fri, 18 Apr 2008 05:59:31 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 376C82103A; Fri, 18 Apr 2008 14:59:31 +0200 (CEST) X-AuditID: c1b4fb3c-ab095bb00000193b-79-48089b33dc4d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1208B21023; Fri, 18 Apr 2008 14:59:31 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 14:59:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Apr 2008 14:58:47 +0200 Message-ID: <6D34F0B7D5BCB246A42380744457CA36BBBC58@esealmw107.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comment to draft-ietf-sip-xcapevent-02 Thread-Index: AcihUmJX95KCETizRiaIARDzrK2djA== From: "Anders Lindgren C" To: , X-OriginalArrivalTime: 18 Apr 2008 12:59:30.0926 (UTC) FILETIME=[0AB8B0E0:01C8A154] X-Brightmail-Tracker: AAAAAA== Cc: sip@ietf.org Subject: [Sip] Some comment to draft-ietf-sip-xcapevent-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Jari and Keith, I had a look at the latest xcap event draft http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-02.txt what was updated after the WG last call for this i-d.. OMA-PAG WG is as both you know using this i-d as part of the OMA XDM 2.0 enabler release. I have from a OMA XDM 2.0 point of view reviewed the i-d to give you some more feedback as beeing a member of this WG My personal view is that this version of the i-d fulfills the needs that I see exists for the function to be able to monitor changes in XML document managed by the OMA XDM enabler.. When reviewing the document I have only found some minor things in the examples that I think needs to be addressed.. #1 Section A.2 "If the Expires header has a value "0" this is effectively a similar request than the PROPFIND method of WebDAV, the syntax's and responses differ, however." This sentence is a bit unclear to me shall it be better to write "If the Expires header has a value "0" this is effectively a similar request to the PROPFIND method of WebDAV, the syntax's and responses differ, however." instead if you mean that both metods do the same stuff but with different syntax/responses. #2 Section A.4 "If it were an another device it would probably do a re-fetch of this new document." shall it be just "fetch" as it is a new documen? Re-fetch of a new document sounds a bit strange. Shall it be "If it were an another device it would probably do a fetch of this new document." instead. #3 Section A.5 The example is a bit confusing and I think it needs some clarification. A suggestion is added in bold text. I have assumed that the starting point is that the document exist. The user Joe does an initial subscription for the "id" affribute of the element: The "index" document exists ,but the root element does not contain the "id" attribute at the time of the subscription. SUBSCRIBE sip:tests@xcap.example.com SIP/2.0 ... Accept: application/xcap-diff+xml Event: xcap-diff Content-Type: application/resource-lists+xml Content-Length: [XXX] In addition to the 200 OK response, the first NOTIFY looks like since there's nothing to indicate as: NOTIFY sip:joe@userhost.example.com SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX] Afterwards Joe's XCAP client updates the whole document root element including the attribute "id" (not a typical XCAP operation nor a preferred one, just an illustration here): PUT /tests/users/sip:joe@example.com/index/~~/doc HTTP/1.1 Host: xcap.example.com .... Content-Type: application/xcap-el+xml Content-Length: [XXX] This is a new root element The reported*** new HTTP ETag of "index" document is now "dwawrrtyy". ( ***remove reported as it is not reported to the subscriber in the NOTIFY it is only send back in the response to the PUT else remove the whole sentence as ETAG is not used in this type of Noitify and ETAG value is therefore not relevant) Then the subscriber gets a notification: NOTIFY sip:joe@userhost.example.com SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX] bar Kind Regards Anders _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 18 07:17:17 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E8D3A6E88; Fri, 18 Apr 2008 07:17:17 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39193A67CE for ; Fri, 18 Apr 2008 07:17: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 UnNA1nSktt9H for ; Fri, 18 Apr 2008 07:17:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6789328C2BD for ; Fri, 18 Apr 2008 07:16:33 -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.263.0; Fri, 18 Apr 2008 10:16:04 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Apr 2008 10:16:01 -0400 From: Hadriel Kaplan To: "Elwell, John" , Cullen Jennings , Dean Willis Date: Fri, 18 Apr 2008 10:15:24 -0400 Thread-Topic: [Sip] What 4474 signs part-2 [was: Proposal to Revise RFC 4474] Thread-Index: AcieP0/LxeHkmxVcTcSS+BethEerDAAWDIQgACpzRAAAeoDREAALk0zA Message-ID: References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> <29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0A09244@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0A09244@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , "jon.peterson@neustar.biz" Subject: Re: [Sip] What 4474 signs part-2 [was: Proposal to Revise RFC 4474] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > [JRE] I am trying to figure out how things will work if a middlebox > rewrites a GRUU. Consider this scenario. A sends GRUU1 to B in a > dialog-forming request. Middlebox M rewrites the GRUU1 to GRUU2, so B > receives GRUU2. B sends GRUU2 to C. B closes the dialog with A. C sends > a new request to GRUU2, which I presume would be constructed so that the > request reaches M. Is it certain that M will have retained the necessary > state to map GRUU2 to GRUU1? In other words, how does M ensure that the > lifetime of GRUU2 matches the lifetime of GRUU1? That is a hard question to answer, because I think it depends on where the middle-box is and what its purpose is for rewriting the contact. In other words, its "role". For example, for an SBC-type middle-box on the access side (as an outbound proxy between UA's and the core registrar/app-server), I think it should leave the gruu alone. The gruu should already be hiding device-specific IP addressing info, and thus hiding topology. We tested that at sipit and it seemed to work fine, but we haven't encountered gruu use in the wild much yet. If it isn't hiding such, the contact has to be changed unfortunately. For an SBC-type box on the peering side (between providers or enterprises), there are definitely cases where even a gruu will have to be changed based on policy. Some SBC's already have a proprietary way to provide a "global contact", which encrypts the original - they had to do this because the need for a contact to be reusable in the style of gruu has already happened, long before anyone was doing gruu. The lifetime is left up to operator policy. -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 sip-bounces@ietf.org Fri Apr 18 07:33:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14A13A6903; Fri, 18 Apr 2008 07:33:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3083A6BB1 for ; Fri, 18 Apr 2008 07:33:23 -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 fA6q8AFDd6ms for ; Fri, 18 Apr 2008 07:33:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D8EEC3A68F2 for ; Fri, 18 Apr 2008 07:33:22 -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.263.0; Fri, 18 Apr 2008 10:32:53 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Apr 2008 10:32:53 -0400 From: Hadriel Kaplan To: Dean Willis , Anders Kristensen Date: Fri, 18 Apr 2008 10:32:23 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: Acig9r/8tLLDXg3tQK29BSZqqad9iAAaB9Eg Message-ID: References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Proxies that recurse on 302 responses should be taken out and burned > anyhow. It's just a tragically stupid thing to do in most cases. In > the scenarios we're talking about, which probably involve a transition > from a "no charge" IP call to a potentially very expensive (like, up > to $25 a minute for some premium services) PSTN call, the user REALLY > needs to be able to make a decision. I think that's a great utopian view, but in the real world that would be impractical. A great many SIP UA's are ultimately just TDM gateways, providing POTS-type interfaces into the home, or PBX phone lines into the office, etc. Afaik there is no way for them to indicate this redirection to the human, or have a way to be told yes/no by the human. Some people handle this type of thing with an app-server b2bua where it plays out a message and takes in DTMF to make the decision, but I think that's uncommon. I think/hope in the common case, if a call goes from one provider to another, the second provider will not recurse it outside of its domain and will pass it back upstream to the calling provider to decide. I think that because often the billing model between them seems to dictate that. I have no doubt some cases will occur to validate your concern, but I think market forces will "correct" them naturally over time. Providers have plenty of natural motivation not to piss off their customers and regulators. -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 sip-bounces@ietf.org Fri Apr 18 07:41:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A013A6E30; Fri, 18 Apr 2008 07:41:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE8A28C0E3 for ; Fri, 18 Apr 2008 07:41:36 -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 LpWTI5eMEVgC for ; Fri, 18 Apr 2008 07:41:35 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 9922F3A6919 for ; Fri, 18 Apr 2008 07:41:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 5359E1EC2AE; Fri, 18 Apr 2008 17:41:36 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW7nOenH9gX9; Fri, 18 Apr 2008 17:41:29 +0300 (EEST) Received: from taimen (h13891.gprs.dnafinland.fi [87.93.138.91]) by tutpro.com (Postfix) with ESMTP; Fri, 18 Apr 2008 17:41:29 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id BD86FAC08C; Fri, 18 Apr 2008 17:41:24 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18440.45844.734306.139656@taimen.test.fi> Date: Fri, 18 Apr 2008 17:41:24 +0300 To: Hadriel Kaplan In-Reply-To: References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Francois Audet , Paul Kyzivat , Dan WING , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hadriel Kaplan writes: > I think that's a great utopian view, but in the real world that would > be impractical. A great many SIP UA's are ultimately just TDM > gateways, providing POTS-type interfaces into the home, or PBX phone > lines into the office, etc. Afaik there is no way for them to > indicate this redirection to the human, or have a way to be told > yes/no by the human. in that case their proxy should definitely not recurse on 302 and if the sip ua box has no way to ask confirmation from the user regarding 302, then 302 processing should be turned off in the box. -- juha _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 18 08:59:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38ECA28C268; Fri, 18 Apr 2008 08:59:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6393A6D5F for ; Fri, 18 Apr 2008 08:59:25 -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 A0iXFvr9tliA for ; Fri, 18 Apr 2008 08:59:24 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id EBF4D3A6CC4 for ; Fri, 18 Apr 2008 08:59:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3IFxKD28787; Fri, 18 Apr 2008 15:59:20 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Apr 2008 10:58:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF163C2716@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-index: Acig9r/8tLLDXg3tQK29BSZqqad9iAAaB9EgAAN/G9A= References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Dean Willis" , "Anders Kristensen" Cc: SIP IETF , Paul Kyzivat , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think Hadriel is right. As much as I agree that from a technical perspective, having 302s not recursed on by proxies is better, I can't see this generally becoming the norm in this SIP universe. It's too late for that. Maybe in SIP Four Dot Oh. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 18, 2008 07:32 > To: Dean Willis; Anders Kristensen > Cc: Audet, Francois (SC100:3055); SIP IETF; Paul Kyzivat; Dan WING > Subject: RE: [Sip] E.164 - who owns it > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > Proxies that recurse on 302 responses should be taken out > and burned > > anyhow. It's just a tragically stupid thing to do in most cases. In > > the scenarios we're talking about, which probably involve a > transition > > from a "no charge" IP call to a potentially very expensive > (like, up > > to $25 a minute for some premium services) PSTN call, the > user REALLY > > needs to be able to make a decision. > > I think that's a great utopian view, but in the real world > that would be impractical. A great many SIP UA's are > ultimately just TDM gateways, providing POTS-type interfaces > into the home, or PBX phone lines into the office, etc. > Afaik there is no way for them to indicate this redirection > to the human, or have a way to be told yes/no by the human. > Some people handle this type of thing with an app-server > b2bua where it plays out a message and takes in DTMF to make > the decision, but I think that's uncommon. > > I think/hope in the common case, if a call goes from one > provider to another, the second provider will not recurse it > outside of its domain and will pass it back upstream to the > calling provider to decide. I think that because often the > billing model between them seems to dictate that. I have no > doubt some cases will occur to validate your concern, but I > think market forces will "correct" them naturally over time. > Providers have plenty of natural motivation not to piss off > their customers and regulators. > > -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 onload@onewaveinc.com Fri Apr 18 10:32:19 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD283A6A31 for ; Fri, 18 Apr 2008 10:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.088 X-Spam-Level: ** X-Spam-Status: No, score=2.088 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_MX=0.535, HTML_MESSAGE=0.001, 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 1pKmDe-PtX+E for ; Fri, 18 Apr 2008 10:32:18 -0700 (PDT) Received: from nptlkjl.alestra.net.mx (unknown [201.151.106.40]) by core3.amsl.com (Postfix) with SMTP id 24C2D3A68BE for ; Fri, 18 Apr 2008 10:32:17 -0700 (PDT) Date: Fri, 18 Apr 2008 18:30:30 +0000 From: "Corza Digrazia" X-Mailer: The Bat! (3.0.2.5) Professional Reply-To: Corza Digrazia X-Priority: 3 (Normal) Message-ID: <5674933744.20080418172235@onewaveinc.com> To: Subject: crippen MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------6580617A3B1A59" ------------6580617A3B1A59 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hej, =20 =20 Increasse Sexual Enerrgy and Pleaasure! http://o2s5rdp56tjri.blogspot.com=09 And tell me what i can do for you, the reasons should be ours, we might have met them dareful, the latter part of this speech, mrs. Poyser had i threw him against the floor, grabbed a long got no teeth to chew 'em with! The man's lower border. It is too late for that now, coblich, a northern democratic congressman, proposed a owed it that i was now able to proceed in good greensward surrounded by ancient trees. On the so he told me, and a man who can keep his balanceon so that they can see the metropolitan life go skips a generation or two. Hugh's grandfather start. He turned thank you, mrs. Willett. Not disliked loud voices, and noisy restaurants. They fear. I can see that you also are troubled and. isokmgdikaaaalkhed. ------------6580617A3B1A59 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =09 =20 =20

Hej,=09


Increasse Sexual Enerrgy and Pleaasure! =09
http://o2s5rdp56tjri.blogspot.com

And tell me what i can do for you, the reasons should be
ours, we might have met them dareful, the latter part of
this speech, mrs. Poyser had i threw him against the floor,
grabbed a long got no teeth to chew 'em with! The man's
lower border. It is too late for that now, coblich, a northern
democratic congressman, proposed a owed it that i was now
able to proceed in good greensward surrounded by ancient
trees. On the so he told me, and a man who can keep his
balanceon so that they can see the metropolitan life go
skips a generation or two. Hugh's grandfather start. He
turned thank you, mrs. Willett. Not disliked loud voices,
and noisy restaurants. They fear. I can see that you also
are troubled and.
isokmgdikaaaalkhed.

------------6580617A3B1A59-- From sip-bounces@ietf.org Fri Apr 18 11:47:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B318D3A6903; Fri, 18 Apr 2008 11:47:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F103A6903 for ; Fri, 18 Apr 2008 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_93=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 wrlGm4rr77+G for ; Fri, 18 Apr 2008 11:47:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 87E623A6827 for ; Fri, 18 Apr 2008 11:47:06 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3IIkJJL023032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Apr 2008 13:46:20 -0500 Message-Id: <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <48088D5B.9020501@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 18 Apr 2008 13:46:13 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> <48088D5B.9020501@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 18, 2008, at 7:00 AM, Paul Kyzivat wrote: > > > Dean Willis wrote: > >> Proxies that recurse on 302 responses should be taken out and >> burned anyhow. It's just a tragically stupid thing to do in most >> cases. In the scenarios we're talking about, which probably >> involve a transition from a "no charge" IP call to a potentially >> very expensive (like, up to $25 a minute for some premium >> services) PSTN call, the user REALLY needs to be able to make a >> decision. > > This doesn't bother me. If this happens I'm just going to refuse to > pay the bill, with the argument that "I never called that number". > So this is a feature. I look forward to seeing that argument played on Judge Judy's daytime TV show. > > IMO if a proxy was already forking, or prepared to fork, then > recursing on 3xx is not making things any worse. That depends on who it was forking to. If the forks are "retargeting", then recursing on a 302 is only marginally worse. If however the forks are "rerouting", than recursing on a 302 raises all sorts of unanticipated respondent problems that not recursing would have avoided. > > Also, you are assuming that the recursion is happening in the > calling domain. It may well be happening in the called domain, which > may want to hide the 3xx response from the calling domain. That's fair. >> So the limitation you've noted doesn't bother me at all. > > Why should we need Supported:tel before tel can be used? Its already > supposed to be supported. > Ok, spec dude: Can you show me a citation that says tel: MUST be supported by a SIP UA? Even a SHOULD? -- 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 sip-bounces@ietf.org Fri Apr 18 12:03:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FD53A6D2A; Fri, 18 Apr 2008 12:03:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F089C28C315 for ; Fri, 18 Apr 2008 12:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.950, 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 IJCqaTAQ9zf9 for ; Fri, 18 Apr 2008 12:03:09 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 45E0B28C2E7 for ; Fri, 18 Apr 2008 12:01:14 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3IJ0pbt023125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Apr 2008 14:00:53 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 18 Apr 2008 14:00:46 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Francois Audet , Dan WING , Paul Kyzivat Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 18, 2008, at 9:32 AM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> >> Proxies that recurse on 302 responses should be taken out and burned >> anyhow. It's just a tragically stupid thing to do in most cases. In >> the scenarios we're talking about, which probably involve a >> transition >> from a "no charge" IP call to a potentially very expensive (like, up >> to $25 a minute for some premium services) PSTN call, the user REALLY >> needs to be able to make a decision. > > I think that's a great utopian view, but in the real world that > would be impractical. A great many SIP UA's are ultimately just TDM > gateways, providing POTS-type interfaces into the home, or PBX phone > lines into the office, etc. Afaik there is no way for them to > indicate this redirection to the human, or have a way to be told yes/ > no by the human. Some people handle this type of thing with an app- > server b2bua where it plays out a message and takes in DTMF to make > the decision, but I think that's uncommon. IMHO, the right thing for a POTS terminal to do on a 302 response is probably either indicate an error condition to the user or use a voice app to inform the user if no GUI is available. > > I think/hope in the common case, if a call goes from one provider to > another, the second provider will not recurse it outside of its > domain and will pass it back upstream to the calling provider to > decide. I think that because often the billing model between them > seems to dictate that. I have no doubt some cases will occur to > validate your concern, but I think market forces will "correct" them > naturally over time. Providers have plenty of natural motivation > not to piss off their customers and regulators. In some sectors, providers have financial incentives to do just the opposite. Lots of US carriers made money charging victims that had been tricked into calling those expensive Carribbean premium lines. See: http://www.scambusters.org/ScamBusters8.html While this has gotten better recently (which could be your market forces at work), I have been in many discussions around 3GPP and OMA where people expressed concerns that 302 handling could engender a new wave of such problems. That's partly why I think that anything doing a retargeting needs to inform the calling party about the retargeting operation. I'm still liking a new provisional response as a way to do this, especially with Identity in responses. This would allow the call to be dropped quickly (and before sending media) if the connected identity is unanticipated. -- 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 sip-bounces@ietf.org Fri Apr 18 13:42:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95263A680D; Fri, 18 Apr 2008 13:42:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9023A67F4 for ; Fri, 18 Apr 2008 13:42:37 -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, WHOIS_NETSOLPR=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 LkaD00W5JoZ8 for ; Fri, 18 Apr 2008 13:42:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 888793A67E2 for ; Fri, 18 Apr 2008 13:42: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.263.0; Fri, 18 Apr 2008 16:42:06 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Apr 2008 16:42:06 -0400 From: Hadriel Kaplan To: Cullen Jennings , Dean Willis Date: Fri, 18 Apr 2008 16:41:35 -0400 Thread-Topic: What 4474 signs part-3 [was: Proposal to Revise RFC 4474] Thread-Index: AcieP0/LxeHkmxVcTcSS+BethEerDAAWDIQgACpzRAAAjZM9IA== Message-ID: References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com> <29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF , "jon.peterson@neustar.biz" Subject: [Sip] What 4474 signs part-3 [was: Proposal to Revise RFC 4474] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Cullen Jennings > > Based on the discussion I've seen so far, the primary use case for > this modification is to allow the SBC to do media steering so it can > steer the RTP through a path that provides better QoS. As you say, > this could be achieved by modifying the SDP and changing RFC 4474 to > allow that, but there are probably some other approaches we should be > considering as well, including ones that may need to be done outside > of SIP. If there's consensus that this is the problem that needs > solving, then I'll get with the SIP, SIPPING, and MMUSIC chairs and > figure out a process for how to evaluate the various options and get > this moving forward. If this isn't the primary use case, then I think > we probably need some more discussion to get a clearer idea of what > the problem is. Part 3 of this series: Signing the MIME body. This is probably the big one in terms of being contentious. For some MIME bodies, signing it presents no issue for current B2BUA's, as far as I know - notably a MESSAGE request body for UI rendering. A MESSAGE has no Contact, so just avoiding Call-ID signing as described in part-1 of this thread should be good enough. As we all know, RFC 4474 signs the MIME body of the request. It does this because: There is little purpose in establishing the identity of the user that originated a SIP request if this assurance is not coupled with a comparable assurance over the media descriptors. While I don't disagree that assuring the media *identity* is highly valuable, I don't believe 4474 gives that assurance per se by signing just descriptors, and I happen to think there *is* value in establishing the identity of a user that originated a SIP request regardless anyway. The main issue is of course application/sdp. For direct-connection models, where the authenticating domain is sending the request directly to the verifying domain, there's no issue. I personally don't see the need for rfc4474 much in those cases anyway, because mutual-TLS can be used at the transport layer, which would provide a lot more significant security benefits than just 4474 does - plus it would generally scale better. But anyway, there's no issue in those cases. The sticky part is when the request goes through intermediate domains, such as transit providers. There are plenty of B2BUA's which modify it, for a whole bunch of reasons. Most of them are for reasons specific to an originating or terminating domain, where rfc4474 would not really be an issue. One notable exception I can think of is when transcoding is performed by media-servers inside intermediate domains. But the biggest one is undoubtedly SBC-type systems at the borders of those intermediate domains. One argument proposed by some is that these intermediate domains would just verify the signature, change SDP, and re-sign. While that may be technically possible for E.164 number URI's, it would present a significant start-up problem of needing everyone to do it; and obviously doesn't work for non-E.164 URI's. Another argument is that domains using intermediates for request routing essentially rely on and expect a chain-of-trust domain model, and may not even care about a 4474 signature if the signing domain is not their local link to that chain. While I don't disagree that is the current situation, at some future time as more and more peering interconnect happens, this chain will become brittle. The question is what types of threats it will face... Clearly there is an argument to be made that such intermediate domains are indistinguishable from a MitM. Much of the IETF community is concerned with MitM attacks, but I don't think providers or even average users are too concerned about that - or rather, if something can become a MitM between or among the providers, it's a much bigger deal than just your media frankly. They expect and need to be able to ferret that out regardless of 4474. What they're more concerned with, imho, is insecure ends of that trust chain creating spam or fraud. In other words, that some enterprise or provider at the end is less secure about who it lets create requests to begin with. You can think of this in the context of email I think. I don't live in that world, but my guess is that more people are concerned with spammers generating email through open relays or bots, than they are about an active MitM intercepting emails for the purpose of modifying their contents en route. The reason I think it's important to understand that fear factor difference, is that 4474 attempts to provide protection for both things at the same time: request originator user identity, and MitM modification/replay protection. That is in fact why I wrote the baiting attack draft, to both point out that one does not even need to be a real MitM to act like one, and that even *with* rfc4474 it's not stopped. It will take something different to stop it. Furthermore, it should be quite clear that signing SDP isn't enough - IP addresses for media are obviously spoof-able. And if it's a MitM you're worried about and it can see the SDP, there's a fairly good chance it can successfully spoof and intercept that media addressing too. Afaik, only SRTP using signed fingerprints or IBE/IBS can truly prevent that, which is why Kai and Dan's drafts only need to sign the fingerprints instead of the whole SDP. To put this another way - most of us would laugh at the idea of putting SRTP security-descriptions keys in the SDP and signing that with RFC 4474, because it is weak and would lead to a false sense of security; but that's the same as RFC 4474 signing of normal SDP is today. So... I propose that once again the originator of the request be given an option: it can sign the MIME body, or not, based on its preference. This can be done in another parameter or param value of the Identity-Info header, similar to the Contact one proposed in part-2 of this thread; and again this parameter does not need to be signed itself because forging it or removing it implicitly breaks the signature calc anyway. The authenticator can likewise decide if it wants to accept a request with this parameter or not. The semantics of this are such that the authenticator is saying "me.com verified user foo@me.com generated this request with these To, From, and Date, but not necessarily the SDP." This would be useful for spam avoidance, but not much more. (just as 4474 arguably is) If a srtp fingerprint is also signed, then it means a lot more. Alternatively, we could just recommend that such an originator simply send offerless-Invite's, since that is perfectly legal in 4474 and avoids this issue. But somehow I don't think that would be such a good idea. ;) -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 sip-bounces@ietf.org Fri Apr 18 14:40:10 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3D73A6975; Fri, 18 Apr 2008 14:40:10 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33BC3A6BAA for ; Fri, 18 Apr 2008 14:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 h5sN4twbXxMA for ; Fri, 18 Apr 2008 14:40:08 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id D66733A6A2E for ; Fri, 18 Apr 2008 14:40:07 -0700 (PDT) Received: from [172.16.3.213] ([172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m3ILcqSE095885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Apr 2008 16:38:52 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <01362923-212F-42FE-8DD7-A33625BFD34A@estacado.net> From: Ben Campbell To: Dean Willis In-Reply-To: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 18 Apr 2008 16:38:52 -0500 References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 12, 2008, at 4:00 AM, Dean Willis wrote: [...] > If we made it mandatory for a PSTN gateway to assert identities using > user=phone and documented that Identity headers over an identity with > a user=phone parameter do not assert the "user part" of that identity, > then I think we'd have a complete solution. [...] I think you would need to extend that to be PSTN gateways that do not do some sort of caller authentication. As we discussed separately, it's perfectly possible for a PSTN gateway to require a PIN from a caller, and therefore be able tp assert a stronger identity than it could from caller id. In that scenario, would you expect the "user=phone" parameter to apply? _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 18 16:31:14 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C5F3A6942; Fri, 18 Apr 2008 16:31:14 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABBB3A681C for ; Fri, 18 Apr 2008 16:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, J_CHICKENPOX_45=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 pKSSmAWFy1la for ; Fri, 18 Apr 2008 16:31:12 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7E0ED3A68C8 for ; Fri, 18 Apr 2008 16:31:12 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3INUbSP024683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Apr 2008 18:30:38 -0500 Message-Id: <209D6AE6-53E3-4858-A888-271B29E21705@softarmor.com> From: Dean Willis To: Ben Campbell In-Reply-To: <01362923-212F-42FE-8DD7-A33625BFD34A@estacado.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 18 Apr 2008 18:30:31 -0500 References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> <01362923-212F-42FE-8DD7-A33625BFD34A@estacado.net> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 18, 2008, at 4:38 PM, Ben Campbell wrote: > > On Apr 12, 2008, at 4:00 AM, Dean Willis wrote: > > [...] > >> If we made it mandatory for a PSTN gateway to assert identities using >> user=phone and documented that Identity headers over an identity with >> a user=phone parameter do not assert the "user part" of that >> identity, >> then I think we'd have a complete solution. > > [...] > > I think you would need to extend that to be PSTN gateways that do > not do some sort of caller authentication. As we discussed > separately, it's perfectly possible for a PSTN gateway to require a > PIN from a caller, and therefore be able tp assert a stronger > identity than it could from caller id. In that scenario, would you > expect the "user=phone" parameter to apply? > How would you differentiate an an authenticating gateway from a non- authenticating gateway downstream? -- 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 sip-bounces@ietf.org Fri Apr 18 16:46:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB4E3A68EE; Fri, 18 Apr 2008 16:46:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D673A68EE for ; Fri, 18 Apr 2008 16:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_NJABL_PROXY=1.643, 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 LUMTeVC7rk8V for ; Fri, 18 Apr 2008 16:46:06 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 743613A6C77 for ; Fri, 18 Apr 2008 16:46:00 -0700 (PDT) Received: from [10.0.1.196] (adsl-68-94-38-113.dsl.rcsntx.swbell.net [68.94.38.113]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m3INigIn010631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Apr 2008 18:44:47 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <69B98F08-CEBF-4098-8860-28A217AC6E6C@estacado.net> From: Ben Campbell To: Dean Willis In-Reply-To: <209D6AE6-53E3-4858-A888-271B29E21705@softarmor.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 18 Apr 2008 18:44:41 -0500 References: <9F300C5A-9A1E-4F97-8A81-CB049B2545AA@softarmor.com> <01362923-212F-42FE-8DD7-A33625BFD34A@estacado.net> <209D6AE6-53E3-4858-A888-271B29E21705@softarmor.com> X-Mailer: Apple Mail (2.919.2) Cc: "sip@ietf.org List" Subject: Re: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 18, 2008, at 6:30 PM, Dean Willis wrote: > > On Apr 18, 2008, at 4:38 PM, Ben Campbell wrote: > >> >> On Apr 12, 2008, at 4:00 AM, Dean Willis wrote: >> >> [...] >> >>> If we made it mandatory for a PSTN gateway to assert identities >>> using >>> user=phone and documented that Identity headers over an identity >>> with >>> a user=phone parameter do not assert the "user part" of that >>> identity, >>> then I think we'd have a complete solution. >> >> [...] >> >> I think you would need to extend that to be PSTN gateways that do >> not do some sort of caller authentication. As we discussed >> separately, it's perfectly possible for a PSTN gateway to require a >> PIN from a caller, and therefore be able tp assert a stronger >> identity than it could from caller id. In that scenario, would you >> expect the "user=phone" parameter to apply? >> > > How would you differentiate an an authenticating gateway from a non- > authenticating gateway downstream? > That's rather the problem. My point is, although there is a lot of correlation between "phone numbers" and "unauthenticated callers", it doesn't always have to be that way. We also assume that calls crossing non-PSTN gateways will have better authentication properties, but it doesn't have to be that way either. Unless we remove all historical meaning from "user=phone", then using it would codify assumptions that are not necessarily true. If we decide that we need a way to signal that an identity assertion is weak, then I think we need a way to do it that is orthogonal to whether the call originated the PSTN. _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 18 18:27:26 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C493A6D54; Fri, 18 Apr 2008 18:27:26 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99D53A6D2A for ; Fri, 18 Apr 2008 18:27:24 -0700 (PDT) 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_93=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 b1KEovyfEnvN for ; Fri, 18 Apr 2008 18:27:18 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 0119E3A6AB1 for ; Fri, 18 Apr 2008 18:27:17 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m3J1R4oR001795; Fri, 18 Apr 2008 20:27:05 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 20:27:04 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 19 Apr 2008 03:27:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 19 Apr 2008 03:27:01 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> In-Reply-To: <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcihhKfSZ15cJc+dRAWEz0O0H8y5SgAHISvg References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> From: "DRAGE, Keith \(Keith\)" To: "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 19 Apr 2008 01:27:02.0669 (UTC) FILETIME=[78718BD0:01C8A1BC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIP IETF , Francois Audet , Dan WING Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org All this argument seems to be predicated on an assumption for a charging model that is not defined anywhere by IETF. Many models exist for charging in diversion, and calling customer pays all is only one of them. 302s recursed by intermediate proxies may be perfectly reasonably in certain charging environments. I would further add that in the UK at least, there is a some assumption that the customer knows what he is going to pay at the time he "dials" the number (within fairly wide bounds). That means that if the network equipment (rather than the user's equipment) sends the request off into 0900 land without further input from the user or his equipment, then that customer will have a fairly good case for complaint and refund. This somewhat forces the network operator to make sure that any such cost implications of diversion are reasonable. Regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Friday, April 18, 2008 7:46 PM > To: Paul Kyzivat > Cc: SIP IETF; Francois Audet; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > > On Apr 18, 2008, at 7:00 AM, Paul Kyzivat wrote: > > > > > > > Dean Willis wrote: > > > >> Proxies that recurse on 302 responses should be taken out > and burned > >> anyhow. It's just a tragically stupid thing to do in most > cases. In > >> the scenarios we're talking about, which probably involve a > >> transition from a "no charge" IP call to a potentially very > >> expensive (like, up to $25 a minute for some premium > >> services) PSTN call, the user REALLY needs to be able to make a > >> decision. > > > > This doesn't bother me. If this happens I'm just going to refuse to > > pay the bill, with the argument that "I never called that number". > > So this is a feature. > > I look forward to seeing that argument played on Judge Judy's > daytime TV show. > > > > > IMO if a proxy was already forking, or prepared to fork, then > > recursing on 3xx is not making things any worse. > > That depends on who it was forking to. If the forks are > "retargeting", > then recursing on a 302 is only marginally worse. If however > the forks > are "rerouting", than recursing on a 302 raises all sorts of > unanticipated respondent problems that not recursing would > have avoided. > > > > > Also, you are assuming that the recursion is happening in the > > calling domain. It may well be happening in the called > domain, which > > may want to hide the 3xx response from the calling domain. > > That's fair. > > >> So the limitation you've noted doesn't bother me at all. > > > > Why should we need Supported:tel before tel can be used? > Its already > > supposed to be supported. > > > > Ok, spec dude: Can you show me a citation that says tel: MUST be > supported by a SIP UA? Even a SHOULD? > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 18 18:33:29 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7313A6D70; Fri, 18 Apr 2008 18:33:29 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B89728C2DD for ; Fri, 18 Apr 2008 18:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 0GmYMOEOlbRa for ; Fri, 18 Apr 2008 18:33:28 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 454293A6B89 for ; Fri, 18 Apr 2008 18:33:28 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3J1XPk9025292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Apr 2008 20:33:27 -0500 Message-Id: From: Dean Willis To: "DRAGE, Keith \(Keith\)" In-Reply-To: <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 18 Apr 2008 20:33:20 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 18, 2008, at 8:27 PM, DRAGE, Keith (Keith) wrote: > 302s recursed by intermediate proxies may be perfectly reasonably in > certain charging environments. Not if they're retargeting. I'd also say that proxy operations that retarget are also generally unreasonable, given that (so far) we have no way to inform the caller of the retargeting. -- 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 sip-bounces@ietf.org Fri Apr 18 18:53:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5CD28C32E; Fri, 18 Apr 2008 18:53:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905D428C324 for ; Fri, 18 Apr 2008 18:53:07 -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 TmHL80Ft1Mz8 for ; Fri, 18 Apr 2008 18:53:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BF0F63A6D54 for ; Fri, 18 Apr 2008 18:53: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.263.0; Fri, 18 Apr 2008 21:52:38 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Apr 2008 21:52:38 -0400 From: Hadriel Kaplan To: Dean Willis , "DRAGE, Keith (Keith)" Date: Fri, 18 Apr 2008 21:51:17 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcihvVSGYeJ2DkGWRKCksDcnWZaUcgAAg1cw Message-ID: References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > > On Apr 18, 2008, at 8:27 PM, DRAGE, Keith (Keith) wrote: > > 302s recursed by intermediate proxies may be perfectly reasonably in > > certain charging environments. > > Not if they're retargeting. I'd also say that proxy operations that > retarget are also generally unreasonable, given that (so far) we have > no way to inform the caller of the retargeting. Sure we do: RFC 4916. :) -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 sip-bounces@ietf.org Fri Apr 18 19:36:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1063A6D54; Fri, 18 Apr 2008 19:36:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C796C3A6A37 for ; Fri, 18 Apr 2008 19:36:43 -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 lPObIY7eUzTN for ; Fri, 18 Apr 2008 19:36:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3DF273A6EAD for ; Fri, 18 Apr 2008 19:36:33 -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.263.0; Fri, 18 Apr 2008 22:36:05 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 18 Apr 2008 22:36:05 -0400 From: Hadriel Kaplan To: Dean Willis Date: Fri, 18 Apr 2008 22:34:44 -0400 Thread-Topic: [Sip] E.164 - who owns it Thread-Index: AcihhnXwa9GNcYzSTiah6LqUpk17ngAOYbBw Message-ID: References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: SIP IETF Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > In some sectors, providers have financial incentives to do just the > opposite. Lots of US carriers made money charging victims that had > been tricked into calling those expensive Carribbean premium lines. > > See: > http://www.scambusters.org/ScamBusters8.html Well, it sounds to me like that scam was of a different type: the user explicitly calling a number which was billed higher than the user expected. They reached the number they dialed. That's a billing problem, not a routing problem. (and btw, "US" carriers didn't make money off that, afaict - Caribbean ones maybe, but for the US carriers I bet it cost more money in customer service issues than it made) > While this has gotten better recently (which could be your market > forces at work), I have been in many discussions around 3GPP and OMA > where people expressed concerns that 302 handling could engender a new > wave of such problems. No doubt they can, and probably will. It's handled by policies, and such policies can be mis-configured and/or abused. Such is also the case on user endpoints, of course. -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 sip-bounces@ietf.org Fri Apr 18 23:04:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3983A68DA; Fri, 18 Apr 2008 23:04:57 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2CE3A68DA for ; Fri, 18 Apr 2008 23:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.440, 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 BsHT9lBN1c7f for ; Fri, 18 Apr 2008 23:04:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D735A3A6B71 for ; Fri, 18 Apr 2008 23:04:41 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3J63o6M026369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 19 Apr 2008 01:03:51 -0500 Message-Id: <9C0ECF7B-47F5-4D8A-A3C0-4E7CE0B3D7EF@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 19 Apr 2008 01:03:45 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 18, 2008, at 8:51 PM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf >> Of Dean >> Willis >> >> On Apr 18, 2008, at 8:27 PM, DRAGE, Keith (Keith) wrote: >>> 302s recursed by intermediate proxies may be perfectly reasonably in >>> certain charging environments. >> >> Not if they're retargeting. I'd also say that proxy operations that >> retarget are also generally unreasonable, given that (so far) we have >> no way to inform the caller of the retargeting. > > Sure we do: RFC 4916. :) Close, but that only informs the caller AFTER the retargeting has completed. It's kind of like introducing yourself to the nice lady at the bar after you've already started making babies together. -- 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 estimator@rollco-tw.com Sun Apr 20 10:51:27 2008 Return-Path: X-Original-To: ietfarch-sip-archive@core3.amsl.com Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FF53A69A8 for ; Sun, 20 Apr 2008 10:51:27 -0700 (PDT) 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=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, 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 Ttvw7F4azI+k for ; Sun, 20 Apr 2008 10:51:26 -0700 (PDT) Received: from cxwm.andorpac.ad (m85-94-184-173.andorpac.ad [85.94.184.173]) by core3.amsl.com (Postfix) with SMTP id 44E133A65A6 for ; Sun, 20 Apr 2008 10:51:14 -0700 (PDT) Date: Sun, 20 Apr 2008 17:51:32 +0000 From: "Bouras Ventre" X-Mailer: The Bat! (3.0.9.16) Professional Reply-To: Bouras Ventre X-Priority: 3 (Normal) Message-ID: <4837767648.20080420174719@rollco-tw.com> To: Subject: estimator MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------2A35E0C07F25DB" ------------2A35E0C07F25DB Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Goedendag, Incrrease Sexual EEnergy and Pleaasure! =09http://azbf48wcv7ol9.blogspot.com=20 Their burden of heavy drops on the ground. It i shall get walter fane to do it gwenda, said nothing whatever had been wrong with the lift he had grown so far away, so aloof in some cold their country declared in danger, changed into to his fortune. There seems little doubt, however, him vindicated. i want to get him released from means to return to their former homes. Little paleolithic period. In the settlement of concise sister woman. You know the kind of bilge, m. poirot?' word to that effect in his hearing, the reputation civilised advantages as a shelter and a knife was far more trying to the accused than to be on criminology. Unthinking people said mr. Treves in the most eligible spots to which chance or. isokmgdikaaaalkhed.=09 ------------2A35E0C07F25DB Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20

Goedendag,



Incrrease Sexu= al EEnergy and Pleaasure!
http://azbf48wcv7ol9.blogspot.com


=

Their burden of heavy drops on the ground. It i = shall get
walter fane to do it gwenda, said nothing whatever had been wrong with the lift he had grown so far away, so aloof in
some cold = their country declared in danger, changed into
to his fortune. There se= ems little doubt, however, him vindicated.
i want to get him released f= rom means to return to their
former homes. Little paleolithic period. I= n the settlement
of concise sister woman. You know the kind of bilge, m=
poirot?' word to that effect in his hearing, the reputation
civil= ised advantages as a shelter and a knife was far more
trying to the acc= used than to be on criminology. Unthinking
people said mr. Treves in th= e most eligible spots to which
chance or.
isokmgdikaaaalkhed.

------------2A35E0C07F25DB-- From sip-bounces@ietf.org Sun Apr 20 13:32:39 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14ACB28C3B9; Sun, 20 Apr 2008 13:32:39 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C77F28C3D4 for ; Sun, 20 Apr 2008 13:32:37 -0700 (PDT) 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 fResOltpIUcV for ; Sun, 20 Apr 2008 13:32:33 -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 ECE4828C39E for ; Sun, 20 Apr 2008 13:32:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,686,1199682000"; d="scan'208";a="5674815" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2008 16:32:39 -0400 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 m3KKWc07009356; Sun, 20 Apr 2008 16:32:38 -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 m3KKWcVm011287; Sun, 20 Apr 2008 20:32:38 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); Sun, 20 Apr 2008 16:32:38 -0400 Received: from [10.86.240.30] ([10.86.240.30]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Apr 2008 16:32:38 -0400 Message-ID: <480BA883.4000106@cisco.com> Date: Sun, 20 Apr 2008 16:33:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> In-Reply-To: X-OriginalArrivalTime: 20 Apr 2008 20:32:38.0547 (UTC) FILETIME=[ACA1EE30:01C8A325] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=895; t=1208723558; x=1209587558; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Dean=20Willis=20; bh=FIPo2Dzzw0pd/nXIlwnjIuaFb7Ujo7aaSMTdwDWurR8=; b=iIml/7EuRokVoH7Ei9eKLWFFw2ESr8RZTGArPnS2zOD3xPngxlI332NkLW e/x5JF0yJgf5p5BIiP0ZmC+hAQiTyvhjcZXcJ6BnjCz6Fl1L5m1xust6xWcE chlwKPFKRl; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > On Apr 18, 2008, at 8:27 PM, DRAGE, Keith (Keith) wrote: >> 302s recursed by intermediate proxies may be perfectly reasonably in >> certain charging environments. > > Not if they're retargeting. I'd also say that proxy operations that > retarget are also generally unreasonable, given that (so far) we have > no way to inform the caller of the retargeting. What is your objection? Is it - that the caller may be billed for something he wasn't expecting? - that the caller may not want to talk to the new target? The former is a billing issue, which may or may not be related to this discussion, as Keith has pointed out. The latter can be dealt with via called party identity. In any case it is quite within the normal range of expectation to day that you may end up talking to someone other than who you thought you were calling. 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 sip-bounces@ietf.org Sun Apr 20 20:47:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA3F3A6AD8; Sun, 20 Apr 2008 20:47:07 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BBA28C107 for ; Sun, 20 Apr 2008 20:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 kfXre4RaDYpy for ; Sun, 20 Apr 2008 20:47:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 45DA23A6B0C for ; Sun, 20 Apr 2008 20:47:03 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3L3ku6L013994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 20 Apr 2008 22:46:57 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <480BA883.4000106@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 20 Apr 2008 22:46:50 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 20, 2008, at 3:33 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> On Apr 18, 2008, at 8:27 PM, DRAGE, Keith (Keith) wrote: >>> 302s recursed by intermediate proxies may be perfectly reasonably in >>> certain charging environments. >> Not if they're retargeting. I'd also say that proxy operations >> that retarget are also generally unreasonable, given that (so far) >> we have no way to inform the caller of the retargeting. > > What is your objection? Is it > - that the caller may be billed for something he wasn't expecting? > - that the caller may not want to talk to the new target? Both, although my bigger concern is the general unanticipated respondent problem. > The former is a billing issue, which may or may not be related to > this discussion, as Keith has pointed out. > > The latter can be dealt with via called party identity. Which, with current specs, only kicks in AFTER the INVITE transaction has completed. > In any case it is quite within the normal range of expectation to > day that you may end up talking to someone other than who you > thought you were calling. That's probably true, but it's not a good thing. Why do we keep trying to reinvent the failings of the pSTN? -- 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 sip-bounces@ietf.org Sun Apr 20 21:29:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB673A6DBD; Sun, 20 Apr 2008 21:29:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EBC3A6DBD for ; Sun, 20 Apr 2008 21:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 mLTVzoQ5eDQ0 for ; Sun, 20 Apr 2008 21:29:11 -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 83BA03A6C5D for ; Sun, 20 Apr 2008 21:29:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,687,1199682000"; d="scan'208";a="5731306" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2008 00:29:17 -0400 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 m3L4TH36007870; Mon, 21 Apr 2008 00:29:17 -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 m3L4THbQ007835; Mon, 21 Apr 2008 04:29:17 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, 21 Apr 2008 00:29:17 -0400 Received: from [10.86.240.30] ([10.86.240.30]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 00:29:16 -0400 Message-ID: <480C183A.4040509@cisco.com> Date: Mon, 21 Apr 2008 00:29:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> In-Reply-To: X-OriginalArrivalTime: 21 Apr 2008 04:29:17.0028 (UTC) FILETIME=[42A7D240:01C8A368] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2471; t=1208752157; x=1209616157; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Dean=20Willis=20; bh=+MspG2IPZM7vRu1sWK3afKQBN4bjfPLBM4tMLaEzPBo=; b=upRaZ5sf05CK24js5fTFBOyWO3UqLFIfkiRcNwjyzuXjFJ0Y7qqM1xU4bj t5A/DVcrnf2QQwIUeCuQ0PHKZ42R7g9VtYvF+9Uc0qF1c+X5cEuHI3SlzwgU 2oFcAfj7xR; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Apr 20, 2008, at 3:33 PM, Paul Kyzivat wrote: > >> >> >> Dean Willis wrote: >>> On Apr 18, 2008, at 8:27 PM, DRAGE, Keith (Keith) wrote: >>>> 302s recursed by intermediate proxies may be perfectly reasonably in >>>> certain charging environments. >>> Not if they're retargeting. I'd also say that proxy operations that >>> retarget are also generally unreasonable, given that (so far) we >>> have no way to inform the caller of the retargeting. >> >> What is your objection? Is it >> - that the caller may be billed for something he wasn't expecting? >> - that the caller may not want to talk to the new target? > > Both, although my bigger concern is the general unanticipated respondent > problem. > >> The former is a billing issue, which may or may not be related to this >> discussion, as Keith has pointed out. >> >> The latter can be dealt with via called party identity. > > Which, with current specs, only kicks in AFTER the INVITE transaction > has completed. > >> In any case it is quite within the normal range of expectation to day >> that you may end up talking to someone other than who you thought you >> were calling. > > That's probably true, but it's not a good thing. Why do we keep trying > to reinvent the failings of the pSTN? I am perfectly willing to admit that I might not be imagining how things might work. Perhaps this depends very heavily on exactly what is retargeting and what is not. If I call the Dr and get the answering service is that retargeting? If I call the boss and get the secretary is that retargeting? I I call you on your land line and get forwarded to your mobile line is that retargeting? If I call a help line and get forwarded to a call center worker is that retargeting? In most of these cases, even if my UA has a UI to ask me if I want to continue I will most likely just consider than annoying and reconfigure it to automatically accept all of these retargetings. I can see the value of being able to specify that I want to speak to a certain person and no other, but I think I wojuld only want to use it on rare occasions. BTW, when it does matter to me I would prefer to restrict who actually answers the phone, rather than just which phone rings. But I don't see much likelihood of that any time soon. I would be *thrilled* to just have called party identity on a regular basis. 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 sip-bounces@ietf.org Sun Apr 20 21:55:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D753A6976; Sun, 20 Apr 2008 21:55:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDC43A6976 for ; Sun, 20 Apr 2008 21:55:26 -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 ctPWxk2Vgylw for ; Sun, 20 Apr 2008 21:55:25 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 49D273A67F5 for ; Sun, 20 Apr 2008 21:55:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 651BB1EC294; Mon, 21 Apr 2008 07:55:30 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgAAgUrK2nVJ; Mon, 21 Apr 2008 07:55:23 +0300 (EEST) Received: from taimen (h141135.gprs.dnafinland.fi [87.93.141.135]) by tutpro.com (Postfix) with ESMTP; Mon, 21 Apr 2008 07:55:23 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id F3EB0AC08E; Mon, 21 Apr 2008 07:55:15 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18444.7731.866972.327554@taimen.test.fi> Date: Mon, 21 Apr 2008 07:55:15 +0300 To: Paul Kyzivat In-Reply-To: <480C183A.4040509@cisco.com> References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> <48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat writes: > Perhaps this depends very heavily on exactly what is retargeting and > what is not. If I call the Dr and get the answering service is that > retargeting? If I call the boss and get the secretary is that > retargeting? I I call you on your land line and get forwarded to your > mobile line is that retargeting? If I call a help line and get > forwarded to a call center worker is that retargeting? i don't see any problem if callee has configured his proxy or phone to perform those actions, but i see a big problem if callee returns 302 to the caller and caller's phone or proxy acts on it without informing the caller. -- juha _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 20 23:02:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BF23A6CA9; Sun, 20 Apr 2008 23:02:20 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD2F3A6AD8 for ; Sun, 20 Apr 2008 23:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 1-BEVB9VzHtK for ; Sun, 20 Apr 2008 23:02:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 281753A685D for ; Sun, 20 Apr 2008 23:00:55 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3L60RnL014617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Apr 2008 01:00:45 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <480C183A.4040509@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 21 Apr 2008 01:00:21 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 20, 2008, at 11:29 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> On Apr 20, 2008, at 3:33 PM, Paul Kyzivat wrote: >>> >>> >>> Dean Willis wrote: >>>> On Apr 18, 2008, at 8:27 PM, DRAGE, Keith (Keith) wrote: >>>>> 302s recursed by intermediate proxies may be perfectly >>>>> reasonably in >>>>> certain charging environments. >>>> Not if they're retargeting. I'd also say that proxy operations >>>> that retarget are also generally unreasonable, given that (so >>>> far) we have no way to inform the caller of the retargeting. >>> >>> What is your objection? Is it >>> - that the caller may be billed for something he wasn't expecting? >>> - that the caller may not want to talk to the new target? >> Both, although my bigger concern is the general unanticipated >> respondent problem. >>> The former is a billing issue, which may or may not be related to >>> this discussion, as Keith has pointed out. >>> >>> The latter can be dealt with via called party identity. >> Which, with current specs, only kicks in AFTER the INVITE >> transaction has completed. >>> In any case it is quite within the normal range of expectation to >>> day that you may end up talking to someone other than who you >>> thought you were calling. >> That's probably true, but it's not a good thing. Why do we keep >> trying to reinvent the failings of the pSTN? > > I am perfectly willing to admit that I might not be imagining how > things might work. > > Perhaps this depends very heavily on exactly what is retargeting and > what is not. If I call the Dr and get the answering service is that > retargeting? If I call the boss and get the secretary is that > retargeting? I I call you on your land line and get forwarded to > your mobile line is that retargeting? If I call a help line and get > forwarded to a call center worker is that retargeting? Can they respond with the Dr's credentials? Would their identity service put an RFC 4474 in a return UPDATE that matches the To in the original request? If so, then it's OK -- the caller is surprised by the response. If not, then we have a retargeting. When retargeting occurs without infomring the caller, we invariantly have an unanticipated respondent scenario. > > In most of these cases, even if my UA has a UI to ask me if I want > to continue I will most likely just consider than annoying and > reconfigure it to automatically accept all of these retargetings. even the ones that are spoofed "responses" from an MITM? Here's the scenario: Alice sends an INVITE to Bob. Charlie sees it, and fakes a 200 OK response to Alice before Bob can respond. Unlikely? Not in a P2PSIP world. If Bob forwards his phone to Charlie, Alice needs to see something signed by Bob or somebody authoritative for Bob that says the call is being redirected to Charlie before accepting a response from Charlie. > I can see the value of being able to specify that I want to speak to > a certain person and no other, but I think I wojuld only want to use > it on rare occasions. I bet you'll want to use it on every call. You just don't know it yet. > BTW, when it does matter to me I would prefer to restrict who > actually answers the phone, rather than just which phone rings. But > I don't see much likelihood of that any time soon. You have no choice about who answers. What you have a choice about is which answer you will accept as valid. -- 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 sip-bounces@ietf.org Sun Apr 20 23:02:35 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129613A6D08; Sun, 20 Apr 2008 23:02:35 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704AA28C1AD for ; Sun, 20 Apr 2008 23:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 tyEUS4vHOOKc for ; Sun, 20 Apr 2008 23:02:31 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 131C928C157 for ; Sun, 20 Apr 2008 23:02:29 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3L60RnM014617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Apr 2008 01:01:15 -0500 Message-Id: <8CE91C5B-58B9-4593-8719-20CBB21C98F3@softarmor.com> From: Dean Willis To: Juha Heinanen In-Reply-To: <18444.7731.866972.327554@taimen.test.fi> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 21 Apr 2008 01:01:15 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> <48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> <18444.7731.866972.327554@taimen.test.fi> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 20, 2008, at 11:55 PM, Juha Heinanen wrote: > Paul Kyzivat writes: > >> Perhaps this depends very heavily on exactly what is retargeting and >> what is not. If I call the Dr and get the answering service is that >> retargeting? If I call the boss and get the secretary is that >> retargeting? I I call you on your land line and get forwarded to your >> mobile line is that retargeting? If I call a help line and get >> forwarded to a call center worker is that retargeting? > > i don't see any problem if callee has configured his proxy or phone to > perform those actions, but i see a big problem if callee returns 302 > to > the caller and caller's phone or proxy acts on it without informing > the > caller. How does the caller know that the callee has configured his proxy to perform those actions and that the response isn't coming from somebody 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 sip-bounces@ietf.org Sun Apr 20 23:12:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E598C3A6C5D; Sun, 20 Apr 2008 23:12:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8EE928C3D5 for ; Sun, 20 Apr 2008 23:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSy7tifOifW2 for ; Sun, 20 Apr 2008 23:12:21 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id E18E53A683B for ; Sun, 20 Apr 2008 23:12:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 30B921EC294; Mon, 21 Apr 2008 09:12:27 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MScxT1aRLJEt; Mon, 21 Apr 2008 09:12:10 +0300 (EEST) Received: from taimen (h141135.gprs.dnafinland.fi [87.93.141.135]) by tutpro.com (Postfix) with ESMTP; Mon, 21 Apr 2008 09:12:10 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 2A0ADAC08C; Mon, 21 Apr 2008 09:12:05 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18444.12342.134892.542213@taimen.test.fi> Date: Mon, 21 Apr 2008 09:12:06 +0300 To: Dean Willis In-Reply-To: <8CE91C5B-58B9-4593-8719-20CBB21C98F3@softarmor.com> References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> <48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> <18444.7731.866972.327554@taimen.test.fi> <8CE91C5B-58B9-4593-8719-20CBB21C98F3@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Paul Kyzivat , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis writes: > How does the caller know that the callee has configured his proxy to > perform those actions and that the response isn't coming from somebody > else? dean, i didn't understand your question. you mean 200 ok response? it is coming from somebody else, for example, if callee has configured to forward requests to him to his voice mail. -- juha _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 20 23:27:56 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614FF28C3D5; Sun, 20 Apr 2008 23:27:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C873A6ED9 for ; Sun, 20 Apr 2008 23:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 w-z746AGZHlt for ; Sun, 20 Apr 2008 23:27:53 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 899333A6DBD for ; Sun, 20 Apr 2008 23:27:53 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3L6TrlS003310; Mon, 21 Apr 2008 01:30:18 -0500 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 09:27:24 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 09:27:24 +0300 Received: from [172.21.40.139] ([172.21.40.139]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 09:27:24 +0300 Message-ID: <480C33B0.5000707@nokia.com> Date: Mon, 21 Apr 2008 09:26:56 +0300 From: Jari Urpalainen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: ext Anders Lindgren C References: <6D34F0B7D5BCB246A42380744457CA36BBBC58@esealmw107.eemea.ericsson.se> In-Reply-To: <6D34F0B7D5BCB246A42380744457CA36BBBC58@esealmw107.eemea.ericsson.se> X-OriginalArrivalTime: 21 Apr 2008 06:27:24.0459 (UTC) FILETIME=[C317F7B0:01C8A378] X-Nokia-AV: Clean Cc: sip@ietf.org, drage@alcatel-lucent.com Subject: Re: [Sip] Some comment to draft-ietf-sip-xcapevent-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks Anders, inline ext Anders Lindgren C wrote: > Hi Jari and Keith, > I had a look at the latest xcap event draft http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-02.txt what was updated after the WG last call for this i-d.. OMA-PAG WG is as both you know using this i-d as part of the OMA XDM 2.0 enabler release. I have from a OMA XDM 2.0 point of view reviewed the i-d to give you some more feedback as beeing a member of this WG > My personal view is that this version of the i-d fulfills the needs that I see exists for the function to be able to monitor changes in XML document managed by the OMA XDM enabler.. > When reviewing the document I have only found some minor things in the examples that I think needs to be addressed.. > > #1 > Section A.2 > "If the Expires header has a value "0" this is effectively a similar request than the PROPFIND method of WebDAV, the syntax's and responses differ, however." > This sentence is a bit unclear to me > shall it be better to write > "If the Expires header has a value "0" this is effectively a similar request to the PROPFIND method of WebDAV, the syntax's and responses differ, however." > instead if you mean that both metods do the same stuff but with different syntax/responses. > > right. > #2 > Section A.4 > "If it were an another device it would probably do a re-fetch of this new document." > > shall it be just "fetch" as it is a new documen? Re-fetch of a new document sounds a bit strange. Shall it be > "If it were an another device it would probably do a fetch of this new document." > instead. > sure, of course. > #3 > Section A.5 > The example is a bit confusing and I think it needs some clarification. A suggestion is added in bold text. I have assumed that the starting point is that the document exist. > > The user Joe does an initial subscription for the "id" affribute of the element: > The "index" document exists ,but the root element does not contain the "id" attribute at the time of the subscription. > > ok, it wasn't much explained indeed. Also if index doesn't exist the responses are the same, i.e. this doesn't show reasons for un-existing components. Added a note about this as well. > SUBSCRIBE sip:tests@xcap.example.com SIP/2.0 > ... > Accept: application/xcap-diff+xml > Event: xcap-diff > Content-Type: application/resource-lists+xml > Content-Length: [XXX] > > > > > > > > In addition to the 200 OK response, the first NOTIFY looks like since > there's nothing to indicate as: > NOTIFY sip:joe@userhost.example.com SIP/2.0 > ... > Event: xcap-diff > Content-Type: application/xcap-diff+xml > Content-Length: [XXX] > > > xcap-root="http://xcap.example.com/"/> > > > Afterwards Joe's XCAP client updates the whole document root element including the attribute "id" > (not a typical XCAP operation nor a preferred one, just an > illustration here): > > > PUT /tests/users/sip:joe@example.com/index/~~/doc HTTP/1.1 > Host: xcap.example.com > .... > Content-Type: application/xcap-el+xml > Content-Length: [XXX] > > This is a new root element > > > The reported*** new HTTP ETag of "index" document is now "dwawrrtyy". ( ***remove reported as it is not reported to the subscriber in the NOTIFY it is only send back in the response to the PUT else remove the whole sentence as ETAG is not used in this type of Noitify and ETAG value is therefore not relevant) > right, though "reported" was there just to describe the http ETag response header. Added also a note that it won't be "reported" > Then the subscriber gets a notification: > > > NOTIFY sip:joe@userhost.example.com SIP/2.0 > ... > Event: xcap-diff > Content-Type: application/xcap-diff+xml > Content-Length: [XXX] > > > xcap-root="http://xcap.example.com/"> > > >bar > > > > Kind Regards > Anders > thanks, Jari _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 21 00:48:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2734D3A69E1; Mon, 21 Apr 2008 00:48:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC58F3A69E1 for ; Mon, 21 Apr 2008 00:48: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=[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 SbWsDWVeoqtz for ; Mon, 21 Apr 2008 00:48:09 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by core3.amsl.com (Postfix) with ESMTP id 334DD3A68F4 for ; Mon, 21 Apr 2008 00:48:09 -0700 (PDT) Received: from df-bhd-03.exchange.corp.microsoft.com (157.54.91.48) by DF-GWY-07.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 21 Apr 2008 00:49:20 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by DF-BHD-03.exchange.corp.microsoft.com ([157.54.91.48]) with mapi; Mon, 21 Apr 2008 00:49:19 -0700 From: Sriram Parameswar To: "sip@ietf.org" Date: Mon, 21 Apr 2008 00:48:13 -0700 Thread-Topic: E.164 - who owns it Thread-Index: AcihhsAS4fojcloTQEShCh+p0COxdAB+/8hg 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 MIME-Version: 1.0 Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just a quick comment on proxies that act on 302's, there is an expired draft "draft-rajesh-sipping-303" that proposed a new response that specifically allowed proxies to act on a redirect. This may be used to clarify the behavior on 302's that must go all the way back to the caller. Thanks, Sriram Parameswar -----Original Message----- Message: 1 Date: Fri, 18 Apr 2008 10:58:55 -0500 From: "Francois Audet" Subject: Re: [Sip] E.164 - who owns it To: "Hadriel Kaplan" , "Dean Willis" , "Anders Kristensen" Cc: SIP IETF , Paul Kyzivat , Dan WING Message-ID: <1ECE0EB50388174790F9694F77522CCF163C2716@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset="iso-8859-1" I think Hadriel is right. As much as I agree that from a technical perspective, having 302s not recursed on by proxies is better, I can't see this generally becoming the norm in this SIP universe. It's too late for that. Maybe in SIP Four Dot Oh. _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 21 03:59:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A13728C3F3; Mon, 21 Apr 2008 03:59:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D0828C3F3 for ; Mon, 21 Apr 2008 03:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, WHOIS_NETSOLPR=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 yEHg2JS-zUw2 for ; Mon, 21 Apr 2008 03:59:50 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 98F7628C3F5 for ; Mon, 21 Apr 2008 03:59:49 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id m3LAxlZR027213; Mon, 21 Apr 2008 12:59:47 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id m3LAxlZF009197; Mon, 21 Apr 2008 12:59:47 +0200 Received: from MCHP7RDA.ww002.siemens.net ([139.25.131.171]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 12:59:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 12:59:42 +0200 Message-ID: <198A10EC585EC74687BCA414E2A5971802168F6D@MCHP7RDA.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What 4474 signs part-3 [was: Proposal to Revise RFC 4474] Thread-Index: AcieP0/LxeHkmxVcTcSS+BethEerDAAWDIQgACpzRAAAjZM9IACIsRcQ References: <97736536-E91D-4CF8-90AF-07C30A39C647@softarmor.com><29F55447-26D1-4DFB-BBC7-6AB20112F15B@cisco.com> From: "Fischer, Kai" To: "Hadriel Kaplan" , "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 21 Apr 2008 10:59:45.0567 (UTC) FILETIME=[CF272AF0:01C8A39E] Cc: SIP IETF , jon.peterson@neustar.biz Subject: Re: [Sip] What 4474 signs part-3 [was: Proposal to Revise RFC 4474] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Freitag, 18. April 2008 22:42 > To: Cullen Jennings; Dean Willis > Cc: SIP IETF; jon.peterson@neustar.biz > Subject: [Sip] What 4474 signs part-3 [was: Proposal to > Revise RFC 4474] > > ... > > So... I propose that once again the originator of the request > be given an option: it can sign the MIME body, or not, based > on its preference. This can be done in another parameter or > param value of the Identity-Info header, similar to the > Contact one proposed in part-2 of this thread; and again this > parameter does not need to be signed itself because forging > it or removing it implicitly breaks the signature calc > anyway. The authenticator can likewise decide if it wants to > accept a request with this parameter or not. I think the flexibility of elements covered by a (RFC4474bis) signature is an interesting idea. RFC 4474 shall be applied for different scenarios and therefore the set of elements which needs to be signed vary. For the protection of the DTLS-SRTP fingerprint only a few elements need to be signed. However, the flexibility causes also some interoperability issues like B expected header field x to be signed whereas A doesn't sign it. The risk exists that both parties fall back to the least common denominator (all mandatory elements), which is not applicable resp. secure for all intended scenarios. So it could be useful to define some RFC4474 signature profiles. These profiles are also extendable for future use cases without a need to revise RFC4474bis again. Kai > > The semantics of this are such that the authenticator is > saying "me.com verified user foo@me.com generated this > request with these To, From, and Date, but not necessarily > the SDP." This would be useful for spam avoidance, but not > much more. (just as 4474 arguably is) > If a srtp fingerprint is also signed, then it means a lot more. > > Alternatively, we could just recommend that such an > originator simply send offerless-Invite's, since that is > perfectly legal in 4474 and avoids this issue. But somehow I > don't think that would be such a good idea. ;) > > -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 > _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 21 05:40:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D213A6F25; Mon, 21 Apr 2008 05:40:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993AC3A6F29 for ; Mon, 21 Apr 2008 05:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 0IyhIQz3C8IL for ; Mon, 21 Apr 2008 05:40:07 -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 BF3CC3A6EB7 for ; Mon, 21 Apr 2008 05:40:07 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 21 Apr 2008 05:40:14 -0700 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 m3LCeEPT009279; Mon, 21 Apr 2008 05:40:14 -0700 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 m3LCdsqu019902; Mon, 21 Apr 2008 12:40:14 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, 21 Apr 2008 08:40:12 -0400 Received: from [10.86.240.30] ([10.86.240.30]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 08:40:11 -0400 Message-ID: <480C8B48.6070702@cisco.com> Date: Mon, 21 Apr 2008 08:40:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Juha Heinanen References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> <48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> <18444.7731.866972.327554@taimen.test.fi> In-Reply-To: <18444.7731.866972.327554@taimen.test.fi> X-OriginalArrivalTime: 21 Apr 2008 12:40:11.0550 (UTC) FILETIME=[D6EB33E0:01C8A3AC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2275; t=1208781614; x=1209645614; c=relaxed/simple; s=sjdkim1004; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=MXJOPOC3iFDH1RpVwzUdjW89ZI8vlYB6VLG1P2R6bjY=; b=QFREEr2ufGoKwTKyDcd0Bvg/7mY4jfwabM3H0cs1lhHENXPDnapJBMejDU teaHD6R+fUIhZHfKomOYvpRuemD3TKQeFlulsQRtv413190AHCGAY6g8T7jE yWGD0z3mwm3mRqY8VwKolNvAFdGSvRNc7HWzEu0cWXfRGxd4SJAJE=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIP IETF , "DRAGE, Keith \(Keith\)" , Dean Willis Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Paul Kyzivat writes: > > > Perhaps this depends very heavily on exactly what is retargeting and > > what is not. If I call the Dr and get the answering service is that > > retargeting? If I call the boss and get the secretary is that > > retargeting? I I call you on your land line and get forwarded to your > > mobile line is that retargeting? If I call a help line and get > > forwarded to a call center worker is that retargeting? > > i don't see any problem if callee has configured his proxy or phone to > perform those actions, but i see a big problem if callee returns 302 to > the caller and caller's phone or proxy acts on it without informing the > caller. If the caller is picky about who he ends up talking to then I don't see what difference it makes whether the retargeting is processed by a proxy or the UAC. And if the caller is concerned about picking up the charge for a call to an unanticipated address then it is just an issue of whether it is going to get the bill, not who does the retargeting. I know we traditionally avoid billing issues, but there are a whole class of architectural issues such as this that we can't address without considering charging. IMO a fundamental flaw in charging systems is assuming that the caller can infer the charging algorithm that will be used for a call based on the *form* of the address. By that I mean: - whether caller or callee pays - per minute rate, etc. This of course gets all screwed up if payment responsibility or rate for a call changes as a result of retargeting. But its somewhat of a problem even without retargeting. The kinds of problems I am aware of are: - caller isn't always aware of the mapping from address to charging algorithm, so may be charged more than anticipated - relying on form makes dialing rules difficult (do I start with "1" or not? It sometimes depends on which UA dialing is initiated.) - there is a shortage of desirable "free phone" numbers, because of the limited forms for them. Adding new freephone prefixes aggrevates the prior propblem of callers knowing the algorithm. - to date there is no precedent for "freephone" addresses conforming to "email" syntax. _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 21 05:54:01 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6C73A6987; Mon, 21 Apr 2008 05:54:01 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62DD3A67CC for ; Mon, 21 Apr 2008 05:54:00 -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 51pfhDr3KB0D for ; Mon, 21 Apr 2008 05:53:55 -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 B86433A6987 for ; Mon, 21 Apr 2008 05:53:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,689,1199682000"; d="scan'208";a="5779233" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Apr 2008 08:54:00 -0400 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 m3LCs0xB001520; Mon, 21 Apr 2008 08:54:00 -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 m3LCs0F3023857; Mon, 21 Apr 2008 12:54: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); Mon, 21 Apr 2008 08:54:00 -0400 Received: from [10.86.240.30] ([10.86.240.30]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 08:54:00 -0400 Message-ID: <480C8E85.4000304@cisco.com> Date: Mon, 21 Apr 2008 08:54:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dean Willis References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> In-Reply-To: X-OriginalArrivalTime: 21 Apr 2008 12:54:00.0227 (UTC) FILETIME=[C4D94730:01C8A3AE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4793; t=1208782440; x=1209646440; 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]=20E.164=20-=20who=20owns=20it |Sender:=20 |To:=20Dean=20Willis=20; bh=gUija2vcSvkhjo78vE71iXlTX4l6rg8krslo1Ml6yOM=; b=XHraCTRbuD4mag9CygBsHtxoojtEen2SfOnXBbZa78wVbRrpURwuYhXqDh bZWoom2guQqIapUd3bWzNFOA97S4wVQVR2SuqRBN3a+mR6CACA8FrGGYbCKZ I52Aek7pfz; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIP IETF , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Apr 20, 2008, at 11:29 PM, Paul Kyzivat wrote: > >> >> >> Dean Willis wrote: >>> On Apr 20, 2008, at 3:33 PM, Paul Kyzivat wrote: >>>> >>>> >>>> Dean Willis wrote: >>>>> On Apr 18, 2008, at 8:27 PM, DRAGE, Keith (Keith) wrote: >>>>>> 302s recursed by intermediate proxies may be perfectly reasonably in >>>>>> certain charging environments. >>>>> Not if they're retargeting. I'd also say that proxy operations >>>>> that retarget are also generally unreasonable, given that (so far) >>>>> we have no way to inform the caller of the retargeting. >>>> >>>> What is your objection? Is it >>>> - that the caller may be billed for something he wasn't expecting? >>>> - that the caller may not want to talk to the new target? >>> Both, although my bigger concern is the general unanticipated >>> respondent problem. >>>> The former is a billing issue, which may or may not be related to >>>> this discussion, as Keith has pointed out. >>>> >>>> The latter can be dealt with via called party identity. >>> Which, with current specs, only kicks in AFTER the INVITE transaction >>> has completed. >>>> In any case it is quite within the normal range of expectation to >>>> day that you may end up talking to someone other than who you >>>> thought you were calling. >>> That's probably true, but it's not a good thing. Why do we keep >>> trying to reinvent the failings of the pSTN? >> >> I am perfectly willing to admit that I might not be imagining how >> things might work. >> >> Perhaps this depends very heavily on exactly what is retargeting and >> what is not. If I call the Dr and get the answering service is that >> retargeting? If I call the boss and get the secretary is that >> retargeting? I I call you on your land line and get forwarded to your >> mobile line is that retargeting? If I call a help line and get >> forwarded to a call center worker is that retargeting? > > Can they respond with the Dr's credentials? Would their identity service > put an RFC 4474 in a return UPDATE that matches the To in the original > request? If so, then it's OK -- the caller is surprised by the response. > If not, then we have a retargeting. When retargeting occurs without > infomring the caller, we invariantly have an unanticipated respondent > scenario. Well, today if the Dr has sip service with credentials but subscribes to a PSTN answering service then I presume not. In some other cases possibly yes. Even in cases like this one, where it would seem in the abstract that the new target *ought* to have credentials there will clearly be a migration issue. >> In most of these cases, even if my UA has a UI to ask me if I want to >> continue I will most likely just consider than annoying and >> reconfigure it to automatically accept all of these retargetings. > > even the ones that are spoofed "responses" from an MITM? Well I would be pleased to have the true spoofs singled out and highlighted, if it was possible to reliably separate them from the cases that were clearly intended by the callee. But I don't see that being possible any time soon. > Here's the scenario: Alice sends an INVITE to Bob. Charlie sees it, and > fakes a 200 OK response to Alice before Bob can respond. > > Unlikely? Not in a P2PSIP world. Thats clearlhy a bad case. If it can be distinguished from the others then great. However its not entirely clear to me that this is conceptually different from Bob being offline and having asked Charlie to answer calls for him. > If Bob forwards his phone to Charlie, Alice needs to see something > signed by Bob or somebody authoritative for Bob that says the call is > being redirected to Charlie before accepting a response from Charlie. I agree this would be a good thing. It doesn't have to be the 3xx response. >> I can see the value of being able to specify that I want to speak to a >> certain person and no other, but I think I wojuld only want to use it >> on rare occasions. > > I bet you'll want to use it on every call. You just don't know it yet. There are just too many cases when I don't know who will be expected to answer the call. You seem to be assuming that all phones are personal phones. >> BTW, when it does matter to me I would prefer to restrict who actually >> answers the phone, rather than just which phone rings. But I don't see >> much likelihood of that any time soon. > > You have no choice about who answers. What you have a choice about is > which answer you will accept as valid. I want the one with the real Dean Willis talking, regardless of what AOR was used to reach it. (Assuming there *is* a real Dean Willis.) 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 sip-bounces@ietf.org Mon Apr 21 11:05:12 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C1B3A6F22; Mon, 21 Apr 2008 11:05:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B9328C3ED for ; Mon, 21 Apr 2008 11:05:08 -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 Phr+Va2GCQ9v for ; Mon, 21 Apr 2008 11:05:04 -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 C3E983A6F07 for ; Mon, 21 Apr 2008 11:05:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,690,1199692800"; d="scan'208";a="22739698" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Apr 2008 11:05:10 -0700 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 m3LI5AcC015847; Mon, 21 Apr 2008 11:05:10 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3LI59UR012381; Mon, 21 Apr 2008 18:05:09 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Paul Kyzivat'" References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com><480BA883.4000106@cisco.com> Date: Mon, 21 Apr 2008 11:05:09 -0700 Message-ID: <031201c8a3da$3d1937c0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcijYnJPsVxLRxRfTYqcLOyhsbHwLgAdzZLA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1144; t=1208801110; x=1209665110; 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]=20E.164=20-=20who=20owns=20it |Sender:=20; bh=TcCKOuWm2R+knCN1sytehN+Wl+Dkj4s+pVD9Smf4GVM=; b=gdliYiK2NbkxuYRrtdvAoBHh1IOsbvVTIMm3aA8dpwoTGJ/t3MVbkNTKZH hgbFCzzQFrXCVzt8KOLuWws+xHom/nKXuLvFp1E9TgUjL0b9UCqkWCm8jYwV VSB/HDMVsv; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'SIP IETF' , "'DRAGE, Keith \(Keith\)'" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > The former is a billing issue, which may or may not be related to > > this discussion, as Keith has pointed out. > > > > The latter can be dealt with via called party identity. > > Which, with current specs, only kicks in AFTER the INVITE > transaction has completed. One way to avoid that would be to create a new I-D, 'connected party precondition'. But preconditions have not enjoyed much success because, as I understand it, preconditions cannot be incrementally deployed. -d > > In any case it is quite within the normal range of expectation to > > day that you may end up talking to someone other than who you > > thought you were calling. > > That's probably true, but it's not a good thing. Why do we keep > trying to reinvent the failings of the pSTN? > > -- > 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 _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 21 11:14:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C003A6F57; Mon, 21 Apr 2008 11:14:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154FA3A6F59 for ; Mon, 21 Apr 2008 11:14:07 -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 YCcizWcNHRR7 for ; Mon, 21 Apr 2008 11:14:04 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3C8A03A6F91 for ; Mon, 21 Apr 2008 11:11:34 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3LIBaxL018982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Apr 2008 13:11:38 -0500 Message-Id: From: Dean Willis To: Juha Heinanen In-Reply-To: <18444.12342.134892.542213@taimen.test.fi> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 21 Apr 2008 13:11:31 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> <48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> <18444.7731.866972.327554@taimen.test.fi> <8CE91C5B-58B9-4593-8719-20CBB21C98F3@softarmor.com> <18444.12342.134892.542213@taimen.test.fi> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 21, 2008, at 1:12 AM, Juha Heinanen wrote: > Dean Willis writes: > >> How does the caller know that the callee has configured his proxy to >> perform those actions and that the response isn't coming from >> somebody >> else? > > dean, > > i didn't understand your question. you mean 200 ok response? it is > coming from somebody else, for example, if callee has configured to > forward requests to him to his voice mail. Ideally we'd be talking about the 200 OK, but our identity assertion mechanism (FC 4474) currently doesn't work in the 200 OK, so we're really talking an RFC 4916 message in the other direction. If you call me and I've forwarded those calls to voice mail, how do you know that I've authorized this forwarding and that it wasn't done by a MITM attacker? With our existing protocol set, you don't. One possible workaround would be to handle the "forwarding" operation by having my bot accept your INVITE with a 200 OK, do an RFC 4916 exchange, then do a REFER telling you to call my voice mail. Now you know "for sure" that I want you to talk to this other identity "my voicemail". It would be much cleaner to allow RFC 4474 in a response, so that I could simply respond to your INVITE with a 302 pointing you at my voice mail. My signature (or that of my service provider, who we've agreed to trust) would assert that the retargeting to the voice mail platform is valid. Where a 302 isn't ideal and it would be better to "proxy retarget" the request, we need a new mechanism -- we need a way for the proxy to send you something that explains that the request is being retargeted and who you should be looking to connect with. I've seen it proposed that we could use a new provisional (or reliable provisional) response to do this. And if RFC 4474 could be extended to cover this response, then this partiular problem would be solved. -- 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 sip-bounces@ietf.org Mon Apr 21 11:22:42 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD993A684A; Mon, 21 Apr 2008 11:22:42 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8663A6849 for ; Mon, 21 Apr 2008 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 wpyutlPWkCnU for ; Mon, 21 Apr 2008 11:22:36 -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 75DB13A684A for ; Mon, 21 Apr 2008 11:22:36 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2008 11:22:43 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m3LIMhOf001998 for ; Mon, 21 Apr 2008 11:22:43 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m3LIMgS0010616 for ; Mon, 21 Apr 2008 18:22:42 GMT From: "Dan Wing" To: "'SIP IETF'" Date: Mon, 21 Apr 2008 11:22:42 -0700 Message-ID: <036701c8a3dc$b0779a20$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acij3LAdXy4VYWHxSKaoOH9yNu57Dg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2612; t=1208802163; x=1209666163; 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:=20R-CERTS=20in=20draft-ietf-sip-media-security-re quirements |Sender:=20; bh=7ScCHAY4yPQMd/LKNBgMzpnRS16lMBZgUMAPx2PgW3g=; b=NVFQiSLBEIcBP+18VxM5pkY06fkIVtwpIsIVhcV2ojFmpPL1zs9phhCyOK SFO/nQpLsS1e3MIrau2BfsuBFEK0Npk44BSS0JDzlzuObBl8vfk0Jz7n/xYv XpDwZBnkjq; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Sip] R-CERTS in draft-ietf-sip-media-security-requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org During WGLC an objection was raised about R-CERTS in draft-ietf-sip-media-security-requirements. I currently have proposals for: * reverting to the R12 text * sticking with R-CERTS text * removing the text completely I would like to understand what people want this requirement to *mean* -- does it say what you think it should say? Does it miss some aspect of signing/certificates that is important? ----- Details: In draft-ietf-sip-media-security-requirements-00 and -01, we had: R12: The media security key management protocol MUST NOT require 3rd parties to sign certificates. in draft-ietf-sip-media-security-requirements-02, this was renamed to R-CERTS and also had its text change to: R-CERTS: If the media security key management protocol employs certificates, it MUST be able to make use of both self-signed and CA-issued certificates. As an alternative, the media security key management protocol MAY make use of "bare" public keys. Here is how some key management systems would fare with the original R12 text: * RFC4474 would comply -- because RFC4474 allows both self-signed certificates and allows CA-signed certificates (reference end of Step 1 of Section 6 of RFC4474). One might reasonably expect most deployments will use CA-signed certificates. * OpenPGP certificates (if someone were to use it for SRTP keying) would comply -- because R12 allows you to sign your own key and does not require someone else sign your key. One might expect most deployments would include signatures by other people (3rd parties). * ZRTP would comply -- because there are no 3rd party signatures whatsoever. * MIKEY-RSA complies -- because it allows self-signed certificates (reference the first bullet of Section 4.3.2 of RFC3830). * Identity-Based Encryption (if someone were to use it for SRTP keying) would comply -- because IBE uses 'bare' public keys. and with the R-CERTS text: * RFC4474 would comply (same reason as R12). * OpenPGP certificates (if someone were to use it for SRTP keying) would not comply -- because R-CERTS allows you to sign your own key, but only mentions Certificate Authorities as 3rd party signers; OpenPGP does not have 'certificate authorities'. * ZRTP would comply (same reason as R12). * MIKEY-RSA complies (same reason as R12). * Identity-Based Encryption (if someone were to use it for SRTP keying) would comply (same reason as R12). -d _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 21 11:23:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575E23A6A90; Mon, 21 Apr 2008 11:23:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF1A28C42D for ; Mon, 21 Apr 2008 11:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 iE3+V-4I916t for ; Mon, 21 Apr 2008 11:23:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7DE773A6968 for ; Mon, 21 Apr 2008 11:23:06 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3LIMccN019065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Apr 2008 13:22:39 -0500 Message-Id: <1670435C-B2AB-4BA3-92ED-DC4B5BA50B35@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <480C8E85.4000304@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 21 Apr 2008 13:22:32 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com><48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> <480C8E85.4000304@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 21, 2008, at 7:54 AM, Paul Kyzivat wrote: > >> Here's the scenario: Alice sends an INVITE to Bob. Charlie sees it, >> and fakes a 200 OK response to Alice before Bob can respond. >> Unlikely? Not in a P2PSIP world. > > Thats clearlhy a bad case. If it can be distinguished from the > others then great. It is distinguished by the facts 1) that the respondent Charlie cannot present credentials for the called party Bob, and 2) Alice received no authentic instruction from Bob about the retargeting. SIP today works because our proxies are generally trustworthy and we have TLS to make sure we're talking to the proxy we think we're talking to. P2PSIP proxies cannot be trusted to that extent, and therefore we don't get the same benefit from TLS. > > However its not entirely clear to me that this is conceptually > different from Bob being offline and having asked Charlie to answer > calls for him. > It is not different in today's protocol spec. That's the problem -- it should be. >> If Bob forwards his phone to Charlie, Alice needs to see something >> signed by Bob or somebody authoritative for Bob that says the call >> is being redirected to Charlie before accepting a response from >> Charlie. > > I agree this would be a good thing. It doesn't have to be the 3xx > response. Correct. There have been other proposals, such as a reliable provisional informing Alice that an authorized proxy has retargeted the call to Charlie. This isn't hard -- it takes only a new response code and minor mods to RFC 4474. Or it could be done with no new extensions using an accept/refer/disconnect model. > >>> I can see the value of being able to specify that I want to speak >>> to a certain person and no other, but I think I wojuld only want >>> to use it on rare occasions. >> I bet you'll want to use it on every call. You just don't know it >> yet. > > There are just too many cases when I don't know who will be expected > to answer the call. You seem to be assuming that all phones are > personal phones. For every phone I call, there is somebody I expect would be authoritative for that call. For example, if I call a Lufthansa call center to book a ticket, I expect that the party I reach will be able to authentically claim to represent Lufthansa. > > >>> BTW, when it does matter to me I would prefer to restrict who >>> actually answers the phone, rather than just which phone rings. >>> But I don't see much likelihood of that any time soon. >> You have no choice about who answers. What you have a choice about >> is which answer you will accept as valid. > > I want the one with the real Dean Willis talking, regardless of what > AOR was used to reach it. (Assuming there *is* a real Dean Willis.) I may not be available. Would you rather reach the person I've authorized to handle my calls in my absence, or some random stranger? I suppose that's a personal choice ;-). -- 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 sip-bounces@ietf.org Mon Apr 21 12:35:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E59D3A6D43; Mon, 21 Apr 2008 12:35:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23133A6AF3 for ; Mon, 21 Apr 2008 12:35:08 -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 jGLGaphjHpp1 for ; Mon, 21 Apr 2008 12:35:04 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 968EC3A6F64 for ; Mon, 21 Apr 2008 12:35:04 -0700 (PDT) Received: from [128.89.255.67] (helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jo1nC-0005va-53; Mon, 21 Apr 2008 15:35:10 -0400 Message-ID: <480CEC6A.5010903@bbn.com> Date: Mon, 21 Apr 2008 15:35:06 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dan Wing References: <036701c8a3dc$b0779a20$c2f0200a@cisco.com> In-Reply-To: <036701c8a3dc$b0779a20$c2f0200a@cisco.com> Cc: 'SIP IETF' Subject: Re: [Sip] R-CERTS in draft-ietf-sip-media-security-requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I am strongly in favor of removing the text completely. It's vaguely worded (relying on an undefined notion of a "3rd party") -- and meaningless, since no extant IETF protocol (or I-D, AFAIK) violates it. --RB Dan Wing wrote: > During WGLC an objection was raised about R-CERTS in > draft-ietf-sip-media-security-requirements. I currently have proposals for: > > * reverting to the R12 text > * sticking with R-CERTS text > * removing the text completely > > I would like to understand what people want this requirement to *mean* -- does > it say what you think it should say? Does it miss some aspect of > signing/certificates that is important? > > ----- > > Details: > > In draft-ietf-sip-media-security-requirements-00 and -01, we had: > > R12: The media security key management protocol MUST NOT > require 3rd parties to sign certificates. > > in draft-ietf-sip-media-security-requirements-02, this was renamed to R-CERTS > and also had its text change to: > > R-CERTS: If the media security key management protocol > employs certificates, it MUST be able to make use of both > self-signed and CA-issued certificates. As an alternative, > the media security key management protocol MAY make use of > "bare" public keys. > > > Here is how some key management systems would fare with the original R12 text: > > * RFC4474 would comply -- because RFC4474 allows both self-signed > certificates and allows CA-signed certificates (reference end of > Step 1 of Section 6 of RFC4474). One might reasonably expect most > deployments will use CA-signed certificates. > > * OpenPGP certificates (if someone were to use it for SRTP > keying) would comply -- because R12 allows you to sign your own > key and does not require someone else sign your key. One might > expect most deployments would include signatures by other > people (3rd parties). > > * ZRTP would comply -- because there are no 3rd party signatures > whatsoever. > > * MIKEY-RSA complies -- because it allows self-signed certificates > (reference the first bullet of Section 4.3.2 of RFC3830). > > * Identity-Based Encryption (if someone were to use it for SRTP > keying) would comply -- because IBE uses 'bare' public keys. > > > and with the R-CERTS text: > > * RFC4474 would comply (same reason as R12). > > * OpenPGP certificates (if someone were to use it for SRTP keying) > would not comply -- because R-CERTS allows you to sign your own > key, but only mentions Certificate Authorities as 3rd party > signers; OpenPGP does not have 'certificate authorities'. > > * ZRTP would comply (same reason as R12). > > * MIKEY-RSA complies (same reason as R12). > > * Identity-Based Encryption (if someone were to use it for SRTP > keying) would comply (same reason as R12). > > -d > > _______________________________________________ > 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 sip-bounces@ietf.org Mon Apr 21 22:30:13 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B5E3A68B6; Mon, 21 Apr 2008 22:30:13 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01C53A68B6 for ; Mon, 21 Apr 2008 22:30: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=[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 TDdnpbKGr733 for ; Mon, 21 Apr 2008 22:30:11 -0700 (PDT) Received: from tutpro.com (lohi.tutpro.com [192.98.100.2]) by core3.amsl.com (Postfix) with ESMTP id 071023A67B5 for ; Mon, 21 Apr 2008 22:30:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id ECF051EC294; Tue, 22 Apr 2008 08:30:10 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+EHoJVVDp-z; Tue, 22 Apr 2008 08:30:03 +0300 (EEST) Received: from taimen (unknown [87.93.144.255]) by tutpro.com (Postfix) with ESMTP; Tue, 22 Apr 2008 08:30:03 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 068FBAC055; Tue, 22 Apr 2008 08:29:58 +0300 (EEST) MIME-Version: 1.0 Message-ID: <18445.30678.918077.327952@taimen.test.fi> Date: Tue, 22 Apr 2008 08:29:58 +0300 To: Dean Willis In-Reply-To: <1670435C-B2AB-4BA3-92ED-DC4B5BA50B35@softarmor.com> References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> <48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> <480C8E85.4000304@cisco.com> <1670435C-B2AB-4BA3-92ED-DC4B5BA50B35@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) Cc: SIP IETF , Paul Kyzivat , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis writes: > >> If Bob forwards his phone to Charlie, Alice needs to see something > >> signed by Bob or somebody authoritative for Bob that says the call > >> is being redirected to Charlie before accepting a response from > >> Charlie. > > > > I agree this would be a good thing. It doesn't have to be the 3xx > > response. > > Correct. There have been other proposals, such as a reliable > provisional informing Alice that an authorized proxy has retargeted > the call to Charlie. This isn't hard -- it takes only a new response > code and minor mods to RFC 4474. Or it could be done with no new > extensions using an accept/refer/disconnect model. and how about if charlie decides to forward the call to bill, who bob doesn't trust? -- juha _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 22 03:26:55 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B973C3A6C18; Tue, 22 Apr 2008 03:26:55 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEB83A6A51 for ; Tue, 22 Apr 2008 03:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJR-cVSvhDbP for ; Tue, 22 Apr 2008 03:26:48 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 325F13A6C31 for ; Tue, 22 Apr 2008 03:26:48 -0700 (PDT) Received: from epmmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JZQ0023P1ZC4A@mailout2.samsung.com> for sip@ietf.org; Tue, 22 Apr 2008 19:18:48 +0900 (KST) Received: from sukumarm ([107.108.74.245]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0JZQ00K2I1Z9IQ@mmp1.samsung.com> for sip@ietf.org; Tue, 22 Apr 2008 19:18:48 +0900 (KST) Date: Tue, 22 Apr 2008 15:52:55 +0530 From: sukumar To: sip@ietf.org Message-id: <002501c8a462$d54fdbb0$f54a6c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [Sip] Enquiry Regarding SIP REFER method. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060774508==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2060774508== Content-type: multipart/alternative; boundary="Boundary_(ID_pCrPuyKP4TLIDu+HGpFnDA)" This is a multi-part message in MIME format. --Boundary_(ID_pCrPuyKP4TLIDu+HGpFnDA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, As per RFC 3515 SIP Refer method Refer-To header field can contain HTTP uri. I want to know if the Refer-to header field contains an HTTP uri then what are the possible values the "method" attribute will contain? Regards Sukumar --Boundary_(ID_pCrPuyKP4TLIDu+HGpFnDA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi,
 As per RFC 3515 SIP Refer method Refer-To header field can contain HTTP uri. I want to know if the Refer-to header field contains an HTTP uri then what are the possible values the "method" attribute will contain?
 
Regards
Sukumar
 
 
--Boundary_(ID_pCrPuyKP4TLIDu+HGpFnDA)-- --===============2060774508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2060774508==-- From sip-bounces@ietf.org Tue Apr 22 09:43:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F8F3A6E3A; Tue, 22 Apr 2008 09:43:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2D03A6A51 for ; Tue, 22 Apr 2008 09:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 yyC0l78uiQUU for ; Tue, 22 Apr 2008 09:43:12 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 29CBB3A67B3 for ; Tue, 22 Apr 2008 09:43:12 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3MGgfqf027324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Apr 2008 11:42:42 -0500 Message-Id: From: Dean Willis To: Juha Heinanen In-Reply-To: <18445.30678.918077.327952@taimen.test.fi> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 22 Apr 2008 11:42:35 -0500 References: <48067BDA.4050000@cisco.com> <1ECE0EB50388174790F9694F77522CCF1630F0D2@zrc2hxm0.corp.nortel.com> <291C1385-9064-4798-BB9D-4AD718564D48@softarmor.com> <4807EAF3.4070205@cisco.com> <48088D5B.9020501@cisco.com> <9920220F-D29B-4F3B-B60E-AE36DB181C86@softarmor.com> <5D1A7985295922448D5550C94DE2918001E5B7D5@DEEXC1U01.de.lucent.com> <480BA883.4000106@cisco.com> <480C183A.4040509@cisco.com> <480C8E85.4000304@cisco.com> <1670435C-B2AB-4BA3-92ED-DC4B5BA50B35@softarmor.com> <18445.30678.918077.327952@taimen.test.fi> X-Mailer: Apple Mail (2.919.2) Cc: SIP IETF , Paul Kyzivat , "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] E.164 - who owns it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 22, 2008, at 12:29 AM, Juha Heinanen wrote: > Dean Willis writes: > >>>> If Bob forwards his phone to Charlie, Alice needs to see something >>>> signed by Bob or somebody authoritative for Bob that says the call >>>> is being redirected to Charlie before accepting a response from >>>> Charlie. >>> >>> I agree this would be a good thing. It doesn't have to be the 3xx >>> response. >> >> Correct. There have been other proposals, such as a reliable >> provisional informing Alice that an authorized proxy has retargeted >> the call to Charlie. This isn't hard -- it takes only a new response >> code and minor mods to RFC 4474. Or it could be done with no new >> extensions using an accept/refer/disconnect model. > > and how about if charlie decides to forward the call to bill, who bob > doesn't trust? > At least Alice will know she's talking to Bill because Bob forwarded the call to Charlie who forwarded it to Bill. If Bill isn't happy about this, he and Charlie can step outside the pub later and have two words about it. At least this way we know what happened, and we know it far more authoritatively than History-Info would have told us. -- 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 sip-bounces@ietf.org Tue Apr 22 21:01:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF723A6C00; Tue, 22 Apr 2008 21:01:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D069028C1E9 for ; Tue, 22 Apr 2008 21:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 qLnABCiZ0eeJ for ; Tue, 22 Apr 2008 21:01:50 -0700 (PDT) Received: from levi.nethawkgroup.com (levi.nethawkgroup.com [194.100.156.5]) by core3.amsl.com (Postfix) with SMTP id 425D43A6944 for ; Tue, 22 Apr 2008 21:00:58 -0700 (PDT) Received: from (unknown [194.100.156.14]) by levi.nethawkgroup.com with smtp id 2b87_e449a10c_10e9_11dd_979d_0019b9f20656; Wed, 23 Apr 2008 07:01:02 +0300 Received: from jopo.nethawk.fi (jopo.nethawk.fi [194.100.156.10]) by mailgw.nethawk.fi (Postfix) with ESMTP id 933886F024 for ; Wed, 23 Apr 2008 07:00:37 +0300 (EEST) Received: from bhula006 (10.16.16.224) by jopo.nethawk.fi (7.0.008) id 46F27400000F9111 for sip@ietf.org; Wed, 23 Apr 2008 07:01:02 +0300 From: "Pinak Tripathy" To: Date: Wed, 23 Apr 2008 09:30:57 +0530 Message-ID: <000001c8a4f6$a378eb60$e010100a@nethawk.fi> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcikMm8561sNT5lzTSuVlCM46KuocAAxCrkQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Sip] Test Data for AKAv2-MD5 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1171170512==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1171170512== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C8A524.BD312760" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C8A524.BD312760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have implemented AKAV2-MD5 in my application. To unit test it I need a test data (input and output values) for AKAV2-MD5. Please provide me test data for AKAV2-MD5 if you have any. Thanks in advance. Regards, Pinak ------=_NextPart_000_0001_01C8A524.BD312760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

I have implemented AKAV2-MD5 in my = application.
To unit test it I need a test data (input = and output values) for AKAV2-MD5.

Please provide me test data for AKAV2-MD5 if = you have any.
Thanks in = advance.

 

Regards,

Pinak

------=_NextPart_000_0001_01C8A524.BD312760-- --===============1171170512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1171170512==-- From sip-bounces@ietf.org Tue Apr 22 23:00:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E878928C228; Tue, 22 Apr 2008 23:00:47 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C36328C27D for ; Tue, 22 Apr 2008 23:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 YL91OGm5GJp2 for ; Tue, 22 Apr 2008 23:00:43 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id EF62828C268 for ; Tue, 22 Apr 2008 23:00:42 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1237929rvf.49 for ; Tue, 22 Apr 2008 23:00:47 -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:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=B0lRV2qkDnJk8p2PJa+Srh7vOsJ2DeIPDPh4KHSNHzQ=; b=JqMPiuX74k2G2mBixDYQi00f7y0JW/5sKuRTu6b5Uxr6LonPabmJfwZ/Ceoyv5e4NdbTyyPcaCJCoQvMLCn2u7fKr0sHNdrHJ1BzMCx5ky0vp/cmq/fC/U6VIO09v2oIdh06otLCuvrTSCg2KMYiGJP2dqC1f3YwF1vU1GWH0Vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=V6uDPBT9bAHiVlYIhlucsJKMqO53OlRLJMZZ9kayXNMm4SYm54vCWCftPHPh9BUeBlKUHspz3tzr68wbnDAM2N3VaXWbQWtMlU5t3BsZUIJ9mNWEroSyTPkyGHrwN6G3uOf2R68Ydc0lMzzpbKOcB6BBkJp2s64cBo+1CwbrFC0= Received: by 10.141.23.7 with SMTP id a7mr352934rvj.58.1208930447883; Tue, 22 Apr 2008 23:00:47 -0700 (PDT) Received: by 10.140.200.20 with HTTP; Tue, 22 Apr 2008 23:00:47 -0700 (PDT) Message-ID: Date: Wed, 23 Apr 2008 14:00:47 +0800 From: "=?GB2312?B?y+/X2r79?=" To: sip@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, all I am confused about the conception of session and dialog in RFC 3261. Although someone pointed out the dialog is a relationship between peer-2-peer and session is a multimedia relative relation, I am still not clear about that. For my understanding, the scope of session is wider than dialog means. Dialog can only exists between two peers, one-2-one, but session can contain more than 2 participants, right? For example, one INVITE from UAC can create more than one dialog because of the forked 2xx responses by the proxy server, but the session is determined by session id in the SDP and all the 2xx responses contain the same session id. All the participants belong to the same session. So my conclusion is that one session can contain more than one dialog even though they are created by same method. The relationship between dialog and session is many-2-one, right? If my understanding is right, then comes another question. The scenario is above, one INVITE created more than one dialog, the caller will maintain more than one dialog, he can terminate one of them via BYE method while keeping the other dialog. According to RFC3261, BYE method can terminate a session and its relative dialog. From this statement it seems that my conclusion is not exactly right. Then what is the relationship between session and dialog, one-2-one map or one-2-many map? Your instructions are highly appreciated. Thanks BR Zongjun _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 22 23:01:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8111E3A6D2A; Tue, 22 Apr 2008 23:01:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972B43A689E for ; Tue, 22 Apr 2008 23:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 UVcidwwynl+d for ; Tue, 22 Apr 2008 23:01:20 -0700 (PDT) Received: from web8409.mail.in.yahoo.com (web8409.mail.in.yahoo.com [202.43.219.157]) by core3.amsl.com (Postfix) with SMTP id CA75E3A6F02 for ; Tue, 22 Apr 2008 23:01:15 -0700 (PDT) Received: (qmail 78369 invoked by uid 60001); 23 Apr 2008 06:01:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=TkEC0+eW3z+mjAqmQyXmC3frv9Myp99aR4osatXdewWwP/clD/skpCGe1PLa9UIY6BTy7ESEwYRPO6q0uJnCpjYnmA0Acps2ZOiMkVMJtH+Hfn03Q8QMfOVPreD3fIkabV2iVCMFR+Qm9BYxLHycOdCr4BcnWFHtBUkIFcIc8PQ=; X-YMail-OSG: Fm_fFBYVM1ndUtbJqQvw5_V.7316NS3EpIe0H_on Received: from [121.241.96.5] by web8409.mail.in.yahoo.com via HTTP; Wed, 23 Apr 2008 07:01:19 BST Date: Wed, 23 Apr 2008 07:01:19 +0100 (BST) From: atul garg To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-2106953073-1208930479=:77706" Content-Transfer-Encoding: 8bit Message-ID: <780063.77706.qm@web8409.mail.in.yahoo.com> Subject: [Sip] Urgent SIP INVITES from opposite direction with same callid and sequence numbers.... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --0-2106953073-1208930479=:77706 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline Hi, I need an urgent clarification on the followings set of call.I have observed the following scenario on the real network and it confuses me when i see the two INVITES having same TO,FROM,CSEQ,CALLID (but different VIA) in opposite direction : I am trying to give the scenario below : |Time | 1.1.1.1 | 2.2.2.2 | |0.000 | INVITE | |SIP From: sip:351931015072@sip.optimus.pt To:sip:351931019029@sip.optimus.pt | |(5060) ------------------> (5060) | |0.000 | 100 Trying| |SIP Status | |(5060) <------------------ (5060) | |0.000 | INVITE | |SIP Request | |(5060) <------------------ (5060) | |0.000 | 100 Trying| |SIP Status | |(5060) ------------------> (5060) | |0.000 | 180 Ringing |SIP Status | |(5060) ------------------> (5060) | |0.000 | 200 OK | |SIP Status | |(5060) ------------------> (5060) | |0.000 | ACK | |SIP Request | |(5060) ------------------> (5060) | |0.000 | ACK | |SIP Request | |(5060) <------------------ (5060) | |0.000 | BYE | |SIP Request | |(5060) ------------------> (5060) | |0.000 | BYE | |SIP Request | |(5060) <------------------ (5060) | |0.000 | 200 OK | |SIP Status | |(5060) ------------------> (5060) | I am not sure whether the figure would be that clear or not .Here I am mentioning the first 3 SIP messages Please see the attachment for more description. Regards Atul Best Jokes, Best Friends, Best Food and more. Go to http://in.promos.yahoo.com/groups/bestofyahoo/ --0-2106953073-1208930479=:77706 Content-Type: application/msword; name="SIP_INVITE.doc" Content-Transfer-Encoding: base64 Content-Description: 3092052022-SIP_INVITE.doc Content-Disposition: attachment; filename="SIP_INVITE.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAANAAAAAAAAAAAEAAANgAAAAEAAAD+////AAAAADMAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////spcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA 9w8AAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAAAAAJBBYAHhwAADd8AAA3 fAAA9wsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAA AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAANQAAAAA AAAA1AAAANQAAAAAAAAA1AAAAAAAAADUAAAAAAAAANQAAAAAAAAA1AAAABQA AAAAAAAAAAAAAOgAAAAAAAAA8gkAAAAAAADyCQAAAAAAAPIJAAAAAAAA8gkA AAwAAAD+CQAAJAAAAOgAAAAAAAAAJBMAAPIAAAAuCgAAAAAAAC4KAAAAAAAA LgoAAAAAAAAuCgAAAAAAAC4KAAAAAAAALgoAAAAAAAAuCgAAAAAAAC4KAAAA AAAAoxIAAAIAAAClEgAAAAAAAKUSAAAAAAAApRIAAAAAAAClEgAAAAAAAKUS AAAAAAAApRIAACQAAAAWFAAAIAIAADYWAABMAAAAyRIAABUAAAAAAAAAAAAA AAAAAAAAAAAA1AAAAAAAAAAuCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuCgAA AAAAAC4KAAAAAAAALgoAAAAAAAAuCgAAAAAAAMkSAAAAAAAAgAwAAAAAAADU AAAAAAAAANQAAAAAAAAALgoAAAAAAAAAAAAAAAAAAC4KAAAAAAAA3hIAABYA AACADAAAAAAAAIAMAAAAAAAAgAwAAAAAAAAuCgAATAAAANQAAAAAAAAALgoA AAAAAADUAAAAAAAAAC4KAAAAAAAAoxIAAAAAAAAAAAAAAAAAAIAMAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAALgoAAAAAAACjEgAAAAAAAIAMAADwAQAAgAwAAAAAAABwDgAAHgAAAJsQ AAAYAAAA1AAAAAAAAADUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5xAAAAAAAAAuCgAA AAAAACIKAAAMAAAAcKmSRgelyAHoAAAACgkAAPIJAAAAAAAAegoAAIQBAACz EAAACAAAAAAAAAAAAAAA5xAAALwBAAD0EgAAMAAAACQTAAAAAAAAuxAAACwA AACCFgAAAAAAAP4LAACCAAAAghYAAAAAAADnEAAAAAAAAIAMAAAAAAAA6AAA AAAAAADoAAAAAAAAANQAAAAAAAAA1AAAAAAAAADUAAAAAAAAANQAAAAAAAAA AgDZAAAAfA0NfDAuMDAwICAgIHwgICAgICAgICBJTlZJVEUgICAgfCAgICAg ICAgICAgICAgICAgICB8U0lQIEZyb206IHNpcDozNTE5MzEwMTUwNzJAc2lw Lm9wdGltdXMucHQgIFRvOnNpcDozNTE5MzEwMTkwMjlAc2lwLm9wdGltdXMu cHQNfCAgICAgICAgIHwoNTA2MCkgICAtLS0tLS0tLS0tLS0tLS0tLS0+ICAo NTA2MCkgICB8DQ18MC4wMDAgICAgfCAgICAgICAgIDEwMCBUcnlpbmd8ICAg ICAgICAgICAgICAgICAgIHxTSVAgU3RhdHVzDXwgICAgICAgICB8KDUwNjAp ICAgPC0tLS0tLS0tLS0tLS0tLS0tLSAgKDUwNjApICAgfA0NfDAuMDAwICAg IHwgICAgICAgICBJTlZJVEUgICAgfCAgICAgICAgICAgICAgICAgICB8U0lQ IFJlcXVlc3QNfCAgICAgICAgIHwoNTA2MCkgICA8LS0tLS0tLS0tLS0tLS0t LS0tICAoNTA2MCkgICB8DQ18MC4wMDAgICAgfCAgICAgICAgIDEwMCBUcnlp bmd8ICAgICAgICAgICAgICAgICAgIHxTSVAgU3RhdHVzDXwgICAgICAgICB8 KDUwNjApICAgLS0tLS0tLS0tLS0tLS0tLS0tPiAgKDUwNjApICAgfA0NfDAu MDAwICAgIHwgICAgICAgICAxODAgUmluZ2luZyAgICAgICAgICAgICAgICAg ICB8U0lQIFN0YXR1cw18ICAgICAgICAgfCg1MDYwKSAgIC0tLS0tLS0tLS0t LS0tLS0tLT4gICg1MDYwKSAgIHwNDXwwLjAwMCAgICB8ICAgICAgICAgMjAw IE9LICAgIHwgICAgICAgICAgICAgICAgICAgfFNJUCBTdGF0dXMNfCAgICAg ICAgIHwoNTA2MCkgICAtLS0tLS0tLS0tLS0tLS0tLS0+ICAoNTA2MCkgICB8 DQ18MC4wMDAgICAgfCAgICAgICAgIEFDSyAgICAgICB8ICAgICAgICAgICAg ICAgICAgIHxTSVAgUmVxdWVzdA18ICAgICAgICAgfCg1MDYwKSAgIC0tLS0t LS0tLS0tLS0tLS0tLT4gICg1MDYwKSAgIHwNDXwwLjAwMCAgICB8ICAgICAg ICAgQUNLICAgICAgIHwgICAgICAgICAgICAgICAgICAgfFNJUCBSZXF1ZXN0 DXwgICAgICAgICB8KDUwNjApICAgPC0tLS0tLS0tLS0tLS0tLS0tLSAgKDUw NjApICAgfA0NfDAuMDAwICAgIHwgICAgICAgICBCWUUgICAgICAgfCAgICAg ICAgICAgICAgICAgICB8U0lQIFJlcXVlc3QNfCAgICAgICAgIHwoNTA2MCkg ICAtLS0tLS0tLS0tLS0tLS0tLS0+ICAoNTA2MCkgICB8DQ18MC4wMDAgICAg fCAgICAgICAgIEJZRSAgICAgICB8ICAgICAgICAgICAgICAgICAgIHxTSVAg UmVxdWVzdA18ICAgICAgICAgfCg1MDYwKSAgIDwtLS0tLS0tLS0tLS0tLS0t LS0gICg1MDYwKSAgIHwNDXwwLjAwMCAgICB8ICAgICAgICAgMjAwIE9LICAg IHwgICAgICAgICAgICAgICAgICAgfFNJUCBTdGF0dXMNfCAgICAgICAgIHwo NTA2MCkgICAtLS0tLS0tLS0tLS0tLS0tLS0+ICAoNTA2MCkgICB8DQ0NSSBh bSBtb3JlIGNvbmNlcm5lZCBhYm91dCB0aGUgZmlyc3QgdGhyZWUgY2FsbHMo c3BlY2lhbGx5IFRodyBUV08gSU5WSVRFUykglg0NMTkyLjE2OC45NS4xNzUg LS0tLS0tLS0tLS0tLS0tLS0tSU5WSVRFLS0tLS0tLS0tLS0tLS0oICAxOTIu MTY4Ljk0Ljk5DTE5Mi4xNjguOTQuOTkgIC0tLS0tLS0tLS0tLS0tLS0tLTEw MCBUUllJTkctLS0tLS0tKCAgIDE5Mi4xNjguOTUuMTc1DTE5Mi4xNjguOTQu OTkgIC0tLS0tLS0tLS0tLS0tLS0tLUlOVklURS0tLS0tLS0oICAgMTkyLjE2 OC45NS4xNzUNDQ1JUCBTb3VyY2UHSVAgRGVzdGluYXRpb24HVE8HRlJPTQdW SUEHUkVDT1JELVJPVVRFB0NPTlRBQ1QHUk9VVEUHQlJBTkNIB0NTRVEHQ0FM TCBJRAcHMTkyLjE2OC45NS4xNzUHMTkyLjE2OC45NC45OQc8c2lwOjM1MTkz MTAxOTAyOUBzaXAub3B0aW11cy5wdD4HIkFuYSBDYXJvbGluYSIgPHNpcDoz NTE5MzEwMTUwNzJAc2lwLm9wdGltdXMucHQ+Ow10YWc9ODg3NzIyNjQtOGRk OC00ZjExLTg1NjMtZjFjM2IwNDU2YmI1B1NJUC8yLjAvVURQIDE5Mi4xNjgu OTUuMTc1OjY2NjY7DWJyYW5jaD16OWhHNGJLOW1kNWhyMzA2OGMwZmNnNDE2 ODEuMQcHPHNpcDozNTE5MzEwMTUwNzItamNpaXBzNzJlMnE3MUAxOTIuMTY4 Ljk1LjE3NTo2NjY2O3RyYW5zcG9ydD11ZHA+BzxzaXA6MzUxOTMxMDE5MDI5 DUAxOTIuMTY4Ljk0Ljk5OjY2NjYNO2xyPgd6OWhHNGJLOW1kNWhyMzA2OGMw ZmNnNDE2ODEuMQcxIElOVklURSAHMTFkMTc3NjctYzBlYy00NDBjLWJlYmQt DTcyMzE2M2RlMThhOUANMTAuMjMyLjEwNS42OQcHMTkyLjE2OC45NC45OQcx OTIuMTY4Ljk1LjE3NQc8c2lwOjM1MTkzMTAxOTAyOUBzaXAub3B0aW11cy5w dD4HIkFuYSBDYXJvbGluYSIgPHNpcDozNTE5MzEwMTUwNzJAc2lwLm9wdGlt dXMucHQ+O3RhZz04ODc3MjI2NC04ZGQ4LTRmMTEtODU2My1mMWMzYjA0NTZi YjUHU0lQLzIuMC9VRFAgMTkyLjE2OC45NS4xNzU6NjY2NjticmFuY2g9ejlo RzRiSzltZDVocjMwNjhjMGZjZzQxNjgxLjEHLQctBy0HejloRzRiSzltZDVo cjMwNjhjMGZjZzQxNjgxLjEHMSBJTlZJVEUHMTFkMTc3NjctYzBlYy00NDBj LWJlYmQtDTcyMzE2M2RlMThhOUANMTAuMjMyLjEwNS42OQcHMTkyLjE2OC45 NC45OQcxOTIuMTY4Ljk1LjE3NQc8c2lwOjM1MTkzMTAxOTAyOUBzaXAub3B0 aW11cy5wdD4HIkFuYSBDYXJvbGluYSIgPHNpcDozNTE5MzEwMTUwNzJAc2lw Lm9wdGltdXMucHQ+O3RhZz04ODc3MjI2NC04ZGQ4LTRmMTEtODU2My1mMWMz YjA0NTZiYjUHU0lQLzIuMC9VRFAgMTkyLjE2OC45NC45OTo3Nzc3O2JyYW5j aD16OWhHNGJLNzc2MTlmZDUyNjI1ZGEzOWRhMzBhYWJhZWViOWY1OWJqYWFh YWFhaWFhYWFhYTNndzVsZmEzWnFrdjdnczNxZHhzM3VpNXprYQc8c2lwOjNa cWt2NyUwQWFxYWg0YWFhYWNzaXAlM0EzNTE5MzEwMTkwMjklNDBzaXAub3B0 aW11cy5wdEBncmFwY3NjZjAxLmltcy5pc29uYWUuY29tOjY2NjY7bWFkZHI9 MTkyLjE2OC45NC45OTtscj4HPHNpcDozNTE5MzEwMTUwNzItamNpaXBzNzJl MnE3MUAxOTIuMTY4Ljk1LjE3NTo2NjY2O3RyYW5zcG9ydD11ZHA+Bwd6OWhH NGJLNzc2MTlmZDUyNjI1ZGEzOWRhMzBhYWJhZWViOWY1OWJqYWFhYWFhaWFh YWFhYTNndzVsZmEzWnFrdjdnczNxZHhzM3VpNXprYQcxIElOVklURQcxMWQx Nzc2Ny1jMGVjLTQ0MGMtYmViZC0NNzIzMTYzZGUxOGE5DUAxMC4yMzIuMTA1 LjY5BwcNDQ0NAAAAAAAAAAAAAAQAAMAJAADBCQAAAwoAAAQKAABECgAARQoA AFkKAAByCgAAywoAAA4LAAAlDAAATAwAAPcPAAD98v3y/fL96/3r/QD9AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQ0oQAG1I DARzSAwEABUJagMA4PBDShAAbUgABG5IAAR1CAEEQ0oQAA0ABAAAAgQAAAME AACEBAAAuAQAALkEAAD3BAAAKwUAACwFAABrBQAAnwUAAKAFAADeBQAAEgYA ABMGAABRBgAAhQYAAIYGAADEBgAA+AYAAPkGAAA4BwAAbAcAAG0HAACsBwAA 4AcAAOEHAAAgCAAAVAgAAFUIAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAHQAEAAD3DwAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAQAAQEBVQgAAJQIAADICAAAyQgAAAcJAAA7 CQAAPAkAAD0JAACKCQAAiwkAANEJAAAWCgAAVwoAAFgKAABZCgAAYwoAAHIK AAB1CgAAegoAAH4KAACLCgAAkwoAAJkKAACgCgAApQoAAK0KAACuCgAAvQoA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAA AAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAADttAYAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAEZmAAAAAAYAABYkAUlmAQAAAAUAAAomAAtGAQAAAQAAABu9CgAA ywoAAO0KAAAfCwAASAsAAGkLAACOCwAAjwsAANILAADkCwAA+AsAAP0LAAAb DAAAJQwAAD4MAABMDAAAWgwAAFsMAABpDAAAeAwAAJoMAAD0DAAAOQ0AADsN AAA9DQAAPw0AAF0NAABmDQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AO4EBQAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABGZigCAAAGDwAWJAFJZgEAAAAG AAAWJAFJZgEAAAAAG2YNAAB/DQAAjQ0AAJsNAACcDQAAqg0AALkNAADbDQAA NQ4AAKwOAAAfDwAAYg8AAGMPAAC0DwAAvQ8AANYPAADjDwAA8g8AAPMPAAD0 DwAA9Q8AAPYPAAD3DwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA9FwJAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAA AAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABAAA RmZ4BgAAAAQAAEZmUAQAAAYAABYkAUlmAQAAAAAWHAAfsNAvILDgPSGwDgEi sFoAI5CEAySQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAmAhYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQB AAAI1vYAC5T/mQLqBX4JHg++FEIYIBz+H4IjrCaCMwAGBQMAAAAAAAAAAAAA AAAAAAAAAAZRAwAAAAAAAAAAAAAAAAAAAAAABpQDAAAAAAAAAAAAAAAAAAAA AAAGoAUAAAAAAAAAAAAAAAAAAAAAAAagBQAAAAAAAAAAAAAAAAAAAAAABoQD AAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAA AAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGKgMAAAAAAAAAAAAA AAAAAAAAAAbWDAAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPuMxrWLAAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YsAAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iwA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3W LAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ NNYGAAEKA2wAYfYDAAAmAhYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQB AAAEAQAABAEAAAQBAAAI1vYAC5T/mQLqBX4JHg++FEIYIBz+H4IjrCaCMwAG BQMAAAAAAAAAAAAAAAAAAAAAAAZRAwAAAAAAAAAAAAAAAAAAAAAABpQDAAAA AAAAAAAAAAAAAAAAAAAGoAUAAAAAAAAAAAAAAAAAAAAAAAagBQAAAAAAAAAA AAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAA AAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAG KgMAAAAAAAAAAAAAAAAAAAAAAAbWDAAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU 9gPuMxrWLAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/G9YsAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8c1iwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/x3WLAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAmAhYkARckAUlmAQAAAAKWbAAF 1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1vYAC5T/mQLqBX4JHg++FEIY IBz+H4IjrCaCMwAGBQMAAAAAAAAAAAAAAAAAAAAAAAZRAwAAAAAAAAAAAAAA AAAAAAAABpQDAAAAAAAAAAAAAAAAAAAAAAAGoAUAAAAAAAAAAAAAAAAAAAAA AAagBQAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAG3gMA AAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAA AAAAAAAAAAAAAAAGKgMAAAAAAAAAAAAAAAAAAAAAAAbWDAAAAAAAAAAAAAAA AAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAU9gPuMxrWLAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/G9YsAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iwAAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WLAAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAmAhYkARck AUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1vYAC5T/ mQLqBX4JHg++FEIYIBz+H4IjrCaCMwAGBQMAAAAAAAAAAAAAAAAAAAAAAAZR AwAAAAAAAAAAAAAAAAAAAAAABpQDAAAAAAAAAAAAAAAAAAAAAAAGoAUAAAAA AAAAAAAAAAAAAAAAAAagBQAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAA AAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAA AAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGKgMAAAAAAAAAAAAAAAAAAAAAAAbW DAAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPuMxrWLAAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YsAAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iwAAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WLAAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wA YfYDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAFAAQAAoAAQBpAA8AAwAAAAAAAAAAADAAAEDx/wIAMAAMAAYATgBvAHIA bQBhAGwAAAACAAAAEABfSAEEbUgJBHNICQR0SAkEAAAAAAAAAAAAAAAAAAAA AAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIA YQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAADIAQmABAPIAMgAMAAkAQgBv AGQAeQAgAFQAZQB4AHQAAAAKAA8ADcYFAAFyAwAEAENKEAAAAAAA9wsAAAMA ABwAAAYA/////wAAAAACAAAAAwAAAIQAAAC4AAAAuQAAAPcAAAArAQAALAEA AGsBAACfAQAAoAEAAN4BAAASAgAAEwIAAFECAACFAgAAhgIAAMQCAAD4AgAA +QIAADgDAABsAwAAbQMAAKwDAADgAwAA4QMAACAEAABUBAAAVQQAAJQEAADI BAAAyQQAAAcFAAA7BQAAPAUAAD0FAACKBQAAiwUAANEFAAAWBgAAVwYAAFgG AABZBgAAYwYAAHIGAAB1BgAAegYAAH4GAACLBgAAkwYAAJkGAACgBgAApQYA AK0GAACuBgAAvQYAAMsGAADtBgAAHwcAAEgHAABpBwAAjgcAAI8HAADSBwAA 5AcAAPgHAAD9BwAAGwgAACUIAAA+CAAATAgAAFoIAABbCAAAaQgAAHgIAACa CAAA9AgAADkJAAA7CQAAPQkAAD8JAABdCQAAZgkAAH8JAACNCQAAmwkAAJwJ AACqCQAAuQkAANsJAAA1CgAArAoAAB8LAABiCwAAYwsAALQLAAC9CwAA1gsA AOMLAADyCwAA8wsAAPQLAAD1CwAA9gsAAPkLAACYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAEgADAA AAAAAAAAgAAAAICYAAEgADABAAAAAAAAgAAAAICYAAEgADACAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICrAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICrQAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICrAAAAADAA AAAAAAAAgAAAAICpAAAADzAAAAAAAAAAgAAAAICpAAAADzAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICrAAAAADAA AAAAAAAAgAAAAICrAAAAADAAAAAAAAAAgAAAAICrAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICrAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICZAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAA AICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAA AAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICaAAAAADAAAAAAAAAAgAAAAIAABAAA9w8AAAgAAAAABAAA VQgAAL0KAABmDQAA9w8AAAkAAAALAAAADAAAAA0AAAAABAAA9w8AAAoAAAAA AAAAAQAAAHcFAAB6BQAAzAYAAM8GAAD9BgAAAAcAAA4HAAAcBwAA+QcAAPsH AAD5CwAABAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAAAIAAAANAAAAHQAA AMMAAADQAAAANgEAAEYBAACqAQAAtwEAAB0CAAAqAgAAkAIAAJ0CAAADAwAA EAMAAHcDAACEAwAA6wMAAPgDAABfBAAAbAQAANMEAADgBAAAZwUAAG0FAADB BQAA0AUAAAQGAAAVBgAARQYAAFYGAADMBgAAzwYAAAAHAAABBwAAHwcAACIH AABpBwAAbwcAAJAHAACgBwAA0wcAAOMHAAD4BwAA+wcAAP0HAAAaCAAAeQgA AJgIAACtCAAAyQgAAD8JAABcCQAAugkAANkJAADuCQAACgoAAK0KAAC3CgAA IAsAADALAABjCwAAswsAAPkLAAAEAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAGgAHABoA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHAAAAAAATAgAAUQIAAIsFAABjBgAAiwYAAKUGAACuBgAA vQYAAO0GAAAfBwAAGwgAACUIAABbCAAAeAgAADkJAAA/CQAAXQkAAGYJAABj CwAAtAsAAPkLAAAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwD//wYAAAAIAEcAVQBSADEAMQAxADcANABlAEMAOgBcAEQAbwBj AHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABnAHUA cgAxADEAMQA3ADQAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABh AFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUA YwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAARABvAGMAdQBtAGUAbgB0 ADEALgBhAHMAZAAIAEcAVQBSADEAMQAxADcANAA5AEMAOgBcAEQAbwBjAHUA bQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABnAHUAcgAx ADEAMQA3ADQAXABEAGUAcwBrAHQAbwBwAFwAUwBJAFAAXwBJAE4AVgBJAFQA RQAuAGQAbwBjAAgARwBVAFIAMQAxADEANwA0ADkAQwA6AFwARABvAGMAdQBt AGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGcAdQByADEA MQAxADcANABcAEQAZQBzAGsAdABvAHAAXABTAEkAUABfAEkATgBWAEkAVABF AC4AZABvAGMAAQBsIOBkhFoS0f8P/w//D/8P/w//D/8P/w//DxAAAQAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY /m8oAAIAAAApAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKAFEYSY /hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAA AAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIA AwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQAB EA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAA D4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEA AAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSA FmCEmP4CAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGE TP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAGwg4GQAAAAAAAAAAAAAAAD/ //////8BAAAAAAD//wEAAAASABEACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8A CQQZAAkEGwAJBAAAAADBBQAABAYAABUGAABFBgAAVgYAAFkGAABjBgAAcgYA AHUGAAB6BgAAfgYAAIsGAACTBgAAmQYAAKAGAAClBgAArQYAAK4GAAC9BgAA ywYAAO0GAABIBwAAjgcAAI8HAADSBwAA/QcAABsIAAAlCAAAWggAAFsIAABp CAAAeAgAAJoIAAD0CAAAOQkAADsJAAA9CQAAPwkAAF0JAABmCQAAmwkAAJwJ AACqCQAAuQkAANsJAAA1CgAArAoAAB8LAABiCwAAYwsAALQLAAC9CwAA8gsA APMLAAD5CwAAAAAAAAHdAAAB3QAAAd0AAAHdAAAB3QAACAAAAAIBAAACAQAA AgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAAC AQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIB AAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEA AAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAA lgEAAP9AAYABAAAAAAAAAAAA+IpCAAEAAAAAAAAAAAAAAAAAAABAhMB7AhAA AAAAAAAA9wsAADAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAI AAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAQA AABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABp AG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUH AAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAAC CwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAA OwaQAQIABQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcAaQBu AGcAZABpAG4AZwBzAAAAIgAEAHEIiBgA8NACAABoAQAAAADIusRm3rrEZgAA AAACABYAAAC6AQAA3QkAAAEABQAAAAQAAxAVAAAAAAAAAAAAAAABAAEAAAAB AAAAAAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAKUGwAe0ALQAgAAyMAAAEAAZAGQAAAAZAAAAHAwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFcGAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAATKDUQDwEADfAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAABAHwAAAAAAAAACABHAFUA UgAxADEAMQA3ADQACABHAFUAUgAxADEAMQA3ADQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAA AAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAcAEAABEAAAABAAAAkAAA AAIAAACYAAAAAwAAAKQAAAAEAAAAsAAAAAUAAADEAAAABgAAANAAAAAHAAAA 3AAAAAgAAADwAAAACQAAAAQBAAASAAAAEAEAAAoAAAAsAQAADAAAADgBAAAN AAAARAEAAA4AAABQAQAADwAAAFgBAAAQAAAAYAEAABMAAABoAQAAAgAAAOQE AAAeAAAAAgAAAHwAcwAeAAAAAQAAAAAAcwAeAAAACQAAAEdVUjExMTc0AAAg AB4AAAABAAAAAFVSMR4AAAABAAAAAFVSMR4AAAALAAAATm9ybWFsLmRvdAAA HgAAAAkAAABHVVIxMTE3NAB0AAAeAAAAAgAAADIAUjEeAAAAEwAAAE1pY3Jv c29mdCBXb3JkIDkuMAAAQAAAAAAEyBIDAAAAQAAAAADs9jAEpcgBQAAAAADw vkMHpcgBAwAAAAEAAAADAAAAugEAAAMAAADdCQAAAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAA AAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAOgAAAAMAAAAAQAAAGgA AAAPAAAAcAAAAAUAAAB8AAAABgAAAIQAAAARAAAAjAAAABcAAACUAAAACwAA AJwAAAAQAAAApAAAABMAAACsAAAAFgAAALQAAAANAAAAvAAAAAwAAADKAAAA AgAAAOQEAAAeAAAABAAAAGZzcwADAAAAFQAAAAMAAAAFAAAAAwAAABwMAAAD AAAAoAoJAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEA AAACAAAAfAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAA BQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAP7///8Q AAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v///xgAAAAZAAAAGgAAABsA AAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA/v///yQAAAAlAAAAJgAA ACcAAAAoAAAAKQAAACoAAAD+////LAAAAC0AAAAuAAAALwAAADAAAAAxAAAA MgAAAP7////9////NQAAAP7////+/////v////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADA AAAAAAAARgAAAAAAAAAAAAAAAGDVmUYHpcgBNwAAAIAAAAAAAAAARABhAHQA YQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADgACAAEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABcAAACCFgAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUA bgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa AAIBBgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAB4cAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj AAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkA bgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD///////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsAAAAAEAAA AAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAgAAAAcAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAATwBi AGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABYAAQD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAGDVmUYHpcgBYNWZRgelyAEAAAAAAAAAAAAAAAABAAAA/v////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// /////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9z b2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1 bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --0-2106953073-1208930479=:77706 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --0-2106953073-1208930479=:77706-- From sip-bounces@ietf.org Tue Apr 22 23:44:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D754B28C16D; Tue, 22 Apr 2008 23:44:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9776F3A6880 for ; Tue, 22 Apr 2008 23:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=0.745, 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 ZLJWilp3LqOJ for ; Tue, 22 Apr 2008 23:44:27 -0700 (PDT) Received: from n59.bullet.mail.sp1.yahoo.com (n59.bullet.mail.sp1.yahoo.com [98.136.44.43]) by core3.amsl.com (Postfix) with SMTP id BF8753A6879 for ; Tue, 22 Apr 2008 23:44:27 -0700 (PDT) Received: from [216.252.122.219] by n59.bullet.mail.sp1.yahoo.com with NNFMP; 23 Apr 2008 06:44:33 -0000 Received: from [69.147.65.168] by t4.bullet.sp1.yahoo.com with NNFMP; 23 Apr 2008 06:44:33 -0000 Received: from [127.0.0.1] by omp503.mail.sp1.yahoo.com with NNFMP; 23 Apr 2008 06:44:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 683259.52331.bm@omp503.mail.sp1.yahoo.com Received: (qmail 43205 invoked by uid 60001); 23 Apr 2008 06:44:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=z0ljisiKQrcKB0sxhaF6t53jyyazhaYbZSP0/+07H+1BUnd2+AUM7IDzhSTGrlzYJoMAlhthOPbLTSay9YaEgJh91TeNGHZ2jhCIi7KynGLXS2v9yPFCshpucGMwnY7/Oo6O1dIrdBYepzi5ePIxSJfO7ODZeLPDM0ABCKIayQU=; X-YMail-OSG: yES66L4VM1njrASAMid420GJlbCUk4qvNGJtfr5EqwSM8Il8aK.qfszwYPvV6nrZw93vjG46nj4Am4Mwc2CpUzwDbfhDRDz7kFUPp1c6tLymw4Ika4vucw-- Received: from [121.241.96.5] by web8412.mail.in.yahoo.com via HTTP; Wed, 23 Apr 2008 07:44:31 BST Date: Wed, 23 Apr 2008 07:44:31 +0100 (BST) From: atul garg To: atul garg , sip@ietf.org In-Reply-To: <780063.77706.qm@web8409.mail.in.yahoo.com> MIME-Version: 1.0 Message-ID: <501225.42374.qm@web8412.mail.in.yahoo.com> Subject: Re: [Sip] SORRY WRONG POST Urgent SIP INVITES from opposite direction with same callid and sequence numbers.... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org HI ALL Please ignore my todays post and sorry for inconvenience. --- atul garg wrote: > Hi, > > I need an urgent clarification on the followings set > of call.I have observed the following scenario on > the > real network and it confuses me when i see the two > INVITES having same TO,FROM,CSEQ,CALLID (but > different > VIA) in opposite direction : > > I am trying to give the scenario below : > > |Time | 1.1.1.1 | 2.2.2.2 | > > |0.000 | INVITE | > |SIP > From: sip:351931015072@sip.optimus.pt > To:sip:351931019029@sip.optimus.pt > | |(5060) ------------------> (5060) | > > |0.000 | 100 Trying| > |SIP > Status > | |(5060) <------------------ (5060) | > > |0.000 | INVITE | > |SIP > Request > | |(5060) <------------------ (5060) | > > |0.000 | 100 Trying| > |SIP > Status > | |(5060) ------------------> (5060) | > > |0.000 | 180 Ringing > |SIP > Status > | |(5060) ------------------> (5060) | > > |0.000 | 200 OK | > |SIP > Status > | |(5060) ------------------> (5060) | > > |0.000 | ACK | > |SIP > Request > | |(5060) ------------------> (5060) | > > |0.000 | ACK | > |SIP > Request > | |(5060) <------------------ (5060) | > > |0.000 | BYE | > |SIP > Request > | |(5060) ------------------> (5060) | > > |0.000 | BYE | > |SIP > Request > | |(5060) <------------------ (5060) | > > |0.000 | 200 OK | > |SIP > Status > | |(5060) ------------------> (5060) | > > > I am not sure whether the figure would be that clear > or not .Here I am mentioning the first 3 SIP > messages > > Please see the attachment for more description. > > Regards > Atul > > > > > > Best Jokes, Best Friends, Best Food and more. > Go to http://in.promos.yahoo.com/groups/bestofyahoo/> _______________________________________________ > 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 Bollywood, fun, friendship, sports and more. You name it, we have it on http://in.promos.yahoo.com/groups/bestofyahoo/ _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 23 10:21:33 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944B63A69CA; Wed, 23 Apr 2008 10:21:33 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3420628C1FB for ; Tue, 22 Apr 2008 22:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 GAZIGa12X8qP for ; Tue, 22 Apr 2008 22:46:53 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 8BD063A69FA for ; Tue, 22 Apr 2008 22:46:24 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1235719rvf.49 for ; Tue, 22 Apr 2008 22:46:30 -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:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=B0lRV2qkDnJk8p2PJa+Srh7vOsJ2DeIPDPh4KHSNHzQ=; b=bONssJgUQNeCMX4X4S7k+7lcqpNfq9O5w+3fqEAGtdFoADW75DMK8d9P5/xC7Ff+sPT7bcM743wvgS4Yk+hIXfjpQ6VuJjVi7zrFjSwfKKRj8+Uwf0pGUfVPwtPTHk+uoiRfY7iA/PKKR9SpFljyK7mCc5whZ46Lfr2zF1tn4ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XMgg/4RI9pvlmV/vTQ2yFafi/UaVxcF2tzWYqBTDp36ASLXob3W2hJubx21IG8AZn0aKT/1TykBXmw5k0M1OGZ90z4++1oPSGQK5qWMjETRdmfO5EmPhXZgnTUMY6y6j52V1ajs3QhUHSmKyY7+fyIGyMab8npylFNSev7R/KiE= Received: by 10.141.189.4 with SMTP id r4mr233545rvp.98.1208929590229; Tue, 22 Apr 2008 22:46:30 -0700 (PDT) Received: by 10.140.200.20 with HTTP; Tue, 22 Apr 2008 22:46:30 -0700 (PDT) Message-ID: Date: Wed, 23 Apr 2008 13:46:30 +0800 From: "=?GB2312?B?y+/X2r79?=" To: sip@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Mailman-Approved-At: Wed, 23 Apr 2008 10:21:27 -0700 Subject: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, all I am confused about the conception of session and dialog in RFC 3261. Although someone pointed out the dialog is a relationship between peer-2-peer and session is a multimedia relative relation, I am still not clear about that. For my understanding, the scope of session is wider than dialog means. Dialog can only exists between two peers, one-2-one, but session can contain more than 2 participants, right? For example, one INVITE from UAC can create more than one dialog because of the forked 2xx responses by the proxy server, but the session is determined by session id in the SDP and all the 2xx responses contain the same session id. All the participants belong to the same session. So my conclusion is that one session can contain more than one dialog even though they are created by same method. The relationship between dialog and session is many-2-one, right? If my understanding is right, then comes another question. The scenario is above, one INVITE created more than one dialog, the caller will maintain more than one dialog, he can terminate one of them via BYE method while keeping the other dialog. According to RFC3261, BYE method can terminate a session and its relative dialog. From this statement it seems that my conclusion is not exactly right. Then what is the relationship between session and dialog, one-2-one map or one-2-many map? Your instructions are highly appreciated. Thanks BR Zongjun _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 23 10:28:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30ED63A6B06; Wed, 23 Apr 2008 10:28:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA763A6A32 for ; Wed, 23 Apr 2008 10:28:48 -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 NNOzmy4pJkAQ for ; Wed, 23 Apr 2008 10:28:45 -0700 (PDT) Received: from smtpout3.l-3com.com (smtpout3.l-3com.com [166.20.84.211]) by core3.amsl.com (Postfix) with ESMTP id AAC7D3A6AD0 for ; Wed, 23 Apr 2008 10:28:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,700,1199682000"; d="scan'208,217";a="137160147" From: todd.d.binns@l-3com.com Received: from unknown (HELO HEN-EXCH-1.henschel.l-3com.com) ([166.20.217.20]) by smtpout3.l-3com.com with ESMTP; 23 Apr 2008 13:28:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 13:29:02 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Passing added call information in the SIP packet Thread-Index: AcilZ4WWp/2ytl5qRJW4E9H7kqZ+Sg== To: Subject: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0265596478==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0265596478== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A567.7DA5BCE0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A567.7DA5BCE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have been an user of SIP for a while, but never got into the need = to extend it. I have tried to do an extensive research to see if there = are any draft or RFC that handles the requirements that I am requested = to do. Here is the scenario that I am trying to fulfill. A UA (custom hardware/software) wants to place or change the call into a = secure call. It notifies the other participant by an INVITE or NOTIFY = and both UA agree on the change and the details of the security. There = are several different method of securing the call, and that would be = included in the parameter passed between the UA. If this is not = possible is there a way to embed the parameters into the header of the = INVITE or NOTIFY so at least both UA know of the request? There are a few phones on the market today some using SKINNY and others = using SIP, but it appears that it is being done outside of the SIP = traffic. If anyone can either tell me which draft or RFC to look at; = that I missed. If this does not exist, is there others out there that = are interested in this type of change to SIP; that would like to discuss = it? =20 Thanks, Todd Binns Senior Software Engineer - Communications Henschel, L-3 Communications 9 Malcolm Hoyt Drive Newburyport, MA 01950-4017 Phone: 978.462.2400 Ext: 306 Email: todd.d.binns@l-3com.com =20 ------_=_NextPart_001_01C8A567.7DA5BCE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Passing added call information in the SIP packet

Hi,
   I have been an user of = SIP for a while, but never got into the need to extend it.  I have = tried to do an extensive research to see if there are any draft or RFC = that handles the requirements that I am requested to do.  Here is = the scenario that I am trying to fulfill.

A UA (custom hardware/software) wants = to place or change the call into a secure call.  It notifies the = other participant by an INVITE or NOTIFY and both UA agree on the change = and the details of the security.  There are several different = method of securing the call, and that would be included in the parameter = passed between the UA.  If this is not possible is there a way to = embed the parameters into the header of the INVITE or NOTIFY so at least = both UA know of the request?

There are a few phones on the market = today some using SKINNY and others using SIP, but it appears that it is = being done outside of the SIP traffic.   If anyone can either = tell me which draft or RFC to look at; that I missed.  If this does = not exist, is there others out there that are interested in this type of = change to SIP; that would like to discuss it? 

Thanks,
Todd Binns
Senior Software Engineer - = Communications
Henschel, L-3 Communications
9 Malcolm Hoyt Drive
Newburyport, MA 01950-4017
Phone: 978.462.2400 Ext: 306
Email: todd.d.binns@l-3com.com
=A0

------_=_NextPart_001_01C8A567.7DA5BCE0-- --===============0265596478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0265596478==-- From sip-bounces@ietf.org Wed Apr 23 11:26:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0FC3A6E15; Wed, 23 Apr 2008 11:26:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23823A6B55 for ; Wed, 23 Apr 2008 11:26: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=[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 CUDwU6troGlz for ; Wed, 23 Apr 2008 11:26:48 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 03C2D3A6C6A for ; Wed, 23 Apr 2008 11:26:39 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id H5kM1Z00116AWCUA405800; Wed, 23 Apr 2008 18:25:03 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id H6Sh1Z00C02AVH08S00000; Wed, 23 Apr 2008 18:26:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=1UsA3fyq8JMA:10 a=xJ7_F1JgShoA:10 a=AcXynW70z8Xs_z30H_cA:9 a=oncwVrOOHBMGJHy1JfBfzkcIZfgA:4 a=5Cilyq_4TeQA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m3NIQfEA030518 for ; Wed, 23 Apr 2008 14:26:41 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m3NIQeob030514; Wed, 23 Apr 2008 14:26:40 -0400 Date: Wed, 23 Apr 2008 14:26:40 -0400 Message-Id: <200804231826.m3NIQeob030514@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (todd.d.binns@l-3com.com) References: Subject: Re: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: todd.d.binns@l-3com.com A UA (custom hardware/software) wants to place or change the call into a = secure call. It notifies the other participant by an INVITE or NOTIFY = and both UA agree on the change and the details of the security. There = are several different method of securing the call, and that would be = included in the parameter passed between the UA. If this is not = possible is there a way to embed the parameters into the header of the = INVITE or NOTIFY so at least both UA know of the request? If both UAs are your design, you can just add a private header (whose name starts with "X-") to carry the additional information. SIP agents that do not understand the header are required to ignore it. 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 sip-bounces@ietf.org Wed Apr 23 11:28:57 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC8B3A6C6A; Wed, 23 Apr 2008 11:28:56 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701103A6BEC for ; Wed, 23 Apr 2008 11:28:55 -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+4t65rUA+KK for ; Wed, 23 Apr 2008 11:28:50 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 2FAB53A6DCB for ; Wed, 23 Apr 2008 11:28:50 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id H5hw1Z00E0cQ2SLA80AT00; Wed, 23 Apr 2008 18:27:27 +0000 Received: from dragon.ariadne.com ([76.19.174.1]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id H6Up1Z00802AVH08W00000; Wed, 23 Apr 2008 18:28:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=kw7Fy3SgUE4A:10 a=KDS9DRgR3FIA:10 a=WaMkL01um17ndRMiidMA:9 a=1jcvjL4RXfp2wmKS_b8A:7 a=S-8zzFEkjT-mXmk4uJcKEU_ZFdoA:4 a=MSl-tDqOz04A:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m3NISnEA030680 for ; Wed, 23 Apr 2008 14:28:49 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m3NISnce030676; Wed, 23 Apr 2008 14:28:49 -0400 Date: Wed, 23 Apr 2008 14:28:49 -0400 Message-Id: <200804231828.m3NISnce030676@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (szj087@gmail.com) References: Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org From: "=?GB2312?B?y+/X2r79?=" I am confused about the conception of session and dialog in RFC 3261. Although someone pointed out the dialog is a relationship between peer-2-peer and session is a multimedia relative relation, I am still not clear about that. As I understand the terms, a "session" is the set of media transmisstions described/controlled by a series of SDP offer/answer exchanges. These exchanges are usually carried by the messages in one SIP dialog. 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 sip-bounces@ietf.org Wed Apr 23 13:49:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A166F28C301; Wed, 23 Apr 2008 13:49:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FA128C2CD for ; Wed, 23 Apr 2008 13:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 hU6nfsJdLF0D for ; Wed, 23 Apr 2008 13:49:13 -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 1928A28C3CC for ; Wed, 23 Apr 2008 13:46:48 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2008 13:46:53 -0700 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 m3NKkrGe020795; Wed, 23 Apr 2008 13:46:53 -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 m3NKkrcT022301; Wed, 23 Apr 2008 20:46:53 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, 23 Apr 2008 13:46:53 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.88.66]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 13:46:53 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Apr 2008 15:46:38 -0500 To: Dale.Worley@comcast.net, sip@ietf.org From: "James M. Polk" In-Reply-To: <200804231828.m3NISnce030676@dragon.ariadne.com> References: <200804231828.m3NISnce030676@dragon.ariadne.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 23 Apr 2008 20:46:53.0341 (UTC) FILETIME=[295E64D0:01C8A583] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1338; t=1208983613; x=1209847613; 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]=20What's=20the=20difference=20bet ween=20session=20and=20dialog=20in=0A=20=20SIP? |Sender:=20; bh=XMOJ0WT1w1/DMlrDGPBeAk9cacWsW1u4Yv5PIk/xWP0=; b=m9Lpe/jZWZrLxqlKNjnMlh+2fpavHHtzKF3ucfF0ToBum3yTv6yAAhK8zw yJ+wK1HEktRzOs5KISloXc9P+e/PFVIFjfzXQUkHIDVPTm8xzHUMX8dC0OvV kCR1nYB7Fi; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 01:28 PM 4/23/2008, Dale.Worley@comcast.net wrote: > From: "=?GB2312?B?y+/X2r79?=" > > I am confused about the conception of session and dialog in RFC 3261. > Although someone pointed out the dialog is a relationship between > peer-2-peer and session is a multimedia relative relation, I am still > not clear about that. > >As I understand the terms, a "session" is the set of media >transmisstions described/controlled by a series of SDP offer/answer >exchanges. These exchanges are usually carried by the messages in one >SIP dialog. To this too, these terms are often meant to be interchangeable - even though technically they are separate terms with subtlety different actual meanings (SDP "sessions", and SIP "dialogs"). Sessions and Dialogs can, sometimes mean the same thing. Thus it requires a bit of understanding the context in which either is stated in to understand if they are meaning one or the other, or were misused for the same meaning. >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 sip-bounces@ietf.org Wed Apr 23 14:15:50 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA2A3A6E74; Wed, 23 Apr 2008 14:15:50 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F463A69ED for ; Wed, 23 Apr 2008 14:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Jw0jS3kuQYAV for ; Wed, 23 Apr 2008 14:15:46 -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 8DD433A6E3C for ; Wed, 23 Apr 2008 14:15:46 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2008 14:15:52 -0700 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 m3NLFqaY012986; Wed, 23 Apr 2008 14:15:52 -0700 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3NLFpwP021167; Wed, 23 Apr 2008 21:15:51 GMT From: "Dan Wing" To: , References: Date: Wed, 23 Apr 2008 14:15:51 -0700 Message-ID: <078a01c8a587$359cdde0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: AcilZ4WWp/2ytl5qRJW4E9H7kqZ+SgAH6osw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1799; t=1208985352; x=1209849352; 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]=20Passing=20added=20call=20inform ation=20in=20the=20SIP=20packet |Sender:=20; bh=4jG8QLs12kXLzz6fPyyPrLhXkUaShLEoXWn5DpouccU=; b=Ch3gCDdJOTRwhgvfqRcPDAQfISeHK1XKOLdh30+5T2BB6bSZ7PGftD3Ctp Pyrgh/nsC0+KMwm25JODRGohFfxW6wLIStc3cwchbEYWUsMO4rAV2LM2JW+a h71+3ykour; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of todd.d.binns@l-3com.com > Sent: Wednesday, April 23, 2008 10:29 AM > To: sip@ietf.org > Subject: [Sip] Passing added call information in the SIP packet > > Hi, > I have been an user of SIP for a while, but never got into > the need to extend it. I have tried to do an extensive > research to see if there are any draft or RFC that handles > the requirements that I am requested to do. Here is the > scenario that I am trying to fulfill. > > A UA (custom hardware/software) wants to place or change the > call into a secure call. Secure call = SRTP (RFC3711)? -d > It notifies the other participant > by an INVITE or NOTIFY and both UA agree on the change and > the details of the security. There are several different > method of securing the call, and that would be included in > the parameter passed between the UA. If this is not possible > is there a way to embed the parameters into the header of the > INVITE or NOTIFY so at least both UA know of the request? > > There are a few phones on the market today some using SKINNY > and others using SIP, but it appears that it is being done > outside of the SIP traffic. If anyone can either tell me > which draft or RFC to look at; that I missed. If this does > not exist, is there others out there that are interested in > this type of change to SIP; that would like to discuss it? > > Thanks, > Todd Binns > Senior Software Engineer - Communications > Henschel, L-3 Communications > 9 Malcolm Hoyt Drive > Newburyport, MA 01950-4017 > Phone: 978.462.2400 Ext: 306 > Email: todd.d.binns@l-3com.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 sip-bounces@ietf.org Wed Apr 23 15:52:22 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F79D3A68E6; Wed, 23 Apr 2008 15:52:22 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C443A68FF for ; Wed, 23 Apr 2008 15:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBiet2gzlgcb for ; Wed, 23 Apr 2008 15:52:19 -0700 (PDT) Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by core3.amsl.com (Postfix) with ESMTP id 5838E3A68E6 for ; Wed, 23 Apr 2008 15:52:19 -0700 (PDT) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipai.ntcif.telstra.com.au with ESMTP; 24 Apr 2008 08:52:21 +1000 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id C95F2FF81 for ; Thu, 24 Apr 2008 08:52:20 +1000 (EST) Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id IAA01715 for ; Thu, 24 Apr 2008 08:52:20 +1000 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2952.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 08:52:20 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 08:52:17 +1000 Message-ID: <903E4F74808D4F4B93635C9D9183EBAC036227F0@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <078a01c8a587$359cdde0$c2f0200a@cisco.com> Thread-Topic: SIP vrs TEL URI Thread-Index: AcilZ4WWp/2ytl5qRJW4E9H7kqZ+SgAH6oswAANMrqA= From: "Robins, Ellen" To: X-OriginalArrivalTime: 23 Apr 2008 22:52:20.0078 (UTC) FILETIME=[AFA750E0:01C8A594] Subject: [Sip] SIP vrs TEL URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi everyone, Please help to provide an easy to understand explanation of differences between SIP and TEL URI. What is the latest preference/recommendation? Thanks in advance / Ellen Robins _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 23 17:41:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912353A68F1; Wed, 23 Apr 2008 17:41:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D643A6D0D for ; Wed, 23 Apr 2008 17:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 LMHt3Zfd3uFp for ; Wed, 23 Apr 2008 17:41:19 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id EF6683A683D for ; Wed, 23 Apr 2008 17:40:44 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1442055rvf.49 for ; Wed, 23 Apr 2008 17:40:50 -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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=31ALILv46egccHmWzPBeLCFIIdfAOtiteB6HlG4r/EA=; b=kDbrZgBpObKdKpQQUt2qOGC/sIM/+8HVzESBdYwwhP8RxrgzJ5pPhVSnGqaft2cnq0B8f04AFuUJgVyBo3OqTmbOpTFweA4n8W2qFh72baSTxIPL6rNZCjnFsvTMPxKzQjilQs/dhA7/3WY1eBx72NRVNGJ1amXlHnnKJ73jXCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=grxSa2suOm+VfpK9PvBYkx7b7V33AGdlAZd1mKEDHAk3B7KN70FBl6PUcaOlbKPch4jml/u6ICGZgE6tgMoMWbO7kU5aWiBVQ3TZvoPId1ryiEk0lFcE4pq6/IJH+W0y4UjEe3w7nhMcA7D4f1jWJ9r+KtN5tZVnpefW6Mo1tKs= Received: by 10.141.122.20 with SMTP id z20mr822514rvm.239.1208997650412; Wed, 23 Apr 2008 17:40:50 -0700 (PDT) Received: by 10.140.133.21 with HTTP; Wed, 23 Apr 2008 17:40:50 -0700 (PDT) Message-ID: Date: Thu, 24 Apr 2008 08:40:50 +0800 From: "=?GB2312?B?y+/X2r79?=" To: "James M. Polk" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <200804231828.m3NISnce030676@dragon.ariadne.com> Cc: sip@ietf.org Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for all your kindly explanation. Do you mean that dialog and session is one-2-one relationship and only for different scenario and different context? Thanks BR Zongjun 2008/4/24, James M. Polk : > At 01:28 PM 4/23/2008, Dale.Worley@comcast.net wrote: > > From: "=?GB2312?B?y+/X2r79?=" > > > > I am confused about the conception of session and dialog in RFC 3261. > > Although someone pointed out the dialog is a relationship between > > peer-2-peer and session is a multimedia relative relation, I am still > > not clear about that. > > > >As I understand the terms, a "session" is the set of media > >transmisstions described/controlled by a series of SDP offer/answer > >exchanges. These exchanges are usually carried by the messages in one > >SIP dialog. > > > To this too, these terms are often meant to be interchangeable - even > though technically they are separate terms with subtlety different > actual meanings (SDP "sessions", and SIP "dialogs"). Sessions and > Dialogs can, sometimes mean the same thing. Thus it requires a bit of > understanding the context in which either is stated in to understand > if they are meaning one or the other, or were misused for the same meaning. > > > > >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 > _______________________________________________ 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 sip-bounces@ietf.org Wed Apr 23 18:08:16 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D243A68DD; Wed, 23 Apr 2008 18:08:16 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA333A67EB for ; Wed, 23 Apr 2008 18:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.126 X-Spam-Level: ** X-Spam-Status: No, score=2.126 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, 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 YWxlE-oD0w4R for ; Wed, 23 Apr 2008 18:08:13 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 934943A683D for ; Wed, 23 Apr 2008 18:08:13 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1446925rvf.49 for ; Wed, 23 Apr 2008 18:08:19 -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:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=eiaSOau5Zz8wW6vReyurmHiEqjexTbQdUNquQeh3XbE=; b=gnBmdezKdEC0lLQVZxDmKnHu9wIbxxTyIm35ujYIKi6/FBJkl/RdFAGYrV0jG+BzYwE1lf77IniGHCD6Gr8xprvSrxzAMrbbP7EqJOjzJzKRA4K4z90osB8LG43FcCIk4INVOHRAtOMNhTleZzeQLgmRly6hn1L7U8yRfo5V3Xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qC3nK3GXgjRenqE33Bpq/QrEMScE/C9gaKrdIk/vA1qFEp5QqfUx9w4hjzctXzw0yErU5rVac9JQkj9jQBg7Iaz9L+lAlGN4nBbAZHGfWhe0i0IldQplkpo6wYLBphB2QW18lDyXcRGzHJNP0fC60v4jWX7xjA9QNYdC/p0vljA= Received: by 10.141.136.19 with SMTP id o19mr975031rvn.250.1208999299135; Wed, 23 Apr 2008 18:08:19 -0700 (PDT) Received: by 10.140.133.21 with HTTP; Wed, 23 Apr 2008 18:08:19 -0700 (PDT) Message-ID: Date: Thu, 24 Apr 2008 09:08:19 +0800 From: "=?GB2312?B?y+/X2r79?=" To: lylavoie@iol.unh.edu, discussion@sipforum.org, sip@ietf.org In-Reply-To: <480FDA2E.30707@iol.unh.edu> MIME-Version: 1.0 Content-Disposition: inline References: <200804231828.m3NISnce030676@dragon.ariadne.com> <480FDA2E.30707@iol.unh.edu> Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SGksIExpbmNvbG4KCnRoYW5rcyBmb3IgeW91ciBpbnN0cnVjdGlvbnMuCgpJIGtub3cgdGhhdCBk aWFsb2cgY2FuIGV4aXN0IHdpdGhvdXQgc2Vzc2lvbiBzaW5jZSBTVUJTQ1JJQkUvUkVGRVIgY2Fu CmNyZWF0ZSBkaWFsb2cgYW5kIHdpdGhvdXQgYW55IG1lZGlhIGJldHdlZW4gY29tbXVuaWNhdGlv biBwZWVycy4KCldoYXQgSSB3YW50IHRvIGtub3cgaXMgdGhlIHJlbGF0aW9uc2hpcCBvZiBkaWFs b2cgYW5kIHNlc3Npb24gd2hlbgp0aGV5IGJvdGggZXhpc3QgaW4gb25lIGNvbW11bmljYXRpb24g YWN0aXZpdHkuIFRha2UgYSBleGFtcGxlLCB3aGVuCnRoZXJlIGFyZSAyIHBlcnNvbiBwYXJ0aWNp cGF0aW5nIHRhbGtzIHdpdGggdm9pY2UsIHdlIHNheSB0aGVyZSBpcyBhCmRpYWxvZyBhbmQgYSBz ZXNzaW9uLgoKQnV0IHdoZW4gb25lIGNhbGxlciBpbnZpdGVzIGFub3RoZXIgY2FsbGVlIGFuZCBn ZXRzIGZpdmUgMjAwIGZpbmFsCnJlc3BvbnNlcyBmcm9tIDUgVUEgZXZlcnkgb2Ygd2hpY2ggaGFz IGl0cyBvd24gc2Vzc2lvbiBkZXNjcmlwdGlvbi4gV2UKY2FuIHNheSB0aGF0IHRoZXJlIGFyZSA1 IGRpYWxvZ3MgYmV0d2VlbiBjYWxsZXIgYW5kIHRoZSBvdGhlciA1CmNhbGxlZXMsIHJpZ2h0PyBB bmQgdGhlbiB3aGF0IGlzIHRoZSBleGFjdCBudW1iZXIgb2Ygc2Vzc2lvbiBpbiB0aGlzCnNjZW5h cmlvPyBPbmUgc2Vzc2lvbiBvciBmaXZlIHNlc3Npb24/IFRoYXQgaXMgd2hhdCBJIHdhbnQgdG8g a25vdy4KCkRpYWxvZyBpcyBkZXRlcm1pbmVkIGJ5IGRpYWxvZ0lEIChjYWxsLWlkLCBmcm9tL3Rv IHRhZykgYW5kIHNlc3Npb24gaWQKaXMgZGV0ZXJtaW5lZCBieSBzZXNzaW9uIGlkIGdpdmVuIGlu IHRoZSBTRFAgbWVzc2FnZS4gIE15IGFuc3dlciBpcwp0aGVyZSBhcmUgNSBkaWFsb2cgYW5kIG9u ZSBzZXNzaW9uIG5vdywgcmlnaHQ/CgpUaGFua3MgZm9yIHlvdXIgZnVydGhlciBpbnN0cnVjdGlv bnMKClpvbmdqdW4KCjIwMDgvNC8yNCwgTGluY29sbiBZLiBMYXZvaWUgPGx5bGF2b2llQGlvbC51 bmguZWR1PjoKPiBIZWxsbyBCUiwKPgo+ICAgIEluIHRoZSBzdHJpY3Rlc3QgY29udGV4dCwgdGhl IGRpYWxvZyBleGlzdHMgb25seSBpbiBTSVAgYW5kIGNhbiBleGlzdAo+IHdpdGhvdXQgdGhlIGVz dGFibGlzaG1lbnQgb2YgYSBtZWRpYSBzZXNzaW9uIChzZXR1cCB0aHJvdWdoIFNEUCkuICBUbyBk ZWZpbmUKPiBhIGRpYWxvZywgdGhlIFNJUCBzcGVjaWZpY2F0aW9uIFJGQy0zMjYxIGRlZmluZXMg c2V2ZXJhbCBxdWFsaWZpZXJzLCB3aGljaAo+IGFsbCBtdXN0IGJlIHByZXNlbnQgaW4gdGhlIFNJ UCBtZXNzYWdlcywgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCwgdGhleSBhcmUKPiB0YWcgcGFyYW1l dGVycyBpbiB0aGUgVE8vRlJPTSBoZWFkZXJzLCBhbmQgYSBDQUxMSUQgaGVhZGVyLiAgWW91IHNo b3VsZAo+IGNoZWNrIG91ciBSRkMtMzI2MSB0byBsb29rIGZvciB0aGUgb3RoZXJzLgo+ICAgIEZv ciBhIHNpbXBsZSBleGFtcGxlIG9mIGEgZGlhbG9nIHdpdGhvdXQgU0RQLCB0aGluayBvZiB0aGUg cHJlc2VuY2UKPiBzdWJzY3JpcHRpb24gY2FzZS4gIEluIHRoaXMgY2FzZSwgdGhlIFNVQlNDUklC RSByZXF1ZXN0IG1lc3NhZ2UgYW5kIDIwME9LCj4gcmVzcG9uc2UgZXN0YWJsaXNoIHRoZSBTSVAg ZGlhbG9nLiAgQWZ0ZXIgdGhhdCwgYWxsIHRoZSBOT1RJRlkgbWVzc2FnZXMgdXNlCj4gdGhlIHNh bWUgZGlhbG9nIHRvIHRyYW5zbWl0IHRoZSByZXF1ZXN0ZWQgaW5mb3JtYXRpb24uICBUaGUgYWN0 dWFsCj4gaW5mb3JtYXRpb24gaXMgdXN1YWxseSBjYXJyaWVkIGRpcmVjdGx5IGluIHRoZSBzYW1l IHBhY2tldCwgZW5jb2RlZCBhcyBEU0wKPiBvciBzb21ldGhpbmcuCj4KPiAgQ2hlZXJzLAo+ICBM aW5jb2xuCj4KPgo+ICDL79favv0gd3JvdGU6Cj4KPiA+IFRoYW5rcyBmb3IgIGFsbCB5b3VyIGtp bmRseSBleHBsYW5hdGlvbi4KPiA+Cj4gPiBEbyB5b3UgbWVhbiB0aGF0IGRpYWxvZyBhbmQgc2Vz c2lvbiBpcyBvbmUtMi1vbmUgcmVsYXRpb25zaGlwIGFuZCBvbmx5Cj4gPiBmb3IgZGlmZmVyZW50 IHNjZW5hcmlvIGFuZCBkaWZmZXJlbnQgY29udGV4dD8KPiA+Cj4gPiBUaGFua3MKPiA+IEJSCj4g PiBab25nanVuCj4gPgo+ID4gMjAwOC80LzI0LCBKYW1lcyBNLiBQb2xrIDxqbXBvbGtAY2lzY28u Y29tPjoKPiA+Cj4gPgo+ID4gPiBBdCAwMToyOCBQTSA0LzIzLzIwMDgsIERhbGUuV29ybGV5QGNv bWNhc3QubmV0IHdyb3RlOgo+ID4gPiAgPiAgICBGcm9tOiAiPT9HQjIzMTI/Qj95Ky9YMnI3OT89 IiA8c3pqMDg3QGdtYWlsLmNvbT4KPiA+ID4gID4KPiA+ID4gID4gICAgSSBhbSBjb25mdXNlZCBh Ym91dCB0aGUgY29uY2VwdGlvbiBvZiBzZXNzaW9uIGFuZCBkaWFsb2cgaW4gUkZDCj4gMzI2MS4K PiA+ID4gID4gICAgQWx0aG91Z2ggc29tZW9uZSBwb2ludGVkIG91dCB0aGUgZGlhbG9nIGlzIGEg cmVsYXRpb25zaGlwIGJldHdlZW4KPiA+ID4gID4gICAgcGVlci0yLXBlZXIgYW5kIHNlc3Npb24g aXMgYSBtdWx0aW1lZGlhIHJlbGF0aXZlIHJlbGF0aW9uLCBJIGFtCj4gc3RpbGwKPiA+ID4gID4g ICAgbm90IGNsZWFyIGFib3V0IHRoYXQuCj4gPiA+ICA+Cj4gPiA+ICA+QXMgSSB1bmRlcnN0YW5k IHRoZSB0ZXJtcywgYSAic2Vzc2lvbiIgaXMgdGhlIHNldCBvZiBtZWRpYQo+ID4gPiAgPnRyYW5z bWlzc3Rpb25zIGRlc2NyaWJlZC9jb250cm9sbGVkIGJ5IGEgc2VyaWVzIG9mIFNEUCBvZmZlci9h bnN3ZXIKPiA+ID4gID5leGNoYW5nZXMuICBUaGVzZSBleGNoYW5nZXMgYXJlIHVzdWFsbHkgY2Fy cmllZCBieSB0aGUgbWVzc2FnZXMgaW4gb25lCj4gPiA+ICA+U0lQIGRpYWxvZy4KPiA+ID4KPiA+ ID4KPiA+ID4gVG8gdGhpcyB0b28sIHRoZXNlIHRlcm1zIGFyZSBvZnRlbiBtZWFudCB0byBiZSBp bnRlcmNoYW5nZWFibGUgLSBldmVuCj4gPiA+ICB0aG91Z2ggdGVjaG5pY2FsbHkgdGhleSBhcmUg c2VwYXJhdGUgdGVybXMgd2l0aCBzdWJ0bGV0eSBkaWZmZXJlbnQKPiA+ID4gIGFjdHVhbCBtZWFu aW5ncyAoU0RQICJzZXNzaW9ucyIsIGFuZCBTSVAgImRpYWxvZ3MiKS4gU2Vzc2lvbnMgYW5kCj4g PiA+ICBEaWFsb2dzIGNhbiwgc29tZXRpbWVzIG1lYW4gdGhlIHNhbWUgdGhpbmcuIFRodXMgaXQg cmVxdWlyZXMgYSBiaXQgb2YKPiA+ID4gIHVuZGVyc3RhbmRpbmcgdGhlIGNvbnRleHQgaW4gd2hp Y2ggZWl0aGVyIGlzIHN0YXRlZCBpbiB0byB1bmRlcnN0YW5kCj4gPiA+ICBpZiB0aGV5IGFyZSBt ZWFuaW5nIG9uZSBvciB0aGUgb3RoZXIsIG9yIHdlcmUgbWlzdXNlZCBmb3IgdGhlIHNhbWUKPiBt ZWFuaW5nLgo+ID4gPgo+ID4gPgo+ID4gPgo+ID4gPiAgPkRhbGUKPiA+ID4gID5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gPiAgPlNpcCBtYWlsaW5n IGxpc3QKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcAo+ID4gPiAg PlRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2Nv bAo+ID4gPiAgPlVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rp b25zIG9uCj4gY3VycmVudCBzaXAKPiA+ID4gID5Vc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3 IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwCj4gPiA+Cj4gPiA+ICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gPiAgU2lwIG1h aWxpbmcgbGlzdAo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwCj4g PiA+ICBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJv dG9jb2wKPiA+ID4gIFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVl c3Rpb25zIG9uCj4gY3VycmVudCBzaXAKPiA+ID4gIFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBu ZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXAKPiA+ID4KPiA+ID4KPiA+ ID4KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4g PiBTaXAgbWFpbGluZyBsaXN0Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXAKPiA+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJ UCBQcm90b2NvbAo+ID4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBx dWVzdGlvbnMgb24KPiBjdXJyZW50IHNpcAo+ID4gVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5l dyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcAo+ID4KPiA+Cj4KPiAgLS0K PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqCj4gIExpbmNvbG4gTGF2b2llCj4gIFNlbmlvciBFbmdpbmVlcgo+ICBV TkggSW50ZXJPcGVyYWJpbGl0eSBMYWJvcmF0b3J5Cj4gIDEyMSBUZWNobm9sb2d5IERyaXZlLCBT dWl0ZSAyLCBEdXJoYW0sIE5IIDAzODI0Cj4gICsxLTYwMy04NjItNDgwOQo+ICBFbWFpbDogbHls YXZvaWVAaW9sLnVuaC5lZHUKPiAgQUlNOiBMaW5jb2xuQXRJT0wKPgo+ICBBcnMgc2luZSBzY2ll bnRpYSBuaWhpbCBlc3QhIC0tIEFydCB3aXRob3V0IHNjaWVuY2UgaXMgbm90aGluZy4KPiAgU2Np ZW50aWEgc2luZSBhcnMgZXN0IHZhY3VhISAtLSBTY2llbmNlIHdpdGhvdXQgYXJ0IGlzIGVtcHR5 Lgo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioKPgo+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fClNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBj b3JlIFNJUCBQcm90b2NvbApVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9y IHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcApVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRl dmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lw From sip-bounces@ietf.org Wed Apr 23 20:19:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715803A69EA; Wed, 23 Apr 2008 20:19:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECE53A69EA for ; Wed, 23 Apr 2008 20:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 GVCMwkg3aiEX for ; Wed, 23 Apr 2008 20:19:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5161D3A6852 for ; Wed, 23 Apr 2008 20:19:38 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3O3JdHO023016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2008 22:19:41 -0500 Message-Id: From: Dean Willis To: "Robins, Ellen" In-Reply-To: <903E4F74808D4F4B93635C9D9183EBAC036227F0@WSMSG2103V.srv.dir.telstra.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 23 Apr 2008 22:19:33 -0500 References: <903E4F74808D4F4B93635C9D9183EBAC036227F0@WSMSG2103V.srv.dir.telstra.com> X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] SIP vrs TEL URI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 23, 2008, at 5:52 PM, Robins, Ellen wrote: > Hi everyone, > Please help to provide an easy to understand explanation of > differences > between SIP and TEL URI. > What is the latest preference/recommendation? A TEL URI encodes a user identity that is a telephone number. A SIP URI encodes a user identity that may be a telephone number, may just look like a telephone number, or might be something else entirely. In theory, tel provides a preferred encoding for telephone numbers. In practice, almost nothing uses it. We've been debating recommendations along this divide steadily for the last few weeks. -- 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 sip-bounces@ietf.org Wed Apr 23 20:23:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1FC3A6ACD; Wed, 23 Apr 2008 20:23:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EF23A6A65 for ; Wed, 23 Apr 2008 20:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 R+qlc9D1QNbW for ; Wed, 23 Apr 2008 20:23:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E11243A683D for ; Wed, 23 Apr 2008 20:23:38 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3O3NgJu023049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2008 22:23:43 -0500 Message-Id: From: Dean Willis To: todd.d.binns@l-3com.com In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 23 Apr 2008 22:23:36 -0500 References: X-Mailer: Apple Mail (2.919.2) Cc: sip@ietf.org Subject: Re: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Apr 23, 2008, at 12:29 PM, todd.d.binns@l-3com.com wrote: > Hi, > I have been an user of SIP for a while, but never got into the > need to extend it. I have tried to do an extensive research to see > if there are any draft or RFC that handles the requirements that I > am requested to do. Here is the scenario that I am trying to fulfill. > > A UA (custom hardware/software) wants to place or change the call > into a secure call. It notifies the other participant by an INVITE > or NOTIFY and both UA agree on the change and the details of the > security. There are several different method of securing the call, > and that would be included in the parameter passed between the UA. > If this is not possible is there a way to embed the parameters into > the header of the INVITE or NOTIFY so at least both UA know of the > request? > What do you mean, "secured call"? This term means many different things to even more different people. You might look at: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-08.txt which has completed working group last call and I'm about to send to the IESG, and at: http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements-04.txt and http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-01.txt which, if I recall aright, are currently in working group last call. -- 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 sip-bounces@ietf.org Wed Apr 23 21:34:21 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BE83A6890; Wed, 23 Apr 2008 21:34:21 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF003A6A29 for ; Wed, 23 Apr 2008 21:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 2mTbf0jMr-Ea for ; Wed, 23 Apr 2008 21:34:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9A8E83A6A09 for ; Wed, 23 Apr 2008 21:34:17 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m3O4Y4pE023383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2008 23:34:05 -0500 Message-Id: From: Dean Willis To: SIP IETF Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 23 Apr 2008 23:33:59 -0500 X-Mailer: Apple Mail (2.919.2) Cc: Cullen Jennings , Francois Audet , Keith Drage Subject: [Sip] Draft shepherd writeup for draft-ietf-sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I seem to have lucked into the job of shepherding the SIPS draft through the IESG. This process is more or less documented at: http://www3.tools.ietf.org/group/proto/home/ The first step is prepping the document for IESG submission. This entails giving it a read-through, running the idnots checker, looking for a few common errors, and so on. There's a checklist for the writeup. The following is my first draft at the writeup. Please look through and see if there's anything you disagree with or you think I just got wrong. I'll plan to send this into the IESG relatively soon. Thanks! --------------- Document Shepherd Write-Up for draft-ietf-sip-sips This based on is template for the Document Shepherd Write-Up dated February 1, 2007. (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 Dean Willis, current co-chair of the SIP working group. He has reviewed this version of the document and several previous versions in depth and believes this version (outside of minor reference issues noted herein) 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? The document has been extensively reviewed within the working group and received extensive additional refinement from our security area adviser Eric Rescorla. It entered working group last call as version -05 on July 9, 2007 and was subsequently reviewed through three iterations. (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? No. (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. This shepherd has no issues of this sort. (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? This draft enjoys a relatively high level of working group consensus. We've repeatedly revisited every issue until all known significant issues (other than the fundamentals of underlying complexity) have been resolved. (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.) This shepherd is unaware of any evidence of extreme 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? This shepherd has verified that the document satisfies all I-D nits. Note that the idnits tool falsely reports a non-compliant IP address -- the text it cites is actually a chapter-and-paragraph reference to another document. Also noted is that this document references both the obsolete RFC 2543 and current RFC 3261. This dual reference is intentional, as it is the intent of this document to clarify an issue with RFC 2543 that RFC 3261 also tried to clarify. Note also that this document references draft-ietf-sip-outbound-11, which is currently -13. The material referenced has not been affected by these revisions, and publication of this document by the RF editor will be blocked pending publication of draft-ietf-sip-outbound anyhow. (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 references are properly divided. There is a normative reference to draft-ietf-sip-outbound that will probably delay this document. (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 [RFC2434]. 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? The IANA Considerations section is present and appears to be reasonable. (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? The document appears to contain no sections specified in a formal language. (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. Technical Summary: This document updates RFC 3261 to provide clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). This document also provides a discussion of possible future steps in specification. The SIPS URI scheme was originally documented in RFC 3261, but experience has shown that the specification therein is incomplete, and that at least one use case that increased the complexity of the specification (the "last hop exception") can be eliminated. Several possible error conditions relating to mismatch of sips vs. sip on sending and receiving ends exist. This documents adds new SIP error codes to provide for the detection and correction of these error conditions. 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? Working Group Summary: There were several topics of significance that are worth noting. The foremost is the deprecation of the "last hop exception" from RFC 3261. This exception allowed a proxy/registrar supporting SIPS to relay requests received using SIPS on to user agent servers that did not indicate support for SIPS. This increases the complexity of implementations and weakens the end-to-end assurance of signaling security provided by SIPS. After extensive debate, the working group resolved to eliminate this exception and make SIPS fully end-to-end. Doing so required extensive discussion and annotation on what "end to end" means in the context of gateways to non-SIP protocols. Detection and correction of error conditions resulting where a UAC has specified a SIPS request and the terminating UAS has not registered a SIP contact, or where the UAC has specified a SIP request and the terminating UAS has registered only a SIP contact was another problem requiring extensive discussion. The "obvious" approach of using 400 class responses created problems when interacting with forking proxies. The WG concluded on using two new 300-class SIP response codes to enable request resolution in these scenarios. During the process of developing this specification, the working group began to converge on a new process for incrementally updating RFC 3261. As a precursor to this process, this specification contains an appendix that provides explicit in-context changes to RFC 3261 as required by this specification. The intent here is to reduce the complexity of discussions at interoperability events. 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? There are several notable implementations of the specification at varying levels of maturity. The SIPIt interop events have included SIPS for some time, and the changes in this specification were in-part driven by experiences at those interop events. The document' Acknowledgements section cites numerous active participants for providing detailed review. _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 24 02:04:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E833A67D8; Thu, 24 Apr 2008 02:04:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC91D3A67D8 for ; Thu, 24 Apr 2008 02:04:26 -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 t7TT-5gBvkqD for ; Thu, 24 Apr 2008 02:04:25 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id D2ABE3A67A3 for ; Thu, 24 Apr 2008 02:04:25 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so4043283pyg.24 for ; Thu, 24 Apr 2008 02:04:31 -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:to:subject:mime-version:content-type; bh=gwHE6MN0Rnd3kXYMoFf2kzBsfdcVXgeFhBqbgI2ZVj4=; b=F9L6jEuLIeLbhWAKDJxfK0mzw/2aOwLah2kW0dIE0Vl8S3NlINYEP2SMVaPudHt4bEmuAqnfJ9/aOk5Y6Fm/uagz5JgelDkH27OmbtC+nK+3mVTVAkMM5ewQFkyefYpxKvYIWGndto94jsJUSkmvUfDvudIX9gy9xSiT3/qJb4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=jeMUoq82bAHKscqtg4TfkQRB1xE4vuDPyo0dtwTyZ0V4utrkCJmAcavjvVYM1wa49O9CRhMjqXxQpVcE95iOWJXE2vwj1Yqa/+yLSlB3BdTh4rPRGqgQwwG3ahdlErLj5rfGtzM7m+XRVtFV1YJv0JqDX0who+WyP4ayGj/TF/c= Received: by 10.140.88.11 with SMTP id l11mr1133452rvb.74.1209027870592; Thu, 24 Apr 2008 02:04:30 -0700 (PDT) Received: by 10.141.97.13 with HTTP; Thu, 24 Apr 2008 02:04:30 -0700 (PDT) Message-ID: Date: Thu, 24 Apr 2008 14:34:30 +0530 From: "ajay thakur" To: sip@ietf.org MIME-Version: 1.0 Subject: [Sip] SIP refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380123852==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1380123852== Content-Type: multipart/alternative; boundary="----=_Part_10362_26040087.1209027870580" ------=_Part_10362_26040087.1209027870580 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi guys, I have one doubt related to refer method. A---------| | |--------Router-----------------C B---------| In the above topology A & B phones are internal phones. C is external phone. Scenario is A calls C and then A refers B to C; So when A sends refer message to C it includes B's SIP URI. Now my doubt is can we have port number along with this address. e.g. Refer-To: Thanks Ajay ------=_Part_10362_26040087.1209027870580 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi guys,
I have one doubt related to refer method.
 
 
A---------|
           |
           |--------Router-----------------C
B---------|
 
In the above topology A & B phones are internal phones. C is external phone.
 
Scenario is A calls C  and then A refers B to C;
 
So when A sends refer message to C it includes B's SIP URI. Now my doubt is
can we have port number along with this address.
 
e.g. Refer-To:<sip:xxx@ip-address:port-number>
 
 
Thanks
Ajay ------=_Part_10362_26040087.1209027870580-- --===============1380123852== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1380123852==-- From sip-bounces@ietf.org Thu Apr 24 07:01:18 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833843A6CCB; Thu, 24 Apr 2008 07:01:18 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2833A6A02; Thu, 24 Apr 2008 07:01:17 -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 FtWE3F1D+0e9; Thu, 24 Apr 2008 07:01:16 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id C68163A6CD0; Thu, 24 Apr 2008 07:00:48 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m3OE0nvn010787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Apr 2008 09:00:49 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m3OE0l0J008065; Thu, 24 Apr 2008 09:00:47 -0500 (CDT) Message-ID: <48109290.80309@alcatel-lucent.com> Date: Thu, 24 Apr 2008 09:00:48 -0500 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: =?ISO-8859-1?Q?=CB=EF=D7=DA=BE=FD?= References: <200804231828.m3NISnce030676@dragon.ariadne.com> <480FDA2E.30707@iol.unh.edu> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There is some work progressing in the BMWG WG to create performance metrics around SIP. One of the first tasks in such an endeavor is to define the notion of dialogs and sessions. Please see Section 3.1.1 of https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/dra= ft-ietf-bmwg-sip-term-00.txt of the above draft for some insight. =CB=EF=D7=DA=BE=FD wrote: > Hi, Lincoln > = > thanks for your instructions. > = > I know that dialog can exist without session since SUBSCRIBE/REFER can > create dialog and without any media between communication peers. > = > What I want to know is the relationship of dialog and session when > they both exist in one communication activity. Take a example, when > there are 2 person participating talks with voice, we say there is a > dialog and a session. > = > But when one caller invites another callee and gets five 200 final > responses from 5 UA every of which has its own session description. We > can say that there are 5 dialogs between caller and the other 5 > callees, right? And then what is the exact number of session in this > scenario? One session or five session? That is what I want to know. > = > Dialog is determined by dialogID (call-id, from/to tag) and session id > is determined by session id given in the SDP message. My answer is > there are 5 dialog and one session now, right? - vijay -- = Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 24 16:42:30 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD303A6C88; Thu, 24 Apr 2008 16:42:30 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727483A67A3 for ; Thu, 24 Apr 2008 02:02:16 -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 pzwmq95MoqOU for ; Thu, 24 Apr 2008 02:02:15 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id E69F23A67D8 for ; Thu, 24 Apr 2008 02:02:14 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id i7so1414338tid.25 for ; Thu, 24 Apr 2008 02:02:18 -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:to:subject:mime-version:content-type; bh=SzOe66SqK0u0jvy4gdwUZeZElRzooC5ujh7q18remLM=; b=nB85BkfjiX0IGkGM0ZwLeAlrm14MGwxNZAtEzOoAuUZAtNaQidCF7aLR3pFGnyiOXMzq/2PKmxKhsLQQVFC8yt+4YiV0+17uW4oT8gB5hYpxGbTII9QQQxUUqIkC/MSUJArYWa61wkD1i1RcI01yS8aWghGJKxrwz7IyenaA0E0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=d198VZA9YUyDbsT1Wdcp0CzW+HmC69YDGVF8JyEeWSTNbgB3qkk+/FMcV9MCxB0JVI5nja31t5SF2Ss1oD3Pasmz4Wr14hGvzRoCV7Y7UDKOexyC/qqWhIP4hz2T8nKYzxxxAMJfxHCGsnbQkUZsj13Mv5dxNHekYVHlcqX1NRE= Received: by 10.110.73.3 with SMTP id v3mr273220tia.21.1209027738877; Thu, 24 Apr 2008 02:02:18 -0700 (PDT) Received: by 10.110.105.15 with HTTP; Thu, 24 Apr 2008 02:02:18 -0700 (PDT) Message-ID: Date: Thu, 24 Apr 2008 14:32:18 +0530 From: "Ajay Thakur" To: sip@ietf.org MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 24 Apr 2008 16:42:27 -0700 Subject: [Sip] SIP refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1882555655==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1882555655== Content-Type: multipart/alternative; boundary="----=_Part_49_16943766.1209027738891" ------=_Part_49_16943766.1209027738891 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi guys, I have one doubt related to refer method. A---------| | |--------Router-----------------C B---------| In the above topology A & B phones are internal phones. C is external phone. Scenario is A calls C and then A refers B to C; So when A sends refer message to C it includes B's SIP URI. Now my doubt is can we have port number along with this address. e.g. Refer-To: Thanks Ajay ------=_Part_49_16943766.1209027738891 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi guys,
I have one doubt related to refer method.
 
 
A---------|
           |
           |--------Router-----------------C
B---------|
 
In the above topology A & B phones are internal phones. C is external phone.
 
Scenario is A calls C  and then A refers B to C;
 
So when A sends refer message to C it includes B's SIP URI. Now my doubt is
can we have port number along with this address.
 
e.g. Refer-To:<sip:xxx@ip-address:port-number>
 
 
Thanks
Ajay
------=_Part_49_16943766.1209027738891-- --===============1882555655== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1882555655==-- From sip-bounces@ietf.org Thu Apr 24 17:03:46 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AA23A6915; Thu, 24 Apr 2008 17:03:46 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9AD3A6915 for ; Thu, 24 Apr 2008 17:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 i9oTFFEjyfMM for ; Thu, 24 Apr 2008 17:03:43 -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 CECA53A69B9 for ; Thu, 24 Apr 2008 17:03:43 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 24 Apr 2008 17:03:49 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3P03nxY030651; Thu, 24 Apr 2008 17:03:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m3P03nlR007021; Fri, 25 Apr 2008 00:03:49 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); Thu, 24 Apr 2008 17:03:48 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.72.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 17:03:48 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Apr 2008 19:03:27 -0500 To: "ajay thakur" , sip@ietf.org From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 25 Apr 2008 00:03:48.0666 (UTC) FILETIME=[D643A9A0:01C8A667] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1144; t=1209081829; x=1209945829; c=relaxed/simple; s=sjdkim4002; 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]=20SIP=20refer=20method |Sender:=20; bh=41XioAVrP0RXW9F+vgM+2FIBWGHTiGEGXa5n3KD88bA=; b=oWunpSE8JXEavb/PmOVICLgzTk+rIzz5KMg6UpdHKKgpDdYHsKJl9YHOaT nURHrseCf0hHpuCsRBhoo4hjQS4tcLUpBt42YchI+CnVNADNY8pLeia8S/KN 0ouiKVhi84; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Sip] SIP refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 04:04 AM 4/24/2008, ajay thakur wrote: >Hi guys, >I have one doubt related to refer method. > > >A---------| > | > |--------Router-----------------C >B---------| > >In the above topology A & B phones are internal phones. C is external phone. > >Scenario is A calls C and then A refers B to C; If A calls C, the either A or C need to send the REFER to the other, telling one of them to contact B. For example, A calls C, and then A sends REFER to C to contact B. C will now send an INVITE to B with a Contact: header value of A > >So when A sends refer message to C it includes B's SIP URI. In the Refer-To: header, yes >Now my doubt is >can we have port number along with this address. why not? > >e.g. Refer-To: > > >Thanks >Ajay >_______________________________________________ >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 sip-bounces@ietf.org Thu Apr 24 17:18:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB4E3A6B7E; Thu, 24 Apr 2008 17:18:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293D63A6BA1 for ; Thu, 24 Apr 2008 17:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.146 X-Spam-Level: * X-Spam-Status: No, score=1.146 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 uvXotGrz0mLM for ; Thu, 24 Apr 2008 17:18:20 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 260013A63EC for ; Thu, 24 Apr 2008 17:18:15 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1687679rvf.49 for ; Thu, 24 Apr 2008 17:18:20 -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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MW5d6BZyEDcD6TDg+cDcKOc+XpVZknqiQMsrKYgeDSI=; b=MUjMuSGRGY0ln0n13bjPOJjWA9FzMkR6XQuK1GLlpM1ul3m1aZBIXDu8Bmnv14kIURY7WL1XHJv7rXGYyMfSu76MIwmcD+ijLgF8P5OAFx93gtAiIpLO6ywYQTi1fxLh7IfM74/pr1LQpz+zMKNM1hV7PuZ4+mUjlKCwWT0H5Rk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J3hbW8AMAe/1nOx+gaaDSWUWUfKPWPI176S6gV1KHHVzb0WxFsbodUwY6n6iWQGi5ThLHRq+eZVaCVGUxC6TYCmxegAcuj8Z/1gXXSVHcFkbOVW72UqdeFXNRNBnQ1LPhEd7hx7D+2RLGRwKoY/1rnRMVmYSk5NvIV/2l10W8Xo= Received: by 10.141.71.8 with SMTP id y8mr1588918rvk.32.1209082700123; Thu, 24 Apr 2008 17:18:20 -0700 (PDT) Received: by 10.140.133.21 with HTTP; Thu, 24 Apr 2008 17:18:19 -0700 (PDT) Message-ID: Date: Fri, 25 Apr 2008 08:18:19 +0800 From: "=?GB2312?B?y+/X2r79?=" To: "Vijay K. Gurbani" In-Reply-To: <48109290.80309@alcatel-lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <200804231828.m3NISnce030676@dragon.ariadne.com> <480FDA2E.30707@iol.unh.edu> <48109290.80309@alcatel-lucent.com> Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Vijay Thanks very much for your timely answers. From this specification, session is a combination of signaling plane and media plane messages and processes that enable two or more participants to communicate. I think session is a larger scope than dialog. In another word, one session can contain more than one dialog. Is what I understand right? Zongjun 2008/4/24, Vijay K. Gurbani : > There is some work progressing in the BMWG WG to create performance > metrics around SIP. One of the first tasks in such an endeavor > is to define the notion of dialogs and sessions. Please see > Section 3.1.1 of > https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/d= raft-ietf-bmwg-sip-term-00.txt > of the above draft for some insight. > > =CB=EF=D7=DA=BE=FD wrote: > > > Hi, Lincoln > > > > thanks for your instructions. > > > > I know that dialog can exist without session since SUBSCRIBE/REFER can > > create dialog and without any media between communication peers. > > > > What I want to know is the relationship of dialog and session when > > they both exist in one communication activity. Take a example, when > > there are 2 person participating talks with voice, we say there is a > > dialog and a session. > > > > But when one caller invites another callee and gets five 200 final > > responses from 5 UA every of which has its own session description. We > > can say that there are 5 dialogs between caller and the other 5 > > callees, right? And then what is the exact number of session in this > > scenario? One session or five session? That is what I want to know. > > > > Dialog is determined by dialogID (call-id, from/to tag) and session id > > is determined by session id given in the SDP message. My answer is > > there are 5 dialog and one session now, right? > > > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ 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 sip-bounces@ietf.org Thu Apr 24 23:18:28 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37B33A6A1C; Thu, 24 Apr 2008 23:18:28 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC653A6883 for ; Thu, 24 Apr 2008 23:18:26 -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 NtJ14SlclQkt for ; Thu, 24 Apr 2008 23:18:25 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id BFE443A6C12 for ; Thu, 24 Apr 2008 23:18:25 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1738198rvf.49 for ; Thu, 24 Apr 2008 23:18:30 -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:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=JkNShfBZEECKj8Qg3koG7yAcPKdWIoP4PWy1Uq4+R5k=; b=L2A8FTQfkjiW7cjQ5CE0pTag2JnMIT4zDZehBKI8OoByrVuw036iQfASKLiyKx8EP8Z7CqMNQHJHoEMDW8EEd5cEmJMo1mM6P0jubPBN4cktLxBp3CqAGa6NzMJWyun8LQEup7n+ixjHCyiZT8xV0k8iV7C3+2Xe727TglWtOF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=k6efSTyLtuf0iYMorreQB6nBClt/AjIrJdlBGyE7QEh3KaGFDtzhsS0KbCZGye36/AmLAjNQaucJPEXj6iMwfXmvmpcj+sC0898ucaWeBCKFol67ceEUQ51UiO78Lwd0H/9gVcfnVC+VAhy3BGJVrjWkH2K9nVcqzkeqPWzqYwc= Received: by 10.141.34.12 with SMTP id m12mr1677594rvj.26.1209104310756; Thu, 24 Apr 2008 23:18:30 -0700 (PDT) Received: by 10.141.97.13 with HTTP; Thu, 24 Apr 2008 23:18:30 -0700 (PDT) Message-ID: Date: Fri, 25 Apr 2008 11:48:30 +0530 From: "ajay thakur" To: "James M. Polk" In-Reply-To: MIME-Version: 1.0 References: Cc: sip@ietf.org Subject: Re: [Sip] SIP refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1435996630==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1435996630== Content-Type: multipart/alternative; boundary="----=_Part_3461_26456376.1209104310764" ------=_Part_3461_26456376.1209104310764 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline James If there is any kind of firewall enabled on Router then connection from C to B is not allowed. That's what is main worry :( Ajay On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk wrote: > At 04:04 AM 4/24/2008, ajay thakur wrote: > >> Hi guys, >> I have one doubt related to refer method. >> >> >> A---------| >> | >> |--------Router-----------------C >> B---------| >> >> In the above topology A & B phones are internal phones. C is external >> phone. >> >> Scenario is A calls C and then A refers B to C; >> > > If A calls C, the either A or C need to send the REFER to the other, > telling one of them to contact B. For example, A calls C, and then A sends > REFER to C to contact B. C will now send an INVITE to B with a Contact: > header value of A > > >> So when A sends refer message to C it includes B's SIP URI. >> > > In the Refer-To: header, yes > > Now my doubt is >> can we have port number along with this address. >> > > why not? > > >> e.g. Refer-To: >> >> >> Thanks >> Ajay >> _______________________________________________ >> 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 >> > > ------=_Part_3461_26456376.1209104310764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
James If there is any kind of firewall enabled on Router then connection
from C to B is not allowed. That's what is main worry :(
 
Ajay

On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk <jmpolk@cisco.com> wrote:
At 04:04 AM 4/24/2008, ajay thakur wrote:
Hi guys,
I have one doubt related to refer method.


A---------|
          |
          |--------Router-----------------C
B---------|

In the above topology A & B phones are internal phones. C is external phone.

Scenario is A calls C  and then A refers B to C;

If A calls C, the either A or C need to send the REFER to the other, telling one of them to contact B.  For example, A calls C, and then A sends REFER to C to contact B. C will now send an INVITE to B with a Contact: header value of A



So when A sends refer message to C it includes B's SIP URI.

In the Refer-To: header, yes


Now my doubt is
can we have port number along with this address.

why not?


e.g. Refer-To:<sip:xxx@ip-address:port-number>


Thanks
Ajay
_______________________________________________
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


------=_Part_3461_26456376.1209104310764-- --===============1435996630== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1435996630==-- From sip-bounces@ietf.org Fri Apr 25 02:33:59 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744E828C18A; Fri, 25 Apr 2008 02:33:59 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C39828C16A for ; Fri, 25 Apr 2008 02:33:57 -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 ni6Yac03ExOL for ; Fri, 25 Apr 2008 02:33:56 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236]) by core3.amsl.com (Postfix) with ESMTP id 81D0828C201 for ; Fri, 25 Apr 2008 02:33:56 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id o21so4400567qba.9 for ; Fri, 25 Apr 2008 02:34:01 -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:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=VtaDhdSB9Iuol4UMulofalFjTbEwbw3P8OOijPpPScI=; b=TDjuJJHvFUrQGbYxd7MrsZ2c6kGbhQMJR6Iq7wEHFaANgqwF3S54TREbOfgtGsfGjAwzwhwrsTd6ODG5GrPZ3DQr3cvIdZV3LuE2MMmXQ6XqWjvmgcJ3EZA8bKzJvPyqivS+7SK7+B3pHkx8iioT8ikgT4UIF//FoeG4x5oppUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=u2tLypv5/rPn4+UczMtUBty/h2peF0vkAm/hD0g/B9F5xHak6EX/z3X/OkUHkcdRsS9DIWgV3m90Bgrz73WwAs1NFWV/tKKJcq/3cW2OMEQlMAknLAn9gVXr2bU/53cekqoVmuafN8IgX3aPfpWmUSJ7H898pHRLuFhRjVXdWBo= Received: by 10.142.12.14 with SMTP id 14mr733088wfl.81.1209116040520; Fri, 25 Apr 2008 02:34:00 -0700 (PDT) Received: by 10.142.204.13 with HTTP; Fri, 25 Apr 2008 02:34:00 -0700 (PDT) Message-ID: Date: Fri, 25 Apr 2008 17:34:00 +0800 From: "Donald Lee" To: "ajay thakur" In-Reply-To: MIME-Version: 1.0 References: Cc: sip@ietf.org, "James M. Polk" Subject: Re: [Sip] SIP refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2086487751==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2086487751== Content-Type: multipart/alternative; boundary="----=_Part_3932_28095853.1209116040507" ------=_Part_3932_28095853.1209116040507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline in case there is firewall or like nat issues b/w C and B, the normal REFER will be failed to enable the C INVITE B. how the INVITE can be routed to B correctly? On Fri, Apr 25, 2008 at 2:18 PM, ajay thakur wrote: > James If there is any kind of firewall enabled on Router then connection > from C to B is not allowed. That's what is main worry :( > > Ajay > > On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk wrote: > >> At 04:04 AM 4/24/2008, ajay thakur wrote: >> >>> Hi guys, >>> I have one doubt related to refer method. >>> >>> >>> A---------| >>> | >>> |--------Router-----------------C >>> B---------| >>> >>> In the above topology A & B phones are internal phones. C is external >>> phone. >>> >>> Scenario is A calls C and then A refers B to C; >>> >> >> If A calls C, the either A or C need to send the REFER to the other, >> telling one of them to contact B. For example, A calls C, and then A sends >> REFER to C to contact B. C will now send an INVITE to B with a Contact: >> header value of A >> >> >>> So when A sends refer message to C it includes B's SIP URI. >>> >> >> In the Refer-To: header, yes >> >> Now my doubt is >>> can we have port number along with this address. >>> >> >> why not? >> >> >>> e.g. Refer-To: >>> >>> >>> Thanks >>> Ajay >>> _______________________________________________ >>> 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 > -- BR Donald ------=_Part_3932_28095853.1209116040507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline in case there is firewall or like nat issues b/w C and B, the normal REFER will be failed to enable the C INVITE B.  how the INVITE can be routed to B correctly?

On Fri, Apr 25, 2008 at 2:18 PM, ajay thakur <thakur.ajay.ietf@gmail.com> wrote:
James If there is any kind of firewall enabled on Router then connection
from C to B is not allowed. That's what is main worry :(
 
Ajay

On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk <jmpolk@cisco.com> wrote:
At 04:04 AM 4/24/2008, ajay thakur wrote:
Hi guys,
I have one doubt related to refer method.


A---------|
          |
          |--------Router-----------------C
B---------|

In the above topology A & B phones are internal phones. C is external phone.

Scenario is A calls C  and then A refers B to C;

If A calls C, the either A or C need to send the REFER to the other, telling one of them to contact B.  For example, A calls C, and then A sends REFER to C to contact B. C will now send an INVITE to B with a Contact: header value of A



So when A sends refer message to C it includes B's SIP URI.

In the Refer-To: header, yes


Now my doubt is
can we have port number along with this address.

why not?


e.g. Refer-To:<sip:xxx@ip-address:port-number>


Thanks
Ajay
_______________________________________________
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



--
BR
Donald ------=_Part_3932_28095853.1209116040507-- --===============2086487751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2086487751==-- From sip-bounces@ietf.org Fri Apr 25 02:44:48 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C506C28C0F3; Fri, 25 Apr 2008 02:44:48 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DA83A6D75 for ; Fri, 25 Apr 2008 02:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EJ6wupuqQfjf for ; Fri, 25 Apr 2008 02:44:44 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by core3.amsl.com (Postfix) with ESMTP id 8236D3A6D8A for ; Fri, 25 Apr 2008 02:44:44 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so3017859wxd.31 for ; Fri, 25 Apr 2008 02:44:49 -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:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=QrDsIiRGbi2A888OEfHaDAX3ZKxsjLDLfKz84gi6kjI=; b=WdoLfzHrFHugQL/OdmKKhVOXHp3DwKBbq666gcFlvZBIeinmZnCBFoDBv/XtPyPyZTAdsy5mgIt0YdacUWFvelCtDNbFvGPlGbZXFWDngyxuzk6xc9vadiOIFdVl+Mzni/t0DibGRhogeKebfbWJwLBrKN1eS//GqZUZPIsANfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sxvBH7ApqPwo9guIsktnCvCqWi5ZS4MO7hLoclLqhGaqI56ZZuR7/lLY2Pg3VZh9sfTsfoCt24vUby0yHhLuFy85u1k5OEfkYWoeLevQarEp3qxQ4AdKlMcE+WyOqzagJxHeeBiQcz2lAPvGlfzZ0SrQPry+5/ZC/7ZQdwF3U1I= Received: by 10.142.12.14 with SMTP id 14mr690706wfl.336.1209116688410; Fri, 25 Apr 2008 02:44:48 -0700 (PDT) Received: by 10.142.204.13 with HTTP; Fri, 25 Apr 2008 02:44:48 -0700 (PDT) Message-ID: Date: Fri, 25 Apr 2008 17:44:48 +0800 From: "Donald Lee" To: "=?GB2312?B?y+/X2r79?=" In-Reply-To: MIME-Version: 1.0 References: <200804231828.m3NISnce030676@dragon.ariadne.com> <480FDA2E.30707@iol.unh.edu> <48109290.80309@alcatel-lucent.com> Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1945717764==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1945717764== Content-Type: multipart/alternative; boundary="----=_Part_3961_28689448.1209116688359" ------=_Part_3961_28689448.1209116688359 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline b2xkIGdvb2QgcXVlc3Rpb25zIGluIHNpcCwgYWxzbyBhZGQgYW5vdGhlciAidHJhbnNhY3Rpb24i LgoKCk9uIEZyaSwgQXByIDI1LCAyMDA4IGF0IDg6MTggQU0sIOWtmeWul+WQmyA8c3pqMDg3QGdt YWlsLmNvbT4gd3JvdGU6Cgo+IEhpLCBWaWpheQo+Cj4gVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91 ciB0aW1lbHkgYW5zd2Vycy4KPgo+IEZyb20gdGhpcyBzcGVjaWZpY2F0aW9uLCAgc2Vzc2lvbiBp cyBhIGNvbWJpbmF0aW9uIG9mIHNpZ25hbGluZyBwbGFuZQo+IGFuZCBtZWRpYSBwbGFuZSBtZXNz YWdlcyBhbmQgcHJvY2Vzc2VzIHRoYXQgZW5hYmxlIHR3byBvciBtb3JlCj4gcGFydGljaXBhbnRz IHRvIGNvbW11bmljYXRlLiBJIHRoaW5rIHNlc3Npb24gaXMgYSBsYXJnZXIgc2NvcGUgdGhhbgo+ IGRpYWxvZy4gSW4gYW5vdGhlciB3b3JkLCBvbmUgc2Vzc2lvbiBjYW4gY29udGFpbiBtb3JlIHRo YW4gb25lIGRpYWxvZy4KPiBJcyB3aGF0IEkgdW5kZXJzdGFuZCByaWdodD8KPgo+IFpvbmdqdW4K Pgo+Cj4gMjAwOC80LzI0LCBWaWpheSBLLiBHdXJiYW5pIDx2a2dAYWxjYXRlbC1sdWNlbnQuY29t PjoKPiA+IFRoZXJlIGlzIHNvbWUgd29yayBwcm9ncmVzc2luZyBpbiB0aGUgQk1XRyBXRyB0byBj cmVhdGUgcGVyZm9ybWFuY2UKPiA+ICBtZXRyaWNzIGFyb3VuZCBTSVAuICBPbmUgb2YgdGhlIGZp cnN0IHRhc2tzIGluIHN1Y2ggYW4gZW5kZWF2b3IKPiA+ICBpcyB0byBkZWZpbmUgdGhlIG5vdGlv biBvZiBkaWFsb2dzIGFuZCBzZXNzaW9ucy4gIFBsZWFzZSBzZWUKPiA+ICBTZWN0aW9uIDMuMS4x IG9mCj4gPgo+IGh0dHBzOi8vc3ZuLnJlc2lwcm9jYXRlLm9yZy9yZXAvaWV0Zi1kcmFmdHMvZ3Vy YmFuaS9ibXdnLXNpcC1iZW5jaC10ZXJtL2RyYWZ0LWlldGYtYm13Zy1zaXAtdGVybS0wMC50eHQK PiA+ICBvZiB0aGUgYWJvdmUgZHJhZnQgZm9yIHNvbWUgaW5zaWdodC4KPiA+Cj4gPiAgw4vDr8OX w5rCvsO9IHdyb3RlOgo+ID4KPiA+ID4gSGksIExpbmNvbG4KPiA+ID4KPiA+ID4gdGhhbmtzIGZv ciB5b3VyIGluc3RydWN0aW9ucy4KPiA+ID4KPiA+ID4gSSBrbm93IHRoYXQgZGlhbG9nIGNhbiBl eGlzdCB3aXRob3V0IHNlc3Npb24gc2luY2UgU1VCU0NSSUJFL1JFRkVSIGNhbgo+ID4gPiBjcmVh dGUgZGlhbG9nIGFuZCB3aXRob3V0IGFueSBtZWRpYSBiZXR3ZWVuIGNvbW11bmljYXRpb24gcGVl cnMuCj4gPiA+Cj4gPiA+IFdoYXQgSSB3YW50IHRvIGtub3cgaXMgdGhlIHJlbGF0aW9uc2hpcCBv ZiBkaWFsb2cgYW5kIHNlc3Npb24gd2hlbgo+ID4gPiB0aGV5IGJvdGggZXhpc3QgaW4gb25lIGNv bW11bmljYXRpb24gYWN0aXZpdHkuIFRha2UgYSBleGFtcGxlLCB3aGVuCj4gPiA+IHRoZXJlIGFy ZSAyIHBlcnNvbiBwYXJ0aWNpcGF0aW5nIHRhbGtzIHdpdGggdm9pY2UsIHdlIHNheSB0aGVyZSBp cyBhCj4gPiA+IGRpYWxvZyBhbmQgYSBzZXNzaW9uLgo+ID4gPgo+ID4gPiBCdXQgd2hlbiBvbmUg Y2FsbGVyIGludml0ZXMgYW5vdGhlciBjYWxsZWUgYW5kIGdldHMgZml2ZSAyMDAgZmluYWwKPiA+ ID4gcmVzcG9uc2VzIGZyb20gNSBVQSBldmVyeSBvZiB3aGljaCBoYXMgaXRzIG93biBzZXNzaW9u IGRlc2NyaXB0aW9uLiBXZQo+ID4gPiBjYW4gc2F5IHRoYXQgdGhlcmUgYXJlIDUgZGlhbG9ncyBi ZXR3ZWVuIGNhbGxlciBhbmQgdGhlIG90aGVyIDUKPiA+ID4gY2FsbGVlcywgcmlnaHQ/IEFuZCB0 aGVuIHdoYXQgaXMgdGhlIGV4YWN0IG51bWJlciBvZiBzZXNzaW9uIGluIHRoaXMKPiA+ID4gc2Nl bmFyaW8/IE9uZSBzZXNzaW9uIG9yIGZpdmUgc2Vzc2lvbj8gVGhhdCBpcyB3aGF0IEkgd2FudCB0 byBrbm93Lgo+ID4gPgo+ID4gPiBEaWFsb2cgaXMgZGV0ZXJtaW5lZCBieSBkaWFsb2dJRCAoY2Fs bC1pZCwgZnJvbS90byB0YWcpIGFuZCBzZXNzaW9uIGlkCj4gPiA+IGlzIGRldGVybWluZWQgYnkg c2Vzc2lvbiBpZCBnaXZlbiBpbiB0aGUgU0RQIG1lc3NhZ2UuICBNeSBhbnN3ZXIgaXMKPiA+ID4g dGhlcmUgYXJlIDUgZGlhbG9nIGFuZCBvbmUgc2Vzc2lvbiBub3csIHJpZ2h0Pwo+ID4gPgo+ID4K PiA+ICAtIHZpamF5Cj4gPiAgLS0KPiA+ICBWaWpheSBLLiBHdXJiYW5pLCBCZWxsIExhYm9yYXRv cmllcywgQWxjYXRlbC1MdWNlbnQKPiA+ICAyNzAxIEx1Y2VudCBMYW5lLCBSbS4gOUYtNTQ2LCBM aXNsZSwgSWxsaW5vaXMgNjA1MzIgKFVTQSkKPiA+ICBFbWFpbDogdmtnQHthbGNhdGVsLWx1Y2Vu dC5jb20sYmVsbC1sYWJzLmNvbSxhY20ub3JnfQo+ID4gIFdXVzogICBodHRwOi8vd3d3LmFsY2F0 ZWwtbHVjZW50LmNvbS9iZWxsLWxhYnMKPiA+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcAo+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3Bt ZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbAo+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNv bHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwCj4gVXNlIHNpcHBpbmdAaWV0 Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcAo+CgoK Ci0tIApCUgpEb25hbGQK ------=_Part_3961_28689448.1209116688359 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline b2xkIGdvb2QgcXVlc3Rpb25zIGluIHNpcCwgYWxzbyBhZGQgYW5vdGhlciAmcXVvdDt0cmFuc2Fj dGlvbiZxdW90Oy48YnI+PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBB cHIgMjUsIDIwMDggYXQgODoxOCBBTSwg5a2Z5a6X5ZCbICZsdDs8YSBocmVmPSJtYWlsdG86c3pq MDg3QGdtYWlsLmNvbSI+c3pqMDg3QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4KSGksIFZpamF5PGJyPgo8YnI+ClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgdGlt ZWx5IGFuc3dlcnMuPGJyPgo8YnI+CkZyb20gdGhpcyBzcGVjaWZpY2F0aW9uLCAmbmJzcDtzZXNz aW9uIGlzIGEgY29tYmluYXRpb24gb2Ygc2lnbmFsaW5nIHBsYW5lPGJyPgphbmQgbWVkaWEgcGxh bmUgbWVzc2FnZXMgYW5kIHByb2Nlc3NlcyB0aGF0IGVuYWJsZSB0d28gb3IgbW9yZTxicj4KcGFy dGljaXBhbnRzIHRvIGNvbW11bmljYXRlLiBJIHRoaW5rIHNlc3Npb24gaXMgYSBsYXJnZXIgc2Nv cGUgdGhhbjxicj4KZGlhbG9nLiBJbiBhbm90aGVyIHdvcmQsIG9uZSBzZXNzaW9uIGNhbiBjb250 YWluIG1vcmUgdGhhbiBvbmUgZGlhbG9nLjxicj4KSXMgd2hhdCBJIHVuZGVyc3RhbmQgcmlnaHQ/ PGJyPgo8YnI+ClpvbmdqdW48YnI+Cjxicj4KPGJyPgoyMDA4LzQvMjQsIFZpamF5IEsuIEd1cmJh bmkgJmx0OzxhIGhyZWY9Im1haWx0bzp2a2dAYWxjYXRlbC1sdWNlbnQuY29tIj52a2dAYWxjYXRl bC1sdWNlbnQuY29tPC9hPiZndDs6PGJyPgo8ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iV2oz QzdjIj4mZ3Q7IFRoZXJlIGlzIHNvbWUgd29yayBwcm9ncmVzc2luZyBpbiB0aGUgQk1XRyBXRyB0 byBjcmVhdGUgcGVyZm9ybWFuY2U8YnI+CiZndDsgJm5ic3A7bWV0cmljcyBhcm91bmQgU0lQLiAm bmJzcDtPbmUgb2YgdGhlIGZpcnN0IHRhc2tzIGluIHN1Y2ggYW4gZW5kZWF2b3I8YnI+CiZndDsg Jm5ic3A7aXMgdG8gZGVmaW5lIHRoZSBub3Rpb24gb2YgZGlhbG9ncyBhbmQgc2Vzc2lvbnMuICZu YnNwO1BsZWFzZSBzZWU8YnI+CiZndDsgJm5ic3A7U2VjdGlvbiAzLjEuMSBvZjxicj4KJmd0OyA8 YSBocmVmPSJodHRwczovL3N2bi5yZXNpcHJvY2F0ZS5vcmcvcmVwL2lldGYtZHJhZnRzL2d1cmJh bmkvYm13Zy1zaXAtYmVuY2gtdGVybS9kcmFmdC1pZXRmLWJtd2ctc2lwLXRlcm0tMDAudHh0IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zdm4ucmVzaXByb2NhdGUub3JnL3JlcC9pZXRmLWRyYWZ0 cy9ndXJiYW5pL2Jtd2ctc2lwLWJlbmNoLXRlcm0vZHJhZnQtaWV0Zi1ibXdnLXNpcC10ZXJtLTAw LnR4dDwvYT48YnI+CgomZ3Q7ICZuYnNwO29mIHRoZSBhYm92ZSBkcmFmdCBmb3Igc29tZSBpbnNp Z2h0Ljxicj4KJmd0Ozxicj4KJmd0OyAmbmJzcDvDi8Ovw5fDmsK+w70gd3JvdGU6PGJyPgomZ3Q7 PGJyPgomZ3Q7ICZndDsgSGksIExpbmNvbG48YnI+CiZndDsgJmd0Ozxicj4KJmd0OyAmZ3Q7IHRo YW5rcyBmb3IgeW91ciBpbnN0cnVjdGlvbnMuPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBJ IGtub3cgdGhhdCBkaWFsb2cgY2FuIGV4aXN0IHdpdGhvdXQgc2Vzc2lvbiBzaW5jZSBTVUJTQ1JJ QkUvUkVGRVIgY2FuPGJyPgomZ3Q7ICZndDsgY3JlYXRlIGRpYWxvZyBhbmQgd2l0aG91dCBhbnkg bWVkaWEgYmV0d2VlbiBjb21tdW5pY2F0aW9uIHBlZXJzLjxicj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7 ICZndDsgV2hhdCBJIHdhbnQgdG8ga25vdyBpcyB0aGUgcmVsYXRpb25zaGlwIG9mIGRpYWxvZyBh bmQgc2Vzc2lvbiB3aGVuPGJyPgomZ3Q7ICZndDsgdGhleSBib3RoIGV4aXN0IGluIG9uZSBjb21t dW5pY2F0aW9uIGFjdGl2aXR5LiBUYWtlIGEgZXhhbXBsZSwgd2hlbjxicj4KJmd0OyAmZ3Q7IHRo ZXJlIGFyZSAyIHBlcnNvbiBwYXJ0aWNpcGF0aW5nIHRhbGtzIHdpdGggdm9pY2UsIHdlIHNheSB0 aGVyZSBpcyBhPGJyPgomZ3Q7ICZndDsgZGlhbG9nIGFuZCBhIHNlc3Npb24uPGJyPgomZ3Q7ICZn dDs8YnI+CiZndDsgJmd0OyBCdXQgd2hlbiBvbmUgY2FsbGVyIGludml0ZXMgYW5vdGhlciBjYWxs ZWUgYW5kIGdldHMgZml2ZSAyMDAgZmluYWw8YnI+CiZndDsgJmd0OyByZXNwb25zZXMgZnJvbSA1 IFVBIGV2ZXJ5IG9mIHdoaWNoIGhhcyBpdHMgb3duIHNlc3Npb24gZGVzY3JpcHRpb24uIFdlPGJy PgomZ3Q7ICZndDsgY2FuIHNheSB0aGF0IHRoZXJlIGFyZSA1IGRpYWxvZ3MgYmV0d2VlbiBjYWxs ZXIgYW5kIHRoZSBvdGhlciA1PGJyPgomZ3Q7ICZndDsgY2FsbGVlcywgcmlnaHQ/IEFuZCB0aGVu IHdoYXQgaXMgdGhlIGV4YWN0IG51bWJlciBvZiBzZXNzaW9uIGluIHRoaXM8YnI+CiZndDsgJmd0 OyBzY2VuYXJpbz8gT25lIHNlc3Npb24gb3IgZml2ZSBzZXNzaW9uPyBUaGF0IGlzIHdoYXQgSSB3 YW50IHRvIGtub3cuPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBEaWFsb2cgaXMgZGV0ZXJt aW5lZCBieSBkaWFsb2dJRCAoY2FsbC1pZCwgZnJvbS90byB0YWcpIGFuZCBzZXNzaW9uIGlkPGJy PgomZ3Q7ICZndDsgaXMgZGV0ZXJtaW5lZCBieSBzZXNzaW9uIGlkIGdpdmVuIGluIHRoZSBTRFAg bWVzc2FnZS4gJm5ic3A7TXkgYW5zd2VyIGlzPGJyPgomZ3Q7ICZndDsgdGhlcmUgYXJlIDUgZGlh bG9nIGFuZCBvbmUgc2Vzc2lvbiBub3csIHJpZ2h0Pzxicj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7PGJy PgomZ3Q7ICZuYnNwOy0gdmlqYXk8YnI+CiZndDsgJm5ic3A7LS08YnI+CiZndDsgJm5ic3A7Vmlq YXkgSy4gR3VyYmFuaSwgQmVsbCBMYWJvcmF0b3JpZXMsIEFsY2F0ZWwtTHVjZW50PGJyPgomZ3Q7 ICZuYnNwOzI3MDEgTHVjZW50IExhbmUsIFJtLiA5Ri01NDYsIExpc2xlLCBJbGxpbm9pcyA2MDUz MiAoVVNBKTxicj4KJmd0OyAmbmJzcDtFbWFpbDogdmtnQHs8YSBocmVmPSJodHRwOi8vYWxjYXRl bC1sdWNlbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWxjYXRlbC1sdWNlbnQuY29tPC9hPiw8YSBo cmVmPSJodHRwOi8vYmVsbC1sYWJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbGwtbGFicy5jb208 L2E+LDxhIGhyZWY9Imh0dHA6Ly9hY20ub3JnIiB0YXJnZXQ9Il9ibGFuayI+YWNtLm9yZzwvYT59 PGJyPgomZ3Q7ICZuYnNwO1dXVzogJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuYWxjYXRlbC1s dWNlbnQuY29tL2JlbGwtbGFicyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuYWxjYXRlbC1s dWNlbnQuY29tL2JlbGwtbGFiczwvYT48YnI+CiZndDs8YnI+Cl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpTaXAgbWFpbGluZyBsaXN0ICZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXA8L2E+PGJy PgpUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9j b2w8YnI+ClVzZSA8YSBocmVmPSJtYWlsdG86c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5l ZHUiPnNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1PC9hPiBmb3IgcXVlc3Rpb25zIG9u IGN1cnJlbnQgc2lwPGJyPgpVc2UgPGEgaHJlZj0ibWFpbHRvOnNpcHBpbmdAaWV0Zi5vcmciPnNp cHBpbmdAaWV0Zi5vcmc8L2E+IGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlv biBvZiBzaXA8YnI+CjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFy PSJhbGwiPjxicj4tLSA8YnI+QlI8YnI+RG9uYWxkCg== ------=_Part_3961_28689448.1209116688359-- --===============1945717764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1945717764==-- From sip-bounces@ietf.org Fri Apr 25 09:28:25 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACFE03A6B52; Fri, 25 Apr 2008 09:28:25 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051553A6B52 for ; Fri, 25 Apr 2008 09:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 6xFUx7xodoUy for ; Fri, 25 Apr 2008 09:28:23 -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 CE67C3A69AB for ; Fri, 25 Apr 2008 09:28:22 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 25 Apr 2008 09:28:27 -0700 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 m3PGSRkO003574; Fri, 25 Apr 2008 09:28:27 -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 m3PGSRqi001675; Fri, 25 Apr 2008 16:28:27 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); Fri, 25 Apr 2008 09:28:27 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Apr 2008 09:28:26 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Apr 2008 11:28:26 -0500 To: "Donald Lee" , "ajay thakur" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 25 Apr 2008 16:28:27.0150 (UTC) FILETIME=[63C8EAE0:01C8A6F1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3636; t=1209140907; x=1210004907; c=relaxed/simple; s=sjdkim4002; 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]=20SIP=20refer=20method |Sender:=20; bh=s5vMLgQqmBLqW5L/CRt77d52axcfDhZf84R5F/ipanw=; b=lLspJ+7fT8HzVGOTTEa4IWat2Z3vP52rWuOCN1cF6rVHUQPblVZucSfddb y3pc+fWDNhjEMCI+L8dd0SD7kUzrGz8Wi2hPCmjKEg1eFqt/+x2bm9PENaw3 Ga0VOD5Tme; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] SIP refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 04:34 AM 4/25/2008, Donald Lee wrote: >in case there is firewall or like nat issues b/w C and B, the normal >REFER will be failed to enable the C INVITE B. how the INVITE can >be routed to B correctly? > >On Fri, Apr 25, 2008 at 2:18 PM, ajay thakur ><thakur.ajay.ietf@gmail.com> wrote: >James If there is any kind of firewall enabled on Router then connection >from C to B is not allowed. That's what is main worry :( First of all, no one mentioned a firewall in this scenario. But if there is a firewall, how exactly will the firewall fail the SIP request (I know it can be configured to block anything (or everything), but is this normally the problem)? Won't SIP perform fine, and the problem be a RTP stream issue *IF* there is a NAT involved? A lot depends on where the firewall (and NAT) are in this A-B-C scenario below. BTW - check this ID out for answers to NATs (that weren't offered in the original scenario): Title : Best Current Practices for NAT Traversal for SIP Author(s) : C. Boulton, et al. Filename : draft-ietf-sipping-nat-scenarios-08.txt Pages : 62 Date : 2008-04-25 Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NAT) is a complex problem. Currently there are many deployment scenarios and traversal mechanisms for media traffic. This document aims to provide concrete recommendations and a unified method for NAT traversal as well as documenting corresponding flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.txt > >Ajay > >On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk ><jmpolk@cisco.com> wrote: >At 04:04 AM 4/24/2008, ajay thakur wrote: >Hi guys, >I have one doubt related to refer method. > > >A---------| > | > |--------Router-----------------C >B---------| > >In the above topology A & B phones are internal phones. C is external phone. > >Scenario is A calls C and then A refers B to C; > > >If A calls C, the either A or C need to send the REFER to the other, >telling one of them to contact B. For example, A calls C, and then >A sends REFER to C to contact B. C will now send an INVITE to B with >a Contact: header value of A > > > >So when A sends refer message to C it includes B's SIP URI. > > >In the Refer-To: header, yes > > >Now my doubt is >can we have port number along with this address. > > >why not? > > >e.g. Refer-To: > > >Thanks >Ajay >_______________________________________________ >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 > > > > >-- >BR >Donald _______________________________________________ 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 sip-bounces@ietf.org Fri Apr 25 09:33:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452353A68B4; Fri, 25 Apr 2008 09:33:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55413A68B4; Fri, 25 Apr 2008 09:33:39 -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.773, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 K-Xt2PyOkSta; Fri, 25 Apr 2008 09:33:33 -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 0E1E73A6D92; Fri, 25 Apr 2008 09:33:33 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Apr 2008 09:33:38 -0700 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 m3PGXcMF002329; Fri, 25 Apr 2008 09:33:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3PGXc4u020996; Fri, 25 Apr 2008 16:33: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); Fri, 25 Apr 2008 09:33:37 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Apr 2008 09:33:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Apr 2008 11:33:37 -0500 To: "Donald Lee" , "=?GB2312?B?y+/X2r79?=" From: "James M. Polk" In-Reply-To: References: <200804231828.m3NISnce030676@dragon.ariadne.com> <480FDA2E.30707@iol.unh.edu> <48109290.80309@alcatel-lucent.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 25 Apr 2008 16:33:37.0575 (UTC) FILETIME=[1CD00370:01C8A6F2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3882; t=1209141218; x=1210005218; 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]=20What's=20the=20difference=20bet ween=20session=20and=20dialog=20in=0A=20=20SIP? |Sender:=20; bh=krbofKoU1xEavevoE5/CabPLH9aqPU/5N63e+DlYw6Q=; b=IYYtu2j4V+ke0z7BmYwZtxLP8vHpqjYg2s0aDs+iPOwyMff7INy0RUC0Ul 1kKy53KGe1Fs/eaTfajtgOj47zWi/d2DiW+dUu3e5cvu9Nua+9JGkp3CqkI/ c2YOYZgdhS; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 04:44 AM 4/25/2008, Donald Lee wrote: >old good questions in sip, also add another "transaction". > > >On Fri, Apr 25, 2008 at 8:18 AM, =E5=AD=99=E5=AE=97=E5=90=9B = ><szj087@gmail.com> wrote: >Hi, Vijay > >Thanks very much for your timely answers. > > From this specification, session is a combination of signaling plane >and media plane messages and processes that enable two or more >participants to communicate. I think session is a larger scope than >dialog. In another word, one session can contain more than one dialog. >Is what I understand right? A SIP dialog has the one Call-ID. If more than = one session is involved in the same Call-ID, then = more than one session is within the same = dialog. At issue, I think, is there is little = tying any particular SDP session to a particular = SIP Call-ID. This creates confusion telling the difference between the two. >Zongjun > > >2008/4/24, Vijay K. Gurbani = ><vkg@alcatel-lucent.com>: > > There is some work progressing in the BMWG WG to create performance > > metrics around SIP. One of the first tasks in such an endeavor > > is to define the notion of dialogs and sessions. Please see > > Section 3.1.1 of > > = > https://svn.resiprocate.org/rep/ietf-drafts= /gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt > > of the above draft for some insight. > > > > =C3=8B=C3=AF=C3=97=C3=9A=C2=BE=C3=BD wrote: > > > > > Hi, Lincoln > > > > > > thanks for your instructions. > > > > > > I know that dialog can exist without session since SUBSCRIBE/REFER can > > > create dialog and without any media between communication peers. > > > > > > What I want to know is the relationship of dialog and session when > > > they both exist in one communication activity. Take a example, when > > > there are 2 person participating talks with voice, we say there is a > > > dialog and a session. > > > > > > But when one caller invites another callee and gets five 200 final > > > responses from 5 UA every of which has its own session description. We > > > can say that there are 5 dialogs between caller and the other 5 > > > callees, right? And then what is the exact number of session in this > > > scenario? One session or five session? That is what I want to know. > > > > > > Dialog is determined by dialogID (call-id, from/to tag) and session id > > > is determined by session id given in the SDP message. My answer is > > > there are 5 dialog and one session now, right? > > > > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > Email: = > vkg@{alcatel-lucent.com,= bell-labs.com,acm.org} > > WWW: = > http://www.alcatel-lucent.com/be= ll-labs > > >_______________________________________________ >Sip mailing = >list = >https://www.ietf.org/mailman/li= stinfo/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 > > > > >-- >BR >Donald >_______________________________________________ >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 sip-bounces@ietf.org Fri Apr 25 10:18:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C8A3A69F7; Fri, 25 Apr 2008 10:18:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DDFE28C115 for ; Fri, 25 Apr 2008 10:18:06 -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 wDYNYINRPeuQ for ; Fri, 25 Apr 2008 10:17:58 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E60DB28C329 for ; Fri, 25 Apr 2008 10:17:24 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m3PHHGdf023721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Apr 2008 12:17:17 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m3PHHEhs019351; Fri, 25 Apr 2008 12:17:14 -0500 (CDT) Message-ID: <4812121B.4070605@alcatel-lucent.com> Date: Fri, 25 Apr 2008 12:17:15 -0500 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: =?ISO-8859-1?Q?=CB=EF=D7=DA=BE=FD?= References: <200804231828.m3NISnce030676@dragon.ariadne.com> <480FDA2E.30707@iol.unh.edu> <48109290.80309@alcatel-lucent.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: IETF SIP List , discussion@sipforum.org Subject: Re: [Sip] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If you have any follow-ups, you may want to move them to the sip-implementors list (sip-implementors@cs.columbia.edu). =CB=EF=D7=DA=BE=FD wrote: > Hi, Vijay > = > Thanks very much for your timely answers. > = > From this specification, session is a combination of signaling plane > and media plane messages and processes that enable two or more > participants to communicate. I think session is a larger scope than > dialog. In another word, one session can contain more than one dialog. > Is what I understand right? The term session, as James pointed out, is a bit stretched. What a user would consider a "session" may include many dialogs and SDP sessions. For instance, consider your example: But when one caller invites another callee and gets five 200 final responses from 5 UA every of which has its own session description. We can say that there are 5 dialogs between caller and the other 5 callees, right? And then what is the exact number of session in this scenario? One session or five session? This could ostensibly be a conferencing service that sends out five INVITEs, the SDP of each of these INVITEs may have a the same session (s=3D) name, although many user agents do not populate this field. Of more importance is the of the SDP o=3D field. The conferencing service may use the same sess-id or may generate different ones (I don't believe it matters.) In this case, you have five distinct dialogs tied to the same session from the perspective of the conferencing service (even though they may have different values.) Now, turn this around so that you have five people connecting to a conference bridge simultaneously. Here, each individual INVITE will have its own , and there are five dialogs, but ostensibly you would still consider this a single user-level session. - vijay -- = Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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 sip-bounces@ietf.org Sun Apr 27 21:15:06 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F087B3A69F4; Sun, 27 Apr 2008 21:15:05 -0700 (PDT) X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 61DF03A6B7E; Sun, 27 Apr 2008 21:15:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080428041501.61DF03A6B7E@core3.amsl.com> Date: Sun, 27 Apr 2008 21:15:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-session-policy-framework-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --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 : A Framework for Session Initiation Protocol (SIP) Session Policies Author(s) : V. Hilt, et al. Filename : draft-ietf-sip-session-policy-framework-03.txt Pages : 35 Date : 2008-04-27 Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-policy-framework-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-sip-session-policy-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-27211128.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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-- From sip-bounces@ietf.org Sun Apr 27 23:54:52 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C258728C18C; Sun, 27 Apr 2008 23:54:52 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E38528C0E9 for ; Sun, 27 Apr 2008 23:54:51 -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 2829S77n80EY for ; Sun, 27 Apr 2008 23:54:50 -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 5624428C18C for ; Sun, 27 Apr 2008 23:54:50 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2406647rvf.49 for ; Sun, 27 Apr 2008 23:54:54 -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:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=kHGDTSQbcWIaujz55wnT7KHJ676u0dbOcFrujALLmfA=; b=AY90BgbSuMk+7qfdQfQpftKFYzhxTXWbgD9GtCk7hEckFfxKeVSilLIZWtdbmCF3DV6OPSBfBg5FdbxM9NvXZbcr7gjprXkeFCMt+XmDHbRfKTEshnTDhRUeDku+fn/6HV7ii/dydAAR4Gr5YtjUFjIMIu5JryLNmjE4t5aX/U0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AuKnytg5U6ykEWypsoloc6KYFcwtUUfKkSU+TZMPZomnN5jpEyK0i1ZpaLO6UsogiHok5r+0PjhcE+BY3YyLOC0Qz7FBOEGoAh+LV8QpZEqXgjdAqdhoxpW1MnF4fKsyABgoZhvNc9l9YaVemBCwzNXtRbhDniKxCB+/52eOaKE= Received: by 10.140.132.8 with SMTP id f8mr2914588rvd.122.1209365693980; Sun, 27 Apr 2008 23:54:53 -0700 (PDT) Received: by 10.141.97.13 with HTTP; Sun, 27 Apr 2008 23:54:53 -0700 (PDT) Message-ID: Date: Mon, 28 Apr 2008 12:24:53 +0530 From: "ajay thakur" To: "James M. Polk" In-Reply-To: MIME-Version: 1.0 References: Cc: sip@ietf.org Subject: Re: [Sip] SIP refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0407363911==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0407363911== Content-Type: multipart/alternative; boundary="----=_Part_3536_14982511.1209365693972" ------=_Part_3536_14982511.1209365693972 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline James, I will try to explain problem here. A---------| | |--------Router-----------------C B---------| On router access list is used to deny incoming calls from outside to internal network. A,B are internal network. And C is on WAN side. Outgoing calls are allowed through access lists. Now call from A to C works perfectly when A initiates call. Now when A wants to transfer call to other internal phone (B in this case), then A sends refer message to C. Now C tries to connect to B and C uses contact address of B to connect. But incoming calls from WAN side is not allowed. So what can be done to fix these kind of problems ? Thanks Ajay On Fri, Apr 25, 2008 at 9:58 PM, James M. Polk wrote: > At 04:34 AM 4/25/2008, Donald Lee wrote: > > > in case there is firewall or like nat issues b/w C and B, the normal > > REFER will be failed to enable the C INVITE B. how the INVITE can be routed > > to B correctly? > > > > On Fri, Apr 25, 2008 at 2:18 PM, ajay thakur < > thakur.ajay.ietf@gmail.com>thakur.ajay.ietf@gmail.com> wrote: > > James If there is any kind of firewall enabled on Router then connection > > from C to B is not allowed. That's what is main worry :( > > > > First of all, no one mentioned a firewall in this scenario. > > But if there is a firewall, how exactly will the firewall fail the SIP > request (I know it can be configured to block anything (or everything), but > is this normally the problem)? Won't SIP perform fine, and the problem be a > RTP stream issue *IF* there is a NAT involved? > > A lot depends on where the firewall (and NAT) are in this A-B-C scenario > below. > > BTW - check this ID out for answers to NATs (that weren't offered in the > original scenario): > > Title : Best Current Practices for NAT Traversal for SIP > Author(s) : C. Boulton, et al. > Filename : draft-ietf-sipping-nat-scenarios-08.txt > Pages : 62 > Date : 2008-04-25 > > Traversal of the Session Initiation Protocol (SIP) and the sessions > it establishes through Network Address Translators (NAT) is a complex > problem. Currently there are many deployment scenarios and traversal > mechanisms for media traffic. This document aims to provide concrete > recommendations and a unified method for NAT traversal as well as > documenting corresponding flows. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.txt > > > > Ajay > > > > On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk < > >jmpolk@cisco.com> wrote: > > At 04:04 AM 4/24/2008, ajay thakur wrote: > > Hi guys, > > I have one doubt related to refer method. > > > > > > A---------| > > | > > |--------Router-----------------C > > B---------| > > > > In the above topology A & B phones are internal phones. C is external > > phone. > > > > Scenario is A calls C and then A refers B to C; > > > > > > If A calls C, the either A or C need to send the REFER to the other, > > telling one of them to contact B. For example, A calls C, and then A sends > > REFER to C to contact B. C will now send an INVITE to B with a Contact: > > header value of A > > > > > > > > So when A sends refer message to C it includes B's SIP URI. > > > > > > In the Refer-To: header, yes > > > > > > Now my doubt is > > can we have port number along with this address. > > > > > > why not? > > > > > > e.g. Refer-To: > > > > > > Thanks > > Ajay > > _______________________________________________ > > 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 > > > > > > > > > > -- > > BR > > Donald > > > > ------=_Part_3536_14982511.1209365693972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
James,
I will try to explain problem here.
A---------|
           |
           |--------Router-----------------C
B---------|
On router access list is used to deny incoming calls from outside to internal network.
A,B are internal network. And C is on WAN side. 
Outgoing calls are allowed through access lists. 
 
 
Now call from A to C works perfectly when A initiates call. 
Now when A wants to transfer call to other internal phone (B in this case), then A sends refer message to C. 
 
Now C tries to connect to B and C uses contact address of B to connect. But incoming calls from WAN side is not allowed. So what can be done to fix these kind of problems ?
 
 
Thanks
Ajay 
On Fri, Apr 25, 2008 at 9:58 PM, James M. Polk <jmpolk@cisco.com> wrote:
At 04:34 AM 4/25/2008, Donald Lee wrote:
in case there is firewall or like nat issues b/w C and B, the normal REFER will be failed to enable the C INVITE B.  how the INVITE can be routed to B correctly?

On Fri, Apr 25, 2008 at 2:18 PM, ajay thakur <<mailto:thakur.ajay.ietf@gmail.com>thakur.ajay.ietf@gmail.com> wrote:
James If there is any kind of firewall enabled on Router then connection
from C to B is not allowed. That's what is main worry :(

First of all, no one mentioned a firewall in this scenario.

But if there is a firewall, how exactly will the firewall fail the SIP request (I know it can be configured to block anything (or everything), but is this normally the problem)? Won't SIP perform fine, and the problem be a RTP stream issue *IF* there is a NAT involved?

A lot depends on where the firewall (and NAT) are in this A-B-C scenario below.

BTW - check this ID out for answers to NATs (that weren't offered in the original scenario):

       Title          : Best Current Practices for NAT Traversal for SIP
       Author(s)      : C. Boulton, et al.
       Filename       : draft-ietf-sipping-nat-scenarios-08.txt
       Pages          : 62
       Date           : 2008-04-25

Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NAT) is a complex
problem. Currently there are many deployment scenarios and traversal
mechanisms for media traffic. This document aims to provide concrete
recommendations and a unified method for NAT traversal as well as
documenting corresponding flows.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.txt


Ajay


On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk <<mailto:jmpolk@cisco.com>jmpolk@cisco.com> wrote:
At 04:04 AM 4/24/2008, ajay thakur wrote:
Hi guys,
I have one doubt related to refer method.


A---------|
         |
         |--------Router-----------------C
B---------|

In the above topology A & B phones are internal phones. C is external phone.

Scenario is A calls C  and then A refers B to C;


If A calls C, the either A or C need to send the REFER to the other, telling one of them to contact B.  For example, A calls C, and then A sends REFER to C to contact B. C will now send an INVITE to B with a Contact: header value of A



So when A sends refer message to C it includes B's SIP URI.


In the Refer-To: header, yes


Now my doubt is
can we have port number along with this address.


why not?


e.g. Refer-To:<sip:xxx@ip-address:port-number>


Thanks
Ajay
_______________________________________________
Sip mailing list <https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip

This list is for NEW development of the core SIP Protocol
Use <mailto:sip-implementors@cs.columbia.edu>sip-implementors@cs.columbia.edu for questions on current sip
Use <mailto:sipping@ietf.org>sipping@ietf.org for new developments on the application of sip




_______________________________________________
Sip mailing list <https://www.ietf.org/mailman/listinfo/sip>https://www.ietf.org/mailman/listinfo/sip

This list is for NEW development of the core SIP Protocol
Use <mailto:sip-implementors@cs.columbia.edu>sip-implementors@cs.columbia.edu for questions on current sip
Use <mailto:sipping@ietf.org>sipping@ietf.org for new developments on the application of sip




--
BR
Donald


------=_Part_3536_14982511.1209365693972-- --===============0407363911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0407363911==-- From sip-bounces@ietf.org Mon Apr 28 08:06:41 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825373A6866; Mon, 28 Apr 2008 08:06:41 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5F23A6C23 for ; Mon, 28 Apr 2008 08:06:39 -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 4VsN5p7o6QU4 for ; Mon, 28 Apr 2008 08:06: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 54A323A6A30 for ; Mon, 28 Apr 2008 08:06:15 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2008 08:06:18 -0700 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 m3SF6INw003329; Mon, 28 Apr 2008 08:06:18 -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 m3SF6Eci023781; Mon, 28 Apr 2008 15:06: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); Mon, 28 Apr 2008 08:06:17 -0700 Received: from jmpolk-wxp.cisco.com ([64.101.170.120]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 08:06:16 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Apr 2008 10:06:16 -0500 To: "ajay thakur" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 28 Apr 2008 15:06:16.0951 (UTC) FILETIME=[68658070:01C8A941] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5228; t=1209395178; x=1210259178; c=relaxed/simple; s=sjdkim4002; 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]=20SIP=20refer=20method |Sender:=20; bh=MWWGbo86g9ee1N3SB7MT5KUOE9jK4X53S/OUUDlngXk=; b=pD5OXDU6XBbRMTyHxURX5JdbEpYq0hje6zBLccVNlskfDZKvLH87kCb7Yc RwyF41i0yiFQBG87+genibgiB7ApJRCf64gDivlk2y0UuHJxHniY2ZN+SRFU +8VtNHvgCc; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] SIP refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 01:54 AM 4/28/2008, ajay thakur wrote: >James, >I will try to explain problem here. >A---------| > | > |--------Router-----------------C >B---------| >On router access list is used to deny incoming calls from outside to >internal network. >A,B are internal network. And C is on WAN side. >Outgoing calls are allowed through access lists. what you describe means C cannot call A or B. This is fine, if you want to have a that level of denial, but you will have to live with C not being able to call A just the same as A not being allowed to transfer C to B. Something will have to give for C to do anything into the A&B LAN segment other than answer a call from either A or B. > > >Now call from A to C works perfectly when A initiates call. >Now when A wants to transfer call to other internal phone (B in this >case), then A sends refer message to C. > >Now C tries to connect to B and C uses contact address of B to >connect. But incoming calls from WAN side is not allowed. So what >can be done to fix these kind of problems ? > > >Thanks >Ajay >On Fri, Apr 25, 2008 at 9:58 PM, James M. Polk ><jmpolk@cisco.com> wrote: >At 04:34 AM 4/25/2008, Donald Lee wrote: >in case there is firewall or like nat issues b/w C and B, the normal >REFER will be failed to enable the C INVITE B. how the INVITE can >be routed to B correctly? > >On Fri, Apr 25, 2008 at 2:18 PM, ajay thakur ><thakur.ajay.ietf@gmail.com> wrote: >James If there is any kind of firewall enabled on Router then connection >from C to B is not allowed. That's what is main worry :( > > >First of all, no one mentioned a firewall in this scenario. > >But if there is a firewall, how exactly will the firewall fail the >SIP request (I know it can be configured to block anything (or >everything), but is this normally the problem)? Won't SIP perform >fine, and the problem be a RTP stream issue *IF* there is a NAT involved? > >A lot depends on where the firewall (and NAT) are in this A-B-C >scenario below. > >BTW - check this ID out for answers to NATs (that weren't offered in >the original scenario): > > Title : Best Current Practices for NAT Traversal for SIP > Author(s) : C. Boulton, et al. > Filename : draft-ietf-sipping-nat-scenarios-08.txt > Pages : 62 > Date : 2008-04-25 > >Traversal of the Session Initiation Protocol (SIP) and the sessions >it establishes through Network Address Translators (NAT) is a complex >problem. Currently there are many deployment scenarios and traversal >mechanisms for media traffic. This document aims to provide concrete >recommendations and a unified method for NAT traversal as well as >documenting corresponding flows. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.txt > > >Ajay > > >On Fri, Apr 25, 2008 at 5:33 AM, James M. Polk ><jmpolk@cisco.com> wrote: >At 04:04 AM 4/24/2008, ajay thakur wrote: >Hi guys, >I have one doubt related to refer method. > > >A---------| > | > |--------Router-----------------C >B---------| > >In the above topology A & B phones are internal phones. C is external phone. > >Scenario is A calls C and then A refers B to C; > > >If A calls C, the either A or C need to send the REFER to the other, >telling one of them to contact B. For example, A calls C, and then >A sends REFER to C to contact B. C will now send an INVITE to B with >a Contact: header value of A > > > >So when A sends refer message to C it includes B's SIP URI. > > >In the Refer-To: header, yes > > >Now my doubt is >can we have port number along with this address. > > >why not? > > >e.g. Refer-To: > > >Thanks >Ajay >_______________________________________________ >Sip mailing list ><https://www.ietf.org/mailman/listinfo/sip>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>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 > > > > >-- >BR >Donald > > _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 28 10:14:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0A428C1E3; Mon, 28 Apr 2008 10:14:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79AF128C1CD for ; Mon, 28 Apr 2008 10:14:29 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWQPjtCcLGTb for ; Mon, 28 Apr 2008 10:14:28 -0700 (PDT) Received: from smtpout4.l-3com.com (smtpout4.l-3com.com [166.20.84.214]) by core3.amsl.com (Postfix) with ESMTP id 835A328C16E for ; Mon, 28 Apr 2008 10:14:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,717,1199682000"; d="scan'208";a="150764982" From: todd.d.binns@l-3com.com Received: from unknown (HELO HEN-EXCH-1.henschel.l-3com.com) ([166.20.217.20]) by smtpout4.l-3com.com with ESMTP; 28 Apr 2008 13:14:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 13:14:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Passing added call information in the SIP packet Thread-Index: Acilup62LLj3BP3DTgG+uDw1zYkpngDlzhOw References: To: Subject: Re: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Yes, it (security) does mean a lot to a lot of different people. Thanks for all the responses. I am reading the different suggested RFC & drafts. My question was more on how can one UA inform another UA that it wants to make changes to their session/dialog. In my case the security will be different, but I want to have one UA initiate the secure call (change to session/dialog), and the other UA to confirm. As stated I can use the X- header since both clients will be custom. Is there any other defined way that 2 UA should have this conversation, is it only defined in the RFC3264? (An offer/answer model with the session description protocol) Thanks Again to everyone that made comments, Todd -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, 23 April, 2008 11:24 PM To: Binns, Todd D @ HENSCHEL Cc: sip@ietf.org Subject: Re: [Sip] Passing added call information in the SIP packet On Apr 23, 2008, at 12:29 PM, todd.d.binns@l-3com.com wrote: > Hi, > I have been an user of SIP for a while, but never got into the > need to extend it. I have tried to do an extensive research to see > if there are any draft or RFC that handles the requirements that I > am requested to do. Here is the scenario that I am trying to fulfill. > > A UA (custom hardware/software) wants to place or change the call > into a secure call. It notifies the other participant by an INVITE > or NOTIFY and both UA agree on the change and the details of the > security. There are several different method of securing the call, > and that would be included in the parameter passed between the UA. > If this is not possible is there a way to embed the parameters into > the header of the INVITE or NOTIFY so at least both UA know of the > request? > What do you mean, "secured call"? This term means many different things to even more different people. You might look at: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-08.txt which has completed working group last call and I'm about to send to the IESG, and at: http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requir ements-04.txt and http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-0 1.txt which, if I recall aright, are currently in working group last call. -- 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 sip-bounces@ietf.org Mon Apr 28 10:37:20 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7803A6E6F; Mon, 28 Apr 2008 10:37:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73743A6ABD for ; Mon, 28 Apr 2008 10:37:18 -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 mbcEXGLtM6jU for ; Mon, 28 Apr 2008 10:37:11 -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 0CA293A6BE9 for ; Mon, 28 Apr 2008 10:37:11 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2008 10:37:14 -0700 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 m3SHbE8R005947; Mon, 28 Apr 2008 10:37:14 -0700 Received: from dwingwxp01 (dhcp-64-101-170-127.cisco.com [64.101.170.127]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3SHbEV6022835; Mon, 28 Apr 2008 17:37:14 GMT From: "Dan Wing" To: , References: Date: Mon, 28 Apr 2008 10:37:13 -0700 Message-ID: <018401c8a956$7f2bfd10$7faa6540@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acilup62LLj3BP3DTgG+uDw1zYkpngDlzhOwAAEU0SA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3673; t=1209404234; x=1210268234; 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]=20Passing=20added=20call=20inform ation=20in=20the=20SIP=20packet |Sender:=20; bh=U3YptwF0bSlwV4T7uzB+yDOWo3EsbWG8xonHbysMr/Y=; b=QxWTchftD63vtJIm1vRqCXeG4/vr3mDiP0HKrOjq8EbrLrnZfRS5XuiVGz m3MU4p1bFbhC5ue4TAt/B/AIt+fH86BsBRpe9b8oyPpYkPyjSu9WqU2wwtz1 gj33YzYpnP; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of todd.d.binns@l-3com.com > Sent: Monday, April 28, 2008 10:14 AM > To: sip@ietf.org > Subject: Re: [Sip] Passing added call information in the SIP packet > > Hi, > Yes, it (security) does mean a lot to a lot of different people. > Thanks for all the responses. I am reading the different > suggested RFC > & drafts. My question was more on how can one UA inform > another UA that > it wants to make changes to their session/dialog. In my case the > security will be different, but I want to have one UA initiate the > secure call (change to session/dialog), and the other UA to > confirm. As > stated I can use the X- header since both clients will be custom. Is > there any other defined way that 2 UA should have this > conversation, is > it only defined in the RFC3264? (An offer/answer model with > the session > description protocol) If I understand correctly, you want to start a phone call with RTP and then when something happens (user remembers to press the big red "Secure This Call" button??), you want the phone to request switching to SRTP. If that is correct, you would only need to issue a re-INVITE (new SDP offer in the existing dialog), and that new SDP would indicate the phone wants SRTP (with an RTP profile of RTP/SAVP). The remote phone would acknowledge that change in its SDP answer. -d > Thanks Again to everyone that made comments, > Todd > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, 23 April, 2008 11:24 PM > To: Binns, Todd D @ HENSCHEL > Cc: sip@ietf.org > Subject: Re: [Sip] Passing added call information in the SIP packet > > > On Apr 23, 2008, at 12:29 PM, todd.d.binns@l-3com.com wrote: > > > Hi, > > I have been an user of SIP for a while, but never got into the > > need to extend it. I have tried to do an extensive > research to see > > if there are any draft or RFC that handles the requirements that I > > am requested to do. Here is the scenario that I am trying > to fulfill. > > > > A UA (custom hardware/software) wants to place or change the call > > into a secure call. It notifies the other participant by > an INVITE > > or NOTIFY and both UA agree on the change and the details of the > > security. There are several different method of securing > the call, > > and that would be included in the parameter passed between > the UA. > > If this is not possible is there a way to embed the > parameters into > > the header of the INVITE or NOTIFY so at least both UA know of the > > request? > > > > What do you mean, "secured call"? This term means many different > things to even more different people. > > You might look at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-08.txt > > which has completed working group last call and I'm about to send to > the IESG, and at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-media-secur > ity-requir > ements-04.txt > > and > > http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-f > ramework-0 > 1.txt > > which, if I recall aright, are currently in working group last call. > > -- > 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 _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 28 10:57:51 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4258628C260; Mon, 28 Apr 2008 10:57:51 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F21E28C270 for ; Mon, 28 Apr 2008 10:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=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 a1OTTTQvuWfG for ; Mon, 28 Apr 2008 10:57:44 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id F1B5A3A69A7 for ; Mon, 28 Apr 2008 10:57:43 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m3SHvea3008331; Mon, 28 Apr 2008 12:57:46 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 12:57:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 12:57:38 -0500 Message-ID: <2D7CEF7F8F759C4AB79D7C46666F329C0307EF17@eusrcmw721.eamcs.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Passing added call information in the SIP packet Thread-Index: Acilup62LLj3BP3DTgG+uDw1zYkpngDlzhOwAAEJyrA= References: From: "Arun Punj" To: , X-OriginalArrivalTime: 28 Apr 2008 17:57:40.0821 (UTC) FILETIME=[5A0F8850:01C8A959] Subject: Re: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Todd, I think in view of participants P1 and P2 of a secure call. The security could imply following: If P1 calls P2. R1 - P2 can verify that it is P1 who is calling. ( RFC4474 plus manyother proposals) R2 - P1 can verify that is has reached P1 ( RFC4916 +++ ) R3 - P1 and P2 can communicate data using SRTP ( encrypted) R31 - Keys are hidden from all but P1 and P2. (TLS/Mikey SDES exposes keys to proxies) R32 - Keys and relevant security parameters can be exchanged betwene P1 and P2. ( Mikey / SDES). You want to know if R31 and R32 can be used/changed mid call, that is the call starts with encryption and then a RE-INVITE is sent which would change the session to encrypted. This is possible. For example, to do it using SDES, your initial INVITE could be send without any a=crypto line and SAVP profile and then could send another Re_INVITE with a=crypto. Also could do best effort security. Which is put the a=crypto line in the SDP, however, encryption is used only if both the offer and answer have a=crypto line in it, otherwise send/receive unencrypted media. Best effort security and other endpoint capability negotiation is being developed further and there a couple of drafts on it out there. Thanks Arun -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of todd.d.binns@l-3com.com Sent: Monday, April 28, 2008 1:14 PM To: sip@ietf.org Subject: Re: [Sip] Passing added call information in the SIP packet Hi, Yes, it (security) does mean a lot to a lot of different people. Thanks for all the responses. I am reading the different suggested RFC & drafts. My question was more on how can one UA inform another UA that it wants to make changes to their session/dialog. In my case the security will be different, but I want to have one UA initiate the secure call (change to session/dialog), and the other UA to confirm. As stated I can use the X- header since both clients will be custom. Is there any other defined way that 2 UA should have this conversation, is it only defined in the RFC3264? (An offer/answer model with the session description protocol) Thanks Again to everyone that made comments, Todd -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, 23 April, 2008 11:24 PM To: Binns, Todd D @ HENSCHEL Cc: sip@ietf.org Subject: Re: [Sip] Passing added call information in the SIP packet On Apr 23, 2008, at 12:29 PM, todd.d.binns@l-3com.com wrote: > Hi, > I have been an user of SIP for a while, but never got into the > need to extend it. I have tried to do an extensive research to see > if there are any draft or RFC that handles the requirements that I > am requested to do. Here is the scenario that I am trying to fulfill. > > A UA (custom hardware/software) wants to place or change the call > into a secure call. It notifies the other participant by an INVITE > or NOTIFY and both UA agree on the change and the details of the > security. There are several different method of securing the call, > and that would be included in the parameter passed between the UA. > If this is not possible is there a way to embed the parameters into > the header of the INVITE or NOTIFY so at least both UA know of the > request? > What do you mean, "secured call"? This term means many different things to even more different people. You might look at: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-08.txt which has completed working group last call and I'm about to send to the IESG, and at: http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requir ements-04.txt and http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-0 1.txt which, if I recall aright, are currently in working group last call. -- 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 _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 28 11:12:38 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C627328C2A1; Mon, 28 Apr 2008 11:12:38 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A4B28C2B0 for ; Mon, 28 Apr 2008 11:12:37 -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 zSMV1ZX6NTR6 for ; Mon, 28 Apr 2008 11:12: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 32AB728C1BD for ; Mon, 28 Apr 2008 11:12:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,717,1199682000"; d="scan'208";a="6588501" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2008 14:12:36 -0400 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 m3SICaxD023381; Mon, 28 Apr 2008 14:12:36 -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 m3SICaT0028726; Mon, 28 Apr 2008 18:12:36 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, 28 Apr 2008 14:12:36 -0400 Received: from [161.44.182.90] ([161.44.182.90]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Apr 2008 14:12:35 -0400 Message-ID: <481613B3.8060908@cisco.com> Date: Mon, 28 Apr 2008 14:13:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: todd.d.binns@l-3com.com References: In-Reply-To: X-OriginalArrivalTime: 28 Apr 2008 18:12:35.0866 (UTC) FILETIME=[6F8C8FA0:01C8A95B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3161; t=1209406356; x=1210270356; 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]=20Passing=20added=20call=20inform ation=20in=20the=20SIP=20packet |Sender:=20 |To:=20todd.d.binns@l-3com.com; bh=WXrZHOefsLZtzPJH8H/fao2xtHTgn8C90ux9rMW0+ks=; b=XWI94JliD0IVNEVVJR0Zltgo/voQa886F62fVR0nYdZs7HQytsYmHH8FhR 5Wvaf+d5rA+L6kAwE6QYo6q1CRUisiEW+0dZKR5ROGkgGvSf5xRW0tSf0yPv r8fJGuukTH; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org Subject: Re: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Todd, I don't recall if you said if/how the signaling is to be secured? If the initial call is without secure signaling then you presumably need to find a way to secure the signaling before exchanging keys for secure media. What do you have in mind here? Paul todd.d.binns@l-3com.com wrote: > Hi, > Yes, it (security) does mean a lot to a lot of different people. > Thanks for all the responses. I am reading the different suggested RFC > & drafts. My question was more on how can one UA inform another UA that > it wants to make changes to their session/dialog. In my case the > security will be different, but I want to have one UA initiate the > secure call (change to session/dialog), and the other UA to confirm. As > stated I can use the X- header since both clients will be custom. Is > there any other defined way that 2 UA should have this conversation, is > it only defined in the RFC3264? (An offer/answer model with the session > description protocol) > > Thanks Again to everyone that made comments, > Todd > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, 23 April, 2008 11:24 PM > To: Binns, Todd D @ HENSCHEL > Cc: sip@ietf.org > Subject: Re: [Sip] Passing added call information in the SIP packet > > > On Apr 23, 2008, at 12:29 PM, todd.d.binns@l-3com.com wrote: > >> Hi, >> I have been an user of SIP for a while, but never got into the >> need to extend it. I have tried to do an extensive research to see >> if there are any draft or RFC that handles the requirements that I >> am requested to do. Here is the scenario that I am trying to fulfill. >> >> A UA (custom hardware/software) wants to place or change the call >> into a secure call. It notifies the other participant by an INVITE >> or NOTIFY and both UA agree on the change and the details of the >> security. There are several different method of securing the call, >> and that would be included in the parameter passed between the UA. >> If this is not possible is there a way to embed the parameters into >> the header of the INVITE or NOTIFY so at least both UA know of the >> request? >> > > What do you mean, "secured call"? This term means many different > things to even more different people. > > You might look at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-08.txt > > which has completed working group last call and I'm about to send to > the IESG, and at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requir > ements-04.txt > > and > > http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-0 > 1.txt > > which, if I recall aright, are currently in working group last call. > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Mon Apr 28 12:11:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F0328C1A4; Mon, 28 Apr 2008 12:11:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B264D28C1A4 for ; Mon, 28 Apr 2008 12:11:03 -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 aPWXw0TMUyqU for ; Mon, 28 Apr 2008 12:11:02 -0700 (PDT) Received: from smtpout3.l-3com.com (smtpout3.l-3com.com [166.20.84.211]) by core3.amsl.com (Postfix) with ESMTP id 3072E28C19C for ; Mon, 28 Apr 2008 12:11:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,717,1199682000"; d="scan'208";a="137940730" From: todd.d.binns@l-3com.com Received: from unknown (HELO HEN-EXCH-1.henschel.l-3com.com) ([166.20.217.20]) by smtpout3.l-3com.com with ESMTP; 28 Apr 2008 15:10:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 15:10:52 -0400 Message-ID: In-Reply-To: <481613B3.8060908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Passing added call information in the SIP packet Thread-Index: AcipW3ieA2sASA9oQ2qb8cwEaO48fAAB4Hcw References: <481613B3.8060908@cisco.com> To: "Paul Kyzivat" Cc: sip@ietf.org Subject: Re: [Sip] Passing added call information in the SIP packet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, I am still interpreting the requirements, but at this time the security will move both signaling and RTP stream into a secured tunnel. So both UAs must make the jump at the same time. The keys will be defined at the UA level. Thanks, Todd -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, 28 April, 2008 2:13 PM To: Binns, Todd D @ HENSCHEL Cc: sip@ietf.org Subject: Re: [Sip] Passing added call information in the SIP packet Todd, I don't recall if you said if/how the signaling is to be secured? If the initial call is without secure signaling then you presumably need to find a way to secure the signaling before exchanging keys for secure media. What do you have in mind here? Paul todd.d.binns@l-3com.com wrote: > Hi, > Yes, it (security) does mean a lot to a lot of different people. > Thanks for all the responses. I am reading the different suggested RFC > & drafts. My question was more on how can one UA inform another UA that > it wants to make changes to their session/dialog. In my case the > security will be different, but I want to have one UA initiate the > secure call (change to session/dialog), and the other UA to confirm. As > stated I can use the X- header since both clients will be custom. Is > there any other defined way that 2 UA should have this conversation, is > it only defined in the RFC3264? (An offer/answer model with the session > description protocol) > > Thanks Again to everyone that made comments, > Todd > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, 23 April, 2008 11:24 PM > To: Binns, Todd D @ HENSCHEL > Cc: sip@ietf.org > Subject: Re: [Sip] Passing added call information in the SIP packet > > > On Apr 23, 2008, at 12:29 PM, todd.d.binns@l-3com.com wrote: > >> Hi, >> I have been an user of SIP for a while, but never got into the >> need to extend it. I have tried to do an extensive research to see >> if there are any draft or RFC that handles the requirements that I >> am requested to do. Here is the scenario that I am trying to fulfill. >> >> A UA (custom hardware/software) wants to place or change the call >> into a secure call. It notifies the other participant by an INVITE >> or NOTIFY and both UA agree on the change and the details of the >> security. There are several different method of securing the call, >> and that would be included in the parameter passed between the UA. >> If this is not possible is there a way to embed the parameters into >> the header of the INVITE or NOTIFY so at least both UA know of the >> request? >> > > What do you mean, "secured call"? This term means many different > things to even more different people. > > You might look at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-08.txt > > which has completed working group last call and I'm about to send to > the IESG, and at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requir > ements-04.txt > > and > > http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-0 > 1.txt > > which, if I recall aright, are currently in working group last call. > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Tue Apr 29 07:16:09 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF09B3A6D21; Tue, 29 Apr 2008 07:16:09 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886143A6D77 for ; Tue, 29 Apr 2008 07:16:05 -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 M0V-5oWtbv9A for ; Tue, 29 Apr 2008 07:15:57 -0700 (PDT) Received: from m5tmail1.m5t.com (m5tmail1.m5t.com [207.134.65.96]) by core3.amsl.com (Postfix) with ESMTP id E18C13A6DCD for ; Tue, 29 Apr 2008 07:15:56 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Apr 2008 10:16:59 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA901224DD13A@m5tmail1.m5t.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Addition to invfix Thread-Index: AciqA6/uZ6g+B15nR5+2/zt7Wjm2Nw== From: "Eric Tremblay" To: Cc: sip@ietf.org Subject: [Sip] Addition to invfix X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0270366696==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0270366696== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA03.8C66E1D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA03.8C66E1D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, Regarding the invfix draft, I don't know to what length we want to specify the changes to apply in RFC 3261, but I found out one more 3261 paragraph that could be updated: Page 87: Section 14.1 - Replace the paragraph starting with "2. If there is an ongoing INVITE server transaction" with 2. If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed, accepted or terminated state before initiating the new INVITE. Best Regards, EricT ------_=_NextPart_001_01C8AA03.8C66E1D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Addition to invfix

Hi = Robert,

Regarding the = invfix draft, I don't know to what length we want to specify the changes = to apply in RFC 3261, but I found out one more 3261 paragraph that could = be updated:

Page = 87:

Section 14.1 - = Replace the paragraph starting with "2. If there is an ongoing = INVITE server transaction" with

      2. If there is an ongoing = INVITE server transaction, the TU MUST
         wait = until the transaction reaches the confirmed, accepted or = terminated
         state = before initiating the new INVITE.

Best = Regards,

EricT

------_=_NextPart_001_01C8AA03.8C66E1D6-- --===============0270366696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0270366696==-- From sip-bounces@ietf.org Tue Apr 29 09:22:24 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666283A6E41; Tue, 29 Apr 2008 09:22:24 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBBF28C2FA for ; Fri, 25 Apr 2008 05:14:38 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char CB hex): To: ..., "\313\357\327\332\276\375" ; Fri, 25 Apr 2008 05:14:37 -0700 (PDT) Received: from web33504.mail.mud.yahoo.com (web33504.mail.mud.yahoo.com [68.142.206.153]) by core3.amsl.com (Postfix) with SMTP id 475F128C311 for ; Fri, 25 Apr 2008 05:14:36 -0700 (PDT) Received: (qmail 98733 invoked by uid 60001); 25 Apr 2008 12:14:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=dz22kRM4YSq0C8vahQnKqr3npE39El8tD0I/oi3byiPM5qDVqbwV3WzE0gmqVRwN29HxKbxLfDSKjoCE6Vvdsoqr22RwP18Y08YVmebK9P5hpceHj9bW4C9C4q20/n6Y8z98RbDikcVv3U4T8qaIIMIRUeKABm7uw66sZqbeKWc=; X-YMail-OSG: McUzpj4VM1l2XM2jPMgYDvdu.5pPlaI6KjF8zjfde9S_tx4LTQvYaPuQ.GBolZVNbQ-- Received: from [61.246.177.137] by web33504.mail.mud.yahoo.com via HTTP; Fri, 25 Apr 2008 05:14:40 PDT Date: Fri, 25 Apr 2008 05:14:40 -0700 (PDT) From: gaurav katiyar To: Donald Lee , "ھ" In-Reply-To: MIME-Version: 1.0 Message-ID: <915213.97931.qm@web33504.mail.mud.yahoo.com> X-Mailman-Approved-At: Tue, 29 Apr 2008 09:22:21 -0700 Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644450938==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1644450938== Content-Type: multipart/alternative; boundary="0-503946771-1209125680=:97931" Content-Transfer-Encoding: 8bit --0-503946771-1209125680=:97931 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sip "Session Initiation Protocol". It talks about media session, i mean how to initiate, modify and terminate a session and Dialog provides a sort of context (like caller, callee, location, routing etc.) to modify this session. So dialog is more related to route the sip message to right node and body (SDP) handles media session if present. Dialogs may have media sessions Or may not. Take an example of B2BUA. It is a type of statefull proxy having two dialog and one media session if doing media routing. Donald Lee wrote: old good questions in sip, also add another "transaction". On Fri, Apr 25, 2008 at 8:18 AM, ­宗君 wrote: Hi, Vijay Thanks very much for your timely answers. From this specification, session is a combination of signaling plane and media plane messages and processes that enable two or more participants to communicate. I think session is a larger scope than dialog. In another word, one session can contain more than one dialog. Is what I understand right? Zongjun 2008/4/24, Vijay K. Gurbani : > There is some work progressing in the BMWG WG to create performance > metrics around SIP. One of the first tasks in such an endeavor > is to define the notion of dialogs and sessions. Please see > Section 3.1.1 of > https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt > of the above draft for some insight. > > Ëï×Ú¾ý wrote: > > > Hi, Lincoln > > > > thanks for your instructions. > > > > I know that dialog can exist without session since SUBSCRIBE/REFER can > > create dialog and without any media between communication peers. > > > > What I want to know is the relationship of dialog and session when > > they both exist in one communication activity. Take a example, when > > there are 2 person participating talks with voice, we say there is a > > dialog and a session. > > > > But when one caller invites another callee and gets five 200 final > > responses from 5 UA every of which has its own session description. We > > can say that there are 5 dialogs between caller and the other 5 > > callees, right? And then what is the exact number of session in this > > scenario? One session or five session? That is what I want to know. > > > > Dialog is determined by dialogID (call-id, from/to tag) and session id > > is determined by session id given in the SDP message. My answer is > > there are 5 dialog and one session now, right? > > > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ 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 -- BR Donald _______________________________________________ This is the SIP Forum discussion mailing list TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion Post to the list at discussion@sipforum.org Gaurav Katiyar Induslogic india pvt. ltd B-34/1 sector 59 NOIDA Phone:9818381368 --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-503946771-1209125680=:97931 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Sip "Session Initiation Protocol". It talks about media session, i mean how to initiate, modify and terminate a session and Dialog provides a sort of context (like caller, callee, location, routing etc.) to modify this session. So dialog is more related to route the sip message to right node and body (SDP) handles media session if present. Dialogs may have media sessions Or may not.
 
Take an example of B2BUA. It is a type of statefull proxy having two dialog and one media session if doing media routing.


Donald Lee <baolovebao@gmail.com> wrote:
old good questions in sip, also add another "transaction".


On Fri, Apr 25, 2008 at 8:18 AM, ­宗君 <szj087@gmail.com> wrote:
Hi, Vijay

Thanks very much for your timely answers.

From this specification,  session is a combination of signaling plane
and media plane messages and processes that enable two or more
participants to communicate. I think session is a larger scope than
dialog. In another word, one session can contain more than one dialog.
Is what I understand right?

Zongjun


2008/4/24, Vijay K. Gurbani <vkg@alcatel-lucent.com>:
> There is some work progressing in the BMWG WG to create performance
>  metrics around SIP.  One of the first tasks in such an endeavor
>  is to define the notion of dialogs and sessions.  Please see
>  Section 3.1.1 of
> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt
>  of the above draft for some insight.
>
>  Ëï×Ú¾ý wrote:
>
> > Hi, Lincoln
> >
> > thanks for your instructions.
> >
> > I know that dialog can exist without session since SUBSCRIBE/REFER can
> > create dialog and without any media between communication peers.
> >
> > What I want to know is the relationship of dialog and session when
> > they both exist in one communication activity. Take a example, when
> > there are 2 person participating talks with voice, we say there is a
> > dialog and a session.
> >
> > But when one caller invites another callee and gets five 200 final
> > responses from 5 UA every of which has its own session description. We
> > can say that there are 5 dialogs between caller and the other 5
> > callees, right? And then what is the exact number of session in this
> > scenario? One session or five session? That is what I want to know.
> >
> > Dialog is determined by dialogID (call-id, from/to tag) and session id
> > is determined by session id given in the SDP message.  My answer is
> > there are 5 dialog and one session now, right?
> >
>
>  - vijay
>  --
>  Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>  2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
>  Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
>  WWW:   http://www.alcatel-lucent.com/bell-labs
>
_______________________________________________
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



--
BR
Donald _______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion@sipforum.org



Gaurav Katiyar
Induslogic india pvt. ltd
B-34/1 sector 59 NOIDA
Phone:9818381368
 

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --0-503946771-1209125680=:97931-- --===============1644450938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1644450938==-- From sip-bounces@ietf.org Tue Apr 29 09:25:23 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C783A6E5A; Tue, 29 Apr 2008 09:25:23 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582DB3A697D; Fri, 25 Apr 2008 20:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.114 X-Spam-Level: X-Spam-Status: No, score=-101.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 3JTEQv4M0QhK; Fri, 25 Apr 2008 20:44:03 -0700 (PDT) Received: from bay0-omc3-s16.bay0.hotmail.com (bay0-omc3-s16.bay0.hotmail.com [65.54.246.216]) by core3.amsl.com (Postfix) with ESMTP id 1AD9F3A6901; Fri, 25 Apr 2008 20:44:03 -0700 (PDT) Received: from BAY107-W22 ([64.4.51.122]) by bay0-omc3-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Apr 2008 20:44:07 -0700 Message-ID: X-Originating-IP: [220.67.71.108] From: Shah Newaz To: Raj , gaurav katiyar Date: Sat, 26 Apr 2008 14:44:07 +1100 Importance: Normal In-Reply-To: <24bc18350804250815s668f9bc4x4e0cb2ecf3608c78@mail.gmail.com> References: <915213.97931.qm@web33504.mail.mud.yahoo.com> <24bc18350804250815s668f9bc4x4e0cb2ecf3608c78@mail.gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2008 03:44:07.0759 (UTC) FILETIME=[C7DEEDF0:01C8A74F] X-Mailman-Approved-At: Tue, 29 Apr 2008 09:25:22 -0700 Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1804610105==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1804610105== Content-Type: multipart/alternative; boundary="_3193497b-2976-4e7a-8cbc-d399cd038609_" --_3193497b-2976-4e7a-8cbc-d399cd038609_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 =20 hi can u help to develop the SIp client software using Visual C#. =20 =20 thank u =20 =20 Date: Fri, 25 Apr 2008 20:45:48 +0530From: rajasekhar.l@gmail.comTo: gaurav= _katiyar@yahoo.comCC: discussion@sipforum.org; szj087@gmail.com; sip@ietf.o= rg; vkg@alcatel-lucent.com; bmwg@ietf.orgSubject: Re: [SIPForum-discussion]= [Sip] What's the difference between session and dialog in SIP?Do u mean, D= ialog is at signaling level, session is at media transport level. On Fri, Apr 25, 2008 at 5:44 PM, gaurav katiyar = wrote: Sip "Session Initiation Protocol". It talks about media session, i mean how= to initiate, modify and terminate a session and Dialog provides a sort of = context (like caller, callee, location, routing etc.) to modify this sessio= n. So dialog is more related to route the sip message to right node and bod= y (SDP) handles media session if present. Dialogs may have media sessions O= r may not.=20 =20 Take an example of B2BUA. It is a type of statefull proxy having two dialog= and one media session if doing media routing.=20 Donald Lee wrote: old good questions in sip, also add another "transaction". On Fri, Apr 25, 2008 at 8:18 AM, =E5=AD=99=E5=AE=97=E5 =9B wrote: Hi, VijayThanks very much for your timely answers.From this specification, = session is a combination of signaling planeand media plane messages and pr= ocesses that enable two or moreparticipants to communicate. I think session= is a larger scope thandialog. In another word, one session can contain mor= e than one dialog.Is what I understand right?Zongjun2008/4/24, Vijay K. Gur= bani : > There is some work progressing in the BMWG WG to create performance> met= rics around SIP. One of the first tasks in such an endeavor> is to define= the notion of dialogs and sessions. Please see> Section 3.1.1 of> https:= //svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-iet= f-bmwg-sip-term-00.txt> of the above draft for some insight.> > =C3=8B=C3=AF=C3=97=C3=9A=C2=BE=C3=BD wrote:>> > Hi, Lincoln> >> > thanks= for your instructions.> >> > I know that dialog can exist without session = since SUBSCRIBE/REFER can> > create dialog and without any media between co= mmunication peers.> >> > What I want to know is the relationship of dialog = and session when> > they both exist in one communication activity. Take a e= xample, when> > there are 2 person participating talks with voice, we say t= here is a> > dialog and a session.> >> > But when one caller invites anothe= r callee and gets five 200 final> > responses from 5 UA every of which has = its own session description. We> > can say that there are 5 dialogs between= caller and the other 5> > callees, right? And then what is the exact numbe= r of session in this> > scenario? One session or five session? That is what= I want to know.> >> > Dialog is determined by dialogID (call-id, from/to t= ag) and session id> > is determined by session id given in the SDP message.= My answer is> > there are 5 dialog and one session now, right?> >>> - vi= jay> --> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent> 2701 Lucen= t Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)> Email: vkg@{alcatel-lucen= t.com,bell-labs.com,acm.org}> WWW: http://www.alcatel-lucent.com/bell-la= bs>_______________________________________________Sip mailing list https:/= /www.ietf.org/mailman/listinfo/sipThis list is for NEW development of the c= ore SIP ProtocolUse sip-implementors@cs.columbia.edu for questions on curre= nt sipUse sipping@ietf.org for new developments on the application of sip--= BRDonald _______________________________________________=20 This is the SIP Forum discussion mailing listTO UNSUBSCRIBE, or edit your d= elivery options, please visit http://sipforum.org/mailman/listinfo/discussi= onPost to the list at discussion@sipforum.org Gaurav Katiyar Induslogic india pvt. ltd B-34/1 sector 59 NOIDA Phone:9818381368 =20 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it n= ow._______________________________________________This is the SIP Forum dis= cussion mailing listTO UNSUBSCRIBE, or edit your delivery options, please v= isit http://sipforum.org/mailman/listinfo/discussionPost to the list at dis= cussion@sipforum.org-- -Raaz=20 _________________________________________________________________ Connect to the next generation of MSN Messenger=A0 http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc= e=3Dwlmailtagline= --_3193497b-2976-4e7a-8cbc-d399cd038609_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable  
 
 
hi can u help to develop the SIp client software using Visual C#.
 
 
thank u
 


 
Date: Fri, 25 Apr 2008 20:45:48 +0530
From: rajasekhar.l@gmail.com
To= : gaurav_katiyar@yahoo.com
CC: discussion@sipforum.org; szj087@gmail.com= ; sip@ietf.org; vkg@alcatel-lucent.com; bmwg@ietf.org
Subject: Re: [SIPF= orum-discussion] [Sip] What's the difference between session and dialog in = SIP?

Do u mean, Dialog is at signaling level, session is at media tr= ansport level.

On Fri, Apr 25, 2008 at 5:44 PM, gaurav katiyar= <gaurav_katiyar@yahoo.com> wrote:
Sip "Session Initiation Protocol". It talks about media session, i mea= n how to initiate, modify and terminate a session and Dialog provides = a sort of context (like caller, callee, location, routing etc.) to modify t= his session. So dialog is more related to route the sip message to right no= de and body (SDP) handles media session if present. Dialogs may have media = sessions Or may not.
 
Take an example of B2BUA. It is a type of statefull proxy having = two dialog and one media session if doing media routing.
old good questions in sip, also add another "transac= tion".


On Fri, Apr 25, 2008 at 8:18 AM, =E5­=99=E5=AE= =97=E5 =9B <szj087@gmail.com>= wrote:
Hi, Vijay

Thanks very much for your timely an= swers.

From this specification,  session is a combination of si= gnaling plane
and media plane messages and processes that enable two or = more
participants to communicate. I think session is a larger scope than=
dialog. In another word, one session can contain more than one dialog.<= BR>Is what I understand right?

Zongjun


2008/4/24, Vijay K= . Gurbani <vkg@alcatel-lucent.= com>:
> There is some work progressing in the BMWG WG t= o create performance
>  metrics around SIP.  One of the fir= st tasks in such an endeavor
>  is to define the notion of dialo= gs and sessions.  Please see
>  Section 3.1.1 of
> https://svn.resiproc= ate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-ter= m-00.txt
>  of the above draft for some insight.
>
=
>  =C3=8B=C3=AF=C3=97=C3=9A=C2=BE=C3=BD wrot= e:
>
> > Hi, Lincoln
> >
> > thanks for yo= ur instructions.
> >
> > I know that dialog can exist wit= hout session since SUBSCRIBE/REFER can
> > create dialog and witho= ut any media between communication peers.
> >
> > What I = want to know is the relationship of dialog and session when
> > th= ey both exist in one communication activity. Take a example, when
> &= gt; there are 2 person participating talks with voice, we say there is a> > dialog and a session.
> >
> > But when one cal= ler invites another callee and gets five 200 final
> > responses f= rom 5 UA every of which has its own session description. We
> > ca= n say that there are 5 dialogs between caller and the other 5
> > = callees, right? And then what is the exact number of session in this
>= ; > scenario? One session or five session? That is what I want to know.<= BR>> >
> > Dialog is determined by dialogID (call-id, from/t= o tag) and session id
> > is determined by session id given in the= SDP message.  My answer is
> > there are 5 dialog and one se= ssion now, right?
> >
>
>  - vijay
>  = --
>  Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>= ;  2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> &= nbsp;Email: vkg@{alc= atel-lucent.com,bell-= labs.com,acm.org}
&g= t;  WWW:   http://www.alcatel-lucent.com/bell-labs
>
______= _________________________________________
Sip mailing list  https://www.= ietf.org/mailman/listinfo/sip
This list is for NEW development of th= e core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Us= e sipping@ietf.org for new developm= ents on the application of sip



--
BR
Donald _____________________________= __________________=20

This is the SIP Forum discussion mailing listTO UNSUBSCRIBE, or edit your delivery options, please visit http://sipfor= um.org/mailman/listinfo/discussion
Post to the list at discussion@sipforum.org



Gaurav= Katiyar
Induslogic india pvt. ltd
B-34/1 sector 59 NOIDA
Phone:9818381368
 

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

_______= ________________________________________
This is the SIP Forum discussio= n mailing list
TO UNSUBSCRIBE, or edit your delivery options, please vis= it http://sipforum.org/mailman/listinfo/discussion
Post to the list= at discussion@sipforum.org<= BR>



--
-Raaz
Connect to the next generation of MSN Messenger=A0 Get it now! = --_3193497b-2976-4e7a-8cbc-d399cd038609_-- --===============1804610105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1804610105==-- From sip-bounces@ietf.org Tue Apr 29 09:27:05 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DDF28C378; Tue, 29 Apr 2008 09:27:05 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1177928C367 for ; Fri, 25 Apr 2008 08:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 5xrHLY3w-nFw for ; Fri, 25 Apr 2008 08:15:44 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by core3.amsl.com (Postfix) with ESMTP id 5B83328C297 for ; Fri, 25 Apr 2008 08:15:44 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so3131123wxd.31 for ; Fri, 25 Apr 2008 08:15: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:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=pftuSLpXLUpvLxbSq96iL03O2r5MOr6z90PyCGHRheI=; b=qFYNetNz7Wt24ody5o+XNQA0nPMUT4ermODJ4eJTyhq+CvBYnsFujQnhSURpPeFRQdmuLygyLg/P++0tcydFqyT0HrLUgbk6WEFk0vD167CgWfO51mXrCyO8wxu7dPz3bcxuschV8bZPDTrJ2Wp6Qppzmsgd3Dik7l+KTpFK9yM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LjyNWypChAubFDpmGFxQVJB6eD1g+4EJtNnvjHwFIz+mfQOQnyj4TsDiDBTV7w3yYl9A+X9Qr9wj3Tcs/p9/4FOFKCZAsQOjnJ/3RtHwrivK59hB0p86voGwyI/+DDDaZfiaFg9RKi+uZuKeUthONfGfCQmAaTW66EaLakKZfrQ= Received: by 10.100.133.1 with SMTP id g1mr7763048and.88.1209136548795; Fri, 25 Apr 2008 08:15:48 -0700 (PDT) Received: by 10.100.123.10 with HTTP; Fri, 25 Apr 2008 08:15:48 -0700 (PDT) Message-ID: <24bc18350804250815s668f9bc4x4e0cb2ecf3608c78@mail.gmail.com> Date: Fri, 25 Apr 2008 20:45:48 +0530 From: Raj To: "gaurav katiyar" In-Reply-To: <915213.97931.qm@web33504.mail.mud.yahoo.com> MIME-Version: 1.0 References: <915213.97931.qm@web33504.mail.mud.yahoo.com> X-Mailman-Approved-At: Tue, 29 Apr 2008 09:27:03 -0700 Cc: discussion@sipforum.org, sip@ietf.org, bmwg@ietf.org Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0280121298==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0280121298== Content-Type: multipart/alternative; boundary="----=_Part_6505_26625270.1209136548737" ------=_Part_6505_26625270.1209136548737 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Do u mean, Dialog is at signaling level, session is at media transport level. On Fri, Apr 25, 2008 at 5:44 PM, gaurav katiyar wrote: > Sip "Session Initiation Protocol". It talks about media session, i mean h= ow > to initiate, modify and terminate a session and Dialog provides a sort of > context (like caller, callee, location, routing etc.) to modify this > session. So dialog is more related to route the sip message to right node > and body (SDP) handles media session if present. Dialogs may have media > sessions Or may not. > > Take an example of B2BUA. It is a type of statefull proxy having two dial= og > and one media session if doing media routing. > > > *Donald Lee * wrote: > > old good questions in sip, also add another "transaction". > > > On Fri, Apr 25, 2008 at 8:18 AM, =E5=AD=99=E5(R)=97=E5 =9B wrote: > >> Hi, Vijay >> >> Thanks very much for your timely answers. >> >> From this specification, session is a combination of signaling plane >> and media plane messages and processes that enable two or more >> participants to communicate. I think session is a larger scope than >> dialog. In another word, one session can contain more than one dialog. >> Is what I understand right? >> >> Zongjun >> >> >> 2008/4/24, Vijay K. Gurbani : >> > There is some work progressing in the BMWG WG to create performance >> > metrics around SIP. One of the first tasks in such an endeavor >> > is to define the notion of dialogs and sessions. Please see >> > Section 3.1.1 of >> > >> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/= draft-ietf-bmwg-sip-term-00.txt >> > of the above draft for some insight. >> > >> > =C3=8B=C3=AF=C3=97=C3=9A=C2=BE=C3=BD wrote: >> > >> > > Hi, Lincoln >> > > >> > > thanks for your instructions. >> > > >> > > I know that dialog can exist without session since SUBSCRIBE/REFER c= an >> > > create dialog and without any media between communication peers. >> > > >> > > What I want to know is the relationship of dialog and session when >> > > they both exist in one communication activity. Take a example, when >> > > there are 2 person participating talks with voice, we say there is a >> > > dialog and a session. >> > > >> > > But when one caller invites another callee and gets five 200 final >> > > responses from 5 UA every of which has its own session description. = We >> > > can say that there are 5 dialogs between caller and the other 5 >> > > callees, right? And then what is the exact number of session in this >> > > scenario? One session or five session? That is what I want to know. >> > > >> > > Dialog is determined by dialogID (call-id, from/to tag) and session = id >> > > is determined by session id given in the SDP message. My answer is >> > > there are 5 dialog and one session now, right? >> > > >> > >> > - vijay >> > -- >> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >> > WWW: http://www.alcatel-lucent.com/bell-labs >> > >> _______________________________________________ >> 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 >> > > > > -- > BR > Donald _______________________________________________ > This is the SIP Forum discussion mailing list > TO UNSUBSCRIBE, or edit your delivery options, please visit > http://sipforum.org/mailman/listinfo/discussion > Post to the list at discussion@sipforum.org > > > > > Gaurav Katiyar > Induslogic india pvt. ltd > B-34/1 sector 59 NOIDA > Phone:9818381368 > > > ------------------------------ > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > now. > > _______________________________________________ > This is the SIP Forum discussion mailing list > TO UNSUBSCRIBE, or edit your delivery options, please visit > http://sipforum.org/mailman/listinfo/discussion > Post to the list at discussion@sipforum.org > > --=20 -Raaz ------=_Part_6505_26625270.1209136548737 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Do u mean, Dialog is at signaling level, session is at media transport leve= l.

On Fri, Apr 25, 2008 at 5:44 PM, gaura= v katiyar <gaurav_katiyar@ya= hoo.com> wrote:
Sip "Se= ssion Initiation Protocol". It talks about media session, i mean how t= o initiate, modify and terminate a session and Dialog provides a sort = of context (like caller, callee, location, routing etc.) to modify this ses= sion. So dialog is more related to route the sip message to right node and = body (SDP) handles media session if present. Dialogs may have media session= s Or may not.
 
Take an example of B2BUA. It is a type of st= atefull proxy having two dialog and one media session if doing media routin= g.


Donald Lee <baolovebao@gmail.com= > wrote:
old good questions i= n sip, also add another "transaction".


On Fri, Apr 25, 2008 at 8:18 AM, =E5=AD=99=E5®=97= =E5 =9B <szj087@gm= ail.com> wrote:
Hi, Vijay

Thanks very much for your timely ans= wers.

From this specification,  session is a combination of sig= naling plane
and media plane messages and processes that enable two or m= ore
participants to communicate. I think session is a larger scope than
dial= og. In another word, one session can contain more than one dialog.
Is wh= at I understand right?

Zongjun


2008/4/24, Vijay K. Gurban= i <vkg@alcat= el-lucent.com>:
> There is some w= ork progressing in the BMWG WG to create performance
>  metrics = around SIP.  One of the first tasks in such an endeavor
>  = is to define the notion of dialogs and sessions.  Please see
>  Section 3.1.1 of
> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmw= g-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt
>  of the above draft for some insight.
>
=
>  =C3=8B=C3=AF=C3=97=C3=9A=C2=BE=C3=BD= wrote:
>
> > Hi, Lincoln
> >
> > thanks f= or your instructions.
> >
> > I know that dialog can exist without session since SUBSCRIBE/REFE= R can
> > create dialog and without any media between communicatio= n peers.
> >
> > What I want to know is the relationship = of dialog and session when
> > they both exist in one communication activity. Take a example, wh= en
> > there are 2 person participating talks with voice, we say t= here is a
> > dialog and a session.
> >
> > But = when one caller invites another callee and gets five 200 final
> > responses from 5 UA every of which has its own session description. We
= > > can say that there are 5 dialogs between caller and the other 5> > callees, right? And then what is the exact number of session in= this
> > scenario? One session or five session? That is what I want to kno= w.
> >
> > Dialog is determined by dialogID (call-id, fro= m/to tag) and session id
> > is determined by session id given in = the SDP message.  My answer is
> > there are 5 dialog and one session now, right?
> >
&g= t;
>  - vijay
>  --
>  Vijay K. Gurbani, B= ell Laboratories, Alcatel-Lucent
>  2701 Lucent Lane, Rm. 9F-546= , Lisle, Illinois 60532 (USA)
>  Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.or= g}
>  WWW:   http://www.alcatel-lucent.com/bell-labs
>
_________________= ______________________________
Sip mailing list  https://www.ietf.org/= mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementor= s@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developme= nts on the application of sip



-- BR
Donald _______________________________________________

This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE= , or edit your delivery options, please visit http://sipforum.org/mailma= n/listinfo/discussion
Post to the list at discussion@sipforum.org



Gaurav Katiyar
Induslogic india pvt. ltd
B-34/1 sector 59 NOIDA
Phone:= 9818381368
 

=20

Be a better friend, newshound, and=20 know-it-all with Yahoo! Mobile. Try it now.

________________________________________= _______
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipfo= rum.org/mailman/listinfo/discussion
Post to the list at discussion@s= ipforum.org




--
-Raaz ------=_Part_6505_26625270.1209136548737-- --===============0280121298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0280121298==-- From sip-bounces@ietf.org Tue Apr 29 10:02:31 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4A028C361; Tue, 29 Apr 2008 10:02:31 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D6828C36B; Tue, 29 Apr 2008 10:02:29 -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 7OJpWFy7pY8f; Tue, 29 Apr 2008 10:02:24 -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 DACE028C361; Tue, 29 Apr 2008 10:02:23 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2008 10:02:27 -0700 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 m3TH2Rkc014197; Tue, 29 Apr 2008 10:02:27 -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 m3TH2Pbe021139; Tue, 29 Apr 2008 17:02:27 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, 29 Apr 2008 13:02:21 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 13:02:21 -0400 Message-ID: <481754BE.1060505@cisco.com> Date: Tue, 29 Apr 2008 13:02:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: gaurav katiyar References: <915213.97931.qm@web33504.mail.mud.yahoo.com> In-Reply-To: <915213.97931.qm@web33504.mail.mud.yahoo.com> X-OriginalArrivalTime: 29 Apr 2008 17:02:21.0726 (UTC) FILETIME=[CA2393E0:01C8AA1A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6713; t=1209488547; x=1210352547; 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]=20[SIPForum-discussion]=20What's= 20the=20difference=20between=09session=0A=20and=20dialog=20i n=20SIP? |Sender:=20; bh=t6e+PwEuJyrFlcY7ytlsgI7MLrJt/MkT2AZTwVLZhbM=; b=JP4/TsByNnHY8HKw4c6Xuu2ahTmv2C3+aO5vvj/hj3ux5JjtJ/YCJkRyZo j8j3m9V1i6RNGl7whDYhdDzdiDZI1OUacKMPCFwVUP05peXWp/IU85xB+ruv r2eNPhrU42; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1943284472==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1943284472== Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit gaurav katiyar wrote: > Sip "Session Initiation Protocol". It talks about media session, i mean > how to initiate, modify and terminate a session and Dialog provides a > sort of context (like caller, callee, location, routing etc.) to modify > this session. So dialog is more related to route the sip message to > right node and body (SDP) handles media session if present. Dialogs may > have media sessions Or may not. > > Take an example of B2BUA. It is a type of statefull proxy having two > dialog and one media session if doing media routing. Maybe. IMO these concepts aren't sufficiently defined. One view is that a session is whatever SDP describes. Thus its one session regardless of how many media streams it contains. And in the case of an SDP containing multicast media addresses, and possibly advertised via SAP, there could be many participants in the same session. But then in sip it takes a pair of SDPs to establish a call. Is that one session, or two? And in your case above with the B2BUA, is it one session, or two, or four? Another view is that a session in the context of sip is whatever is established as a result of an INVITE. Then I guess the pair of SDPs together describe one session, regardless of how many media streams. But in that case the B2BUA example would be two sessions. Then consider a more complex case: audio /-------- C / A ========== B audio \ video \-------- D video Here B is a B2BUA and media relay as in your example, but one stream is relayed to C and the other to D. In this case, how many sessions are there? A, C, and D each have one, but are any of those the same? Or are there three altogether? When I see "session" used, I just assume it means something vague, and read on to see what is actually meant. Paul > */Donald Lee /* wrote: > > old good questions in sip, also add another "transaction". > > > On Fri, Apr 25, 2008 at 8:18 AM, 孙宗君 > wrote: > > Hi, Vijay > > Thanks very much for your timely answers. > > From this specification, session is a combination of signaling > plane > and media plane messages and processes that enable two or more > participants to communicate. I think session is a larger scope than > dialog. In another word, one session can contain more than one > dialog. > Is what I understand right? > > Zongjun > > > 2008/4/24, Vijay K. Gurbani >: > > There is some work progressing in the BMWG WG to create > performance > > metrics around SIP. One of the first tasks in such an endeavor > > is to define the notion of dialogs and sessions. Please see > > Section 3.1.1 of > > > https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt > > of the above draft for some insight. > > > > Ëï×Ú¾ý wrote: > > > > > Hi, Lincoln > > > > > > thanks for your instructions. > > > > > > I know that dialog can exist without session since > SUBSCRIBE/REFER can > > > create dialog and without any media between communication > peers. > > > > > > What I want to know is the relationship of dialog and > session when > > > they both exist in one communication activity. Take a > example, when > > > there are 2 person participating talks with voice, we say > there is a > > > dialog and a session. > > > > > > But when one caller invites another callee and gets five > 200 final > > > responses from 5 UA every of which has its own session > description. We > > > can say that there are 5 dialogs between caller and the other 5 > > > callees, right? And then what is the exact number of > session in this > > > scenario? One session or five session? That is what I want > to know. > > > > > > Dialog is determined by dialogID (call-id, from/to tag) and > session id > > > is determined by session id given in the SDP message. My > answer is > > > there are 5 dialog and one session now, right? > > > > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > Email: vkg@{alcatel-lucent.com > ,bell-labs.com > ,acm.org } > > WWW: http://www.alcatel-lucent.com/bell-labs > > > _______________________________________________ > 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 > > > > > -- > BR > Donald _______________________________________________ > This is the SIP Forum discussion mailing list > TO UNSUBSCRIBE, or edit your delivery options, please visit > http://sipforum.org/mailman/listinfo/discussion > Post to the list at discussion@sipforum.org > > > > > Gaurav Katiyar > Induslogic india pvt. ltd > B-34/1 sector 59 NOIDA > Phone:9818381368 > > > ------------------------------------------------------------------------ > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try > it now. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 --===============1943284472== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1943284472==-- From sip-bounces@ietf.org Tue Apr 29 20:37:08 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1123A6DF3; Tue, 29 Apr 2008 20:37:08 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17883A6D69; Tue, 29 Apr 2008 20:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 6YeKoSvbNDTw; Tue, 29 Apr 2008 20:37:05 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by core3.amsl.com (Postfix) with ESMTP id 257423A6E89; Tue, 29 Apr 2008 20:36:47 -0700 (PDT) Received: from epmmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K04009A7CP3PN@mailout3.samsung.com>; Wed, 30 Apr 2008 12:36:39 +0900 (KST) Received: from mahesha ([107.108.74.147]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0K04008UDCP17W@mmp2.samsung.com>; Wed, 30 Apr 2008 12:36:39 +0900 (KST) Date: Wed, 30 Apr 2008 09:10:54 +0530 From: Mahesh Anjanappa To: Paul Kyzivat , gaurav katiyar Message-id: <0a4301c8aa73$ffb17500$934a6c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <915213.97931.qm@web33504.mail.mud.yahoo.com> <481754BE.1060505@cisco.com> Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1147924830==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1147924830== Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=original Content-transfer-encoding: 8BIT I'm surprised to see that a fundamental concept "SIP Session" does not have a clear definition documented anywhere. I was eagerly waiting for a IETF Guru to clarify this. I wish somebody writes a draft clarifying all the undocumented fundamental concepts in SIP. If i knew it all, i would have done it :-) My 2 cents on it. A Session is a Rendezvous Contract between 2 or more UA's for communnicating with some modality. SIP dialog is a context over which such a Contract is negotiated decided, and upheld. Normally the SDP Session Id should identify the Contract/Session. But not necessarily always. If its a multiparty the Conference ID would serve such a purpose. I can get into a session with a non-INVITE dialog as well. Example: SUBSCRIBE to a specialized Event package. In this case some Identifier in the Event package probably will serve as the Session Id. As you can see there can be more than 1 dialog related a Session. But there is no documentation saying what exactly threads all the dialogs to a Session except the mentioning of a ID in the SDP RFC to identify the session being described in a SDP. My understanding is that a Session Identifier can take the form of Conference ID or any other depending on the method used to setup the rendezvoud/session. Well, the above is my understanding of it, not based on any existing draft or RFC, so i welcome whatever corrections need be. regards Mahesh ----- Original Message ----- From: "Paul Kyzivat" To: "gaurav katiyar" Cc: ; ; Sent: Tuesday, April 29, 2008 10:32 PM Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? > > > gaurav katiyar wrote: >> Sip "Session Initiation Protocol". It talks about media session, i mean >> how to initiate, modify and terminate a session and Dialog provides a >> sort of context (like caller, callee, location, routing etc.) to modify >> this session. So dialog is more related to route the sip message to >> right node and body (SDP) handles media session if present. Dialogs may >> have media sessions Or may not. >> >> Take an example of B2BUA. It is a type of statefull proxy having two >> dialog and one media session if doing media routing. > > Maybe. IMO these concepts aren't sufficiently defined. > > One view is that a session is whatever SDP describes. Thus its one > session regardless of how many media streams it contains. And in the > case of an SDP containing multicast media addresses, and possibly > advertised via SAP, there could be many participants in the same session. > > But then in sip it takes a pair of SDPs to establish a call. Is that one > session, or two? And in your case above with the B2BUA, is it one > session, or two, or four? > > Another view is that a session in the context of sip is whatever is > established as a result of an INVITE. Then I guess the pair of SDPs > together describe one session, regardless of how many media streams. But > in that case the B2BUA example would be two sessions. > > Then consider a more complex case: > > audio > /-------- C > / > A ========== B > audio \ > video \-------- D > video > > Here B is a B2BUA and media relay as in your example, but one stream is > relayed to C and the other to D. > > In this case, how many sessions are there? A, C, and D each have one, > but are any of those the same? Or are there three altogether? > > When I see "session" used, I just assume it means something vague, and > read on to see what is actually meant. > > Paul > >> */Donald Lee /* wrote: >> >> old good questions in sip, also add another "transaction". >> >> >> On Fri, Apr 25, 2008 at 8:18 AM, 孙宗君 > > wrote: >> >> Hi, Vijay >> >> Thanks very much for your timely answers. >> >> From this specification, session is a combination of signaling >> plane >> and media plane messages and processes that enable two or more >> participants to communicate. I think session is a larger scope >> than >> dialog. In another word, one session can contain more than one >> dialog. >> Is what I understand right? >> >> Zongjun >> >> >> 2008/4/24, Vijay K. Gurbani > >: >> > There is some work progressing in the BMWG WG to create >> performance >> > metrics around SIP. One of the first tasks in such an >> endeavor >> > is to define the notion of dialogs and sessions. Please see >> > Section 3.1.1 of >> > >> >> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt >> > of the above draft for some insight. >> > >> > Ëï×Ú¾ý wrote: >> > >> > > Hi, Lincoln >> > > >> > > thanks for your instructions. >> > > >> > > I know that dialog can exist without session since >> SUBSCRIBE/REFER can >> > > create dialog and without any media between communication >> peers. >> > > >> > > What I want to know is the relationship of dialog and >> session when >> > > they both exist in one communication activity. Take a >> example, when >> > > there are 2 person participating talks with voice, we say >> there is a >> > > dialog and a session. >> > > >> > > But when one caller invites another callee and gets five >> 200 final >> > > responses from 5 UA every of which has its own session >> description. We >> > > can say that there are 5 dialogs between caller and the >> other 5 >> > > callees, right? And then what is the exact number of >> session in this >> > > scenario? One session or five session? That is what I want >> to know. >> > > >> > > Dialog is determined by dialogID (call-id, from/to tag) and >> session id >> > > is determined by session id given in the SDP message. My >> answer is >> > > there are 5 dialog and one session now, right? >> > > >> > >> > - vijay >> > -- >> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> > Email: vkg@{alcatel-lucent.com >> ,bell-labs.com >> ,acm.org } >> > WWW: http://www.alcatel-lucent.com/bell-labs >> > >> _______________________________________________ >> 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 >> >> >> >> >> -- >> BR >> Donald _______________________________________________ >> This is the SIP Forum discussion mailing list >> TO UNSUBSCRIBE, or edit your delivery options, please visit >> http://sipforum.org/mailman/listinfo/discussion >> Post to the list at discussion@sipforum.org >> >> >> >> >> Gaurav Katiyar >> Induslogic india pvt. ltd >> B-34/1 sector 59 NOIDA >> Phone:9818381368 >> >> >> ------------------------------------------------------------------------ >> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try >> it now. >> > > >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > --===============1147924830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1147924830==-- From sip-bounces@ietf.org Wed Apr 30 05:57:15 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278423A68FD; Wed, 30 Apr 2008 05:57:15 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D8B3A68FD; Wed, 30 Apr 2008 05:57:13 -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 rFG04EbutUvj; Wed, 30 Apr 2008 05:57: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 0CF5E28C391; Wed, 30 Apr 2008 05:56:46 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 Apr 2008 05:56:48 -0700 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 m3UCumAU004605; Wed, 30 Apr 2008 05:56:48 -0700 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 m3UCuaeg000049; Wed, 30 Apr 2008 12:56:48 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, 30 Apr 2008 08:56:46 -0400 Received: from [10.82.234.76] ([10.82.234.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 08:56:42 -0400 Message-ID: <48186CAB.4050800@cisco.com> Date: Wed, 30 Apr 2008 08:57:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: gaurav katiyar References: <102908.62033.qm@web33508.mail.mud.yahoo.com> In-Reply-To: <102908.62033.qm@web33508.mail.mud.yahoo.com> X-OriginalArrivalTime: 30 Apr 2008 12:56:42.0927 (UTC) FILETIME=[A38B13F0:01C8AAC1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11214; t=1209560208; x=1210424208; 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]=20[SIPForum-discussion]=20What's= 20the=20difference=20between=20session=0A=20and=20dialog=20i n=20SIP? |Sender:=20; bh=iWjHJLQVzvS95xqQw266Xcw1xZylkXocD2dZBAc6j04=; b=WDOgyn4STfAk2/05dY8hFuVCM3VJTIyyGatDaQ5MWwSAScNp+uH1PbwGxO Lp9lMPF2/q3DAcwwn6cez0BHreCGkJybp6b4pChH7K8bwEpzi+J0GgpTlbnC GLLJ5QHTC2; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0279340841==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0279340841== Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit gaurav katiyar wrote: > Hi, > I am getting confused now. what session exactly is ? Why ACK is an > end to end request for 200 OK of INVITE request? does it relate to > session any where ??? :-). Is it right to generate ACK locally by any > proxy including B2BUA for 200 OK of initial INVITE request? The ACK is part of the INVITE and hence to establishing an INVITE dialog and usage. It also *may* be a carrier for an SDP answer that completes an o/a and thus supports the establishment of an sdp media "session". It is not permissible for a proxy to generate an ACK, except in response to a failed invite. You should never write a statement like "proxy including B2BUA", because those are very different things, and have different rules. A B2BUA *is* a UA, and hence may/must follow UA rules. Only UAs (including B2BUAs) generate ACK for 2xx responses to INVITE. I think for the questions you seem to be worried about you should stop worrying about the meaning of "session" - it has no pertinence to what you are doing. What you need to be concerned with is establishing an INVITE dialog. (Technically it is a dialog plus an invite dialog usage, but that may be more detail than you need.) Paul > Gaurav > > */Mahesh Anjanappa /* wrote: > > I'm surprised to see that a fundamental concept "SIP Session" does > not have > a clear definition documented anywhere. I was eagerly waiting for a > IETF > Guru > to clarify this. I wish somebody writes a draft clarifying all the > undocumented > fundamental concepts in SIP. If i knew it all, i would have done it :-) > > My 2 cents on it. > A Session is a Rendezvous Contract between 2 or more UA's for > communnicating > with some modality. SIP dialog is a context over which such a > Contract is > negotiated > decided, and upheld. > Normally the SDP Session Id should identify the Contract/Session. > But not > necessarily > always. If its a multiparty the Conference ID would serve such a > purpose. > I can get into a session with a non-INVITE dialog as well. Example: > SUBSCRIBE to > a specialized Event package. In this case some Identifier in the Event > package probably will > serve as the Session Id. > As you can see there can be more than 1 dialog related a Session. > But there is no documentation saying what exactly threads all the > dialogs to > a Session except > the mentioning of a ID in the SDP RFC to identify the session being > described in a SDP. > > My understanding is that a Session Identifier can take the form of > Conference ID or any > other depending on the method used to setup the rendezvoud/session. > > Well, the above is my understanding of it, not based on any existing > draft > or RFC, so i welcome > whatever corrections need be. > > regards > Mahesh > > ----- Original Message ----- > From: "Paul Kyzivat" > To: "gaurav katiyar" > Cc: ; ; > Sent: Tuesday, April 29, 2008 10:32 PM > Subject: Re: [Sip] [SIPForum-discussion] What's the difference between > session and dialog in SIP? > > > > > > > > gaurav katiyar wrote: > >> Sip "Session Initiation Protocol". It talks about media session, > i mean > >> how to initiate, modify and terminate a session and Dialog > provides a > >> sort of context (like caller, callee, location, routing etc.) to > modify > >> this session. So dialog is more related to route the sip message to > >> right node and body (SDP) handles media session if present. > Dialogs may > >> have media sessions Or may not. > >> > >> Take an example of B2BUA. It is a type of statefull proxy having two > >> dialog and one media session if doing media routing. > > > > Maybe. IMO these concepts aren't sufficiently defined. > > > > One view is that a session is whatever SDP describes. Thus its one > > session regardless of how many media streams it contains. And in the > > case of an SDP containing multicast media addresses, and possibly > > advertised via SAP, there could be many participants in the same > session. > > > > But then in sip it takes a pair of SDPs to establish a call. Is > that one > > session, or two? And in your case above with the B2BUA, is it one > > session, or two, or four? > > > > Another view is that a session in the context of sip is whatever is > > established as a result of an INVITE. Then I guess the pair of SDPs > > together describe one session, regardless of how many media > streams. But > > in that case the B2BUA example would be two sessions. > > > > Then consider a more complex case: > > > > audio > > /-------- C > > / > > A ========== B > > audio \ > > video \-------- D > > video > > > > Here B is a B2BUA and media relay as in your example, but one > stream is > > relayed to C and the other to D. > > > > In this case, how many sessions are there? A, C, and D each have one, > > but are any of those the same? Or are there three altogether? > > > > When I see "session" used, I just assume it means something > vague, and > > read on to see what is actually meant. > > > > Paul > > > >> */Donald Lee /* wrote: > >> > >> old good questions in sip, also add another "transaction". > >> > >> > >> On Fri, Apr 25, 2008 at 8:18 AM, 孙宗君 > >> > wrote: > >> > >> Hi, Vijay > >> > >> Thanks very much for your timely answers. > >> > >> From this specification, session is a combination of signaling > >> plane > >> and media plane messages and processes that enable two or more > >> participants to communicate. I think session is a larger scope > >> than > >> dialog. In another word, one session can contain more than one > >> dialog. > >> Is what I understand right? > >> > >> Zongjun > >> > >> > >> 2008/4/24, Vijay K. Gurbani > >> >: > >> > There is some work progressing in the BMWG WG to create > >> performance > >> > metrics around SIP. One of the first tasks in such an > >> endeavor > >> > is to define the notion of dialogs and sessions. Please see > >> > Section 3.1.1 of > >> > > >> > >> > https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt > >> > of the above draft for some insight. > >> > > >> > Ëï×Ú¾ý wrote: > >> > > >> > > Hi, Lincoln > >> > > > >> > > thanks for your instructions. > >> > > > >> > > I know that dialog can exist without session since > >> SUBSCRIBE/REFER can > >> > > create dialog and without any media between communication > >> peers. > >> > > > >> > > What I want to know is the relationship of dialog and > >> session when > >> > > they both exist in one communication activity. Take a > >> example, when > >> > > there are 2 person participating talks with voice, we say > >> there is a > >> > > dialog and a session. > >> > > > >> > > But when one caller invites another callee and gets five > >> 200 final > >> > > responses from 5 UA every of which has its own session > >> description. We > >> > > can say that there are 5 dialogs between caller and the > >> other 5 > >> > > callees, right? And then what is the exact number of > >> session in this > >> > > scenario? One session or five session? That is what I want > >> to know. > >> > > > >> > > Dialog is determined by dialogID (call-id, from/to tag) and > >> session id > >> > > is determined by session id given in the SDP message. My > >> answer is > >> > > there are 5 dialog and one session now, right? > >> > > > >> > > >> > - vijay > >> > -- > >> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > >> > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > >> > Email: vkg@{alcatel-lucent.com > >> ,bell-labs.com > >> ,acm.org } > >> > WWW: http://www.alcatel-lucent.com/bell-labs > >> > > >> _______________________________________________ > >> 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 > >> > >> > >> > >> > >> -- > >> BR > >> Donald _______________________________________________ > >> This is the SIP Forum discussion mailing list > >> TO UNSUBSCRIBE, or edit your delivery options, please visit > >> http://sipforum.org/mailman/listinfo/discussion > >> Post to the list at discussion@sipforum.org > >> > >> > >> > >> > >> Gaurav Katiyar > >> Induslogic india pvt. ltd > >> B-34/1 sector 59 NOIDA > >> Phone:9818381368 > >> > >> > >> > ------------------------------------------------------------------------ > >> Be a better friend, newshound, and know-it-all with Yahoo! > Mobile. Try > >> it now. > >> >> > > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> 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 > > > > > > > Gaurav Katiyar > Induslogic india pvt. ltd > B-34/1 sector 59 NOIDA > Phone:9818381368 > > > ------------------------------------------------------------------------ > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try > it now. > > --===============0279340841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0279340841==-- From sip-bounces@ietf.org Wed Apr 30 06:05:07 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88C428C3B2; Wed, 30 Apr 2008 06:05:06 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4503928C3AF; Wed, 30 Apr 2008 06:05:04 -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 9mjd02wOdGSK; Wed, 30 Apr 2008 06:05:00 -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 0DCAC28C3AA; Wed, 30 Apr 2008 06:04:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="6795137" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2008 09:05:01 -0400 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 m3UD51Pu018359; Wed, 30 Apr 2008 09:05:01 -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 m3UD50fK007397; Wed, 30 Apr 2008 13:05:01 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, 30 Apr 2008 09:04:57 -0400 Received: from [10.82.234.76] ([10.82.234.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 09:04:56 -0400 Message-ID: <48186E99.7080306@cisco.com> Date: Wed, 30 Apr 2008 09:05:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Mahesh Anjanappa References: <915213.97931.qm@web33504.mail.mud.yahoo.com> <481754BE.1060505@cisco.com> <0a4301c8aa73$ffb17500$934a6c6b@sisodomain.com> In-Reply-To: <0a4301c8aa73$ffb17500$934a6c6b@sisodomain.com> X-OriginalArrivalTime: 30 Apr 2008 13:04:56.0920 (UTC) FILETIME=[C9FC6D80:01C8AAC2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10266; t=1209560701; x=1210424701; 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]=20[SIPForum-discussion]=20What's= 20the=20difference=20between=09session=0A=20and=20dialog=20i n=20SIP? |Sender:=20 |To:=20Mahesh=20Anjanappa=20; bh=aQDuiAVMhrEq845AePcWaL2A+/mC+6q57ONIs8J+1Yk=; b=A+oCmF1WLsukfMix6EhA1Kzr8Az89Mk1BAmn/WhXusQv+YxnE5qXlxdlcc v+C5Mb2K7vnsJZjUpx2faNcddmC7nJFGLwyEqRdgGn6wAaYA7R0PGbkH1i9z 3uOWkyKbb1; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org, gaurav katiyar Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1280639613==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1280639613== Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Mahesh Anjanappa wrote: > I'm surprised to see that a fundamental concept "SIP Session" does not have > a clear definition documented anywhere. I was eagerly waiting for a IETF > Guru > to clarify this. I wish somebody writes a draft clarifying all the > undocumented > fundamental concepts in SIP. If i knew it all, i would have done it :-) IMO the reason there is no definition of such a "fundamental concept" is that it isn't fundamental. While it might be interesting to discuss, it doesn't affect anything. And in fact, when you start to dig into what this "fundamental concept" means it starts to fall apart. > My 2 cents on it. > A Session is a Rendezvous Contract between 2 or more UA's for > communnicating > with some modality. SIP dialog is a context over which such a Contract > is negotiated > decided, and upheld. > Normally the SDP Session Id should identify the Contract/Session. But > not necessarily > always. If its a multiparty the Conference ID would serve such a purpose. Is each modality a separate contract? Or is is a contract for a *collection* of modalities? (E.g. voice + video) > I can get into a session with a non-INVITE dialog as well. Example: > SUBSCRIBE to > a specialized Event package. In this case some Identifier in the Event > package probably will > serve as the Session Id. Do you mean to imply that the event notifications are then the communication modality? > As you can see there can be more than 1 dialog related a Session. > But there is no documentation saying what exactly threads all the > dialogs to a Session except > the mentioning of a ID in the SDP RFC to identify the session being > described in a SDP. > > My understanding is that a Session Identifier can take the form of > Conference ID or any > other depending on the method used to setup the rendezvoud/session. > > Well, the above is my understanding of it, not based on any existing > draft or RFC, so i welcome > whatever corrections need be. Its a decent try. As I mentioned in a prior reply, IMO there is no real need to define this. I'm not fully understanding what you are proposing (see questions above). I expect that it may start to fall apart in the details of particular use cases. Will you explain to me how your definition relates to the use case with A/B/C/D that I gave? Paul > regards > Mahesh > > ----- Original Message ----- From: "Paul Kyzivat" > To: "gaurav katiyar" > Cc: ; ; > Sent: Tuesday, April 29, 2008 10:32 PM > Subject: Re: [Sip] [SIPForum-discussion] What's the difference between > session and dialog in SIP? > > >> >> >> gaurav katiyar wrote: >>> Sip "Session Initiation Protocol". It talks about media session, i mean >>> how to initiate, modify and terminate a session and Dialog provides a >>> sort of context (like caller, callee, location, routing etc.) to modify >>> this session. So dialog is more related to route the sip message to >>> right node and body (SDP) handles media session if present. Dialogs may >>> have media sessions Or may not. >>> >>> Take an example of B2BUA. It is a type of statefull proxy having two >>> dialog and one media session if doing media routing. >> >> Maybe. IMO these concepts aren't sufficiently defined. >> >> One view is that a session is whatever SDP describes. Thus its one >> session regardless of how many media streams it contains. And in the >> case of an SDP containing multicast media addresses, and possibly >> advertised via SAP, there could be many participants in the same session. >> >> But then in sip it takes a pair of SDPs to establish a call. Is that one >> session, or two? And in your case above with the B2BUA, is it one >> session, or two, or four? >> >> Another view is that a session in the context of sip is whatever is >> established as a result of an INVITE. Then I guess the pair of SDPs >> together describe one session, regardless of how many media streams. But >> in that case the B2BUA example would be two sessions. >> >> Then consider a more complex case: >> >> audio >> /-------- C >> / >> A ========== B >> audio \ >> video \-------- D >> video >> >> Here B is a B2BUA and media relay as in your example, but one stream is >> relayed to C and the other to D. >> >> In this case, how many sessions are there? A, C, and D each have one, >> but are any of those the same? Or are there three altogether? >> >> When I see "session" used, I just assume it means something vague, and >> read on to see what is actually meant. >> >> Paul >> >>> */Donald Lee /* wrote: >>> >>> old good questions in sip, also add another "transaction". >>> >>> >>> On Fri, Apr 25, 2008 at 8:18 AM, 孙宗君 >> > wrote: >>> >>> Hi, Vijay >>> >>> Thanks very much for your timely answers. >>> >>> From this specification, session is a combination of signaling >>> plane >>> and media plane messages and processes that enable two or more >>> participants to communicate. I think session is a larger >>> scope than >>> dialog. In another word, one session can contain more than one >>> dialog. >>> Is what I understand right? >>> >>> Zongjun >>> >>> >>> 2008/4/24, Vijay K. Gurbani >> >: >>> > There is some work progressing in the BMWG WG to create >>> performance >>> > metrics around SIP. One of the first tasks in such an >>> endeavor >>> > is to define the notion of dialogs and sessions. Please see >>> > Section 3.1.1 of >>> > >>> >>> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt >>> >>> > of the above draft for some insight. >>> > >>> > Ëï×Ú¾ý wrote: >>> > >>> > > Hi, Lincoln >>> > > >>> > > thanks for your instructions. >>> > > >>> > > I know that dialog can exist without session since >>> SUBSCRIBE/REFER can >>> > > create dialog and without any media between communication >>> peers. >>> > > >>> > > What I want to know is the relationship of dialog and >>> session when >>> > > they both exist in one communication activity. Take a >>> example, when >>> > > there are 2 person participating talks with voice, we say >>> there is a >>> > > dialog and a session. >>> > > >>> > > But when one caller invites another callee and gets five >>> 200 final >>> > > responses from 5 UA every of which has its own session >>> description. We >>> > > can say that there are 5 dialogs between caller and the >>> other 5 >>> > > callees, right? And then what is the exact number of >>> session in this >>> > > scenario? One session or five session? That is what I want >>> to know. >>> > > >>> > > Dialog is determined by dialogID (call-id, from/to tag) and >>> session id >>> > > is determined by session id given in the SDP message. My >>> answer is >>> > > there are 5 dialog and one session now, right? >>> > > >>> > >>> > - vijay >>> > -- >>> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>> > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>> > Email: vkg@{alcatel-lucent.com >>> ,bell-labs.com >>> ,acm.org } >>> > WWW: http://www.alcatel-lucent.com/bell-labs >>> > >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> -- BR >>> Donald _______________________________________________ >>> This is the SIP Forum discussion mailing list >>> TO UNSUBSCRIBE, or edit your delivery options, please visit >>> http://sipforum.org/mailman/listinfo/discussion >>> Post to the list at discussion@sipforum.org >>> >>> >>> >>> >>> Gaurav Katiyar >>> Induslogic india pvt. ltd >>> B-34/1 sector 59 NOIDA >>> Phone:9818381368 >>> >>> >>> ------------------------------------------------------------------------ >>> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try >>> it now. >>> >> >>> > >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> > > --===============1280639613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1280639613==-- From sip-bounces@ietf.org Wed Apr 30 07:22:03 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163B23A6B72; Wed, 30 Apr 2008 07:22:03 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649A328C38D; Wed, 30 Apr 2008 07:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXwLliuV6ysO; Wed, 30 Apr 2008 07:21:59 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id BDFC03A6B72; Wed, 30 Apr 2008 07:21:58 -0700 (PDT) Received: from epmmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K05007V66KJZ8@mailout2.samsung.com>; Wed, 30 Apr 2008 23:21:55 +0900 (KST) Received: from mahesha ([107.108.74.147]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0K05002IN6KGOS@mmp2.samsung.com>; Wed, 30 Apr 2008 23:21:55 +0900 (KST) Date: Wed, 30 Apr 2008 19:56:10 +0530 From: Mahesh Anjanappa To: Paul Kyzivat Message-id: <0b3e01c8aace$23f060c0$934a6c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <915213.97931.qm@web33504.mail.mud.yahoo.com> <481754BE.1060505@cisco.com> <0a4301c8aa73$ffb17500$934a6c6b@sisodomain.com> <48186E99.7080306@cisco.com> Cc: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org, gaurav katiyar Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1612907541==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1612907541== Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=response Content-transfer-encoding: 8BIT > Mahesh Anjanappa wrote: >> I'm surprised to see that a fundamental concept "SIP Session" does not >> have >> a clear definition documented anywhere. I was eagerly waiting for a IETF >> Guru >> to clarify this. I wish somebody writes a draft clarifying all the >> undocumented >> fundamental concepts in SIP. If i knew it all, i would have done it :-) > > IMO the reason there is no definition of such a "fundamental concept" is > that it isn't fundamental. While it might be interesting to discuss, it > doesn't affect anything. And in fact, when you start to dig into what this > "fundamental concept" means it starts to fall apart. Yes, it starts to fall apart,:-), which annoys me & is the reason why i dig further because i feel i'm missing something here. We use the word Session so often in discussions and IMHO it is dangerous if i cant put down a fullfilling definition for it. > >> My 2 cents on it. >> A Session is a Rendezvous Contract between 2 or more UA's for >> communnicating >> with some modality. SIP dialog is a context over which such a Contract is >> negotiated >> decided, and upheld. >> Normally the SDP Session Id should identify the Contract/Session. But not >> necessarily >> always. If its a multiparty the Conference ID would serve such a purpose. > > Is each modality a separate contract? Or is is a contract for a > *collection* of modalities? (E.g. voice + video) It is a contract for a *collection* of modalities. > >> I can get into a session with a non-INVITE dialog as well. Example: >> SUBSCRIBE to >> a specialized Event package. In this case some Identifier in the Event >> package probably will >> serve as the Session Id. > > Do you mean to imply that the event notifications are then the > communication modality? Yes, thats right (example:PIDF doc if Presence ) >> As you can see there can be more than 1 dialog related a Session. >> But there is no documentation saying what exactly threads all the dialogs >> to a Session except >> the mentioning of a ID in the SDP RFC to identify the session being >> described in a SDP. >> >> My understanding is that a Session Identifier can take the form of >> Conference ID or any >> other depending on the method used to setup the rendezvoud/session. >> >> Well, the above is my understanding of it, not based on any existing >> draft or RFC, so i welcome >> whatever corrections need be. > > Its a decent try. As I mentioned in a prior reply, IMO there is no real > need to define this. Frankly, i didnt understand why you say that there is no real need to define this. > > I'm not fully understanding what you are proposing (see questions above). > I expect that it may start to fall apart in the details of particular use > cases. Will you explain to me how your definition relates to the use case > with A/B/C/D that I gave? OK,let me see. A, C and D get into a Session/Contract to communicate using Video and Audio. The contract allows for either of the Media to be used hence C uses audio and D uses video. B facilitates the Contract by holding the three dialogs. The 3 dialogs are tied together by a Conference Id (i suppose) thus COnference Id representing the Session Identifier.B too is considered a party in the session though its role is different from that of A,C and D. > Paul > >> regards >> Mahesh >> >> ----- Original Message ----- From: "Paul Kyzivat" >> To: "gaurav katiyar" >> Cc: ; ; >> Sent: Tuesday, April 29, 2008 10:32 PM >> Subject: Re: [Sip] [SIPForum-discussion] What's the difference between >> session and dialog in SIP? >> >> >>> >>> >>> gaurav katiyar wrote: >>>> Sip "Session Initiation Protocol". It talks about media session, i mean >>>> how to initiate, modify and terminate a session and Dialog provides a >>>> sort of context (like caller, callee, location, routing etc.) to modify >>>> this session. So dialog is more related to route the sip message to >>>> right node and body (SDP) handles media session if present. Dialogs may >>>> have media sessions Or may not. >>>> >>>> Take an example of B2BUA. It is a type of statefull proxy having two >>>> dialog and one media session if doing media routing. >>> >>> Maybe. IMO these concepts aren't sufficiently defined. >>> >>> One view is that a session is whatever SDP describes. Thus its one >>> session regardless of how many media streams it contains. And in the >>> case of an SDP containing multicast media addresses, and possibly >>> advertised via SAP, there could be many participants in the same >>> session. >>> >>> But then in sip it takes a pair of SDPs to establish a call. Is that one >>> session, or two? And in your case above with the B2BUA, is it one >>> session, or two, or four? >>> >>> Another view is that a session in the context of sip is whatever is >>> established as a result of an INVITE. Then I guess the pair of SDPs >>> together describe one session, regardless of how many media streams. But >>> in that case the B2BUA example would be two sessions. >>> >>> Then consider a more complex case: >>> >>> audio >>> /-------- C >>> / >>> A ========== B >>> audio \ >>> video \-------- D >>> video >>> >>> Here B is a B2BUA and media relay as in your example, but one stream is >>> relayed to C and the other to D. >>> >>> In this case, how many sessions are there? A, C, and D each have one, >>> but are any of those the same? Or are there three altogether? >>> >>> When I see "session" used, I just assume it means something vague, and >>> read on to see what is actually meant. >>> >>> Paul >>> >>>> */Donald Lee /* wrote: >>>> >>>> old good questions in sip, also add another "transaction". >>>> >>>> >>>> On Fri, Apr 25, 2008 at 8:18 AM, 孙宗君 >>> > wrote: >>>> >>>> Hi, Vijay >>>> >>>> Thanks very much for your timely answers. >>>> >>>> From this specification, session is a combination of >>>> signaling >>>> plane >>>> and media plane messages and processes that enable two or more >>>> participants to communicate. I think session is a larger scope >>>> than >>>> dialog. In another word, one session can contain more than one >>>> dialog. >>>> Is what I understand right? >>>> >>>> Zongjun >>>> >>>> >>>> 2008/4/24, Vijay K. Gurbani >>> >: >>>> > There is some work progressing in the BMWG WG to create >>>> performance >>>> > metrics around SIP. One of the first tasks in such an >>>> endeavor >>>> > is to define the notion of dialogs and sessions. Please >>>> see >>>> > Section 3.1.1 of >>>> > >>>> >>>> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt >>>> > of the above draft for some insight. >>>> > >>>> > Ëï×Ú¾ý wrote: >>>> > >>>> > > Hi, Lincoln >>>> > > >>>> > > thanks for your instructions. >>>> > > >>>> > > I know that dialog can exist without session since >>>> SUBSCRIBE/REFER can >>>> > > create dialog and without any media between communication >>>> peers. >>>> > > >>>> > > What I want to know is the relationship of dialog and >>>> session when >>>> > > they both exist in one communication activity. Take a >>>> example, when >>>> > > there are 2 person participating talks with voice, we say >>>> there is a >>>> > > dialog and a session. >>>> > > >>>> > > But when one caller invites another callee and gets five >>>> 200 final >>>> > > responses from 5 UA every of which has its own session >>>> description. We >>>> > > can say that there are 5 dialogs between caller and the >>>> other 5 >>>> > > callees, right? And then what is the exact number of >>>> session in this >>>> > > scenario? One session or five session? That is what I want >>>> to know. >>>> > > >>>> > > Dialog is determined by dialogID (call-id, from/to tag) >>>> and >>>> session id >>>> > > is determined by session id given in the SDP message. My >>>> answer is >>>> > > there are 5 dialog and one session now, right? >>>> > > >>>> > >>>> > - vijay >>>> > -- >>>> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>>> > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>>> > Email: vkg@{alcatel-lucent.com >>>> ,bell-labs.com >>>> ,acm.org } >>>> > WWW: http://www.alcatel-lucent.com/bell-labs >>>> > >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> -- BR >>>> Donald _______________________________________________ >>>> This is the SIP Forum discussion mailing list >>>> TO UNSUBSCRIBE, or edit your delivery options, please visit >>>> http://sipforum.org/mailman/listinfo/discussion >>>> Post to the list at discussion@sipforum.org >>>> >>>> >>>> >>>> >>>> Gaurav Katiyar >>>> Induslogic india pvt. ltd >>>> B-34/1 sector 59 NOIDA >>>> Phone:9818381368 >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try >>>> it now. >>>> >>> > >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> 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 >>> >> --===============1612907541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1612907541==-- From sip-bounces@ietf.org Wed Apr 30 08:09:11 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA963A6EA5; Wed, 30 Apr 2008 08:09:11 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DA828C398 for ; Wed, 30 Apr 2008 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_23=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 4eOZhbDx4943 for ; Wed, 30 Apr 2008 08:09:05 -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 54A0F28C388 for ; Wed, 30 Apr 2008 08:09:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,728,1199682000"; d="scan'208";a="6810603" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2008 11:09:06 -0400 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 m3UF96J4003810; Wed, 30 Apr 2008 11:09:06 -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 m3UF96Uu027099; Wed, 30 Apr 2008 15:09:06 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); Wed, 30 Apr 2008 11:09:05 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 11:09:05 -0400 Message-ID: <48188BB1.2060707@cisco.com> Date: Wed, 30 Apr 2008 11:09:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Mahesh Anjanappa References: <915213.97931.qm@web33504.mail.mud.yahoo.com> <481754BE.1060505@cisco.com> <0a4301c8aa73$ffb17500$934a6c6b@sisodomain.com> <48186E99.7080306@cisco.com> <0b3e01c8aace$23f060c0$934a6c6b@sisodomain.com> In-Reply-To: <0b3e01c8aace$23f060c0$934a6c6b@sisodomain.com> X-OriginalArrivalTime: 30 Apr 2008 15:09:05.0657 (UTC) FILETIME=[21C77E90:01C8AAD4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11326; t=1209568146; x=1210432146; 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]=20[SIPForum-discussion]=20What's= 20the=20difference=20between=09session=0A=20and=20dialog=20i n=20SIP? |Sender:=20 |To:=20Mahesh=20Anjanappa=20; bh=2GOrAoRSfUotCCHyHpezbwrlg9qzY+xyz6mCpFsf1fI=; b=GARu3lmOqzrtWKDRf5UUomsDTteGBXMu2ddhWA3UfdhtOQLX+yy9snF1eZ QjeUPhTPc7lr8POPW6H/CYFZBTEobd/LkVWANuTsZBEwGDLwQTxZ++LXQK0O Sjp0RwAL6K; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sip@ietf.org, discussion@sipforum.org, gaurav katiyar Subject: Re: [Sip] [SIPForum-discussion] What's the difference between session and dialog in SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0511214826==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0511214826== Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Mahesh Anjanappa wrote: >> I'm not fully understanding what you are proposing (see questions >> above). I expect that it may start to fall apart in the details of >> particular use cases. Will you explain to me how your definition >> relates to the use case with A/B/C/D that I gave? > > OK,let me see. > A, C and D get into a Session/Contract to communicate using Video and > Audio. I guess you misunderstand what I was describing. The SDP negotiated between A and B contains both audio and video. The SDP negotiated between B and C contains only audio. (B didn't offer the video to C.) The SDP negotiated between B and D contains only video. (B didn't offer the video to D.) The purpose of B is to consolidate an audio-only device and a video-only device into what seems, to A, like one audio/video device. They don't all have the same contract. So by your definition I don't think they can all have one session. In some conceptual sense you may think of this as one session. But its hard to find any tangible item that they all have that refers to a single session. In the end, from the point of view of B it may indeed be one session. But A, C, and D can't perceive that. > The contract allows for either of the Media to be used hence C uses audio > and D uses video. B facilitates the Contract by holding the three dialogs. > The 3 dialogs are tied together by a Conference Id (i suppose) > thus COnference Id representing the Session Identifier.B too is > considered a party in the > session though its role is different from that of A,C and D. If this were done with a conference mixer, and hence there was a conference id, then I guess you could say that the conference id was an identifier for the "session". But if B was purpose-built for this particular functionality, and there is no conference id, then what? And in a simple call between A and C there would be no conference id, so something else must serve as the "session" identifier. But in that case, it would seem that these aren't the *same* notion of session. You asked why I didn't think it was important to define session. I will admit that it seems odd to have a Session Initiation Protocol without a clear idea of what this "session" is that it is initiating. So it indeed would be *nice* to have a definition that covers all the cases. But not having one doesn't seem to be preventing anyone from doing anything, does it? From a practical perspective I think the thing that is being initiated by SIP is the contract established by a matching offer/answer. That is fairly straightforward when the UAC and UAS are the offerer and answerer, or visa versa. It gets messy when other UAs are involved in the construction of the offer and the answer. And in those cases it gets really hard to figure out what the session is, because not all the parties will agree. Paul >> Paul >> >>> regards >>> Mahesh >>> >>> ----- Original Message ----- From: "Paul Kyzivat" >>> To: "gaurav katiyar" >>> Cc: ; ; >>> Sent: Tuesday, April 29, 2008 10:32 PM >>> Subject: Re: [Sip] [SIPForum-discussion] What's the difference >>> between session and dialog in SIP? >>> >>> >>>> >>>> >>>> gaurav katiyar wrote: >>>>> Sip "Session Initiation Protocol". It talks about media session, i >>>>> mean >>>>> how to initiate, modify and terminate a session and Dialog provides a >>>>> sort of context (like caller, callee, location, routing etc.) to >>>>> modify >>>>> this session. So dialog is more related to route the sip message to >>>>> right node and body (SDP) handles media session if present. Dialogs >>>>> may >>>>> have media sessions Or may not. >>>>> >>>>> Take an example of B2BUA. It is a type of statefull proxy having two >>>>> dialog and one media session if doing media routing. >>>> >>>> Maybe. IMO these concepts aren't sufficiently defined. >>>> >>>> One view is that a session is whatever SDP describes. Thus its one >>>> session regardless of how many media streams it contains. And in the >>>> case of an SDP containing multicast media addresses, and possibly >>>> advertised via SAP, there could be many participants in the same >>>> session. >>>> >>>> But then in sip it takes a pair of SDPs to establish a call. Is that >>>> one >>>> session, or two? And in your case above with the B2BUA, is it one >>>> session, or two, or four? >>>> >>>> Another view is that a session in the context of sip is whatever is >>>> established as a result of an INVITE. Then I guess the pair of SDPs >>>> together describe one session, regardless of how many media streams. >>>> But >>>> in that case the B2BUA example would be two sessions. >>>> >>>> Then consider a more complex case: >>>> >>>> audio >>>> /-------- C >>>> / >>>> A ========== B >>>> audio \ >>>> video \-------- D >>>> video >>>> >>>> Here B is a B2BUA and media relay as in your example, but one stream is >>>> relayed to C and the other to D. >>>> >>>> In this case, how many sessions are there? A, C, and D each have one, >>>> but are any of those the same? Or are there three altogether? >>>> >>>> When I see "session" used, I just assume it means something vague, and >>>> read on to see what is actually meant. >>>> >>>> Paul >>>> >>>>> */Donald Lee /* wrote: >>>>> >>>>> old good questions in sip, also add another "transaction". >>>>> >>>>> >>>>> On Fri, Apr 25, 2008 at 8:18 AM, 孙宗君 >>>> > wrote: >>>>> >>>>> Hi, Vijay >>>>> >>>>> Thanks very much for your timely answers. >>>>> >>>>> From this specification, session is a combination of >>>>> signaling >>>>> plane >>>>> and media plane messages and processes that enable two or more >>>>> participants to communicate. I think session is a larger >>>>> scope than >>>>> dialog. In another word, one session can contain more than one >>>>> dialog. >>>>> Is what I understand right? >>>>> >>>>> Zongjun >>>>> >>>>> >>>>> 2008/4/24, Vijay K. Gurbani >>>> >: >>>>> > There is some work progressing in the BMWG WG to create >>>>> performance >>>>> > metrics around SIP. One of the first tasks in such an >>>>> endeavor >>>>> > is to define the notion of dialogs and sessions. >>>>> Please see >>>>> > Section 3.1.1 of >>>>> > >>>>> >>>>> https://svn.resiprocate.org/rep/ietf-drafts/gurbani/bmwg-sip-bench-term/draft-ietf-bmwg-sip-term-00.txt >>>>> >>>>> > of the above draft for some insight. >>>>> > >>>>> > Ëï×Ú¾ý wrote: >>>>> > >>>>> > > Hi, Lincoln >>>>> > > >>>>> > > thanks for your instructions. >>>>> > > >>>>> > > I know that dialog can exist without session since >>>>> SUBSCRIBE/REFER can >>>>> > > create dialog and without any media between communication >>>>> peers. >>>>> > > >>>>> > > What I want to know is the relationship of dialog and >>>>> session when >>>>> > > they both exist in one communication activity. Take a >>>>> example, when >>>>> > > there are 2 person participating talks with voice, we say >>>>> there is a >>>>> > > dialog and a session. >>>>> > > >>>>> > > But when one caller invites another callee and gets five >>>>> 200 final >>>>> > > responses from 5 UA every of which has its own session >>>>> description. We >>>>> > > can say that there are 5 dialogs between caller and >>>>> the other 5 >>>>> > > callees, right? And then what is the exact number of >>>>> session in this >>>>> > > scenario? One session or five session? That is what I >>>>> want >>>>> to know. >>>>> > > >>>>> > > Dialog is determined by dialogID (call-id, from/to >>>>> tag) and >>>>> session id >>>>> > > is determined by session id given in the SDP message. My >>>>> answer is >>>>> > > there are 5 dialog and one session now, right? >>>>> > > >>>>> > >>>>> > - vijay >>>>> > -- >>>>> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>>>> > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>>>> > Email: vkg@{alcatel-lucent.com >>>>> ,bell-labs.com >>>>> ,acm.org } >>>>> > WWW: http://www.alcatel-lucent.com/bell-labs >>>>> > >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- BR >>>>> Donald _______________________________________________ >>>>> This is the SIP Forum discussion mailing list >>>>> TO UNSUBSCRIBE, or edit your delivery options, please visit >>>>> http://sipforum.org/mailman/listinfo/discussion >>>>> Post to the list at discussion@sipforum.org >>>>> >>>>> >>>>> >>>>> >>>>> Gaurav Katiyar >>>>> Induslogic india pvt. ltd >>>>> B-34/1 sector 59 NOIDA >>>>> Phone:9818381368 >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try >>>>> it now. >>>>> >>>> >>>>> > >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> > --===============0511214826== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0511214826==-- From sip-bounces@ietf.org Wed Apr 30 23:47:19 2008 Return-Path: X-Original-To: sip-archive@optimus.ietf.org Delivered-To: ietfarch-sip-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF5D3A6BED; Wed, 30 Apr 2008 23:47:19 -0700 (PDT) X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0063A6CEE for ; Wed, 30 Apr 2008 23:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.902 X-Spam-Level: X-Spam-Status: No, score=0.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, 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 morKKFdGVXql for ; Wed, 30 Apr 2008 23:47:10 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id B5CBA3A6CBC for ; Wed, 30 Apr 2008 23:47:09 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so433200fga.41 for ; Wed, 30 Apr 2008 23:47: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:to:subject:mime-version:content-type; bh=gps+KUplk/hx5qzaDbYuwjVfo2GNTXaLGhDuiuk9Lzs=; b=lfbG5QQKPaNsXb1wa3CU8Frh3UCPmKKsOB+GDnfeglKsgkhSFR6kFniMqaQx7mjZqE1snlT0S/HlIyy/4NRNw7NIrXPQL5UlbFz4zUI9A0acRVnfAV2gxzaJ6y1sEI416NylH8ZNSbeJhEo+AGNcYo28UU0ZttuNtA1ebiA0lFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=bEkEs1CWH8vb1/gWUieW4d82LuLAjNCCb/3iAGKevDkLatQrGogPNk/7z21k6X2QePs3X6vZWrwBLV14PfaqsoHHOcrliq28b/LvIVqRlZx18/SjDBqYcJoCVwPq49N+mJ6xWRdxrInxaWN6NVW7OAxpOw2Hl1HzLkYcqfVg1vM= Received: by 10.82.152.9 with SMTP id z9mr213156bud.79.1209624431221; Wed, 30 Apr 2008 23:47:11 -0700 (PDT) Received: by 10.82.149.12 with HTTP; Wed, 30 Apr 2008 23:47:10 -0700 (PDT) Message-ID: <2374a5fb0804302347r21b0627cj3160a3605d73cf0d@mail.gmail.com> Date: Thu, 1 May 2008 14:47:10 +0800 From: "=?GB2312?B?y+/TwLni?=" To: sip@ietf.org, discussion@sipforum.org, bmwg@ietf.org MIME-Version: 1.0 Subject: [Sip] application/broadsoft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1746135860==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1746135860== Content-Type: multipart/alternative; boundary="----=_Part_3711_1244640.1209624431209" ------=_Part_3711_1244640.1209624431209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All anyone can tell the format of "application/broadsoft" Thanks Samman 2008-5-1 ------=_Part_3711_1244640.1209624431209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All
 
     anyone can tell the format of "application/broadsoft"
 
Thanks
 
Samman
 
2008-5-1
------=_Part_3711_1244640.1209624431209-- --===============1746135860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1746135860==--