From mailnull@www1.ietf.org Thu Jan 2 14:17:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11786 for ; Thu, 2 Jan 2003 14:17:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02JPq914605 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 14:25:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JPqJ14602 for ; Thu, 2 Jan 2003 14:25:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11777 for ; Thu, 2 Jan 2003 14:16:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JOUJ14563; Thu, 2 Jan 2003 14:24:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JNDJ14527 for ; Thu, 2 Jan 2003 14:23:13 -0500 Received: from md2.ksolutions.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11742 for ; Thu, 2 Jan 2003 14:14:17 -0500 (EST) Received: from computer ([62.98.178.35]) by md2.ksolutions.it (Mirapoint) with ESMTP id BGF28666 (AUTH enzo.abate@katamail.com); Thu, 2 Jan 2003 20:17:22 +0100 (CET) From: "Enzo" To: Date: Thu, 2 Jan 2003 20:16:19 +0100 Message-ID: <000a01c2b293$6fde2000$23b2623e@computer> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C2B29B.D1A28800" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [Sipping] conference and participant's list Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C2B29B.D1A28800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In a centralized conference model, I have the problem of discovering participant's identities. I have found 2 solutions: 1. I can use the SIP extension (CONF method) described in "draft-miladinovic-sip-multiparty-ext-01"; 2. The conference server can use a 200 OK in response to a REGISTER request, to carry the participant's list, and then the client can subscribe a "conference" event as described in "draft-ietf-sipping-conference-package-00", to obtain notifications of list changes. They seem equivalent methods; what of these ways "SHOULD" I go? Thanks in advance. Enzo. ------=_NextPart_000_000B_01C2B29B.D1A28800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Messaggio

In a=20 centralized conference model, I have the problem of discovering=20 participant's identities. I have = found 2=20 solutions:

  1. I can=20 use the SIP extension (CONF method) described in=20 "draft-miladinovic-sip-multiparty-ext-01";
  2. The=20 conference server can use a 200 OK in response to a REGISTER request, = to carry=20 the participant's = list, and then=20 the client can subscribe a "conference" event as described in=20 "draft-ietf-sipping-conference-package-00", to = obtain notifications=20 of list changes.

They seem=20 equivalent methods; what of these ways "SHOULD" I go?

 

Thanks in=20 advance.

Enzo.

------=_NextPart_000_000B_01C2B29B.D1A28800-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 14:37:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12418 for ; Thu, 2 Jan 2003 14:37:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Jjvo16259 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 14:45:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JjvJ16256 for ; Thu, 2 Jan 2003 14:45:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12411 for ; Thu, 2 Jan 2003 14:37:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JjAJ16221; Thu, 2 Jan 2003 14:45:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JiYJ16170 for ; Thu, 2 Jan 2003 14:44:34 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12369 for ; Thu, 2 Jan 2003 14:35:38 -0500 (EST) Received: from diamond.cs.columbia.edu (diamond.cs.columbia.edu [128.59.16.9]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id h02Jcn9N027667 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 2 Jan 2003 14:38:50 -0500 (EST) Received: from diamond.cs.columbia.edu (localhost [127.0.0.1]) by diamond.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id h02JcmcR004961; Thu, 2 Jan 2003 14:38:48 -0500 (EST) Received: (from petkos@localhost) by diamond.cs.columbia.edu (8.12.6/8.12.6/Submit) id h02Jcmlf004958; Thu, 2 Jan 2003 14:38:48 -0500 (EST) From: "Petri K. Koskelainen" Message-Id: <200301021938.h02Jcmlf004958@diamond.cs.columbia.edu> Subject: Re: [Sipping] conference and participant's list To: enzo.abate@katamail.com (Enzo) Date: Thu, 2 Jan 2003 14:38:48 -0500 (EST) Cc: sipping@ietf.org In-Reply-To: <000a01c2b293$6fde2000$23b2623e@computer> from "Enzo" at Jan 02, 2003 08:16:19 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Enzo, > In a centralized conference model, I have the problem of discovering > participant's identities. I have found 2 solutions: > You can subscribe to conference state and get notifications about the participants. See http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-00.txt > 1. I can use the SIP extension (CONF method) described in > "draft-miladinovic-sip-multiparty-ext-01"; This idea will not be used. > 2. The conference server can use a 200 OK in response to a REGISTER > request, to carry the participant's list, You don't need this (makes no sense anyway). > and then the client can > subscribe a "conference" event as described in > "draft-ietf-sipping-conference-package-00", to obtain notifications of > list changes. You can do this without using REGISTER. First notify includes the current participant list. Why this is not enough for your purposes ? > They seem equivalent methods; what of these ways "SHOULD" I go? Forget option 1. Using Subscribe/Notify for this is a SHOULD. Conferencing Framework document should also clarify these issues. Br, Petri _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 14:50:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12625 for ; Thu, 2 Jan 2003 14:50:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Jx6s16899 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 14:59:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Jx6J16892 for ; Thu, 2 Jan 2003 14:59:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12611 for ; Thu, 2 Jan 2003 14:50:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Jw1J16811; Thu, 2 Jan 2003 14:58:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JtWJ16696 for ; Thu, 2 Jan 2003 14:55:32 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12545 for ; Thu, 2 Jan 2003 14:46:35 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22578 for ; Thu, 2 Jan 2003 14:49:44 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14349 for ; Thu, 2 Jan 2003 14:49:45 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Jan 2003 14:49:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5C96@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sipping@ietf.org'" Date: Thu, 2 Jan 2003 14:49:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Gateway BCP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I'm planning on writing a BCP on gateways. I'm going to start with enterprise/home style gateways rather than "tandem" PSTN gateways. If you have experience, as we do, where every gateway does things different enough that your sipphone/proxy has all kinds of special purpose code in it to cope, please let me know where the differences arise, and I'll try to get something in there to make it one way. I'll stick to sip stuff, leaving configuration/provisioning out of it to start, although I'm tempted to put stuff like DHCP support in there. One of the big areas we have problems with is getting URIs correct so that CallerId works both ways. I'd like to start a thread on that, which I will do in the next email. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 14:51:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12670 for ; Thu, 2 Jan 2003 14:51:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02K0Fw16983 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 15:00:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02K0FJ16980 for ; Thu, 2 Jan 2003 15:00:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12663 for ; Thu, 2 Jan 2003 14:51:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Jx4J16853; Thu, 2 Jan 2003 14:59:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JuCJ16713 for ; Thu, 2 Jan 2003 14:56:12 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12548 for ; Thu, 2 Jan 2003 14:47:15 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22592 for ; Thu, 2 Jan 2003 14:50:24 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14380 for ; Thu, 2 Jan 2003 14:50:25 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Jan 2003 14:50:25 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5C97@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sipping@ietf.org'" Date: Thu, 2 Jan 2003 14:50:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] URIs for Gateways Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , On an enterprise type gateway, it's a problem to construct headers to get the correct thing to happen, especially with CallerId and multiple "lines". Enterprise gateways almost always have multiple ports/lines connected to them. These lines may be connected to the PSTN or they may be connected to a PBX. Some gateways are simple analog loops, others are digital telephone loops, ISDN BRI, CAS or ISDN PRI trunks. There are two ways these gateways are deployed: Pool - where all the lines are in a big pool, and calls come in to the first available line in the pool, and go out on the next available line in the pool. It's pretty close to impossible to have correct CallerId with pooled lines Mapped - a user is mapped to a particular line/port. All calls to that line/port go to that user, all calls from that user go to that line/port When you have a shared trunk like a CAS or PRI, effectively you have a hybrid. Each of the "DS0s" are pooled, but the gateway can obtain/insert phone number information to determine/assert the called/calling party. Many, but not all, gateways implement mapped; you can provision a URI with a line/port. When a call arrives at the line, a SIP call is made to the specified URI. When a sip call comes to the gateway, the FROM line is matched with the provisioned URIs to pick the line/port to place the call. For example, I might have a mapping of "brian.rosen@sip.marconi.com" to port3 on gateway2.marconi.com. A call from 4125551212 to my phone number, 7247426826 might result in an INVITE from the gateway like: INVITE brian.rosen@sip.marconi.com From: port3@gateway2.marconi.com To: brian.rosen@sip.marconi.com To place a call on the gateway, some gateways use the user part of a URI as a phone number. So: INVITE 4125551212@gateway2.marconi.com From: brian.rosen@sip.marconi.com To: 4125551212@gateway2.marconi.com Not all gateways work like this. Some use the display name for the number, and the username as the port: INVITE port3@gateway2.marconi.com From: brian.rosen@sip.marconi.com To: "4125551212" Now, we add the complication of CallerId. For gateways that maintain mappings, some gateways send called party number for terminating calls in the display name of the From: INVITE brian.rosen@sip.marconi.com From "4125551212" I have not seen a gateway that actually accepts a calling party number in the display name of a From on an originating call, but it might be useful if more than one number mapped to the same user. Many of the PRI/CAS gateways don't have full tables for the hundreds of numbers per trunk that they can handle. For these gateways, you tell them what number to use for the outgoing CallerId, and they report what called number they got on an incoming call. If there is no mapping table, then you need some intermediary to translate the called party to a sip URI. So, the gateway might send INVITE 7247426826@translate.marconi.com From: "4125551212" To: "7247426826" <7247526826@translate.marconi.com> The translator would have to redirect the call to the correct party INVITE brian.rosen@sip.marconi.com From: "4125551212" To: "7247426826" <7247526826@translate.marconi.com> Similarly, the outgoing call would start as: INVITE 4125551212@translate.marconi.com From: brian.rosen@sip.marconi.com To: "4125551212@translate.marconi.com" and the translator would send INVITE port3@gateway2.marconi.com From: "7247426826" To: "4125551212@translate.marconi.com" This is a no-no if the translator is a proxy. It would have to be a B2BUA. So, one question is whether we should indeed force the UAS to know its phone number, so it can construct the From: correctly. If a UA has multiple "lines", then it actually needs a way to tell the gateway which "line" it wants to use for an outgoing call. Most systems don't do this, so it's a big deal to make this assumption. Translators are pretty useful. Many systems have them, because you don't want UAs to know which gateway they should use. I would prefer to make the rules such that the username was the port name. That allows the port name to be registered, and checked. That implies the numbers go in the display name. We might actually want to specify how tel URIs are used instead of sip URIs. I'm not sure I know what the right thing to do is, because some gateways need that port number. I'd like to get a new header for the calling party number on an outbound call. That way, the translator can be a proxy and add the header. I'd recommend that gateways allow the number to be in the From. Comments? Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 15:11:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13122 for ; Thu, 2 Jan 2003 15:11:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02KJnw18435 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 15:19:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KJnJ18432 for ; Thu, 2 Jan 2003 15:19:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13113 for ; Thu, 2 Jan 2003 15:10:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KIZJ18357; Thu, 2 Jan 2003 15:18:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KE3J18174 for ; Thu, 2 Jan 2003 15:14:03 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12982 for ; Thu, 2 Jan 2003 15:05:07 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h02K8IFk013111 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Jan 2003 15:08:18 -0500 (EST) Message-ID: <3E149C8F.8020000@cs.columbia.edu> Date: Thu, 02 Jan 2003 15:09:51 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5C97@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5C97@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I'd like to get a new header for the calling party number on > an outbound call. That way, the translator can be a proxy and > add the header. I'd recommend that gateways allow the number > to be in the From. Generalized, you want something like the Request-URI that can be modified or inserted. How about the NAI stuff? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 15:38:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13595 for ; Thu, 2 Jan 2003 15:38:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02KlCJ20183 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 15:47:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KlCJ20180 for ; Thu, 2 Jan 2003 15:47:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13588 for ; Thu, 2 Jan 2003 15:38:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KkFJ20111; Thu, 2 Jan 2003 15:46:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Kk1J20088 for ; Thu, 2 Jan 2003 15:46:01 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13570 for ; Thu, 2 Jan 2003 15:37:02 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h02KeHYH024631; Thu, 2 Jan 2003 15:40:17 -0500 (EST) Message-ID: <3E14A3AD.2070005@dynamicsoft.com> Date: Thu, 02 Jan 2003 15:40:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5C97@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > On an enterprise type gateway, it's a problem to construct headers to > get the correct thing to happen, especially with CallerId and multiple > "lines". Let me just make sure I have your network diagram right. You are worried about a SIP-based enterprise that has a gateway for communicating to outside PSTN users, right? > To place a call on the gateway, some gateways use the user part of a URI > as a phone number. So: > INVITE 4125551212@gateway2.marconi.com > From: brian.rosen@sip.marconi.com > To: 4125551212@gateway2.marconi.com > > Not all gateways work like this. Some use the display name for the number, > and the username as the port: > INVITE port3@gateway2.marconi.com > From: brian.rosen@sip.marconi.com > To: "4125551212" This is a big no-no, since the To field cannot be used as an identifier for the desired target. It only specifies the original intended target. Had their been proxying inbetween, the wrong number would be dialed. > > Now, we add the complication of CallerId. > For gateways that maintain mappings, some gateways send called party number > for terminating calls in the display name of the From: > INVITE brian.rosen@sip.marconi.com >>From "4125551212" To: "7247426826" > > I have not seen a gateway that actually accepts a calling party > number in the display name of a From on an originating call, but > it might be useful if more than one number mapped to the same > user. > > Many of the PRI/CAS gateways don't have full tables for the hundreds of > numbers per trunk that they can handle. For these gateways, you tell > them what number to use for the outgoing CallerId, and they report > what called number they got on an incoming call. > If there is no mapping table, then you need some intermediary > to translate the called party to a sip URI. So, the gateway might send > INVITE 7247426826@translate.marconi.com > From: "4125551212" > To: "7247426826" <7247526826@translate.marconi.com> > > The translator would have to redirect the call to the correct party > INVITE brian.rosen@sip.marconi.com > From: "4125551212" > To: "7247426826" <7247526826@translate.marconi.com> > > Similarly, the outgoing call would start as: > INVITE 4125551212@translate.marconi.com > From: brian.rosen@sip.marconi.com > To: "4125551212@translate.marconi.com" > > and the translator would send > INVITE port3@gateway2.marconi.com > From: "7247426826" > To: "4125551212@translate.marconi.com" > > This is a no-no if the translator is a proxy. It would have to be > a B2BUA. I don't understand why this is not just network asserted ID. > So, one question is whether we should indeed force the > UAS to know its phone number, so it can construct the From: > correctly. If a UA has multiple "lines", then it actually needs > a way to tell the gateway which "line" it wants to use for an > outgoing call. Most systems don't do this, so it's a big deal > to make this assumption. There is another issue you have been touching on. It relates back to the app components ID that I wrote some time ago (http://www.jdrosen.net/papers/draft-rosenberg-sip-app-components-01.txt). Really, a gateway is an application-independent component, just like a conference server or a voicexml server. All of them have the same general problem of how you invoke services on them. For a vxml server, its how to pass the vxml script. For a conference serevr, its how to identify the conference to join. For a gateway, its how to identify the user to call, along with other invocation parameters, such as what port to join. What I think you are talking about is that a gateway has several parameters needed for "service invocation" on it, and these need to somehow been standardized. I still believe we are in need of a framework for service invocation in sip, presenting a generic way to name services, discover capabilities, pass parameters, register new services, and so on. That work was discussed in sipping but never took off.... > I would prefer to make the rules such that the username was > the port name. That allows the port name to be registered, and checked. > That implies the numbers go in the display name. As I point out above, you cannot use the To field display name. > We might actually > want to specify how tel URIs are used instead of sip URIs. > I'm not sure I know what the right thing to do is, because some > gateways need that port number. > > I'd like to get a new header for the calling party number on > an outbound call. That way, the translator can be a proxy and > add the header. I'd recommend that gateways allow the number > to be in the From. As I asked above, why is this bit not the network asserted ID? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 15:47:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13743 for ; Thu, 2 Jan 2003 15:47:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Ktut20669 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 15:55:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KttJ20666 for ; Thu, 2 Jan 2003 15:55:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13735 for ; Thu, 2 Jan 2003 15:46:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Kt6J20633; Thu, 2 Jan 2003 15:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KsXJ20562 for ; Thu, 2 Jan 2003 15:54:33 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13723 for ; Thu, 2 Jan 2003 15:45:35 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24687; Thu, 2 Jan 2003 15:48:45 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21240; Thu, 2 Jan 2003 15:48:46 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Jan 2003 15:48:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5C9D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Thu, 2 Jan 2003 15:48:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Yeah, I actually thought of just allowing a display name in the Request URI and using that, but it seems so foolish to make a change, and have that change not be exactly what we needed. We could use NAI. I suppose we could use a P-Asserted-Identity with a tel URI: P-Asserted-Identity tel:+17247426826 What do we do when the "real" NAI happens? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 02, 2003 3:10 PM > To: Rosen, Brian > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] URIs for Gateways > > > > I'd like to get a new header for the calling party number on > > an outbound call. That way, the translator can be a proxy and > > add the header. I'd recommend that gateways allow the number > > to be in the From. > > Generalized, you want something like the Request-URI that can be > modified or inserted. How about the NAI stuff? > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 16:00:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14177 for ; Thu, 2 Jan 2003 16:00:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02L98H22266 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 16:09:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L98J22263 for ; Thu, 2 Jan 2003 16:09:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14148 for ; Thu, 2 Jan 2003 16:00:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L8AJ22168; Thu, 2 Jan 2003 16:08:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L7vJ22085 for ; Thu, 2 Jan 2003 16:07:57 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14091 for ; Thu, 2 Jan 2003 15:58:58 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25094; Thu, 2 Jan 2003 16:02:08 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22544; Thu, 2 Jan 2003 16:02:09 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Jan 2003 16:02:09 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5C9E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Thu, 2 Jan 2003 16:02:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Yes, it's a SIP based enterprise communication system with a gateway to a PSTN or PBX. I'm not really happy with the display name trick, but there are lots and lots of gateways that do this. It works because, as we know, To: and From: are never modified. It's up to normal SIP routing to get the INVITE to the right gateway. When it gets there, the display name on the To: should be intact. However, overloading the display name with the number to dial is not a great idea, even if a lot of stuff in the field does it. In a prior message, I did agree that P-Asserted-Identity with a tel URI could be used for a proxy asserting the translation, but not the "real" NAI stuff (Jon's signed headers). Do you want a BCP to say that P-Asserted-Identity is what translators use to get the phone number in the message? The "P-" is a problem. P-Asserted-Identity should go away once the signed header idea is fully baked, but this problem stays for a very long time. I guess I think putting a gateway in the category of a service component and designing a new framework for service invocation on it is a bit heavy handed given the problem, but I agree that a brand new thing can be made to solve any problem. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, January 02, 2003 3:40 PM > To: Rosen, Brian > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] URIs for Gateways > > > > > Rosen, Brian wrote: > > On an enterprise type gateway, it's a problem to construct > headers to > > get the correct thing to happen, especially with CallerId > and multiple > > "lines". > > Let me just make sure I have your network diagram right. You > are worried > about a SIP-based enterprise that has a gateway for communicating to > outside PSTN users, right? > > > To place a call on the gateway, some gateways use the user > part of a URI > > as a phone number. So: > > INVITE 4125551212@gateway2.marconi.com > > From: brian.rosen@sip.marconi.com > > To: 4125551212@gateway2.marconi.com > > > > Not all gateways work like this. Some use the display name > for the number, > > and the username as the port: > > INVITE port3@gateway2.marconi.com > > From: brian.rosen@sip.marconi.com > > To: "4125551212" > > This is a big no-no, since the To field cannot be used as an > identifier > for the desired target. It only specifies the original > intended target. > Had their been proxying inbetween, the wrong number would be dialed. > > > > > Now, we add the complication of CallerId. > > For gateways that maintain mappings, some gateways send > called party number > > for terminating calls in the display name of the From: > > INVITE brian.rosen@sip.marconi.com > >>From "4125551212" > To: "7247426826" > > > > I have not seen a gateway that actually accepts a calling party > > number in the display name of a From on an originating call, but > > it might be useful if more than one number mapped to the same > > user. > > > > Many of the PRI/CAS gateways don't have full tables for the > hundreds of > > numbers per trunk that they can handle. For these > gateways, you tell > > them what number to use for the outgoing CallerId, and they report > > what called number they got on an incoming call. > > If there is no mapping table, then you need some intermediary > > to translate the called party to a sip URI. So, the > gateway might send > > INVITE 7247426826@translate.marconi.com > > From: "4125551212" > > To: "7247426826" <7247526826@translate.marconi.com> > > > > The translator would have to redirect the call to the correct party > > INVITE brian.rosen@sip.marconi.com > > From: "4125551212" > > To: "7247426826" <7247526826@translate.marconi.com> > > > > Similarly, the outgoing call would start as: > > INVITE 4125551212@translate.marconi.com > > From: brian.rosen@sip.marconi.com > > To: "4125551212@translate.marconi.com" > > > > and the translator would send > > INVITE port3@gateway2.marconi.com > > From: "7247426826" > > To: "4125551212@translate.marconi.com" > > > > This is a no-no if the translator is a proxy. It would have to be > > a B2BUA. > > I don't understand why this is not just network asserted ID. > > > So, one question is whether we should indeed force the > > UAS to know its phone number, so it can construct the From: > > correctly. If a UA has multiple "lines", then it actually needs > > a way to tell the gateway which "line" it wants to use for an > > outgoing call. Most systems don't do this, so it's a big deal > > to make this assumption. > > There is another issue you have been touching on. It relates > back to the > app components ID that I wrote some time ago > (http://www.jdrosen.net/papers/draft-rosenberg-sip-app-compone > nts-01.txt). > Really, a gateway is an application-independent component, > just like a > conference server or a voicexml server. All of them have the same > general problem of how you invoke services on them. For a > vxml server, > its how to pass the vxml script. For a conference serevr, its how to > identify the conference to join. For a gateway, its how to > identify the > user to call, along with other invocation parameters, such as > what port > to join. > > What I think you are talking about is that a gateway has several > parameters needed for "service invocation" on it, and these need to > somehow been standardized. I still believe we are in need of > a framework > for service invocation in sip, presenting a generic way to name > services, discover capabilities, pass parameters, register > new services, > and so on. That work was discussed in sipping but never took off.... > > > I would prefer to make the rules such that the username was > > the port name. That allows the port name to be registered, > and checked. > > That implies the numbers go in the display name. > > As I point out above, you cannot use the To field display name. > > > We might actually > > want to specify how tel URIs are used instead of sip URIs. > > I'm not sure I know what the right thing to do is, because some > > gateways need that port number. > > > > I'd like to get a new header for the calling party number on > > an outbound call. That way, the translator can be a proxy and > > add the header. I'd recommend that gateways allow the number > > to be in the From. > > As I asked above, why is this bit not the network asserted ID? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 16:32:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14811 for ; Thu, 2 Jan 2003 16:32:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02LfNh24320 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 16:41:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LfNJ24317 for ; Thu, 2 Jan 2003 16:41:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14787 for ; Thu, 2 Jan 2003 16:32:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LebJ24247; Thu, 2 Jan 2003 16:40:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LdTJ24166 for ; Thu, 2 Jan 2003 16:39:29 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14731 for ; Thu, 2 Jan 2003 16:30:31 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h02LYFRY011217; Thu, 2 Jan 2003 16:34:15 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX27516; Thu, 2 Jan 2003 16:38:37 -0500 (EST) Message-ID: <3E14B02F.9010307@cisco.com> Date: Thu, 02 Jan 2003 16:33:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5C9E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > > I'm not really happy with the display name trick, but there are > lots and lots of gateways that do this. It works because, as we > know, To: and From: are never modified. It's up to normal > SIP routing to get the INVITE to the right gateway. When it gets there, > the display name on the To: should be intact. You miss the point. You may have called sip:alice. That call is then proxied to a pstn number "1234567890" sip:port@gateway. The proxy can't change the To address to put the phone number in. It can't even solve the problem with a redirect, because your UAC will probably just change the request id and reissue the invite with the old To value. > > However, overloading the display name with the number to dial is > not a great idea, even if a lot of stuff in the field does it. > > In a prior message, I did agree that P-Asserted-Identity with > a tel URI could be used for a proxy asserting the translation, > but not the "real" NAI stuff (Jon's signed headers). Do you > want a BCP to say that P-Asserted-Identity is what translators > use to get the phone number in the message? What you are suggesting seems backward. The P-Asserted-Identity is only useful for the calling number, not the called number. Assuming the gateway can trust the callerid info it gets from the PSTN, it should be inserting a P-Asserted-Identity header with that value for inbound calls. And it ought to be using it to generate callerid on outbound calls. The kind of translator you describe seems useless for this. I think the best choice right now for outbound calls is a tel: uri. You can pack all sorts of info into it. This can also be represented as a sip uri with user=phone. If you want to use a translator, start by generating a tel: uri, then route it to the translator, which can turn it into a sip uri with user=phone, using the domain name to select the actual gateway. It can also fill in extra parameters (defined in the tel: uri) in the user part of the sip uri to help the gateway do the right thing. > The "P-" is a > problem. P-Asserted-Identity should go away once the > signed header idea is fully baked, but this problem stays for > a very long time. I don't think the signed header is a replacement for the P-Asserted-Identity. Which to use depends on whether you have trusted servers in the network that are responsible for some aspects of identity. As long as you are interoperating with the PSTN this will probably remain as a requirement. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 18:33:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16957 for ; Thu, 2 Jan 2003 18:33:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Ng4E32451 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 18:42:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Ng4J32448 for ; Thu, 2 Jan 2003 18:42:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16932 for ; Thu, 2 Jan 2003 18:33:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NfQJ32401; Thu, 2 Jan 2003 18:41:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NeWJ32337 for ; Thu, 2 Jan 2003 18:40:32 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16899; Thu, 2 Jan 2003 18:31:32 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H84008JI1HU5L@firewall.wcom.com>; Thu, 02 Jan 2003 23:34:43 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H8400F011HURV@pmismtp02.wcomnet.com>; Thu, 02 Jan 2003 23:34:42 +0000 (GMT) Received: from hsinnreich2 ([166.42.41.19]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H8400DCP1HSJ2@pmismtp02.wcomnet.com>; Thu, 02 Jan 2003 23:34:42 +0000 (GMT) Date: Thu, 02 Jan 2003 17:34:40 -0600 From: Henry Sinnreich To: sipping@ietf.org, midcom@ietf.org Message-id: <000601c2b2b7$864567d0$13292aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Sipping] UPnP and routing updates for SIPPING and MIDCOM I-Ds Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is quite a bit of excellent work reflected in all the SIPPING and MIDCOM I-Ds on NAT and Firewall traversal and some solutions, such as STUN and TURN. I believe we need however also updated versions of this work by enlarging the focus with some other aspects. Here are two examples that come to my mind, there may be other: UPnP Commercial UPnP residential gateways allow UPnP enabled SIP UA to function well, examples are commercial wired NAT/FWs and wireless access points working with some well known softphone clients and SIP phones. Please see for reference: http://upnp.org/resources/whitepapers.asp After experiencing the true "plug-and-play" nature of the UPnP solution, I happen to believe it is also a valid enterprise approach as well and the I-Ds should consider such an enterprise scenario for outsourced and enterprise services. UPnP gateways have a wider application area since they will also support collaboration applications that may not be SIP based, appliances, etc. Along this rationale SIP phones MUST support UPnP, I believe, see http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt . Some SIP phones already support UPnP. Both the MIDCOM and Sipping WGs need to come to grips with the reality of the excellent work done by the UPnP people and document it in an informational RFC IMHO. Is the architecture as IP-centric and good as it seems? Are there any issues, such as scalability or security? It appears UPnP has solved much of the MIDCOM problem space. Ignoring UPnP by the IETF is not a good option. Routing Solutions in most recent I-D have a single NAT/FW - this often an unacceptable single point of failure. The drafts need to show solutions with multiple NAT/FW locations and the routing implications, since all internal routers need to be aware of the NAT/FWs at the edge of the enterprise network. Should this be reflected in updates to the charter of the SIPPING and MIDCOM WGs as well? What do you think? Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 18:41:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17047 for ; Thu, 2 Jan 2003 18:41:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02NoA732751 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 18:50:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NoAJ32748 for ; Thu, 2 Jan 2003 18:50:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17041 for ; Thu, 2 Jan 2003 18:41:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Nn6J32713; Thu, 2 Jan 2003 18:49:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Nm7J32660 for ; Thu, 2 Jan 2003 18:48:07 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17018 for ; Thu, 2 Jan 2003 18:39:07 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02NepSK010075; Thu, 2 Jan 2003 18:40:52 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 17:42:14 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643BE@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Peterson, Jon'" , "'Francois Audet'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Meaning of status codes Date: Thu, 2 Jan 2003 17:42:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I also remain a little unsure what the SDP in 180 is meant to accomplish. I'll provide a strawman. E.180 defines a "Ringing Tone" to be played to a caller for ringback. E.180 also defines a "Caller Waiting Tone", which is typically a concatenation of a ringback tone and a call-waiting tone (for most locales). It lets the caller know that the called party is on another call, but is being alerted nonetheless. (Although not in widespread use for US landline exchanges, I have heard such a tone when calling certain PBXes and mobile phones). Arguably, a "180 Ringing" with media, then, has the ability to provide this additional bit of information to the caller -- so it's not completely valueless. /a (I'm not going to even mention how grateful I am that I've had considerate co-workers who, upon calling my GSM phone and hearing, say, a Spanish ringback tone have thought better of disturbing me at 3 in the morning and promptly hung up). _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 18:46:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17121 for ; Thu, 2 Jan 2003 18:46:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Nt7w00487 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 18:55:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Nt7J00484 for ; Thu, 2 Jan 2003 18:55:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17115 for ; Thu, 2 Jan 2003 18:46:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NsIJ00460; Thu, 2 Jan 2003 18:54:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NriJ00407 for ; Thu, 2 Jan 2003 18:53:44 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17105 for ; Thu, 2 Jan 2003 18:44:43 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02NkVSK010093; Thu, 2 Jan 2003 18:46:31 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 17:47:54 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643BF@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , Paul Kyzivat Cc: "Peterson, Jon" , sipping@ietf.org Subject: RE: [Sipping] Re: Meaning of status codes Date: Thu, 2 Jan 2003 17:47:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > From: Rohan Mahy [mailto:rohan@cisco.com] > > > > I *think* Rohan is proposing to use UPDATE to move the media stream > > for each dialog to a unique port. > > yes Why? Differentiation? You can get that from the SSRC. /a _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 2 21:28:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20209 for ; Thu, 2 Jan 2003 21:28:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h032bRg10871 for sipping-archive@odin.ietf.org; Thu, 2 Jan 2003 21:37:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032bQJ10852 for ; Thu, 2 Jan 2003 21:37:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20205 for ; Thu, 2 Jan 2003 21:28:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032abJ10306; Thu, 2 Jan 2003 21:36:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h032ZrJ10274 for ; Thu, 2 Jan 2003 21:35:53 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20196 for ; Thu, 2 Jan 2003 21:26:48 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id h032TrKv011505; Thu, 2 Jan 2003 18:29:53 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABM74723; Thu, 2 Jan 2003 18:26:47 -0800 (PST) Date: Thu, 2 Jan 2003 18:29:49 -0800 Subject: Re: [Sipping] Re: Meaning of status codes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Paul Kyzivat , "Peterson, Jon" , sipping@ietf.org To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643BF@DYN-TX-EXCH-001.dynamicsoft.com> Message-Id: <3B64B710-1EC3-11D7-891B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, January 2, 2003, at 03:47 PM, Adam Roach wrote: >> From: Rohan Mahy [mailto:rohan@cisco.com] >>> >>> I *think* Rohan is proposing to use UPDATE to move the media stream >>> for each dialog to a unique port. >> >> yes > > Why? Differentiation? You can get that from the SSRC. As an aside, technically you shouldn't use SSRC to differentiate, because the SSRCs could collide. However this is a one in a million style corner case, which I am willing to ignore at the moment. I am much more concerned with correlation than with differentitation. If you get 3 SSRCs, you can't correlate this to a SIP (early) dialog or a Contact. Note that if RTP were symmetric, or if you knew your peers' SSRCs through their answer this would not be a problem. thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 01:29:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23799 for ; Fri, 3 Jan 2003 01:29:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h036cSQ23407 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 01:38:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036cSJ23404 for ; Fri, 3 Jan 2003 01:38:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23789 for ; Fri, 3 Jan 2003 01:29:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036aEJ22666; Fri, 3 Jan 2003 01:36:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036ZLJ22634 for ; Fri, 3 Jan 2003 01:35:21 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23767 for ; Fri, 3 Jan 2003 01:26:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h036TQYH024729; Fri, 3 Jan 2003 01:29:27 -0500 (EST) Message-ID: <3E152DC4.6020703@dynamicsoft.com> Date: Fri, 03 Jan 2003 01:29:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5C9E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Rosen, Brian wrote: > I'm not really happy with the display name trick, but there are > lots and lots of gateways that do this. It works because, as we > know, To: and From: are never modified. It's up to normal > SIP routing to get the INVITE to the right gateway. When it gets there, > the display name on the To: should be intact. Right, but it will be WRONG if the call has been forwarded before reaching the gateway. That is, I call you, Brian, and you forward the call to a PSTN number. The To display name is YOUR number, when the number that the gateway needs to use is the forwarded number. > In a prior message, I did agree that P-Asserted-Identity with > a tel URI could be used for a proxy asserting the translation, > but not the "real" NAI stuff (Jon's signed headers). Why not? They both support assertion of identity; the difference is in whether its done through transitive trust or digital signatures. > I guess I think putting a gateway in the category of a service > component and designing a new framework for service invocation > on it is a bit heavy handed given the problem, but I agree that a > brand new thing can be made to solve any problem. I think that, as a framework, this particular one can be looked at as amazingly complicated or quite simple, depending on how you scope it. THe main thing it needs to tackle is to simply declare that these are really all the same problem, and to give some general guidelines, whether its to use the r-uri for passing parameters (as in rfc3087) or whether its in a soap body in the INVITE request. Anyway, it is our job here in sipping to look at the broader issues with any problem, is it not? I think that viewing these as the same is at least worthy of discussion. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 03:54:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05367 for ; Fri, 3 Jan 2003 03:54:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03939Z09547 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 04:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03939J09544 for ; Fri, 3 Jan 2003 04:03:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05364 for ; Fri, 3 Jan 2003 03:53:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0391wJ09229; Fri, 3 Jan 2003 04:01:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0390RJ09140 for ; Fri, 3 Jan 2003 04:00:27 -0500 Received: from gbnewp0915s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05320 for ; Fri, 3 Jan 2003 03:51:14 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; 3 Jan 2003 08:53:34 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Re: Meaning of status codes Date: Fri, 3 Jan 2003 08:54:27 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE018C2584@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sipping] Re: Meaning of status codes Thread-Index: AcKyuL4bcctkPu8MR7qoJdTX0LTcgwATKS8w From: "James Undery" To: "Adam Roach" , "Peterson, Jon" , "Francois Audet" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0390RJ09141 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hmm "Caller Waiting Tone" shouldn't this be 182 Queued, but then again I've no idea about E.180 James > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 02 January 2003 23:42 > To: 'Peterson, Jon'; 'Francois Audet' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] Re: Meaning of status codes > > > I also remain a little unsure what the SDP in 180 is meant to > accomplish. > > I'll provide a strawman. > > E.180 defines a "Ringing Tone" to be played to a caller for ringback. > > E.180 also defines a "Caller Waiting Tone", which is typically a > concatenation of a ringback tone and a call-waiting tone (for most > locales). It lets the caller know that the called party is on another > call, but is being alerted nonetheless. > > (Although not in widespread use for US landline exchanges, I > have heard > such a tone when calling certain PBXes and mobile phones). > > Arguably, a "180 Ringing" with media, then, has the ability to provide > this additional bit of information to the caller -- so it's > not completely > valueless. > > /a > > (I'm not going to even mention how grateful I am that I've > had considerate > co-workers who, upon calling my GSM phone and hearing, say, a Spanish > ringback tone have thought better of disturbing me at 3 in > the morning and > promptly hung up). > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 10:52:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11697 for ; Fri, 3 Jan 2003 10:52:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03G1CA01790 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 11:01:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03G1CJ01787 for ; Fri, 3 Jan 2003 11:01:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11680 for ; Fri, 3 Jan 2003 10:51:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03G0BJ01664; Fri, 3 Jan 2003 11:00:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03FvLJ01469 for ; Fri, 3 Jan 2003 10:57:21 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11417 for ; Fri, 3 Jan 2003 10:47:59 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18210; Fri, 3 Jan 2003 10:51:10 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11278; Fri, 3 Jan 2003 10:51:12 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Jan 2003 10:51:11 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CA5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Fri, 3 Jan 2003 10:51:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hmm, well, another case of explain the problem and you often solve it yourself. > You miss the point. You may have called sip:alice. That call is then > proxied to a pstn number "1234567890" sip:port@gateway. The > proxy can't > change the To address to put the phone number in. It can't even solve > the problem with a redirect, because your UAC will probably > just change > the request id and reissue the invite with the old To value. I'll agree that if you called alice, and it got proxied to 1234567890 then the proxy can't change the To:. On the other hand, all the proxy can do is to change the Request URI, and that doesn't have a display name, so you can't actually proxy to "1234567890" sip:port@gateway You can proxy to a Tel URI, which has a phone number, but does not have the port and gateway. However, point taken. > > In a prior message, I did agree that P-Asserted-Identity with > > a tel URI could be used for a proxy asserting the translation, > > but not the "real" NAI stuff (Jon's signed headers). Do you > > want a BCP to say that P-Asserted-Identity is what translators > > use to get the phone number in the message? > > What you are suggesting seems backward. The > P-Asserted-Identity is only > useful for the calling number, not the called number. Assuming the > gateway can trust the callerid info it gets from the PSTN, it > should be > inserting a P-Asserted-Identity header with that value for inbound > calls. And it ought to be using it to generate callerid on outbound > calls. The kind of translator you describe seems useless for this. Let's start with inbound calls. The gateway has calling and called numbers, it may have a calledId name. If it has mapping, it has the sip URI of the intended recipient. I now see that this works: The text of 3325 talks about asserting the identity of the entity the message is from. For an inbound call, this is really the gateway, but in this case, I think we would assume that we would use it for the calling party identity as you say. Two of them can be used to get both the number and the name. The Request URI, if the gateway has mapping, could be the end UAS, but if it doesn't, either it has to be a translator URI, or it just sends it with a tel URI, and the proxies handle it. The gateway could use a tel URI as the From field which would be the called party number, but it would have to get the port number in as a parameter to the tel URI because if translation is needed, that information is essential to the translation. If the gateway doesn't have translation, the translator takes the called party from the Request URI, or if necessary, the From: and changes the Request URI to the sip URI of the UAS. Okay, that works. Never saw a gateway that came even close to it (okay, well I've seen some gateways take a tel uri in the Request URI for the calling number), but it seems to work. On outgoing calls, the originating UAC could construct a tel URI, or a phone number@gateway sip uri for the Request URI and To: and it would clearly put it's sip URI, not it's phone number in the From. If there was a translator, it would put a P-Asserted-Identity of the From (the sip UAC) as a phone number (and name if it wanted). It would have to add the port number to the Request URI as a parameter to the tel URI and forward it to the gateway. I guess the UAC could put the P-Asserted-Identity in the original INVITE just like the gateway does if there is no translator. I'm not sure I understand how routing is done if the proxy that knows which gateway is associated with the user's line (or destination phone number if that's the routing decision) would construct a Request URI with the port@gateway addressing and still keep the number to dial. That means the routing gateway has to be next-to-last proxy in the path, which is clearly not always true. > > I think the best choice right now for outbound calls is a > tel: uri. You > can pack all sorts of info into it. This can also be represented as a > sip uri with user=phone. If you want to use a translator, start by > generating a tel: uri, then route it to the translator, which > can turn > it into a sip uri with user=phone, using the domain name to > select the > actual gateway. It can also fill in extra parameters (defined in the > tel: uri) in the user part of the sip uri to help the gateway do the > right thing. > > > The "P-" is a > > problem. P-Asserted-Identity should go away once the > > signed header idea is fully baked, but this problem stays for > > a very long time. > > I don't think the signed header is a replacement for the > P-Asserted-Identity. Which to use depends on whether you have trusted > servers in the network that are responsible for some aspects of > identity. As long as you are interoperating with the PSTN this will > probably remain as a requirement. Probably not the thread for a discussion like this, but it does seem to me that the "right" way we want to move to is to have the UAC set identity correctly, and have the trusted proxy sign it to authenticate it. I think there is then no reason to keep P-Asserted-Identity for any NAI application, including 3G and PSTN interwork. The only thing that won't do is allow the "trusted" network to have some identity that the UAC is unaware of. I don't think that is a good plan although you still need the phone number AND the UAC sip uri, which is what we are really talking about, so the P-A-I morphs into a UAC (or local, untrusted, proxy) thing, and not a trusted proxy thing, and the trusted proxy signs it, authenticating it. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 11:21:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12202 for ; Fri, 3 Jan 2003 11:21:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03GTvi03742 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 11:29:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GTuJ03737 for ; Fri, 3 Jan 2003 11:29:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12199 for ; Fri, 3 Jan 2003 11:20:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GSYJ03676; Fri, 3 Jan 2003 11:28:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GQjJ03583 for ; Fri, 3 Jan 2003 11:26:45 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12114 for ; Fri, 3 Jan 2003 11:17:25 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h03GKYJ19346 for ; Fri, 3 Jan 2003 11:20:34 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jan 2003 16:20:33 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006FFB401@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Paul Kyzivat , "Rosen, Brian" Cc: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Fri, 3 Jan 2003 16:20:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , See inline Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 02 January 2003 21:34 > To: Rosen, Brian > Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > Subject: Re: [Sipping] URIs for Gateways > > > Rosen, Brian wrote: > > > > I'm not really happy with the display name trick, but there are > > lots and lots of gateways that do this. It works because, as we > > know, To: and From: are never modified. It's up to normal > > SIP routing to get the INVITE to the right gateway. When > it gets there, > > the display name on the To: should be intact. > > You miss the point. You may have called sip:alice. That call is then > proxied to a pstn number "1234567890" sip:port@gateway. The > proxy can't > change the To address to put the phone number in. It can't even solve > the problem with a redirect, because your UAC will probably > just change > the request id and reissue the invite with the old To value. > > > > > However, overloading the display name with the number to dial is > > not a great idea, even if a lot of stuff in the field does it. > > > > In a prior message, I did agree that P-Asserted-Identity with > > a tel URI could be used for a proxy asserting the translation, > > but not the "real" NAI stuff (Jon's signed headers). Do you > > want a BCP to say that P-Asserted-Identity is what translators > > use to get the phone number in the message? > > What you are suggesting seems backward. The > P-Asserted-Identity is only > useful for the calling number, not the called number. Assuming the > gateway can trust the callerid info it gets from the PSTN, it > should be > inserting a P-Asserted-Identity header with that value for inbound > calls. And it ought to be using it to generate callerid on outbound > calls. The kind of translator you describe seems useless for this. Why is the P-Asserted-Identity only useful for calling number. It is perfectly valid in responses to INVITE. Obviously you still need to meet the requirements of having a first proxy to assert the identity, but that does exist in certain architectures, e.g. 3GPP, and the mechanisms to identify and include such a proxy are standards track items. > > I think the best choice right now for outbound calls is a > tel: uri. You > can pack all sorts of info into it. This can also be represented as a > sip uri with user=phone. If you want to use a translator, start by > generating a tel: uri, then route it to the translator, which > can turn > it into a sip uri with user=phone, using the domain name to > select the > actual gateway. It can also fill in extra parameters (defined in the > tel: uri) in the user part of the sip uri to help the gateway do the > right thing. > > > The "P-" is a > > problem. P-Asserted-Identity should go away once the > > signed header idea is fully baked, but this problem stays for > > a very long time. > > I don't think the signed header is a replacement for the > P-Asserted-Identity. Which to use depends on whether you have trusted > servers in the network that are responsible for some aspects of > identity. As long as you are interoperating with the PSTN this will > probably remain as a requirement. I have commented on this in another mail. I support Paul on this. They are two different solutions and their usage depends on the network architecture that you are working with. > > Paul > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 11:22:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12240 for ; Fri, 3 Jan 2003 11:22:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03GV8D03891 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 11:31:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GV8J03888 for ; Fri, 3 Jan 2003 11:31:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12236 for ; Fri, 3 Jan 2003 11:21:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GU3J03779; Fri, 3 Jan 2003 11:30:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GQkJ03587 for ; Fri, 3 Jan 2003 11:26:46 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12116 for ; Fri, 3 Jan 2003 11:17:26 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h03GKaJ19362 for ; Fri, 3 Jan 2003 11:20:36 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jan 2003 16:20:33 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006FFB400@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Rosen, Brian" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Fri, 3 Jan 2003 16:20:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Network asserted identity (RFC 3325) is the real network asserted identity. It is a P header not because it is preliminary, but because the whole idea of network assertion is not generally applicable to all SIP architectures. For RFC 3325 a trust domain needs to exist between proxies that use the P-Asserted-Identity in order to guarantee the privacy, this does not exist in all SIP networks. In does in 3GPP and therefore 3GPP are using RFC 3325. If you want to let the 1et outbound proxy assert identity on your behalf then use RFC 3325. If you want to let application servers with whom you have a secure relationship assert your identity, then use Jon Petersons drafts, when they eventually become RFCs. One is not a short term solution for the other. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 02 January 2003 20:49 > To: 'Henning Schulzrinne' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > Yeah, I actually thought of just allowing a display name in the > Request URI and using that, but it seems so foolish to make a change, > and have that change not be exactly what we needed. > > We could use NAI. I suppose we could use a P-Asserted-Identity > with a tel URI: > P-Asserted-Identity tel:+17247426826 > > What do we do when the "real" NAI happens? > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, January 02, 2003 3:10 PM > > To: Rosen, Brian > > Cc: 'sipping@ietf.org' > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > I'd like to get a new header for the calling party number on > > > an outbound call. That way, the translator can be a proxy and > > > add the header. I'd recommend that gateways allow the number > > > to be in the From. > > > > Generalized, you want something like the Request-URI that can be > > modified or inserted. How about the NAI stuff? > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 13:50:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16058 for ; Fri, 3 Jan 2003 13:50:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03IxMs15736 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 13:59:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03IxMJ15730 for ; Fri, 3 Jan 2003 13:59:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16033 for ; Fri, 3 Jan 2003 13:49:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03IwKJ15653; Fri, 3 Jan 2003 13:58:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03IvwJ15624 for ; Fri, 3 Jan 2003 13:57:58 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15962 for ; Fri, 3 Jan 2003 13:48:34 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h03IqI6H011817; Fri, 3 Jan 2003 13:52:18 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX31871; Fri, 3 Jan 2003 13:56:39 -0500 (EST) Message-ID: <3E15DBB9.8030208@cisco.com> Date: Fri, 03 Jan 2003 13:51:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "Rosen, Brian" , "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <475FF955A05DD411980D00508B6D5FB006FFB401@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > >>What you are suggesting seems backward. The >>P-Asserted-Identity is only >>useful for the calling number, not the called number. Assuming the >>gateway can trust the callerid info it gets from the PSTN, it >>should be >>inserting a P-Asserted-Identity header with that value for inbound >>calls. And it ought to be using it to generate callerid on outbound >>calls. The kind of translator you describe seems useless for this. > > > Why is the P-Asserted-Identity only useful for calling number. > It is perfectly valid in responses to INVITE. > Obviously you still need to meet the requirements of having a > first proxy to assert the identity, but that does exist in certain > architectures, e.g. 3GPP, and the mechanisms to identify and > include such a proxy are standards track items. Sorry - I wasn't specific enough. It seemed that Brian was trying to use P-Asserted-Identity in a *request* to identify the *called* number. But NAI in the request can only identify who is calling. This is what seemed backward to me. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 14:29:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17237 for ; Fri, 3 Jan 2003 14:29:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03Jci319565 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 14:38:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JciJ19562 for ; Fri, 3 Jan 2003 14:38:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17222 for ; Fri, 3 Jan 2003 14:29:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JbNJ19292; Fri, 3 Jan 2003 14:37:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JaLJ18860 for ; Fri, 3 Jan 2003 14:36:21 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17178 for ; Fri, 3 Jan 2003 14:26:56 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h03JUeCD017379; Fri, 3 Jan 2003 14:30:41 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX32223; Fri, 3 Jan 2003 14:35:02 -0500 (EST) Message-ID: <3E15E4B8.1080905@cisco.com> Date: Fri, 03 Jan 2003 14:30:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5CA5@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, Some of your comments seem so confusing to me that I think I must be misunderstanding them in some fundamental way. Are you talking about a situation where a particular port on a gateway is intended to map 1:1 to a particular phone number in the PSTN and to a particular sip uri in the sip network? (To be specific, lets call these +1-987-654-3210, sip:foo@bar.com, sip:port3@gw.bar.com.) Do you then want take all outbound calls to the pstn from sip:foo@bar to be routed thru sip:port3@gw.bar.com, and all inbound calls from the pstn to arrive at port3 on the gateway and then be sent to sip:foo@bar.com? If the above are true, do you then want to put knowledge of these mappings in your translator proxy rather than in the gateway? Under those assumptions, I can start to make some sense of your comments. If the gw always sends inbound calls from the pstn to the translator, putting the port address (sip:port2@gw.bar.com) in the From header, then I suppose the translator could use the from address to map sip:port3@gw.bar.com to sip:foo@bar.com. But it seems like an odd thing to do. It would make way more sense to me in this case for the gw to put tel:+1-987-654-3210 in the To and request addresses, and then send the request to the translator. The translator could then look that up and forward the request to sip:foo@bar.com. Going the other way - a call from sip:foo@bar.com to some phone number in the pstn (e.g. +1-789-456-0123), I would expect the UAC to put its own address in the From, and a tel: uri in the To and request uris. Then it would probably deliver this to the translator. The translator would look up +1-789-456-0123, and discover it isn't in the sip network and so must be in the pstn. Given the assumptions I think you are making, it would then decide it must route this call to the gateway port associated with the caller. So it would look up the From address (sip:foo@bar.com) and translate it to a gateway address (sip:port3@gw.bar.com) and forward the request there. But that breaks down, because the gw has no good way to learn called number. This simplest answer I can see to this is for the translator to simply translate the From address to the FQDN of the gateway, and then to use that to convert the request address from tel: format to sip format: and also insert an NAI of the caller as tel:+1-987-654-3210. This gets the call to the right gateway with the necessary information. It would be up to the gateway to figure out that calls from NAI tel:+1-987-654-3210 should use port3. Further comments inline below. Paul Rosen, Brian wrote: > > Let's start with inbound calls. The gateway has calling and called > numbers, it may have a calledId name. If it has mapping, it has the > sip URI of the intended recipient. I now see that this works: > > The text of 3325 talks about asserting the identity of the entity > the message is from. For an inbound call, this is really the gateway, > but in this case, I think we would assume that we would use it for > the calling party identity as you say. Two of them can be used to get > both the number and the name. The Request URI, if the gateway > has mapping, could be the end UAS, but if it doesn't, either it has to be > a translator URI, or it just sends it with a tel URI, and the proxies > handle it. The last makes the most sense to me. > The gateway could use a tel URI as the From field which > would be the called party number, ^^^^^^ calling??? I hope this was a typo. Why would you put the *called* number in the From field? > but it would have to get the port > number in as a parameter to the tel URI because if translation is > needed, that information is essential to the translation. Why? It would be a lot simpler if the gw at least knew, or could get, the phone number corresponding to each port, so it can form a tel: uri to use as the To address. Then the translator will have something useful to work from. > If the gateway doesn't have translation, the translator takes the > called party from the Request URI, or if necessary, the From: ^^^^^ ????? The above is still worrying me. > and changes the Request URI to the sip URI of the UAS. Okay, > that works. Never saw a gateway that came even close to it (okay, > well I've seen some gateways take a tel uri in the Request URI > for the calling number), but it seems to work. > > On outgoing calls, the originating UAC could construct a tel URI, > or a phone number@gateway sip uri for the Request URI and To: and > it would clearly put it's sip URI, not it's phone number in the From. > If there was a translator, it would put a P-Asserted-Identity of the >>From (the sip UAC) as a phone number (and name if it wanted). Tat seems ok. > It would have to add the port number to the Request URI as a parameter > to the tel URI and forward it to the gateway. See above for a way to finesse this. > I guess the UAC could > put the P-Asserted-Identity in the original INVITE just like the gateway > does if there is no translator. I'm not sure I understand how > routing is done if the proxy that knows which gateway is associated > with the user's line (or destination phone number if that's the routing > decision) would construct a Request URI with the port@gateway > addressing and still keep the number to dial. That means the > routing gateway has to be next-to-last proxy in the path, which is > clearly not always true. Possible answer above. > Probably not the thread for a discussion like this, but it does seem > to me that the "right" way we want to move to is to have the UAC set > identity correctly, and have the trusted proxy sign it to authenticate > it. I think there is then no reason to keep P-Asserted-Identity for > any NAI application, including 3G and PSTN interwork. The only > thing that won't do is allow the "trusted" network to have some > identity that the UAC is unaware of. I don't think that is a good > plan although you still need the phone number AND the UAC sip uri, > which is what we are really talking about, so the P-A-I morphs > into a UAC (or local, untrusted, proxy) thing, and not a trusted > proxy thing, and the trusted proxy signs it, authenticating it. I'm not confident that I understand all the issues yet. Jon's proposal seems pretty heavyweight - so I am not yet confident that it can be a total solution on its own. Also, I think as long as we have to deal with the PSTN, which assumes trusted network components, we may continue to need the NAI approach. But maybe not. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 22:16:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24444 for ; Fri, 3 Jan 2003 22:16:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h043PLM11904 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 22:25:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043PLJ11901 for ; Fri, 3 Jan 2003 22:25:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24440 for ; Fri, 3 Jan 2003 22:15:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043OSJ11849; Fri, 3 Jan 2003 22:24:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043NSJ11815 for ; Fri, 3 Jan 2003 22:23:28 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24410 for ; Fri, 3 Jan 2003 22:13:53 -0500 (EST) Received: from cs.columbia.edu ([12.85.3.253]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030104031706.UKVL12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Sat, 4 Jan 2003 03:17:06 +0000 Message-ID: <3E1651A1.2030207@cs.columbia.edu> Date: Fri, 03 Jan 2003 22:14:41 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: <4.3.2.7.2.20021223165256.00b2de58@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Mike. I don't want to require that a SIP UA has to use a specific "local" outbound proxy, for example, but it may do so as a performance optimization. The local outbound proxy can and should recognize the local emergency number (in addition to 'sos') - that's fairly trivial. There isn't really anything much the terminal (UA) needs to do special in that case. (Possible exception: if the terminal normally ignores the outbound proxy, it might decide not to in an emergency. That seems a stretch since ignoring the outbound proxy is likely to have you run smack into the firewall.) The draft already says Outbound proxy servers {\MUST} be configurable to recognize additional local emergency numbers. What other special actions does the *terminal* need to perform in case of emergency? Michael Hammer wrote: > Mike, > > Before a "terminal" can handle the local dial plan, it must first > determine what "local" is. It is still not clear to me how that is > going to occur. > > The terminal may be able to handle a number input by the end-user and > formulate a request, but then it may need to rely on a nearby proxy > which is more fixed and knowledgeable of what local is and route > accordingly. But, this may depend on the topology of the network and > its relationship to geography and jurisdictional boundaries. > > Mike > > > At 03:11 PM 12/23/2002 -0500, Mpierce1@aol.com wrote: > >> In a message dated 12/21/2002 12:06:10 AM Eastern Standard Time, >> hgs@cs.columbia.edu writes: >> >> >>> That's why I argued that incorporating all local numbers is not feasible >>> nor desirable. I'm still undecided whether favoring 112 or 911 is a good >>> idea (I suspect it may not be since it's hard to draw the line). >> >> >> >> >> [MAP] I think there is still confusion here. Of course, a device can >> not "incorporate" all local numbers. My comment was that it must >> "handle" all local numbers (where the primary discussion at the moment >> is regarding emergency numbers). If this is claiming to lead to an >> "international standard", then it can not "favor" 112 or 911. While >> "SOS" itself could be a good idea, perhaps the discussion and draft >> should be separated from the more general, complex issue of >> recognition by a terminal of the local dial plan. Maybe just a >> statement to the effect that "besides handling the "SOS" as defined in >> this note, a terminal must correctly handle the local dial plan, >> including the appropriate emergency number(s), which is not described >> here". >> >> Mike Pierce >> Artel > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 22:33:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24630 for ; Fri, 3 Jan 2003 22:33:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h043grj13016 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 22:42:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043grJ13013 for ; Fri, 3 Jan 2003 22:42:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24627 for ; Fri, 3 Jan 2003 22:33:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043gCJ12994; Fri, 3 Jan 2003 22:42:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043fhJ12962 for ; Fri, 3 Jan 2003 22:41:43 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24612 for ; Fri, 3 Jan 2003 22:32:08 -0500 (EST) Received: from cs.columbia.edu ([12.85.3.253]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030104033520.YWYP9286.mtiwmhc11.worldnet.att.net@cs.columbia.edu>; Sat, 4 Jan 2003 03:35:20 +0000 Message-ID: <3E1655E8.4060308@cs.columbia.edu> Date: Fri, 03 Jan 2003 22:32:56 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'James.Hamlin@RNID.org.uk'" , sipping@ietf.org Subject: Re: [Sipping] Authentication issues with emergency and other serv ices References: <313680C9A886D511A06000204840E1CF030B5C65@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > Well, the basic problem is that you need a global PKI to > have the signature of the signer verified. That is > a hard problem no one has solved. You might be able to > provide some traceability using the P-asserted-identity > header, or the subsequent work Jon Peterson has proposed. > That would imply that there is a trusted service provider, > and it wouldn't give you any information about the network > beyond the "demarc". Also, as long as identities are cheap, even a client-level PKI doesn't really help all that much. We already have SIP services where you can get a SIP identity without identifying yourself beyond possibly a throw-away email address. You would effectively need a 'bonded' SIP address. This might be useful for spam prevention, too, but it's even harder here since while one can easily refuse to receive un-authenticated email, it's not generally legally possible or desirable to refuse unauthenticated emergency calls. > > We have talked about the other side of that problem = > authenticating that the caller is talking to a bona fide > PSAP. Even that is seen as an impossibly hard problem = > getting all PSAPs to get a cert signed by a global PSAP > CA. To amplify: the typical SSL cert from Thawte or Verisign wouldn't do much good here. You need somebody to provide a certificate that psap.sometown.ny.us is indeed a PSAP and not the Pseudo-Service Agency imPersonator. Things would be somewhat easier if ICANN created another restricted top-level domain similar to .museum, but I know of no such plans. > > Brian > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 22:49:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24881 for ; Fri, 3 Jan 2003 22:49:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h043wqR13558 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 22:58:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043wqJ13555 for ; Fri, 3 Jan 2003 22:58:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24871 for ; Fri, 3 Jan 2003 22:49:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043wAJ13532; Fri, 3 Jan 2003 22:58:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043v2J13473 for ; Fri, 3 Jan 2003 22:57:02 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24811 for ; Fri, 3 Jan 2003 22:47:26 -0500 (EST) Received: from cs.columbia.edu ([12.85.3.253]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030104035039.VBNC12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Sat, 4 Jan 2003 03:50:39 +0000 Message-ID: <3E16597E.3070203@cs.columbia.edu> Date: Fri, 03 Jan 2003 22:48:14 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'James.Hamlin@RNID.org.uk'" , sipping@ietf.org Subject: Re: [Sipping] Authentication issues with emergency and other serv ices References: <313680C9A886D511A06000204840E1CF030B5C65@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One additional comment: even with a global PKI, the caller would need to be able to reliably determine the public key of the specific PSAP. There doesn't seem to be a way to do this at this point, without adding a lot of non-standard signaling exchanges. (The caller would have to place an unencrypted call to get back a signed response or use OPTIONS, as proposed by Cullen, presumably without any location or other privacy-relevant content, and then re-issue the request. This seems likely to add multiple seconds to the call setup time. Unless there is a recognizable name or some other certificate extension, this doesn't really help much.) _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 3 23:12:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25135 for ; Fri, 3 Jan 2003 23:12:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h044L5r15002 for sipping-archive@odin.ietf.org; Fri, 3 Jan 2003 23:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h044L5J14996 for ; Fri, 3 Jan 2003 23:21:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25122 for ; Fri, 3 Jan 2003 23:11:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h044KLJ14946; Fri, 3 Jan 2003 23:20:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h044JaJ14890 for ; Fri, 3 Jan 2003 23:19:36 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25089 for ; Fri, 3 Jan 2003 23:10:00 -0500 (EST) Received: from cs.columbia.edu ([12.85.3.253]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030104041312.VLJK12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Sat, 4 Jan 2003 04:13:12 +0000 Message-ID: <3E165EC7.6090107@cs.columbia.edu> Date: Fri, 03 Jan 2003 23:10:47 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Marshall CC: Brian.Rosen@marconi.com, sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: <200212191500.KAA51775@fish.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit William Marshall wrote: > One aspect of 'sos' calls that is rather annoying is that there > is no agreed standard for some details of the service. While > organizations such as NENA and ANSI write various documents, local > justidictions actually set the requirements as part of CLEC- > certification (important if you want to get blocks of phone numbers > from the NANP so PSTN subscribers can call your subscribers). > > Some jurisdictions require "called-party control" on 9-1-1 calls. Some > jurisdictions require PSAP-initiated constant-ring on an attempted hangup. > (I realize that SIP phones, like cell phones, are under the user's > control and can be disconnected or powered off and the real usefulness > of these requirements is dubious; but CLEC-certification is still useful). Since this comes up again and again, I've asked this question (a while ago) on the NENA mailing and nobody (that answered) was able to provide any indication that this is still true for E911 today. (It was true for the early 911 service where the PSAP was connected directly to the local switch.) It was claimed that modern ISDN switches don't provide this functionality, either. Maybe you're talking about non-North American jurisdictions? Do you have citable evidence on this requirement? Since the PSAP tandem and the caller switch may be several 'hops' apart, this capability would have to be part of ISUP. I looked at one of the Telcordia/Bellcore specs for 911 service and it doesn't mandate it, either. Since CLECs generally don't (like to) write their own switch software, I'd imagine that this would at least be a Bellcore requirement. I got the following two contradictory quotes, among others: "I can't speak for Call Transfer however Call Waiting and Three Way Calling are still available to the 9-1-1 caller. At least it is here in a DMS environment." "From my experience, most switches (5ESS, DMX-100, and GTD5EAX) disable custom calling features for the entire call when calling to N11 services in a manner similar to when they are establishing a call to another number. In other words, the switch deals with the 911 call like when you are listening to a ringing signal (i.e. no call waiting, no call transfer, no 3-way calling, etc.)." This only requires the originating switch to recognize N11, so that seems fairly easy in PSTN land. I suppose one could say that UAs should not use REFER. > > There is a basic design decision of whether it is all in the UA, and if > not, potentially a standardization issue. > > If the decision is that the UA doesn't really know when it calls an > emergence service (possibly due to the numerous ways to dial such a > service), then there are several areas that would need some agreement. This probably argues again for a global identifier. Some behavior, like call waiting, doesn't really apply in UAs. REFER issued by the UA to the PSAP is harmless. > > 1) what is the effect of a BYE request generated by a UAC that is > rejected by the UAS with a 4xx (e.g. 403-Forbidden)? Does the UA > need to wait for the response to the BYE before tossing call state? > Likewise, call-stateful proxies on the path? There is, of course, > a denial-of-service threat here when a non-PSAP rejects a BYE. Given the many ways that the caller can terminate a call, this seems like a second-order problem. Can ISUP refuse a teardown request? What happens in that case? This may be a simple UI issue. Since this is primarily a prevention of accidental disconnects, a UA might want to treat the 403 as a "Callee doesn't want to hang up. Do you really want to terminate the call?" (The rough equivalent of the corresponding Windows Ctrl-Alt-Del behavior...) > > 2) what is the effect of a mid-call INVITE when the instrument is > in an on-hook state? Is 180-Ringing an allowable response? You mean for PSAP initiated call-back? This would be the same situation as if I had sent a BYE and an INVITE crossed on the wire. It would probably yield an invalid call-ID error. > > I believe both case are "under-specified" in rfc3261, so the needed > behavior is allowed but not mandated. I think this is more than a BCP. Since these are corner-cases, it seems a bad idea to rely on specific UA behavior. Do cell phones support any of the features you describe? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 4 11:06:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12766 for ; Sat, 4 Jan 2003 11:06:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04GFjw26943 for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 11:15:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GFjJ26940 for ; Sat, 4 Jan 2003 11:15:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12759 for ; Sat, 4 Jan 2003 11:05:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GEnJ26908; Sat, 4 Jan 2003 11:14:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GCrJ26839 for ; Sat, 4 Jan 2003 11:12:53 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12735 for ; Sat, 4 Jan 2003 11:03:02 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04G64Te007391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Jan 2003 11:06:05 -0500 (EST) Message-ID: <3E170671.4020904@cs.columbia.edu> Date: Sat, 04 Jan 2003 11:06:09 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: "Rosen, Brian" , "'Mpierce1@aol.com'" , sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: <4.3.2.7.2.20021218151742.05261d00@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20021218151742.05261d00@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This is the same issue that TIA TR45.2 had to address when dealing with > cell phones and determining how to route to the correct PSAP. An > example given was that a caller in Georgia will be directed to a 911 > center in Atlanta, but the connection to the police/fire/medical > personnel had to be local to the caller. And often the caller did not > know where he was. A number of solutions were proposed, which included > various angle of arrival (AOA), time of arrival (TOA), and GPS-assisted > triangulation methods where either the phone or the radio station > determined and reported this type of information. > > I don't know if we want to repeat that whole history here. But, it > might be useful to provide the ability to add that information to the > INVITE. Is there any current technique for doing that? We've been playing around with a simple mechanism that includes the location information, both civil and geographic, in a SIP header only for 'sos' calls. This is simple to implement and avoids having to set up a large infrastructure. It also greatly simplifies the trust relationships. If you deliver this information out-of-band *e.g., as part of a presence mechanism via UPDATE), the PSAP has to convince the entity holding the location information that it is indeed a PSAP and, more over, preferably the one the user just called. (See the related discussion on the difficulties of authenticating users.) The location information can be added by the UA or the proxy; it is somewhat similar in spirit to the NAI problem. The reason for suggesting a SIP header field instead of a body is that proxies aren't supposed to be adding body parts to requests. However, a header like this should be standardized outside the emergency call context since it is more generic. >> 2. If it requires that a proxy actively know that an emergency >> number is dialed, and take some distinguished action based on that >> knowledge, then we don't need any standards. We could write >> a BCP or Informational. My take is that we should not *require* that a proxy between the caller and the home domain know that the call is special, but allow this. The Draft describes two such actions: - the obp may recognize a local emergency number and route it to a local gateway or PSAP - the obp may recognize 'sos' and do the same. >> In simple systems, none of the above is necessary. The scenario >> where it might be necessary to do some work is a situation in >> which you have: >> A number of UAs in different geographic locations >> A set of proxy servers where the UAs served by one >> proxy server do not respect geographic locations >> A set of gateways in different geographic locations >> A set of users who can roam from UA to UA >> >> In this case, if the user dialed the "local" emergency number, >> the some entity must know which gateway to route the call to. >> It isn't dependent on the user, it's dependent on the UA, or more >> precisely, the geographic location of the UA when the call is made. >> The distinction is what happens if the UA is moved. >> If a user whose home registrar is in New York visits a site in >> Chicago and calls 911, you need the call to route to a gateway >> in Chicago. The proxy server for Chicago might be in St. Louis. >> Somehow, the proxy server needs to know that a call from the UA >> in Chicago, regardless of who is registered, needs to be routed >> to the gateway in Chicago. We have implemented a system that does exactly that, based on the location information I mentioned above, using a commercially-available database. Unfortunately, the protocol that maps location information to jurisdiction is proprietary and it is very difficult to gain access to the database. (You need to set a strange VPN, establish contracts and the like. This makes this arrangement suitable for large telecom carriers, but not for a small or mid-sized business with its own proxy servers.) >> >> Generally, most real systems have dialing plans, where dialing >> strings are interpreted by some element to determine how to >> route a call. Most systems I know of use a proxy server to >> implement the dialing plan. It's a local matter for the proxy >> server to determine how to route a call to the emergency number >> BUT, it has to know the geographic location of the UA. >> So, we might have some work to do in order to pass that >> kind of information from UA to proxy server. There is some work >> on this underway (thanks again Henning). I'm not sure there is >> anything else we need do. >> I agree. My current hunch is that my draft or something improved is probably heading for BCP or Informational. It really doesn't describe any new SIP protocol elements. At this point, there is an opportunity to ensure somewhat SIP-friendly non-jurisdiction-specific solutions in this space, rather than mandating replicating the existing system with all its warts. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 4 11:47:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13305 for ; Sat, 4 Jan 2003 11:47:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04GuxD28716 for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 11:56:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GuxJ28713 for ; Sat, 4 Jan 2003 11:56:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13297 for ; Sat, 4 Jan 2003 11:47:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GuFJ28697; Sat, 4 Jan 2003 11:56:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04GtBJ28674 for ; Sat, 4 Jan 2003 11:55:11 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13294 for ; Sat, 4 Jan 2003 11:45:19 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04GmTmd000455 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Jan 2003 11:48:29 -0500 (EST) Message-ID: <3E171064.8070303@cs.columbia.edu> Date: Sat, 04 Jan 2003 11:48:36 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: mhammer@cisco.com, sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [MAP] There is nothing wrong with building a phone with a special button > that translates into a dialed number, e.g., 911, but my point is that > the user must still be able to dial 911 and have the exact same thing > happen. Which means if the phone does something special when you push > that button, then it must do the same special thing when you dial 911. As suggested for 3G, it would be helpful, but not necessary, to have some geographically local entity provide this information to the UA. (After all, a telephone doesn't need to know that the digits 911 are special in some way.) There are, I believe, only two plausible solutions: (1) DHCP or possibly SLP. Given that it's in the same broadcast domain as the caller, most likely to be local, at least at the country level. (Even traveling dial-in users will rarely dial an out-of-country number.) SLP would seem most appropriate, but it is yet another specialized service that would be used only for a very narrow purpose. (Unless, of course, our suggestion of using SLP [draft-zhao-iptel-gwloc-slp] for local gateway location catches on...) The only extension needed would be the list of locally valid emergency numbers. (2) Outbound proxy. Given the separation of data carriage and SIP services, may be at corporate headquarters or at some centralized SIP service provider POP. Thus, (1) seems better. However, for DHCP, since it's the outbound proxy server that needs to route the calls, it may be better to have it indicate what the numbers it can handle. A slightly different approach would be to have DHCP identify a local gateway that can handle local emergency calls, rather than just the numbers. > [MAP] But I think the question is, what is the "locality" that does the > translating? And how? If it is the user agent (phone), it needs to know > the local dialing plan. If it is some "network" element, it needs to > know the location of the originating user. I don't see an easy solution > to either. Fortunately, for this problem, either entity only needs to know the country (or, in Western Europe and North America, a good chunk of a continent) rather than more precise location. This may make it more manageable. In general, since there are likely going to be far fewer outbound proxies than UAs, I tend to prefer a 'UA does a best guess at location, outbound proxy knows local dialing plans'. For devices that are unlikely to move beyond national borders, such as the SIP phone on your desk, a local dialing plan will work pretty well. > >> In arguing against this, you have not reduced the infrastructure workload >> one bit, but you have pushed the problem to the end-user to configure, >> with >> attendant Murphy's Law consequences. > > > [MAP] Yes, I understand the end-user configuration problem. And I think > the rules would say that calls to 911 must work without any end-user > configuration. That's the intent of the draft. > > Mike Pierce > Artel > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 4 12:49:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14020 for ; Sat, 4 Jan 2003 12:49:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04HwiH31729 for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 12:58:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04HwiJ31726 for ; Sat, 4 Jan 2003 12:58:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13989 for ; Sat, 4 Jan 2003 12:47:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04HuWJ31667; Sat, 4 Jan 2003 12:56:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04HtNJ31593 for ; Sat, 4 Jan 2003 12:55:23 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13927 for ; Sat, 4 Jan 2003 12:45:32 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04Hmdmd022234 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Jan 2003 12:48:39 -0500 (EST) Message-ID: <3E171E82.2000808@cs.columbia.edu> Date: Sat, 04 Jan 2003 12:48:50 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Michael Hammer'" , Mpierce1@aol.com, sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: <475FF955A05DD411980D00508B6D5FB00439EB5A@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB5A@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > While you may converge on a small set of consistent SIP URLs, you > will still need to cater for people who go to an unfamiliar device > that happens to look like a phone, and enter the PSTN local service > number they associate with emergency dialling. I believe supporting > such emergency calls is a requirement, and the regulators will insist > that it is so. Thus we continue to have the same problem in SIP > space. Hopefully, the devices can then have a red button marked 'SOS' which should deal with some of the user interface issues. See the other discussion on means to find the local emergency number. In practice, this may not be a big issue. After all, in the worst case that the call goes back 'home' across several timezones, the list of such numbers is no larger than the list of 200+ countries, so a simple SOAP service that retrieves the current list is pretty straightforward. (I'm restricting myself to countries with national emergency numbers.) The harder part is then routing the call to a place that can dial the number and reach somebody useful. In practice, I don't see anything except an obp local to the caller (at least within the same country) that can do this. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 4 13:10:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14152 for ; Sat, 4 Jan 2003 13:10:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04IJsL00357 for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 13:19:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IJrJ00354 for ; Sat, 4 Jan 2003 13:19:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14136 for ; Sat, 4 Jan 2003 13:10:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IJIJ00338; Sat, 4 Jan 2003 13:19:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IIcJ00309 for ; Sat, 4 Jan 2003 13:18:38 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14128 for ; Sat, 4 Jan 2003 13:08:46 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04IBuTe021893 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Jan 2003 13:11:57 -0500 (EST) Message-ID: <3E1723F8.7080508@cs.columbia.edu> Date: Sat, 04 Jan 2003 13:12:08 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mills, Duncan, D, CND Tech Dev, VF UK" CC: "Drage, Keith (Keith)" , sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mills, Duncan, D, CND Tech Dev, VF UK wrote: > In section 5 of the draft - 'Request Routing': > > You talk about the need for a UA to be able to provide information > about its location. You mention providing exact information such as > longitude, latitude and altitude. You also mention possibilities of > providing 'Agent-Circuit-ID' and 'Remote-ID', as per RFC 3046. > > Have you considered also mentioning the use of the > p-access-network-info header for this purpose? (see > draft-garcia-sipping-3gpp-p-headers-02 which is in the RFC editors > queue). > > The p-access-network-info header enables you to specify an > access-type and an access-info field in cases where the UA is aware > of the access network. This seems potentially useful, but somewhat in the wrong direction and at the wrong layer. At least currently, the information appears to be a list of physical layers, as in "IEEE-802.11a" / "IEEE-802.11b" / "3GPP-GERAN" / "3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" / "3GPP-CDMA2000" and is provided by the UA. This type of information doesn't seem to help much in determining the local emergency number, a local suitable gateway or other emergency information. How would you envision extending this information and how would the UA find out this information? > > In 3GPP circles this helps (as Keith said) the outbound proxy to try > and figure out if the 'dialled digits' are that of a local emergency > centre or not... > > Best Regards, > > Duncan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 4 13:31:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14286 for ; Sat, 4 Jan 2003 13:31:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04IfBg01506 for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 13:41:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IfBJ01503 for ; Sat, 4 Jan 2003 13:41:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14275 for ; Sat, 4 Jan 2003 13:31:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IeKJ01477; Sat, 4 Jan 2003 13:40:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IdZJ01414 for ; Sat, 4 Jan 2003 13:39:35 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14261 for ; Sat, 4 Jan 2003 13:29:43 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h04IWtmd007482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Jan 2003 13:32:55 -0500 (EST) Message-ID: <3E1728E4.9090704@cs.columbia.edu> Date: Sat, 04 Jan 2003 13:33:08 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sipping@ietf.org References: <1c5.30e3c4a.2b2b7db9@aol.com> In-Reply-To: <1c5.30e3c4a.2b2b7db9@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Comments on revised 'sos' draft Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your comments. Skipping things discussed already, some remarks inline. Mpierce1@aol.com wrote: > This capability to support a special universal identifier does not > replace any requirements that a user must be able to dial local > emergency numbers and have the UA correctly handle the call, including > any appropriate processing.. I noted that this is an additional capability. > If the approach in the 6h paragraph of defining subaddresses is used > (e.g., fire, rescue, police), it would be necessary to be able to define > many other types, as well as to deal with language differences. Note > that "SOS" itself was chosen due it its international recognition and > not being dependent on a particular language. There would need to be, at > a minimum, an IANA Considerations for assignment of other subaddresses. Has been added. > > The seventh paragraph states that the "sos" user name and user names > starting with "sos." MUST NOT be assigned to any user. Such a > restriction can not possibly be enforced due to possible existing > conflicts (as noted in Section 6). While this restriction may be > "recommended", just as it might be recommended that a PBX not use an > extension number of 911, this can not be the basis for any processing on > the URL in a proxy. Depending on a URL of the form "sos@any_domain" to > call the emergency center is not sufficient. This could result in many > unwanted calls to emergency centers. Do you have any suggestions that work better? The section 'Alternative Identifiers Considered' describes why I believe that none of the obvious alternatives is workable if you want - gradual deployability (this rules out special tel: URIs) - ability for non-modified UAs to dial this number (this rules out a new header field or URI parameter) We have a long-standing precedent for this, namely the 'postmaster' convention in RFC 2821, Section 4.5.1: Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name. > > 4. Request handling > > The 4th paragraph talks about "testing" by use of OPTIONS. Since the > testing is only "recommended", there should be no reason that the random > intervals be a "MUST". This does not follow logically. It simply states that "if you do X, you MUST do it in a certain way." I don't want to say that "if you do X, you SHOULD do it that way, but may do it differently if you need to". > > The next paragraph states that "any proxy ... that receives such a > request MUST forward the request to the appropriate local emergency > number". Since this certainly does not refer to the test call in the > preceding paragraph, this paragraph should be moved. Moved. > > Mike Pierce > Artel > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 4 13:34:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14340 for ; Sat, 4 Jan 2003 13:34:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04Ihd201625 for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 13:43:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IhdJ01622 for ; Sat, 4 Jan 2003 13:43:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14330 for ; Sat, 4 Jan 2003 13:33:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04Ih4J01603; Sat, 4 Jan 2003 13:43:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04IgYJ01552 for ; Sat, 4 Jan 2003 13:42:34 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14306 for ; Sat, 4 Jan 2003 13:32:41 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h04IZk8W008346; Sat, 4 Jan 2003 12:35:46 -0600 From: "Dean Willis" To: "'Henning Schulzrinne'" , "'Rosen, Brian'" Cc: , Subject: RE: [Sipping] Authentication issues with emergency and other serv ices Date: Sat, 4 Jan 2003 12:35:24 -0600 Message-ID: <003601c2b420$0bbcc930$0c02a8c0@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E1655E8.4060308@cs.columbia.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h04IgYJ01553 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > > We have talked about the other side of that problem = > > authenticating that the caller is talking to a bona fide > > PSAP. Even that is seen as an impossibly hard problem = > > getting all PSAPs to get a cert signed by a global PSAP > > CA. > > To amplify: the typical SSL cert from Thawte or Verisign wouldn't do > much good here. You need somebody to provide a certificate that > psap.sometown.ny.us is indeed a PSAP and not the > Pseudo-Service Agency > imPersonator. Things would be somewhat easier if ICANN > created another > restricted top-level domain similar to .museum, but I know of > no such plans. Well, the problem is that you need to be able to trust that the PSAP URL you've been given is a valid PSAP. That boils down to "so, where did you get this PSAP URL from?" Once you HAVE a URL, pki can validate that the party you end up talking to is the rightful holder of that URL. So let's separate the problem out. Where does the PSAP URL come from? Possibilities: 1) Something like DHCP. Well, this pushes the whole trust problem onto DHCP, doesn't it? Although we SEEM ready to trust DHCP for everything else, including assignment of DNS servers. This same model generalizes to the "trusted introducer/configuratio nserver" problem. 2) Something statically configured, perhaps "operator provisioned". This would mean that the routing infrastructure would have to find you the "right" PSAP among the many. Potentially, an interesting application of nearest-anycast, or simply a design problem for an operator network. Might work in a 3GPP-ish environment (where th P-CSCF can make local diversion decisions), but how does it help the SIP-phone at my desk? -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 4 20:06:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18036 for ; Sat, 4 Jan 2003 20:06:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h051G6f18743 for sipping-archive@odin.ietf.org; Sat, 4 Jan 2003 20:16:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h051G6J18740 for ; Sat, 4 Jan 2003 20:16:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18031 for ; Sat, 4 Jan 2003 20:06:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h051FDJ18714; Sat, 4 Jan 2003 20:15:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0519kJ18621 for ; Sat, 4 Jan 2003 20:09:46 -0500 Received: from mtiwmhc13.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17975 for ; Sat, 4 Jan 2003 19:59:45 -0500 (EST) Received: from cs.columbia.edu ([12.85.1.245]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030105010257.FUSS20003.mtiwmhc13.worldnet.att.net@cs.columbia.edu>; Sun, 5 Jan 2003 01:02:57 +0000 Message-ID: <3E1783B0.7050209@cs.columbia.edu> Date: Sat, 04 Jan 2003 20:00:32 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Rosen, Brian'" , James.Hamlin@RNID.org.uk, sipping@ietf.org Subject: Re: [Sipping] Authentication issues with emergency and other serv ices References: <003601c2b420$0bbcc930$0c02a8c0@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Well, the problem is that you need to be able to trust that the PSAP URL > you've been given is a valid PSAP. That boils down to "so, where did you get > this PSAP URL from?" Once you HAVE a URL, pki can validate that the party > you end up talking to is the rightful holder of that URL. The problem is even worse in that I have no realistic way to determine whether I reached the right PSAP, leaving the PKI issues aside. The PSAP is determined (in the US) by the MSAG, the Master Street-Address Guide, which maps street locations to PSAPs (roughly speaking). Another database maps longitude/latitude to jurisdictions. As far as I know, this information is not public. (You have to pay a certain database company serious money to get it and be authorized.) In addition, PSAPs back up each other, so that you may end up at a different PSAP than last time you called for quite legitimate reasons. Thus, under the best of circumstances (with a special credential or a restricted domain), you might be able to tell that you have reached *a* PSAP among the 5,000 or so in the United States. Whether this is the correct PSAP can, at best, be guessed at. Plus, unlike in the typical case, where you send an INVITE to dean.will@softarmor.com and can expect to get a cert with the principal being that address, you'd dial 'sos@somewhere' or 'tel:911' and might get back something signed by 'agent17@admin.co.fayette.ga.us' (to pick a real-life example from http://www.admin.co.fayette.ga.us/communications/fayetteco911/). The SSL-style cert would be useful for the ERC (to use my draft terminology). Once it determines the correct PSAP SIP address, it can indeed verify that it got connected to it. In practice, this may be sufficient as long as you can trust the database. > > So let's separate the problem out. > > Where does the PSAP URL come from? > > Possibilities: > > 1) Something like DHCP. Well, this pushes the whole trust problem onto DHCP, > doesn't it? Although we SEEM ready to trust DHCP for everything else, > including assignment of DNS servers. This same model generalizes to the > "trusted introducer/configuratio nserver" problem. DHCP is unlikely. My understanding is that jurisdictional boundaries change, albeit infrequently, and PSAPs get split and reorganized. Thus, you probably don't want to update the DHCP server in each dentist's office and law practice when that happens. (It's not even clear how you'd notify them all.). Thus, you typically have companies like Intrado that provide these databases. (Intrado calls this the CRDB database, see http://www.intrado.com/main/offerings/intellivector/wireless/nineoneone/) > > 2) Something statically configured, perhaps "operator provisioned". This > would mean that the routing infrastructure would have to find you the > "right" PSAP among the many. Potentially, an interesting application of > nearest-anycast, or simply a design problem for an operator network. Might > work in a 3GPP-ish environment (where th P-CSCF can make local diversion > decisions), but how does it help the SIP-phone at my desk? As above. We have implemented a system that takes a street address, converts it to long/lat, feeds it to the database mentioned earlier and gets the PSAP. (Clearly, you'd cache the data for your desk SIP phone since there's little point in asking the same question again and again.) > > -- > Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Jan 5 22:44:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14961 for ; Sun, 5 Jan 2003 22:44:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h063sCw06974 for sipping-archive@odin.ietf.org; Sun, 5 Jan 2003 22:54:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063sCJ06971 for ; Sun, 5 Jan 2003 22:54:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14940 for ; Sun, 5 Jan 2003 22:43:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063nYJ06856; Sun, 5 Jan 2003 22:49:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063mpJ06820 for ; Sun, 5 Jan 2003 22:48:51 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14881 for ; Sun, 5 Jan 2003 22:38:18 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h063fSYH025550; Sun, 5 Jan 2003 22:41:28 -0500 (EST) Message-ID: <3E18FAE9.8040609@dynamicsoft.com> Date: Sun, 05 Jan 2003 22:41:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: William Marshall , Brian.Rosen@marconi.com, sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: <200212191500.KAA51775@fish.research.att.com> <3E165EC7.6090107@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > William Marshall wrote: > > >> 1) what is the effect of a BYE request generated by a UAC that is >> rejected by the UAS with a 4xx (e.g. 403-Forbidden)? Does the UA >> need to wait for the response to the BYE before tossing call state? >> Likewise, call-stateful proxies on the path? There is, of course, >> a denial-of-service threat here when a non-PSAP rejects a BYE. > > > Given the many ways that the caller can terminate a call, this seems > like a second-order problem. Can ISUP refuse a teardown request? What > happens in that case? SIP does in fact describe behavior here. According to Section 15.1.1: The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. Thus, rejecting the call will not achieve the "desired" effect. >> >> 2) what is the effect of a mid-call INVITE when the instrument is >> in an on-hook state? Is 180-Ringing an allowable response? > > > You mean for PSAP initiated call-back? This would be the same situation > as if I had sent a BYE and an INVITE crossed on the wire. It would > probably yield an invalid call-ID error. THis re-INVITE would appear to the UA as a new INVITE (not corresponding to an existing dialog) but with tags. Behavior in this case is also well specified in 3261. Section 13.3.1 bullet 3 covers this case, and it refers the reader to Section 12.2.2. That section says that, unless you are specifically re-creating old dialogs beacuse you are a conferencing server or something, then you should send a 481. > >> >> I believe both case are "under-specified" in rfc3261, so the needed >> behavior is allowed but not mandated. I think this is more than a BCP. It is most certainly not "under-specified". -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 00:23:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16563 for ; Mon, 6 Jan 2003 00:23:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h065XMi12017 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 00:33:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h065XLJ12014 for ; Mon, 6 Jan 2003 00:33:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16543 for ; Mon, 6 Jan 2003 00:22:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h065T4J11873; Mon, 6 Jan 2003 00:29:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h065RuJ11788 for ; Mon, 6 Jan 2003 00:27:56 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16472 for ; Mon, 6 Jan 2003 00:17:19 -0500 (EST) Received: from cisco.com (desh.cisco.com [192.122.173.43]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h065K0jS004004 for ; Sun, 5 Jan 2003 21:20:00 -0800 (PST) Received: from cisco.com ([10.77.138.78]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA18976 for ; Mon, 6 Jan 2003 10:50:11 +0530 (IST) Message-ID: <3E19121E.ACF487EA@cisco.com> Date: Mon, 06 Jan 2003 10:50:31 +0530 From: Sunderajan Selvaraj X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: "'sipping@ietf.org'" References: <475FF955A05DD411980D00508B6D5FB006FFB400@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] UNSUBSCRIBE Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Drage, Keith (Keith)" wrote: > Network asserted identity (RFC 3325) is the real network asserted identity. It is a P header not because it is preliminary, but because the whole idea of network assertion is not generally applicable to all SIP architectures. For RFC 3325 a trust domain needs to exist between proxies that use the P-Asserted-Identity in order to guarantee the privacy, this does not exist in all SIP networks. In does in 3GPP and therefore 3GPP are using RFC 3325. > > If you want to let the 1et outbound proxy assert identity on your behalf then use RFC 3325. If you want to let application servers with whom you have a secure relationship assert your identity, then use Jon Petersons drafts, when they eventually become RFCs. > > One is not a short term solution for the other. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 02 January 2003 20:49 > > To: 'Henning Schulzrinne' > > Cc: 'sipping@ietf.org' > > Subject: RE: [Sipping] URIs for Gateways > > > > > > Yeah, I actually thought of just allowing a display name in the > > Request URI and using that, but it seems so foolish to make a change, > > and have that change not be exactly what we needed. > > > > We could use NAI. I suppose we could use a P-Asserted-Identity > > with a tel URI: > > P-Asserted-Identity tel:+17247426826 > > > > What do we do when the "real" NAI happens? > > > > Brian > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Thursday, January 02, 2003 3:10 PM > > > To: Rosen, Brian > > > Cc: 'sipping@ietf.org' > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > > I'd like to get a new header for the calling party number on > > > > an outbound call. That way, the translator can be a proxy and > > > > add the header. I'd recommend that gateways allow the number > > > > to be in the From. > > > > > > Generalized, you want something like the Request-URI that can be > > > modified or inserted. How about the NAI stuff? > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 07:27:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02059 for ; Mon, 6 Jan 2003 07:27:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06CcAg13881 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 07:38:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06CcAJ13878 for ; Mon, 6 Jan 2003 07:38:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02052 for ; Mon, 6 Jan 2003 07:27:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06CYkJ13139; Mon, 6 Jan 2003 07:34:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06CX6J13068 for ; Mon, 6 Jan 2003 07:33:06 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01942 for ; Mon, 6 Jan 2003 07:22:21 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id ED3FE4CF9F; Mon, 6 Jan 2003 07:25:35 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id HAA04045; Mon, 6 Jan 2003 07:25:34 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id HAA06165; Mon, 6 Jan 2003 07:24:51 -0500 (EST) Date: Mon, 6 Jan 2003 07:24:51 -0500 (EST) Message-Id: <200301061224.HAA06165@fish.research.att.com> To: jdrosen@dynamicsoft.com Cc: sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Jonathan wrote: > It is most certainly not "under-specified". I'll conceed on the first point (a rejected BYE), but not yet on the second. Nowhere in RFC3261 does it state that if SIP is being used to control a 2500-style telehpone handset, and that handset goes to an "onhook" state with a session active, that the UA MUST send a BYE. If the UA does not, due e.g. to knowing that it just called a number such as 9-1-1, and the PSAP sends a mid-call INVITE with all the proper Route headers and Contact values and tags, it will certainly match the existing dialog at the UA, so will not be a new INVITE. So a 481 is not the proper response. Is 180-Ringing allowable? Bill Marshall wtm@research.att.com -----original message----- Date: Sun, 05 Jan 2003 22:41:29 -0500 From: Jonathan Rosenberg To: Henning Schulzrinne Cc: William Marshall , Brian.Rosen@marconi.com, sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft inline. Henning Schulzrinne wrote: > William Marshall wrote: > > >> 1) what is the effect of a BYE request generated by a UAC that is >> rejected by the UAS with a 4xx (e.g. 403-Forbidden)? Does the UA >> need to wait for the response to the BYE before tossing call state? >> Likewise, call-stateful proxies on the path? There is, of course, >> a denial-of-service threat here when a non-PSAP rejects a BYE. > > > Given the many ways that the caller can terminate a call, this seems > like a second-order problem. Can ISUP refuse a teardown request? What > happens in that case? SIP does in fact describe behavior here. According to Section 15.1.1: The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. Thus, rejecting the call will not achieve the "desired" effect. >> >> 2) what is the effect of a mid-call INVITE when the instrument is >> in an on-hook state? Is 180-Ringing an allowable response? > > > You mean for PSAP initiated call-back? This would be the same situation > as if I had sent a BYE and an INVITE crossed on the wire. It would > probably yield an invalid call-ID error. THis re-INVITE would appear to the UA as a new INVITE (not corresponding to an existing dialog) but with tags. Behavior in this case is also well specified in 3261. Section 13.3.1 bullet 3 covers this case, and it refers the reader to Section 12.2.2. That section says that, unless you are specifically re-creating old dialogs beacuse you are a conferencing server or something, then you should send a 481. > >> >> I believe both case are "under-specified" in rfc3261, so the needed >> behavior is allowed but not mandated. I think this is more than a BCP. It is most certainly not "under-specified". -Jonathan R. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 08:13:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02792 for ; Mon, 6 Jan 2003 08:13:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06DNo216121 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 08:23:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DNoJ16118 for ; Mon, 6 Jan 2003 08:23:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02773 for ; Mon, 6 Jan 2003 08:13:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DITJ15895; Mon, 6 Jan 2003 08:18:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DHFJ15848 for ; Mon, 6 Jan 2003 08:17:15 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02667 for ; Mon, 6 Jan 2003 08:06:30 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id CCCE01E0AF; Mon, 6 Jan 2003 08:09:43 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA04411; Mon, 6 Jan 2003 08:09:40 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA62581; Mon, 6 Jan 2003 08:08:42 -0500 (EST) Date: Mon, 6 Jan 2003 08:08:42 -0500 (EST) Message-Id: <200301061308.IAA62581@fish.research.att.com> To: hgs@cs.columbia.edu Cc: Brian.Rosen@marconi.com, sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Henning, Very good questions, and I really wish I had something citable as evidence of the current situation. I've been told that Bell South has written their own specifications for 9-1-1 service, and don't use the Bellcore ones. (but no citation). And I certainly agree that these "basic-9-1-1 features" won't work in an E911 system when the caller is not connected to the same class 5 switch as the PSAP. I believe all the NENA and Bellcore documents on E911 are consistent on this. The most solid piece of evidence that I have is that the packetcable signaling draft specification was rejected by the cable operators because it did not support PSAP-initiated constant-ring on an attempted hangup. At least one cable operator (unknown which one) insisted this was an absolute requirement in their service area. But since it was an anonymous veto, there is again no citation available. So we just deal with it (and a few lines of text added to the next rev of the proxy- proxy I-D defining an additional token to the P-DCS-OSPS header). I really do wish that I had a better answer for this one. > Given the many ways that the caller can terminate a call, this seems > like a second-order problem. Can ISUP refuse a teardown request? What > happens in that case? I agree that the technical situation borders on ludicrous, but the fact remains that CLEC-certification is essential and is not a technical issue. > Do cell phones support any of the features you describe? Keith can answer this one more completely, but I believe emergency calls on cell phones are not supported yet in IMS - that the cell phones are required to use the circuit-switch modes for 9-1-1 calls. As for non-3G phones, nothing prevents them being turned off, and (fortunately) nobody considers that a problem. Bill Marshall wtm@research.att.com -----original message----- Date: Fri, 03 Jan 2003 23:10:47 -0500 From: Henning Schulzrinne To: William Marshall Cc: Brian.Rosen@marconi.com, sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft William Marshall wrote: > One aspect of 'sos' calls that is rather annoying is that there > is no agreed standard for some details of the service. While > organizations such as NENA and ANSI write various documents, local > justidictions actually set the requirements as part of CLEC- > certification (important if you want to get blocks of phone numbers > from the NANP so PSTN subscribers can call your subscribers). > > Some jurisdictions require "called-party control" on 9-1-1 calls. Some > jurisdictions require PSAP-initiated constant-ring on an attempted hangup. > (I realize that SIP phones, like cell phones, are under the user's > control and can be disconnected or powered off and the real usefulness > of these requirements is dubious; but CLEC-certification is still useful). Since this comes up again and again, I've asked this question (a while ago) on the NENA mailing and nobody (that answered) was able to provide any indication that this is still true for E911 today. (It was true for the early 911 service where the PSAP was connected directly to the local switch.) It was claimed that modern ISDN switches don't provide this functionality, either. Maybe you're talking about non-North American jurisdictions? Do you have citable evidence on this requirement? Since the PSAP tandem and the caller switch may be several 'hops' apart, this capability would have to be part of ISUP. I looked at one of the Telcordia/Bellcore specs for 911 service and it doesn't mandate it, either. Since CLECs generally don't (like to) write their own switch software, I'd imagine that this would at least be a Bellcore requirement. I got the following two contradictory quotes, among others: "I can't speak for Call Transfer however Call Waiting and Three Way Calling are still available to the 9-1-1 caller. At least it is here in a DMS environment." "From my experience, most switches (5ESS, DMX-100, and GTD5EAX) disable custom calling features for the entire call when calling to N11 services in a manner similar to when they are establishing a call to another number. In other words, the switch deals with the 911 call like when you are listening to a ringing signal (i.e. no call waiting, no call transfer, no 3-way calling, etc.)." This only requires the originating switch to recognize N11, so that seems fairly easy in PSTN land. I suppose one could say that UAs should not use REFER. > > There is a basic design decision of whether it is all in the UA, and if > not, potentially a standardization issue. > > If the decision is that the UA doesn't really know when it calls an > emergence service (possibly due to the numerous ways to dial such a > service), then there are several areas that would need some agreement. This probably argues again for a global identifier. Some behavior, like call waiting, doesn't really apply in UAs. REFER issued by the UA to the PSAP is harmless. > > 1) what is the effect of a BYE request generated by a UAC that is > rejected by the UAS with a 4xx (e.g. 403-Forbidden)? Does the UA > need to wait for the response to the BYE before tossing call state? > Likewise, call-stateful proxies on the path? There is, of course, > a denial-of-service threat here when a non-PSAP rejects a BYE. Given the many ways that the caller can terminate a call, this seems like a second-order problem. Can ISUP refuse a teardown request? What happens in that case? This may be a simple UI issue. Since this is primarily a prevention of accidental disconnects, a UA might want to treat the 403 as a "Callee doesn't want to hang up. Do you really want to terminate the call?" (The rough equivalent of the corresponding Windows Ctrl-Alt-Del behavior...) > > 2) what is the effect of a mid-call INVITE when the instrument is > in an on-hook state? Is 180-Ringing an allowable response? You mean for PSAP initiated call-back? This would be the same situation as if I had sent a BYE and an INVITE crossed on the wire. It would probably yield an invalid call-ID error. > > I believe both case are "under-specified" in rfc3261, so the needed > behavior is allowed but not mandated. I think this is more than a BCP. Since these are corner-cases, it seems a bad idea to rely on specific UA behavior. Do cell phones support any of the features you describe? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 10:48:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05852 for ; Mon, 6 Jan 2003 10:47:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06FwHj25721 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 10:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FwGJ25718 for ; Mon, 6 Jan 2003 10:58:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05839 for ; Mon, 6 Jan 2003 10:47:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FsLJ25525; Mon, 6 Jan 2003 10:54:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FrhJ25446 for ; Mon, 6 Jan 2003 10:53:43 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05767 for ; Mon, 6 Jan 2003 10:42:55 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h06Fk7c07661 for ; Mon, 6 Jan 2003 10:46:08 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 15:46:06 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB7B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henning Schulzrinne'" , "Mills, Duncan, D, CND Tech Dev, VF UK" Cc: "Drage, Keith (Keith)" , sipping@ietf.org Subject: RE: [Sipping] Re: Comments on revised 'sos' draft Date: Mon, 6 Jan 2003 15:46:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , See below Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 04 January 2003 18:12 > To: Mills, Duncan, D, CND Tech Dev, VF UK > Cc: Drage, Keith (Keith); sipping@ietf.org > Subject: Re: [Sipping] Re: Comments on revised 'sos' draft > > > Mills, Duncan, D, CND Tech Dev, VF UK wrote: > > In section 5 of the draft - 'Request Routing': > > > > You talk about the need for a UA to be able to provide information > > about its location. You mention providing exact information such as > > longitude, latitude and altitude. You also mention possibilities of > > providing 'Agent-Circuit-ID' and 'Remote-ID', as per RFC 3046. > > > > Have you considered also mentioning the use of the > > p-access-network-info header for this purpose? (see > > draft-garcia-sipping-3gpp-p-headers-02 which is in the RFC editors > > queue). > > > > The p-access-network-info header enables you to specify an > > access-type and an access-info field in cases where the UA is aware > > of the access network. > > This seems potentially useful, but somewhat in the wrong > direction and > at the wrong layer. At least currently, the information > appears to be a > list of physical layers, as in > > "IEEE-802.11a" / "IEEE-802.11b" / > "3GPP-GERAN" / "3GPP-UTRAN-FDD" / > "3GPP-UTRAN-TDD" / > "3GPP-CDMA2000" > > and is provided by the UA. This type of information doesn't > seem to help > much in determining the local emergency number, a local > suitable gateway > or other emergency information. How would you envision extending this > information and how would the UA find out this information? The relevant parts of the information is (from the 3GPP P-headers i-d): cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string) utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL (token / quoted-string) The values for "cgi-3gpp" and "utran-cell-id-3gpp" are defined in 3GPP TS 24.229 [15]. 3GPP TS 24.229 then defines: If the access type field is equal to "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD" or "3GPP-CDMA2000" the access info field shall contain a value for "utran-cell-id-3gpp" parameter. This value shall be made up of a concatenation of the MCC, MNC, LAC (as described in 3GPP TS 23.003) and the UMTS Cell Identity (as described in 3GPP TS 25.331), obtained from lower layers of the UE, and is coded as a text string as follows: Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length code of 16 bits using full hexadecimal representation) and UMTS Cell Identity (fixed length code of 28 bits). A similar definition exists for the GERAN type of access. Other access mechanisms would be expected to make their own definitions of location information, as the structure of the data in this header is specific to the access mechanism, i.e. it has not been converted into a standard geodetic specification. > > > > > In 3GPP circles this helps (as Keith said) the outbound proxy to try > > and figure out if the 'dialled digits' are that of a local emergency > > centre or not... > > > > Best Regards, > > > > Duncan > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 10:59:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06025 for ; Mon, 6 Jan 2003 10:59:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06G9YD26863 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 11:09:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G9YJ26860 for ; Mon, 6 Jan 2003 11:09:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06017 for ; Mon, 6 Jan 2003 10:58:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G5OJ26054; Mon, 6 Jan 2003 11:05:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G41J26000 for ; Mon, 6 Jan 2003 11:04:01 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05920 for ; Mon, 6 Jan 2003 10:53:13 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h06FuPc12289 for ; Mon, 6 Jan 2003 10:56:25 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 15:56:24 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henning Schulzrinne'" , "'sipping@ietf.org'" Date: Mon, 6 Jan 2003 15:56:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Comments on sos draft -0 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Rather than reply to the other mails on this draft, I thought I should start from scratch on generating comments, although some of the comments below have some bearing on the discussions that are already taking place. Comments on draft-schulzrinne-sipping-sos-03 1) The document is missing an abstract which defines the scope. I am therefore unsure whether it is just a requirements document, or whether it is intended to be provide the total solution for emergency calls. My assumption is the latter, and therefore this ultimately will be the RFC that will register the sos and sos. urls, and will also define the actions of UAs and proxies in regard to emergency calls. However the latter presumably should be SIP actions, and should be in the SIP group. The following should therefore be done: - add an abstract detailing the scope of this specification - if the document is to define requirements for SIP UAs and proxies, then decide whether it should be a SIP group draft. 2) section 3 (Emergency URI). I think we should break down this section into 2. The first should detail requirements for SIP URLs and the second should deal with tel URLs. It seems to me that the requirements for these are somewhat different. For sip URLs we assume that designated URLs are always emergency calls, and send them to the local emergency centre. For tel URLs, we have the additional problem of determining whether the related telephony number is an emergency local service number, and this issue requires considerable discussion in its own right, see later comments. Perhaps we also need to take a step further back, and start with the user input itself. Perhaps we need a requirement that "UAs that determine that a dialog or transaction relates to an emergency MUST use an emergency call identifier in the Request-URI". Such a requirement would relate to where the user pushes the big red emergency button, and also to where input key sequences are analysed against a list of emergency related key sequences. 3) section 3 (Emergency URI), last paragraph, text: 'The "sos" user name and user names starting with "sos." MUST NOT be assigned to any regular user.' I assume this a requirement relating specificly to SIP URLs, and is not a general URL requirement. It would be desirable to state this explicitly. 4) section 3 (Emergency URI), last paragraph, text: 'It is RECOMMENDED that SIP MESSAGE requests are directed....' is presumably a requirement that must be taken in the context of section 4, i.e. it applies to all UAs and all proxies. It would be better specified in clause 4, and its applicability should be made clear. Further "SIP messaging" should presumably be "instant messaging" which is I believe the terminology used in the SIP MESSAGE RFC. 5) section 3 (Emergency URI), 3rd paragraph: "In addition, user agents and proxies SHOULD also recognise the telephone numbers 911 and 112 ...". The 3GPP specification (3GPP TS 22.101) makes a somewhat longer list of numbers that should be applied. The following two sentences apply: - "The following emergency numbers shall be stored in the ME for use when no emergency numbers are stored in the SIM/USIM: 000, 08, 112, 110, 911 and 999. " - "The following emergency numbers shall be stored in the ME for use without SIM/USIM: 000, 08, 112, 110, 118, 119, 911 and 999." Given that the above lists work for all existing GSM phones in the countries of the world where GSM is used, which is most, it would seem sensible to use those lists rather than come up with a new IETF specific list. As to which list should be used, perhaps in fact the answer is both. The first list should apply where there is an additional number list in the SIP phone that is dynamically configurable by some external entity, and the second when there is not. More on these requirements in other comments. 6) section 3 (Emergency URI), 3rd paragraph: use of "phone-context". Is it appropriate to use phone context in any emergency call. In 3GPP, any use of one of the numbers from the list stored in the phone is an emergency call, no matter where it originates from. If my understanding of phone-context is correct, it SHOULD NOT be used, as it could result in failure to deliver an emergency call. 7) Section 4 (Request handling). There are mentions of "sos.*" in this text. Is the intent that "sos.*" should be a valid SIP URL with appropriate emergency call handling, or is it being used as a shorthand in this document to refer to those defined in section 3, and as such would not appear in a Request-URI? 8) Section 4 (Request handling), text: "It is RECOMMENDED that user agents periodically automatically check for the availability....". I consider that the use of this may be unnecessary in all cases. If the phone can be loaded with emergency numbers dynamically, and the update of those numbers is of reasonable frequency, then there is no need to regularly perform the OPTIONS request. For this reason, it would appear to be unnecessary for 3GPP phones. 9) Section 4 (Request handling): There seems to be an assumption that a local emergency number, e.g. 911 is more routeable in a network of SIP proxies than a sos URL. Surely this is a matter of local policy. Surely it is possible that the emergency call is entirely routed as a sos URL. Surely the main requirement is that the owner of the first proxy reached is responsible for routing it to an emergency call centre, and it is a matter of local policy how that is done. 10) Section 4 (Request handling): Further the text should acknowledge that where a SIP outbound proxy exists then that can also perform such analysis of keyed numbers. Mechanisms for establishing an outbound proxy at registration time are standards track items. 3GPP accompanies all requests with the Mobile Country Code and the Mobile Network Code to assist in this analysis (where the analysis has failed at the phone). Some text for this is currently stated in section 3, but section 3 is the wrong place for this information. 11) Section 5 (Request routing): I believe the text should acknowledge that at least some phones will have the capability of storing dynamically emergency numbers for use in analysing calls made with telephony type user input. 3GPP SIP phones will carry this requirement, and any SIP phone that uses some SIM like technology to carry subscription information is capable of being programmed at subscription time (i.e. delivery of the SIM to the subscriber) to carry the appropriate emergency numbers. It is becoming clear from the discussion that no one method is appropriate for doing this, but I believe there should be a discussion of the mechanisms that do exist, and any future SIP extensions should take account of that. Clause 5 should not be specific to the one mechanism that is specified here; for example 3GPP will use another mechanism and not one based on DHCP. 12) If this draft is creating the sos URLs, should it not have an IANA considerations section telling IANA to register these URLs. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 14:08:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10778 for ; Mon, 6 Jan 2003 14:08:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06JImL06669 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 14:18:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JImJ06663 for ; Mon, 6 Jan 2003 14:18:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10752 for ; Mon, 6 Jan 2003 14:07:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JCQJ06494; Mon, 6 Jan 2003 14:12:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JBmJ06457 for ; Mon, 6 Jan 2003 14:11:48 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10518 for ; Mon, 6 Jan 2003 14:00:55 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h06J3g813457; Mon, 6 Jan 2003 19:03:42 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 14:06:01 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB4DB@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Drage, Keith (Keith)'" , "Rosen, Brian" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Mon, 6 Jan 2003 14:05:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , RFC3325 was 'short-term' because it was achievable in the short-term and has a more limited (but still useful) applicability. The long-term identity solution must be a superset of the functionality of short-term - it must address the short-term scope of applicability, but also encompass general needs for network assertion (which SIP does have). Accordingly, it takes longer to develop. At such a time as there is a workable long-term solution, it would be pointless to allow both to be SIP standards except as part of a transition plan. So in that sense, I disagree - one is a short-term solution of the other. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, January 03, 2003 8:20 AM > To: Rosen, Brian; 'Henning Schulzrinne' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > Network asserted identity (RFC 3325) is the real network > asserted identity. It is a P header not because it is > preliminary, but because the whole idea of network assertion > is not generally applicable to all SIP architectures. For RFC > 3325 a trust domain needs to exist between proxies that use > the P-Asserted-Identity in order to guarantee the privacy, > this does not exist in all SIP networks. In does in 3GPP and > therefore 3GPP are using RFC 3325. > > If you want to let the 1et outbound proxy assert identity on > your behalf then use RFC 3325. If you want to let application > servers with whom you have a secure relationship assert your > identity, then use Jon Petersons drafts, when they eventually > become RFCs. > > One is not a short term solution for the other. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: 02 January 2003 20:49 > > To: 'Henning Schulzrinne' > > Cc: 'sipping@ietf.org' > > Subject: RE: [Sipping] URIs for Gateways > > > > > > Yeah, I actually thought of just allowing a display name in the > > Request URI and using that, but it seems so foolish to make > a change, > > and have that change not be exactly what we needed. > > > > We could use NAI. I suppose we could use a P-Asserted-Identity > > with a tel URI: > > P-Asserted-Identity tel:+17247426826 > > > > What do we do when the "real" NAI happens? > > > > Brian > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Thursday, January 02, 2003 3:10 PM > > > To: Rosen, Brian > > > Cc: 'sipping@ietf.org' > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > > I'd like to get a new header for the calling party number on > > > > an outbound call. That way, the translator can be a proxy and > > > > add the header. I'd recommend that gateways allow the number > > > > to be in the From. > > > > > > Generalized, you want something like the Request-URI that can be > > > modified or inserted. How about the NAI stuff? > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 14:35:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11882 for ; Mon, 6 Jan 2003 14:35:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06JjjA08754 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 14:45:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JjiJ08751 for ; Mon, 6 Jan 2003 14:45:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11847 for ; Mon, 6 Jan 2003 14:34:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JVQJ07398; Mon, 6 Jan 2003 14:31:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JUKJ07323 for ; Mon, 6 Jan 2003 14:30:20 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11238 for ; Mon, 6 Jan 2003 14:19:28 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h06JMdJE017331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Jan 2003 14:22:40 -0500 (EST) Message-ID: <3E19D7A1.3060901@cs.columbia.edu> Date: Mon, 06 Jan 2003 14:23:13 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "Mills, Duncan, D, CND Tech Dev, VF UK" , sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: <475FF955A05DD411980D00508B6D5FB00439EB7B@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB7B@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The relevant parts of the information is (from the 3GPP P-headers i-d): > > cgi-3gpp = "cgi-3gpp" EQUAL > (token / quoted-string) > utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL > (token / quoted-string) > > The values for "cgi-3gpp" and "utran-cell-id-3gpp" > are defined in 3GPP TS 24.229 [15]. > > 3GPP TS 24.229 then defines: > > If the access type field is equal to "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD" or "3GPP-CDMA2000" the access info field shall contain a value for "utran-cell-id-3gpp" parameter. This value shall be made up of a concatenation of the MCC, MNC, LAC (as described in 3GPP TS 23.003) and the UMTS Cell Identity (as described in 3GPP TS 25.331), obtained from lower layers of the UE, and is coded as a text string as follows: > Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length code of 16 bits using full hexadecimal representation) and UMTS Cell Identity (fixed length code of 28 bits). > > A similar definition exists for the GERAN type of access. > > Other access mechanisms would be expected to make their own definitions of location information, as the structure of the data in this header is specific to the access mechanism, i.e. it has not been converted into a standard geodetic specification. > I've added a reference to this. I suppose for an 802.11 wireless base station, the basestation MAC address would be the equivalent. Any interest in defining this, given that the draft already lists IEEE-802.11a and IEEE-802.11b as access-types? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 15:10:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13489 for ; Mon, 6 Jan 2003 15:10:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06KKRp11241 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 15:20:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KKQJ11237 for ; Mon, 6 Jan 2003 15:20:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13475 for ; Mon, 6 Jan 2003 15:09:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KHNJ11049; Mon, 6 Jan 2003 15:17:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KDGJ10883 for ; Mon, 6 Jan 2003 15:13:16 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13260 for ; Mon, 6 Jan 2003 15:02:24 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h06K5bK5018011 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Jan 2003 15:05:37 -0500 (EST) Message-ID: <3E19E1B3.5010205@cs.columbia.edu> Date: Mon, 06 Jan 2003 15:06:11 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Comments on sos draft -0 (scope) References: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Rather than reply to the other mails on this draft, I thought I > should start from scratch on generating comments, although some of > the comments below have some bearing on the discussions that are > already taking place. > > Comments on draft-schulzrinne-sipping-sos-03 Thanks for your extensive comments. Responses inline, where needed. I've split my response to keep it to a length that others may still read... > > 1) The document is missing an abstract which defines the scope. I am > therefore unsure whether it is just a requirements document, or > whether it is intended to be provide the total solution for emergency > calls. My assumption is the latter, and therefore this ultimately > will be the RFC that will register the sos and sos. urls, and will > also define the actions of UAs and proxies in regard to emergency > calls. However the latter presumably should be SIP actions, and > should be in the SIP group. The following should therefore be done: > > - add an abstract detailing the scope of this specification - if the > document is to define requirements for SIP UAs and proxies, then > decide whether it should be a SIP group draft. Abstract updated as: This document describes how SIP user agents and proxies can set up emergency calls and, more generally, reach emergency assistance via SIP requests. For that purpose, it defines a universal emergency SIP URI, sip:sos@domain and sips:sos@domain, that allows SIP user agents to contact the local emergency number. It also defines conventions that increase the high probability of reaching the appropriate emergency call center. The document does not define any SIP protocol extensions. Except for a reserved-name, the spec does not modify or extend SIP protocol behavior (that's the point). Thus, I don't think this requires SIP WG action. I believe this activity falls under WG charter item 2: "2. Documenting the usage of SIP to solve real problems that need to be solved in a standardized way." _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 16:00:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14659 for ; Mon, 6 Jan 2003 16:00:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06LB5A14596 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 16:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LB5J14593 for ; Mon, 6 Jan 2003 16:11:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14655 for ; Mon, 6 Jan 2003 16:00:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KpAJ13255; Mon, 6 Jan 2003 15:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KmnJ13148 for ; Mon, 6 Jan 2003 15:48:49 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14199 for ; Mon, 6 Jan 2003 15:37:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h06KfCYH026152; Mon, 6 Jan 2003 15:41:12 -0500 (EST) Message-ID: <3E19E9E5.3060002@dynamicsoft.com> Date: Mon, 06 Jan 2003 15:41:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Marshall CC: sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: <200301061224.HAA06165@fish.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit William Marshall wrote: > Jonathan wrote: > >>It is most certainly not "under-specified". > > > I'll conceed on the first point (a rejected BYE), but not yet on the second. > > Nowhere in RFC3261 does it state that if SIP is being used to control > a 2500-style telehpone handset, and that handset goes to an "onhook" > state with a session active, that the UA MUST send a BYE. Of course. My point was that if it DID send a BYE, the behavior would be to send a 481. > > If the UA does not, due e.g. to knowing that it just called a number > such as 9-1-1, and the PSAP sends a mid-call INVITE with all the > proper Route headers and Contact values and tags, it will certainly > match the existing dialog at the UA, so will not be a new INVITE. > So a 481 is not the proper response. Is 180-Ringing allowable? Sure, the UAS can send a 180. Whether the UA would "alert" the user when receiving a re-INVITE is a matter of UI, and not subject to specification. The intent of the re-INVITE is standardized, though - to modify session characteristics. Thus a UA would decide whether to alert the user based on this definition. It would not be correct to interpret the re-INVITE as specifically for the purposes of PSAP initiated ring, however. -JOnathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 16:25:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15263 for ; Mon, 6 Jan 2003 16:25:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06LaDK15603 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 16:36:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LaDJ15600 for ; Mon, 6 Jan 2003 16:36:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15237 for ; Mon, 6 Jan 2003 16:25:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LXKJ15466; Mon, 6 Jan 2003 16:33:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LTUJ15310 for ; Mon, 6 Jan 2003 16:29:30 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15080 for ; Mon, 6 Jan 2003 16:18:35 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27682; Mon, 6 Jan 2003 16:21:48 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25227; Mon, 6 Jan 2003 16:21:49 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Jan 2003 16:21:48 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CC4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , "'Drage, Keith (Keith)'" , "Rosen, Brian" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Mon, 6 Jan 2003 16:21:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I agree with this. I'm confused by those who seem to think that P-Asserted-Identity is needed when the long term solution is fully baked. If the UA knows its identity, which seems reasonable, then it can "assert" it, and have that assertion validated by a trusted entity using cryptographic means. That is the fundamental idea I get out of Jon's proposal. The only circumstance where that won't work is where the UA doesn't know its identity. I don't see that as a problem on any network I'm aware of, but ...... keep reading. I do think there is a problem which this whole thread talks about. The basic reality is that many users of SIP UAs will have two identities - a SIP URI and a telephone number. It may be necessary to assert both identities in one call, because the originator of the call does not know which identity may be needed. There is no current header to do this. I think that it is advantageous to have a proxy be able to assert the phone number. Otherwise EVERY UA will have to be able to understand that two identities are possible, know them both by some unspecified means, and assert them in every call on every UA. This seems unreasonable. I'm not sure that there is a reason to have both identities validated, but there could be. Brian > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Monday, January 06, 2003 2:06 PM > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > > RFC3325 was 'short-term' because it was achievable in the > short-term and has > a more limited (but still useful) applicability. The > long-term identity > solution must be a superset of the functionality of > short-term - it must > address the short-term scope of applicability, but also > encompass general > needs for network assertion (which SIP does have). > Accordingly, it takes > longer to develop. At such a time as there is a workable > long-term solution, > it would be pointless to allow both to be SIP standards > except as part of a > transition plan. So in that sense, I disagree - one is a > short-term solution > of the other. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Friday, January 03, 2003 8:20 AM > > To: Rosen, Brian; 'Henning Schulzrinne' > > Cc: 'sipping@ietf.org' > > Subject: RE: [Sipping] URIs for Gateways > > > > > > Network asserted identity (RFC 3325) is the real network > > asserted identity. It is a P header not because it is > > preliminary, but because the whole idea of network assertion > > is not generally applicable to all SIP architectures. For RFC > > 3325 a trust domain needs to exist between proxies that use > > the P-Asserted-Identity in order to guarantee the privacy, > > this does not exist in all SIP networks. In does in 3GPP and > > therefore 3GPP are using RFC 3325. > > > > If you want to let the 1et outbound proxy assert identity on > > your behalf then use RFC 3325. If you want to let application > > servers with whom you have a secure relationship assert your > > identity, then use Jon Petersons drafts, when they eventually > > become RFCs. > > > > One is not a short term solution for the other. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: 02 January 2003 20:49 > > > To: 'Henning Schulzrinne' > > > Cc: 'sipping@ietf.org' > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > Yeah, I actually thought of just allowing a display name in the > > > Request URI and using that, but it seems so foolish to make > > a change, > > > and have that change not be exactly what we needed. > > > > > > We could use NAI. I suppose we could use a P-Asserted-Identity > > > with a tel URI: > > > P-Asserted-Identity tel:+17247426826 > > > > > > What do we do when the "real" NAI happens? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > Sent: Thursday, January 02, 2003 3:10 PM > > > > To: Rosen, Brian > > > > Cc: 'sipping@ietf.org' > > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > > > > > I'd like to get a new header for the calling party number on > > > > > an outbound call. That way, the translator can be a proxy and > > > > > add the header. I'd recommend that gateways allow the number > > > > > to be in the From. > > > > > > > > Generalized, you want something like the Request-URI > that can be > > > > modified or inserted. How about the NAI stuff? > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 17:15:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17143 for ; Mon, 6 Jan 2003 17:15:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06MPZc20456 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 17:25:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MPZJ20453 for ; Mon, 6 Jan 2003 17:25:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17139 for ; Mon, 6 Jan 2003 17:14:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MMSJ20242; Mon, 6 Jan 2003 17:22:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MJHJ19882 for ; Mon, 6 Jan 2003 17:19:17 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16844 for ; Mon, 6 Jan 2003 17:08:21 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h06MCAos001291; Mon, 6 Jan 2003 17:12:10 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX42166; Mon, 6 Jan 2003 17:16:31 -0500 (EST) Message-ID: <3E19FF11.5000806@cisco.com> Date: Mon, 06 Jan 2003 17:11:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: William Marshall , sipping@ietf.org Subject: Re: [Sipping] Re: Comments on revised 'sos' draft References: <200301061224.HAA06165@fish.research.att.com> <3E19E9E5.3060002@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >> If the UA does not, due e.g. to knowing that it just called a number >> such as 9-1-1, and the PSAP sends a mid-call INVITE with all the >> proper Route headers and Contact values and tags, it will certainly >> match the existing dialog at the UA, so will not be a new INVITE. >> So a 481 is not the proper response. Is 180-Ringing allowable? > > > Sure, the UAS can send a 180. Whether the UA would "alert" the user when > receiving a re-INVITE is a matter of UI, and not subject to > specification. The intent of the re-INVITE is standardized, though - to > modify session characteristics. Thus a UA would decide whether to alert > the user based on this definition. It would not be correct to interpret > the re-INVITE as specifically for the purposes of PSAP initiated ring, > however. While there is probably nothing wrong with returning a 180 in this case, I believe there is something wrong with then actually ringing the phone and waiting for it to to go off hook before sending a final response. The reason is that this is a reINVITE. There has been a bunch of discussion of call flows involving reinvite, and the need for it to complete without an extended delay. Perhaps that decision could be reopened now. I have some other cases where it is desirable to permit alerting, with the associated delay, on a reinvite. But it will be messy to reopen that can of worms. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 18:14:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18354 for ; Mon, 6 Jan 2003 18:14:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06NOQH23786 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 18:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NOQJ23783 for ; Mon, 6 Jan 2003 18:24:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18335 for ; Mon, 6 Jan 2003 18:13:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NLTJ23670; Mon, 6 Jan 2003 18:21:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NILJ23559 for ; Mon, 6 Jan 2003 18:18:21 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18260 for ; Mon, 6 Jan 2003 18:07:23 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h06NAbJE013511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Jan 2003 18:10:38 -0500 (EST) Message-ID: <3E1A0D0F.3090505@cs.columbia.edu> Date: Mon, 06 Jan 2003 18:11:11 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB7C@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > 5) section 3 (Emergency URI), 3rd paragraph: "In addition, user > two sentences apply: - "The following emergency numbers shall be > stored in the ME for use when no emergency numbers are stored in the > SIM/USIM: 000, 08, 112, 110, 911 and 999. " - "The following Good idea. The only difference seems to be 118 and 119. > 6) section 3 (Emergency URI), 3rd paragraph: use of "phone-context". > Is it appropriate to use phone context in any emergency call. In > 3GPP, any use of one of the numbers from the list stored in the phone > is an emergency call, no matter where it originates from. If my > understanding of phone-context is correct, it SHOULD NOT be used, as > it could result in failure to deliver an emergency call. > I wrote this before the most recent phone-context discussion and I tend to agree. If there's to be a phone context at all, it would need to be something like 'sos' or some other recognized identifier. The problem occurs with 118 and 119, which presumably are omitted from the shorter list since they mean something other than emergency somewhere. (Apparently, 118 is directory assistance in the UK; 119 is fire in Japan.) The outbound proxy doesn't know whether the phone was configured with a local list or not, so it needs to be able to tell whether tel:118 is emergency or something else. One simple, pragmatic rule would be that numbers from the longer list without context always mean emergency. > 8) Section 4 (Request handling), text: "It is RECOMMENDED that user > agents periodically automatically check for the availability....". I > consider that the use of this may be unnecessary in all cases. If the > phone can be loaded with emergency numbers dynamically, and the > update of those numbers is of reasonable frequency, then there is no > need to regularly perform the OPTIONS request. For this reason, it > would appear to be unnecessary for 3GPP phones. The problem is that I can't rely on a local friendly outbound proxy that knows how to handle either sip:sos or tel:XXX. You can mandate this for 3GPP providers, but not all VoIP systems will be run by common carriers. I'm reluctant to encode 'I'm a 3GPP phone, so I don't need to do this' into the protocol. After all, this 3GPP phone may also use your friendly neighborhood 802.11 hotspot. > > 9) Section 4 (Request handling): There seems to be an assumption that > a local emergency number, e.g. 911 is more routeable in a network of > SIP proxies than a sos URL. Surely this is a matter of local policy. > Surely it is possible that the emergency call is entirely routed as a > sos URL. Surely the main requirement is that the owner of the first > proxy reached is responsible for routing it to an emergency call > centre, and it is a matter of local policy how that is done. This wasn't the intent. I'll reword. > > 10) Section 4 (Request handling): Further the text should acknowledge > that where a SIP outbound proxy exists then that can also perform > such analysis of keyed numbers. Mechanisms for establishing an > outbound proxy at registration time are standards track items. 3GPP > accompanies all requests with the Mobile Country Code and the Mobile > Network Code to assist in this analysis (where the analysis has > failed at the phone). Some text for this is currently stated in > section 3, but section 3 is the wrong place for this information. Moved and reworded. > 12) If this draft is creating the sos URLs, should it not have an > IANA considerations section telling IANA to register these URLs. There will be a section on registering additional sos.* services. There currently is no registry for reserved SIP user identities and tel URIs. Should there be? Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 6 21:17:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21623 for ; Mon, 6 Jan 2003 21:17:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h072Ra202374 for sipping-archive@odin.ietf.org; Mon, 6 Jan 2003 21:27:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h072RaJ02371 for ; Mon, 6 Jan 2003 21:27:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21575 for ; Mon, 6 Jan 2003 21:13:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h072M1J02251; Mon, 6 Jan 2003 21:22:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h072KYJ02202 for ; Mon, 6 Jan 2003 21:20:34 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21542 for ; Mon, 6 Jan 2003 21:09:34 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h072Cmkw019502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 6 Jan 2003 21:12:48 -0500 (EST) Message-ID: <3E1A37C0.5050104@cs.columbia.edu> Date: Mon, 06 Jan 2003 21:13:20 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'sipping@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] New -sos- draft (04) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-sos-04.txt will be submitted shortly, hopefully reflecting the comments received. Additional comments are most welcome. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 02:51:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06358 for ; Tue, 7 Jan 2003 02:51:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07828131741 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 03:02:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07827J31738 for ; Tue, 7 Jan 2003 03:02:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06352 for ; Tue, 7 Jan 2003 02:51:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h077ujJ31430; Tue, 7 Jan 2003 02:56:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h077tHJ31373 for ; Tue, 7 Jan 2003 02:55:17 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06265 for ; Tue, 7 Jan 2003 02:44:10 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18VoSB-0000Bv-00; Tue, 07 Jan 2003 09:47:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15898.34306.984596.183022@harjus.eng.song.fi> Date: Tue, 7 Jan 2003 09:47:14 +0200 To: "Rosen, Brian" Cc: "'Peterson, Jon'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CC4@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF030B5CC4@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian writes: > I do think there is a problem which this whole thread talks about. > The basic reality is that many users of SIP UAs will have two > identities - a SIP URI and a telephone number. It may be > necessary to assert both identities in one call, because the > originator of the call does not know which identity may be > needed. There is no current header to do this. I think that > it is advantageous to have a proxy be able to assert the phone > number. Otherwise EVERY UA will have to be able to understand > that two identities are possible, know them both by some > unspecified means, and assert them in every call on every UA. > This seems unreasonable. I'm not sure that there is a reason > to have both identities validated, but there could be. if your proxy receives a call from sip:foo@bar.com who has also been allocated a phone number +1234567890, why can't is add an asserted identity header containing sip:+1234567890@bar.com to the call in case the call is bound to pstn? why would you need yet another header for that purpose? -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 06:40:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10097 for ; Tue, 7 Jan 2003 06:40:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07Botn13513 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 06:50:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07BotJ13510 for ; Tue, 7 Jan 2003 06:50:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10083 for ; Tue, 7 Jan 2003 06:39:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07BgZJ13102; Tue, 7 Jan 2003 06:42:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Bf6J12949 for ; Tue, 7 Jan 2003 06:41:06 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09875 for ; Tue, 7 Jan 2003 06:29:53 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h07BWw825862; Tue, 7 Jan 2003 11:32:58 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 06:35:18 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB4E6@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Rosen, Brian'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Tue, 7 Jan 2003 06:35:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , First, it is possible, with the long-term identity mechanism, to assert two identities in an authenticated identity body. So, you could have headers corresponding to a telephone number and a SIP URI of a gateway or a user - it strikes me that a telephone number is a good Reply-To, actually, when a call comes from a gateway (originating in the PSTN, say) and the From header field contains a SIP URI for the gateway, perhaps including some port information. The identity that the gateway which handles a PSTN-SIP call would assert needs to be its own, and recipients of calls from gateways need to trust the telephone number provided by the gateway or not accordingly (i.e. a signature from att.com vouching for such a request should be acceptable). Technologies like ENUM (when/where available) could enable gateways to convert originating telephone numbers into URIs. Of course, a gateway wouldn't be able to assert that identity to an intermediary unless it possessed credentials appropriate to that URI, which is unlikely. For outbound calls (SIP-PSTN), the gateway may or may not be able to map (authenticated) SIP URIs representing originators to appropriate telephone numbers via some sort of local tables as you suggested. If not, might also pick a number from a pool, sure. The question of whether some authentication service should be able to assert an originating telephone number (in an authenticated identity body, say) that a gateway will use is also a trust question - it is possible to put the tel URL in the AIB. If the gateway has a reason to trust the authentication service, then certainly it should send that number to the PSTN (when the protocol allows gateways to supply a number, like with ISUP or Q.931). The gateway would be very ill advised to take just any authentication service's word on this matter, though. The target of the calls for the PSTN should be identified with a telephone number - at least, by the time the call arrives a gateway, it's Request-URI should contain a tel URL or a SIP URI with a tel URL component. Whether the originating UAC sets the To header field to a tel URL or a subsequent proxy retargets the request doesn't seem to make much difference. ENUM can also play a pretty obvious role here. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, January 06, 2003 1:22 PM > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning > Schulzrinne' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > I agree with this. I'm confused by those who seem to think that > P-Asserted-Identity is needed when the long term solution is > fully baked. If the UA knows its identity, which seems > reasonable, then it can "assert" it, and have that assertion > validated by a trusted entity using cryptographic means. > That is the fundamental idea I get out of Jon's proposal. > The only circumstance where that won't work is where the > UA doesn't know its identity. I don't see that as a problem > on any network I'm aware of, but ...... keep reading. > > I do think there is a problem which this whole thread talks about. > The basic reality is that many users of SIP UAs will have two > identities - a SIP URI and a telephone number. It may be > necessary to assert both identities in one call, because the > originator of the call does not know which identity may be > needed. There is no current header to do this. I think that > it is advantageous to have a proxy be able to assert the phone > number. Otherwise EVERY UA will have to be able to understand > that two identities are possible, know them both by some > unspecified means, and assert them in every call on every UA. > This seems unreasonable. I'm not sure that there is a reason > to have both identities validated, but there could be. > > Brian > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Monday, January 06, 2003 2:06 PM > > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne' > > Cc: 'sipping@ietf.org' > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > RFC3325 was 'short-term' because it was achievable in the > > short-term and has > > a more limited (but still useful) applicability. The > > long-term identity > > solution must be a superset of the functionality of > > short-term - it must > > address the short-term scope of applicability, but also > > encompass general > > needs for network assertion (which SIP does have). > > Accordingly, it takes > > longer to develop. At such a time as there is a workable > > long-term solution, > > it would be pointless to allow both to be SIP standards > > except as part of a > > transition plan. So in that sense, I disagree - one is a > > short-term solution > > of the other. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Friday, January 03, 2003 8:20 AM > > > To: Rosen, Brian; 'Henning Schulzrinne' > > > Cc: 'sipping@ietf.org' > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > Network asserted identity (RFC 3325) is the real network > > > asserted identity. It is a P header not because it is > > > preliminary, but because the whole idea of network assertion > > > is not generally applicable to all SIP architectures. For RFC > > > 3325 a trust domain needs to exist between proxies that use > > > the P-Asserted-Identity in order to guarantee the privacy, > > > this does not exist in all SIP networks. In does in 3GPP and > > > therefore 3GPP are using RFC 3325. > > > > > > If you want to let the 1et outbound proxy assert identity on > > > your behalf then use RFC 3325. If you want to let application > > > servers with whom you have a secure relationship assert your > > > identity, then use Jon Petersons drafts, when they eventually > > > become RFCs. > > > > > > One is not a short term solution for the other. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: 02 January 2003 20:49 > > > > To: 'Henning Schulzrinne' > > > > Cc: 'sipping@ietf.org' > > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > Yeah, I actually thought of just allowing a display name in the > > > > Request URI and using that, but it seems so foolish to make > > > a change, > > > > and have that change not be exactly what we needed. > > > > > > > > We could use NAI. I suppose we could use a P-Asserted-Identity > > > > with a tel URI: > > > > P-Asserted-Identity tel:+17247426826 > > > > > > > > What do we do when the "real" NAI happens? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > Sent: Thursday, January 02, 2003 3:10 PM > > > > > To: Rosen, Brian > > > > > Cc: 'sipping@ietf.org' > > > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > > I'd like to get a new header for the calling party number on > > > > > > an outbound call. That way, the translator can be > a proxy and > > > > > > add the header. I'd recommend that gateways allow > the number > > > > > > to be in the From. > > > > > > > > > > Generalized, you want something like the Request-URI > > that can be > > > > > modified or inserted. How about the NAI stuff? > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 06:49:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10286 for ; Tue, 7 Jan 2003 06:49:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07C05h13861 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 07:00:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07C04J13858 for ; Tue, 7 Jan 2003 07:00:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10259 for ; Tue, 7 Jan 2003 06:48:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Bq7J13613; Tue, 7 Jan 2003 06:52:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07BpBJ13541 for ; Tue, 7 Jan 2003 06:51:11 -0500 Received: from relay4.clb.oleane.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10091 for ; Tue, 7 Jan 2003 06:39:58 -0500 (EST) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay4.clb.oleane.net with SMTP id h07BhCDh031150 for ; Tue, 7 Jan 2003 12:43:13 +0100 Message-ID: <01f301c2b643$343137a0$0601a8c0@oleane.com> From: "Peter Lewis" To: Date: Tue, 7 Jan 2003 12:52:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F0_01C2B64B.95AADB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Sipping] The International SIP 2003 Conference Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_01F0_01C2B64B.95AADB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Happy New Year and all the best for you and your family!=20 The International SIP 2003 Conference is going to take place in Paris in = one week, from the=20 14th to the 17th of January 03.=20 You can still register for the conference at: = http://www.upperside.fr/intersip03/sip03earlyreg.htm=20 ------=_NextPart_000_01F0_01C2B64B.95AADB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Happy New Year and all the best for you = and your=20 family!

The International SIP 2003=20 Conference is going to take place in Paris in one week, from = the=20
14th to the 17th of January 03.

You can still = register for=20 the conference at: http://www.= upperside.fr/intersip03/sip03earlyreg.htm=20
 
------=_NextPart_000_01F0_01C2B64B.95AADB00-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 08:37:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12679 for ; Tue, 7 Jan 2003 08:37:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07Dme720514 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 08:48:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DmeJ20511 for ; Tue, 7 Jan 2003 08:48:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12671 for ; Tue, 7 Jan 2003 08:37:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DfjJ20208; Tue, 7 Jan 2003 08:41:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07De5J20093 for ; Tue, 7 Jan 2003 08:40:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12023; Tue, 7 Jan 2003 08:28:50 -0500 (EST) Message-Id: <200301071328.IAA12023@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 Jan 2003 08:28:49 -0500 Subject: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-req-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Session Policy for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-rosenberg-sipping-session-policy-req-00.txt Pages : 15 Date : 2003-1-6 The proxy server plays a central role as an intermediary in the establishment of sessions in the Session Initiation Protocol (SIP). In that role, they can define and impact policies on call routing, rendezvous, and other call features. However, there is no standard means by which proxies can have any influence on session policies, such as the codecs that are to be used. As such, ad-hoc and non-conformant techniques have been deployed to allow for such policy mechanisms. There is a need for a standards-based and complete mechanism for session policies. This document defines a set of requirements for such a mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-req-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sipping-session-policy-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sipping-session-policy-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6145302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sipping-session-policy-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sipping-session-policy-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145302.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 08:50:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13670 for ; Tue, 7 Jan 2003 08:50:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07E1Bv21347 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 09:01:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07E1BJ21344 for ; Tue, 7 Jan 2003 09:01:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13626 for ; Tue, 7 Jan 2003 08:49:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Do5J20627; Tue, 7 Jan 2003 08:50:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DnTJ20588 for ; Tue, 7 Jan 2003 08:49:29 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12694 for ; Tue, 7 Jan 2003 08:38:13 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA17718; Tue, 7 Jan 2003 08:41:28 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA13770; Tue, 7 Jan 2003 08:41:28 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Jan 2003 08:41:27 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CCB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'jh@lohi.eng.song.fi'" Cc: "'Peterson, Jon'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Tue, 7 Jan 2003 08:41:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , It may be that we want to use P-Asserted-Identity for this purpose. I currently think it's a pretty good idea, but: * It doesn't really meet the definition in RFC3325 * The "P" bothers me if this is a permanent solution Brian > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Tuesday, January 07, 2003 2:47 AM > To: Rosen, Brian > Cc: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne'; > 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > Rosen, Brian writes: > > > I do think there is a problem which this whole thread talks about. > > The basic reality is that many users of SIP UAs will have two > > identities - a SIP URI and a telephone number. It may be > > necessary to assert both identities in one call, because the > > originator of the call does not know which identity may be > > needed. There is no current header to do this. I think that > > it is advantageous to have a proxy be able to assert the phone > > number. Otherwise EVERY UA will have to be able to understand > > that two identities are possible, know them both by some > > unspecified means, and assert them in every call on every UA. > > This seems unreasonable. I'm not sure that there is a reason > > to have both identities validated, but there could be. > > if your proxy receives a call from sip:foo@bar.com who has also been > allocated a phone number +1234567890, why can't is add an asserted > identity header containing sip:+1234567890@bar.com to the call in case > the call is bound to pstn? why would you need yet another header for > that purpose? > > -- juha > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 08:57:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14119 for ; Tue, 7 Jan 2003 08:57:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07E8fU22368 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 09:08:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07E8fJ22365 for ; Tue, 7 Jan 2003 09:08:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14057 for ; Tue, 7 Jan 2003 08:54:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DwFJ21139; Tue, 7 Jan 2003 08:58:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DvRJ21018 for ; Tue, 7 Jan 2003 08:57:27 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13267 for ; Tue, 7 Jan 2003 08:46:10 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18Vu6c-0000c1-00; Tue, 07 Jan 2003 15:49:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15898.56033.854083.599679@harjus.eng.song.fi> Date: Tue, 7 Jan 2003 15:49:21 +0200 To: "Rosen, Brian" Cc: "'Peterson, Jon'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CCB@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF030B5CCB@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian writes: > It may be that we want to use P-Asserted-Identity for this > purpose. I currently think it's a pretty good idea, but: > * It doesn't really meet the definition in RFC3325 > * The "P" bothers me if this is a permanent solution brian, you can take a look at the archives and see that i was strongly against in making asserted-identity a p header for the reason that as long as it is a p header, sip/ss7 gw vendors are not likely to support in their gateways as a means to obtain the asserted pstn number of the calling party. so in practice the header became a 3gpp only thing. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 10:20:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17653 for ; Tue, 7 Jan 2003 10:20:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07FVQY27959 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 10:31:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FVQJ27956 for ; Tue, 7 Jan 2003 10:31:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17625 for ; Tue, 7 Jan 2003 10:20:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FKAJ27360; Tue, 7 Jan 2003 10:20:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FJjJ27307 for ; Tue, 7 Jan 2003 10:19:45 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16486 for ; Tue, 7 Jan 2003 10:08:28 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23073; Tue, 7 Jan 2003 10:11:41 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29593; Tue, 7 Jan 2003 10:11:41 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Jan 2003 10:11:40 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CCD@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Tue, 7 Jan 2003 10:11:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I think Reply-To is a so-so place to put a second identity. I think it's problematic to have a From have the "real" SIP URI and the Reply-To have the "real" tel URI. It warps the definition of Reply-To. It also has a serious problem that a proxy can't add it. One of the requirements I have is that a proxy be able to do the translation. Not every gateway can hold all the tables required for this kind of translation, and I don't think we want to force every gateway to have the tables. I think your proposals on identity will not work unless the signer can be a proxy which later in the routing than my proxy that does the translation. If the gateway does the translation, then in theory there would have to be a trust relationship between the PSTN and the gateway. That won't work for an enterprise gateway, although I'm not sure that's a practical problem, because if the gateway translated, the PSTN is going to check that the number the gateway asserted is one of the identities that loop is allocated (PRIs have ranges). I don't see how ENUM is useful with identity assertion, although it's clearly applicable to the proxy that translates a SIP URI into a phone number or vice versa in the Request URI. Brian > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, January 07, 2003 6:35 AM > To: 'Rosen, Brian'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > > First, it is possible, with the long-term identity mechanism, > to assert two > identities in an authenticated identity body. So, you could > have headers > corresponding to a telephone number and a SIP URI of a > gateway or a user - > it strikes me that a telephone number is a good Reply-To, > actually, when a > call comes from a gateway (originating in the PSTN, say) and > the From header > field contains a SIP URI for the gateway, perhaps including some port > information. The identity that the gateway which handles a > PSTN-SIP call > would assert needs to be its own, and recipients of calls > from gateways need > to trust the telephone number provided by the gateway or not > accordingly > (i.e. a signature from att.com vouching for such a request should be > acceptable). > > Technologies like ENUM (when/where available) could enable gateways to > convert originating telephone numbers into URIs. Of course, a gateway > wouldn't be able to assert that identity to an intermediary unless it > possessed credentials appropriate to that URI, which is unlikely. > > For outbound calls (SIP-PSTN), the gateway may or may not be > able to map > (authenticated) SIP URIs representing originators to > appropriate telephone > numbers via some sort of local tables as you suggested. If > not, might also > pick a number from a pool, sure. The question of whether some > authentication > service should be able to assert an originating telephone > number (in an > authenticated identity body, say) that a gateway will use is > also a trust > question - it is possible to put the tel URL in the AIB. If > the gateway has > a reason to trust the authentication service, then certainly > it should send > that number to the PSTN (when the protocol allows gateways to supply a > number, like with ISUP or Q.931). The gateway would be very > ill advised to > take just any authentication service's word on this matter, though. > > The target of the calls for the PSTN should be identified > with a telephone > number - at least, by the time the call arrives a gateway, > it's Request-URI > should contain a tel URL or a SIP URI with a tel URL > component. Whether the > originating UAC sets the To header field to a tel URL or a > subsequent proxy > retargets the request doesn't seem to make much difference. > ENUM can also > play a pretty obvious role here. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Monday, January 06, 2003 1:22 PM > > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning > > Schulzrinne' > > Cc: 'sipping@ietf.org' > > Subject: RE: [Sipping] URIs for Gateways > > > > > > I agree with this. I'm confused by those who seem to think that > > P-Asserted-Identity is needed when the long term solution is > > fully baked. If the UA knows its identity, which seems > > reasonable, then it can "assert" it, and have that assertion > > validated by a trusted entity using cryptographic means. > > That is the fundamental idea I get out of Jon's proposal. > > The only circumstance where that won't work is where the > > UA doesn't know its identity. I don't see that as a problem > > on any network I'm aware of, but ...... keep reading. > > > > I do think there is a problem which this whole thread talks about. > > The basic reality is that many users of SIP UAs will have two > > identities - a SIP URI and a telephone number. It may be > > necessary to assert both identities in one call, because the > > originator of the call does not know which identity may be > > needed. There is no current header to do this. I think that > > it is advantageous to have a proxy be able to assert the phone > > number. Otherwise EVERY UA will have to be able to understand > > that two identities are possible, know them both by some > > unspecified means, and assert them in every call on every UA. > > This seems unreasonable. I'm not sure that there is a reason > > to have both identities validated, but there could be. > > > > Brian > > > -----Original Message----- > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: Monday, January 06, 2003 2:06 PM > > > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne' > > > Cc: 'sipping@ietf.org' > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > RFC3325 was 'short-term' because it was achievable in the > > > short-term and has > > > a more limited (but still useful) applicability. The > > > long-term identity > > > solution must be a superset of the functionality of > > > short-term - it must > > > address the short-term scope of applicability, but also > > > encompass general > > > needs for network assertion (which SIP does have). > > > Accordingly, it takes > > > longer to develop. At such a time as there is a workable > > > long-term solution, > > > it would be pointless to allow both to be SIP standards > > > except as part of a > > > transition plan. So in that sense, I disagree - one is a > > > short-term solution > > > of the other. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > > Sent: Friday, January 03, 2003 8:20 AM > > > > To: Rosen, Brian; 'Henning Schulzrinne' > > > > Cc: 'sipping@ietf.org' > > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > Network asserted identity (RFC 3325) is the real network > > > > asserted identity. It is a P header not because it is > > > > preliminary, but because the whole idea of network assertion > > > > is not generally applicable to all SIP architectures. For RFC > > > > 3325 a trust domain needs to exist between proxies that use > > > > the P-Asserted-Identity in order to guarantee the privacy, > > > > this does not exist in all SIP networks. In does in 3GPP and > > > > therefore 3GPP are using RFC 3325. > > > > > > > > If you want to let the 1et outbound proxy assert identity on > > > > your behalf then use RFC 3325. If you want to let application > > > > servers with whom you have a secure relationship assert your > > > > identity, then use Jon Petersons drafts, when they eventually > > > > become RFCs. > > > > > > > > One is not a short term solution for the other. > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: 02 January 2003 20:49 > > > > > To: 'Henning Schulzrinne' > > > > > Cc: 'sipping@ietf.org' > > > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > Yeah, I actually thought of just allowing a display > name in the > > > > > Request URI and using that, but it seems so foolish to make > > > > a change, > > > > > and have that change not be exactly what we needed. > > > > > > > > > > We could use NAI. I suppose we could use a > P-Asserted-Identity > > > > > with a tel URI: > > > > > P-Asserted-Identity tel:+17247426826 > > > > > > > > > > What do we do when the "real" NAI happens? > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > Sent: Thursday, January 02, 2003 3:10 PM > > > > > > To: Rosen, Brian > > > > > > Cc: 'sipping@ietf.org' > > > > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > > > > > I'd like to get a new header for the calling > party number on > > > > > > > an outbound call. That way, the translator can be > > a proxy and > > > > > > > add the header. I'd recommend that gateways allow > > the number > > > > > > > to be in the From. > > > > > > > > > > > > Generalized, you want something like the Request-URI > > > that can be > > > > > > modified or inserted. How about the NAI stuff? > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 11:40:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20270 for ; Tue, 7 Jan 2003 11:40:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07Gp3r01748 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 11:51:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07Gp3J01745 for ; Tue, 7 Jan 2003 11:51:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20252 for ; Tue, 7 Jan 2003 11:39:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GkoJ01601; Tue, 7 Jan 2003 11:46:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GjeJ01561 for ; Tue, 7 Jan 2003 11:45:40 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20110 for ; Tue, 7 Jan 2003 11:34:22 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h07GcCCe000875; Tue, 7 Jan 2003 11:38:12 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX45995; Tue, 7 Jan 2003 11:42:32 -0500 (EST) Message-ID: <3E1B024A.1020309@cisco.com> Date: Tue, 07 Jan 2003 11:37:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-req-00.txt References: <200301071328.IAA12023@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This document provides many detailed requirements. But I am still left with a feeling of uncertainty about the overall scope. For instance: - I'm not sure what is in scope and out of scope for a media policy. Is there anything that can be negotiated via an offer/answer exchange that is out of scope? Certain specific features that are encoded in SDP are called out specifically. This might imply that it is intended that features not mentioned are out of scope. An example of a specific feature not mentioned, is the a=direction attribute used by comedia. It is possible to imagine an intermediate node might want to alter an a=direction:both to be only a=direction:active. Does this need to be listed as a requirement before it can be addressed by policy? I am somewhat concerned that this is a slippery slope. Unless we can clearly define what is in scope and what is out, I think we will find that we are simply defining a new representation of SDP, one syntactic element at a time. At the least, this seems to require a sort of meta-model for offers and answers that transcends SDP and SDPng. - Continuing the scope question a bit, is there any intent to support policies that can't already be expressed via an offer/answer exchange? (I don't think so, but just checking.) - There is much mention of proxies as the nodes that want to specify policy. But I think there are other kinds of servers that may also take on this role. Specifically, a B2BUA may also want to work cooperatively with the endpoints in same way. Of course a B2BUA already has more capabilities to modify the SDP directly, but it may want to be more subtle and friendly in its manipulations. For instance, this mechanism may permit a more extended pre-alert negotiation than is currently possible. So I would like to see these requirements phrased to permit a B2BUA as a policy setter if that makes sense. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 11:50:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20704 for ; Tue, 7 Jan 2003 11:50:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07H1ii02309 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 12:01:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07H1iJ02306 for ; Tue, 7 Jan 2003 12:01:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20684 for ; Tue, 7 Jan 2003 11:50:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GvCJ02130; Tue, 7 Jan 2003 11:57:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GulJ02099 for ; Tue, 7 Jan 2003 11:56:47 -0500 Received: from imo-m04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20544 for ; Tue, 7 Jan 2003 11:45:29 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m04.mx.aol.com (mail_out_v34.13.) id 7.128.1f9ae0e1 (4552); Tue, 7 Jan 2003 11:48:12 -0500 (EST) Message-ID: <128.1f9ae0e1.2b4c5ecc@aol.com> Date: Tue, 7 Jan 2003 11:48:12 EST Subject: Re: [Sipping] Comments on sos draft -03 (URI) To: hgs@cs.columbia.edu CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 6.0 for Windows XP US sub 51 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In a message dated 1/6/2003 6:51:38 PM Eastern Standard Time, hgs@cs.columbia.edu writes: The problem occurs with 118 and 119, which presumably are omitted from the shorter list since they mean something other than emergency somewhere. [MAP] This is the fundamental problem. If a number means something else someplace else, then it can't be coded into the phone and setup to automatically initiate a call to emergency if dialed. This also applies if the number means nothing somewhere else. For example, if 118 means emergency somewhere, but is unused in the US, then if I dial 118 on my SIP phone when I'm in the US, it can't be allowed to initiate a call to emergency. People can get fined for false calls to emergency, but you can't very easily fault someone if it was the design of their phone that did it when they dialed a non-existant digit string. As Henning wrote on 12/21: "Are you arguing that 112 does *not* work on GSM phones in the US? (I don't know; I don't want to try on mine...)" I believe that this rules out any numbers being automatically recognized by a phone device, unless that device has specific knowledge about the local dialing plan. So, until the issue of how a phone knows the local dial plan is solved/answered, I suggest that all discussion of storing emergency (or other) numbers in the phone be dropped. In a message dated 1/4/2003 1:33:09 PM Eastern Standard Time, hgs@cs.columbia.edu writes: [MAP] > The seventh paragraph states that the "sos" user name and user names > starting with "sos." MUST NOT be assigned to any user. Such a > restriction can not possibly be enforced due to possible existing > conflicts (as noted in Section 6). [HS] Do you have any suggestions that work better? The section 'Alternative Identifiers Considered' describes why I believe that none of the obvious alternatives is workable if you want Yes, I have a suggestion, but I know it is highly controversial and is not liked, since it goes against the vision of how the Internet MUST work. I don't think that the draft (Section 10 in -04) makes the case that the alternatives listed are not workable. The first "tel:sos" says it is not a valid tel URI and it only works if every outbound proxy knows what to do with it. Can't this form be included in the definition of tel:url? The draft says that a URI parameter won't work since it "requires mechanism-aware user agents", but everything we've been discussing seems to be based on a premise that the user agent is "mechanism-aware" (has a special button or recognizes "emergency" numbers). Special domain: Same as tel:uri. Further, the statement in support of not using the tel:sos scheme also says that the "SIP URI proposed here only requires a user's home domain to be appropriately configured". This is a major disadvantage with this scheme, which I suppose has been the subject of some past discussions. There is a fundamental problem with this approach. The user's home domain is not subject to any of the regulations that apply to the local area regarding the support of emergency telephone service. It couldn't even be required to support it. Depending on the user's home domain to know how to handle emergency calls for the area that the user is in (if the home domain even knows where they are) is very problematic. It presumes that the home domain not only understands the "sos.", but knows how to call the emergency service local to the user. I can't imagine for a monent that any local regulatory body (which, in the end, controls how emergency services are reached) would accept a scheme that depends on some distant equipment, which it does not control through regulations, to be the critical point in providing emergency service. The solution to the above is to state that the outbound proxy must recognize and take action on all emergency calls, whether dialed with 911, 118, etc. or by the use of a special button on the phone which sends a special URI. The URI can be some new form defined within the context of the tel:url, since it is intended as a direct replacement for a telephone number, or some other form. The user's home domain is never responsible to handling emergency calls. Further, all calls require the use of an outbound proxy. (The alternative is for the phone itself to be able to perform the functions of the outbound proxy, which requires, among other things, that it know the entire local dialing plan. It could know this through configuration or download of parameters when it is turned on.) (See, I said it was controversial!) Mike Pierce Artel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 12:04:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21096 for ; Tue, 7 Jan 2003 12:04:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07HF6r03663 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 12:15:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HF5J03660 for ; Tue, 7 Jan 2003 12:15:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21070 for ; Tue, 7 Jan 2003 12:03:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07H8DJ03397; Tue, 7 Jan 2003 12:08:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07H6UJ02617 for ; Tue, 7 Jan 2003 12:06:30 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20899 for ; Tue, 7 Jan 2003 11:55:12 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29419; Tue, 7 Jan 2003 11:58:25 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18308; Tue, 7 Jan 2003 11:58:26 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Jan 2003 11:58:26 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CCF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" , Jonathan Rosenberg Cc: sipping@ietf.org Subject: RE: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-r eq-00.txt Date: Tue, 7 Jan 2003 11:58:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Agree. I specifically want to have the mechanism allowed to specify the bandwidth parameters (I ask for a 6MB video stream, the proxy tells me I can only send 4, everything else is the same). So, is this in scope or out? I'll point out that this is an interesting one because there is no middle box; there is simply a bandwidth manager that is doing something much better than simplistic call admission control. However, I don't see any reason to judge why one SDP parameter is subject to policy, and another one is not. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, January 07, 2003 11:38 AM > To: Jonathan Rosenberg > Cc: sipping@ietf.org > Subject: Re: [Sipping] I-D > ACTION:draft-rosenberg-sipping-session-policy-req-00.txt > > > This document provides many detailed requirements. But I am > still left > with a feeling of uncertainty about the overall scope. For instance: > > - I'm not sure what is in scope and out of scope for a media > policy. Is > there anything that can be negotiated via an offer/answer > exchange that > is out of scope? Certain specific features that are encoded > in SDP are > called out specifically. This might imply that it is intended that > features not mentioned are out of scope. > > An example of a specific feature not mentioned, is the a=direction > attribute used by comedia. It is possible to imagine an intermediate > node might want to alter an a=direction:both to be only > a=direction:active. Does this need to be listed as a > requirement before > it can be addressed by policy? > > I am somewhat concerned that this is a slippery slope. Unless we can > clearly define what is in scope and what is out, I think we will find > that we are simply defining a new representation of SDP, one > syntactic > element at a time. At the least, this seems to require a sort of > meta-model for offers and answers that transcends SDP and SDPng. > > - Continuing the scope question a bit, is there any intent to support > policies that can't already be expressed via an offer/answer > exchange? > (I don't think so, but just checking.) > > - There is much mention of proxies as the nodes that want to specify > policy. But I think there are other kinds of servers that may > also take > on this role. Specifically, a B2BUA may also want to work > cooperatively > with the endpoints in same way. Of course a B2BUA already has more > capabilities to modify the SDP directly, but it may want to be more > subtle and friendly in its manipulations. For instance, this > mechanism > may permit a more extended pre-alert negotiation than is currently > possible. So I would like to see these requirements phrased > to permit a > B2BUA as a policy setter if that makes sense. > > Paul > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 12:28:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21620 for ; Tue, 7 Jan 2003 12:28:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07HcoH05300 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 12:38:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HcoJ05297 for ; Tue, 7 Jan 2003 12:38:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21598 for ; Tue, 7 Jan 2003 12:27:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HYAJ04545; Tue, 7 Jan 2003 12:34:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HX2J04494 for ; Tue, 7 Jan 2003 12:33:02 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21530 for ; Tue, 7 Jan 2003 12:21:42 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h07HOuEE028883 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Jan 2003 12:24:57 -0500 (EST) Message-ID: <3E1B0D86.8070407@cs.columbia.edu> Date: Tue, 07 Jan 2003 12:25:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sipping@ietf.org Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: <128.1f9ae0e1.2b4c5ecc@aol.com> In-Reply-To: <128.1f9ae0e1.2b4c5ecc@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [MAP] This is the fundamental problem. If a number means something else > someplace else, then it can't be coded into the phone and setup to > automatically initiate a call to emergency if dialed. This also applies if > the number means nothing somewhere else. For example, if 118 means emergency > somewhere, but is unused in the US, then if I dial 118 on my SIP phone when > I'm in the US, it can't be allowed to initiate a call to emergency. People > can get fined for false calls to emergency, but you can't very easily fault > someone if it was the design of their phone that did it when they dialed a > non-existant digit string. I guess you'll have to argue this with 3GPP, since they preload a set of numbers into the phone. There are basically two kinds of errors: (1) The user dials a three-digit number reasonably expecting it to reach emergency and it reaches, say, repair service or nobody. Bad, with potentially life-threatening consequences. (2) The user dials a three-digit number, believing it reaches some service like repair or directory assistance, and gets connected to the police department. Unless the caller insists on getting grandma's phone number, this is mostly a nuisance. (I don't think accidentally dialing 911 is a crime, since this occurs quite commonly with cell phones that have one-button emergency calls. Reporting a non-existing emergency is, obviously, punishable.) This becomes a problem if this number is widely advertised. If the device recognizes the three-digit number combination, it can easily pop up a dialog that says "you're dialing an emergency number, please confirm". (This, btw, argues for translating all of these into sos URIs, since there's otherwise no way for the user to dial tel:118 for directory assistance since the proxy will *always* assume its an emergency number.) My interpretation of the 3GPP list is that none of the numbers, with the exception of 118 and 119, are used for anything else of importance, so that (2) is not likely to be common. This is not terribly satisfying, but pragmatic, given case (1). > > As Henning wrote on 12/21: "Are you arguing that 112 does *not* work on GSM > phones in > the US? (I don't know; I don't want to try on mine...)" > > I believe that this rules out any numbers being automatically recognized by a > phone device, unless that device has specific knowledge about the local > dialing plan. So, until the issue of how a phone knows the local dial plan is > solved/answered, I suggest that all discussion of storing emergency (or > other) numbers in the phone be dropped. Again, something you should take up with 3GPP first. > The first "tel:sos" says it is not a valid tel URI and it only works if every > outbound proxy knows what to do with it. Can't this form be included in the > definition of tel:url? It could, but the other problem remains. Plus, conceptually, I'm reluctant to classify emergency calls as a tel(ephone) service. If we go down this route of what is essentially a URN, I think it's cleaner to define a new URN scheme that identifies generic communication services, similar to the ISBN schemes and organizations, as in URN:service:sos We had a related discussion in the IPTEL working group, since this is one of the major open issues remaining for the tel URI. Defining the URN is easy, defining the resolution is hard, particulary if you want to allow things like URN:service:pizza or even URN:service:phone-directory where multiple providers want to be reached via that URN. I don't think NAPTR works for this, for example. You effectively recreate the 'mnemonic name' problem, see RFC 2972, 3367 and 3368 for one such service. Indeed, you could use go:sos today, except that CNRP seems to have been one of those 2000-era ideas that floundered. (http://www.realnames.com is no more...) > > The draft says that a URI parameter won't work since it "requires > mechanism-aware user agents", but everything we've been discussing seems to > be based on a premise that the user agent is "mechanism-aware" (has a special > button or recognizes "emergency" numbers). Not really. I can take a SIP phone and dial 911 or any of the other numbers and that would work (assuming it gets translated to a tel URI) or dial sos@mydomain and this will work, without any UA modification. Clearly, some proxy has to recognize these identifiers, but UAs do not. (Actually, even that's not true for the common case where the gateway is in the same country. Dialing tel:911 today may work, even though you may be talking to a police department that's in a different part of the country.) > > Special domain: Same as tel:uri. > > Further, the statement in support of not using the tel:sos scheme also says > that the "SIP URI proposed here only requires a user's home domain to be > appropriately configured". This is a major disadvantage with this scheme, > which I suppose has been the subject of some past discussions. There is a > fundamental problem with this approach. The user's home domain is not subject > to any of the regulations that apply to the local area regarding the support > of emergency telephone service. It couldn't even be required to support it. I don't know what you mean by 'local area'. I don't see how I can require Starbucks to support a PSTN gateway in each of its 802.11 hot spots. > Depending on the user's home domain to know how to handle emergency calls for > the area that the user is in (if the home domain even knows where they are) > is very problematic. It presumes that the home domain not only understands > the "sos.", but knows how to call the emergency service local to the user. I > can't imagine for a monent that any local regulatory body (which, in the end, > controls how emergency services are reached) would accept a scheme that > depends on some distant equipment, which it does not control through > regulations, to be the critical point in providing emergency service. Are you mandating that every LAN, every 802.11 hotspot, every IETF wireless LAN has to have: - an outbound SIP proxy server, and - a PSTN gateway that can dial 911 ? Good luck. I'm trying to build a system that will work well once this is true and will work ok (and be testable) until this is true. > > The solution to the above is to state that the outbound proxy must recognize > and take action on all emergency calls, whether dialed with 911, 118, etc. or The draft already says that. The problem is that there may be no outbound proxy in every LAN or local geographic area. After all, this is not a mandatory piece of equipment and not every network will be SIP-aware. I want to be able to use SIP phones without local support. Once we have outbound proxies everywhere, things will work better (and exactly as well as your proposal). > by the use of a special button on the phone which sends a special URI. The > URI can be some new form defined within the context of the tel:url, since it > is intended as a direct replacement for a telephone number, or some other > form. The user's home domain is never responsible to handling emergency > calls. Further, all calls require the use of an outbound proxy. (The > alternative is for the phone itself to be able to perform the functions of > the outbound proxy, which requires, among other things, that it know the > entire local dialing plan. It could know this through configuration or > download of parameters when it is turned on.) > > (See, I said it was controversial!) > > Mike Pierce > Artel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 13:18:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23199 for ; Tue, 7 Jan 2003 13:18:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07IT3x08192 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 13:29:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IT3J08189 for ; Tue, 7 Jan 2003 13:29:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23156 for ; Tue, 7 Jan 2003 13:17:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IP5J08004; Tue, 7 Jan 2003 13:25:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IOEJ07936 for ; Tue, 7 Jan 2003 13:24:14 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22925 for ; Tue, 7 Jan 2003 13:12:53 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02567; Tue, 7 Jan 2003 13:16:06 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA29329; Tue, 7 Jan 2003 13:16:07 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Jan 2003 13:16:07 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CD0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Mpierce1@aol.com Cc: sipping@ietf.org Subject: RE: [Sipping] Comments on sos draft -03 (URI) Date: Tue, 7 Jan 2003 13:15:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I don't think this works. Not all dialing plans are the same, and even if all 3G phones have the same dialing plans, that won't be the same as, say, an enterprise telephony system. In most US enterprises, and for that matter, in most US college campuses, the emergency number is 9-911. 911 would not connect (the 9 would be interpreted as "outside line", and the 11 would probably be interpreted as an illegal number). In a "greenfield" all-VoIP system, this could be changed, but in general, it can't. A great many enterprise systems have 3 digit extensions where 1 is a legal first digit. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, January 07, 2003 12:25 PM > To: Mpierce1@aol.com > Cc: sipping@ietf.org > Subject: Re: [Sipping] Comments on sos draft -03 (URI) > > > > [MAP] This is the fundamental problem. If a number means > something else > > someplace else, then it can't be coded into the phone and setup to > > automatically initiate a call to emergency if dialed. This > also applies if > > the number means nothing somewhere else. For example, if > 118 means emergency > > somewhere, but is unused in the US, then if I dial 118 on > my SIP phone when > > I'm in the US, it can't be allowed to initiate a call to > emergency. People > > can get fined for false calls to emergency, but you can't > very easily fault > > someone if it was the design of their phone that did it > when they dialed a > > non-existant digit string. > > I guess you'll have to argue this with 3GPP, since they > preload a set of > numbers into the phone. > > There are basically two kinds of errors: > > (1) The user dials a three-digit number reasonably expecting > it to reach > emergency and it reaches, say, repair service or nobody. Bad, with > potentially life-threatening consequences. > > (2) The user dials a three-digit number, believing it reaches some > service like repair or directory assistance, and gets > connected to the > police department. Unless the caller insists on getting > grandma's phone > number, this is mostly a nuisance. (I don't think > accidentally dialing > 911 is a crime, since this occurs quite commonly with cell > phones that > have one-button emergency calls. Reporting a non-existing > emergency is, > obviously, punishable.) This becomes a problem if this number > is widely > advertised. If the device recognizes the three-digit number > combination, > it can easily pop up a dialog that says "you're dialing an emergency > number, please confirm". (This, btw, argues for translating > all of these > into sos URIs, since there's otherwise no way for the user to dial > tel:118 for directory assistance since the proxy will *always* assume > its an emergency number.) > > My interpretation of the 3GPP list is that none of the > numbers, with the > exception of 118 and 119, are used for anything else of > importance, so > that (2) is not likely to be common. This is not terribly satisfying, > but pragmatic, given case (1). > > > > > > As Henning wrote on 12/21: "Are you arguing that 112 does > *not* work on GSM > > phones in > > the US? (I don't know; I don't want to try on mine...)" > > > > I believe that this rules out any numbers being > automatically recognized by a > > phone device, unless that device has specific knowledge > about the local > > dialing plan. So, until the issue of how a phone knows the > local dial plan is > > solved/answered, I suggest that all discussion of storing > emergency (or > > other) numbers in the phone be dropped. > > Again, something you should take up with 3GPP first. > > > The first "tel:sos" says it is not a valid tel URI and it > only works if every > > outbound proxy knows what to do with it. Can't this form be > included in the > > definition of tel:url? > > It could, but the other problem remains. Plus, conceptually, I'm > reluctant to classify emergency calls as a tel(ephone) > service. If we go > down this route of what is essentially a URN, I think it's cleaner to > define a new URN scheme that identifies generic communication > services, > similar to the ISBN schemes and organizations, as in > > URN:service:sos > > We had a related discussion in the IPTEL working group, since this is > one of the major open issues remaining for the tel URI. > Defining the URN > is easy, defining the resolution is hard, particulary if you want to > allow things like > > URN:service:pizza > > or even > > URN:service:phone-directory > > where multiple providers want to be reached via that URN. I > don't think > NAPTR works for this, for example. You effectively recreate the > 'mnemonic name' problem, see RFC 2972, 3367 and 3368 for one such > service. Indeed, you could use > > go:sos > > today, except that CNRP seems to have been one of those > 2000-era ideas > that floundered. (http://www.realnames.com is no more...) > > > > > The draft says that a URI parameter won't work since it "requires > > mechanism-aware user agents", but everything we've been > discussing seems to > > be based on a premise that the user agent is > "mechanism-aware" (has a special > > button or recognizes "emergency" numbers). > > Not really. I can take a SIP phone and dial 911 or any of the other > numbers and that would work (assuming it gets translated to a > tel URI) > or dial sos@mydomain and this will work, without any UA modification. > Clearly, some proxy has to recognize these identifiers, but > UAs do not. > (Actually, even that's not true for the common case where the > gateway is > in the same country. Dialing tel:911 today may work, even > though you may > be talking to a police department that's in a different part of the > country.) > > > > > Special domain: Same as tel:uri. > > > > Further, the statement in support of not using the tel:sos > scheme also says > > that the "SIP URI proposed here only requires a user's home > domain to be > > appropriately configured". This is a major disadvantage > with this scheme, > > which I suppose has been the subject of some past > discussions. There is a > > fundamental problem with this approach. The user's home > domain is not subject > > to any of the regulations that apply to the local area > regarding the support > > of emergency telephone service. It couldn't even be > required to support it. > > I don't know what you mean by 'local area'. I don't see how I can > require Starbucks to support a PSTN gateway in each of its > 802.11 hot spots. > > > Depending on the user's home domain to know how to handle > emergency calls for > > the area that the user is in (if the home domain even knows > where they are) > > is very problematic. It presumes that the home domain not > only understands > > the "sos.", but knows how to call the emergency service > local to the user. I > > can't imagine for a monent that any local regulatory body > (which, in the end, > > controls how emergency services are reached) would accept a > scheme that > > depends on some distant equipment, which it does not > control through > > regulations, to be the critical point in providing > emergency service. > > Are you mandating that every LAN, every 802.11 hotspot, every IETF > wireless LAN has to have: > - an outbound SIP proxy server, and > - a PSTN gateway that can dial 911 > ? > > Good luck. I'm trying to build a system that will work well > once this is > true and will work ok (and be testable) until this is true. > > > > > > The solution to the above is to state that the outbound > proxy must recognize > > and take action on all emergency calls, whether dialed with > 911, 118, etc. or > > The draft already says that. The problem is that there may be no > outbound proxy in every LAN or local geographic area. After > all, this is > not a mandatory piece of equipment and not every network will be > SIP-aware. I want to be able to use SIP phones without local support. > Once we have outbound proxies everywhere, things will work > better (and > exactly as well as your proposal). > > > by the use of a special button on the phone which sends a > special URI. The > > URI can be some new form defined within the context of the > tel:url, since it > > is intended as a direct replacement for a telephone number, > or some other > > form. The user's home domain is never responsible to > handling emergency > > calls. Further, all calls require the use of an outbound > proxy. (The > > alternative is for the phone itself to be able to perform > the functions of > > the outbound proxy, which requires, among other things, > that it know the > > entire local dialing plan. It could know this through > configuration or > > download of parameters when it is turned on.) > > > > (See, I said it was controversial!) > > > > > > Mike Pierce > > Artel > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 13:18:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23219 for ; Tue, 7 Jan 2003 13:18:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07ITR908216 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 13:29:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ITQJ08213 for ; Tue, 7 Jan 2003 13:29:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23187 for ; Tue, 7 Jan 2003 13:17:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IOkJ07955; Tue, 7 Jan 2003 13:24:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07INOJ07914 for ; Tue, 7 Jan 2003 13:23:24 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22909 for ; Tue, 7 Jan 2003 13:11:58 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h07IFlmh016150; Tue, 7 Jan 2003 13:15:48 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX46860; Tue, 7 Jan 2003 13:20:07 -0500 (EST) Message-ID: <3E1B1929.8040507@cisco.com> Date: Tue, 07 Jan 2003 13:15:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: hgs@cs.columbia.edu, sipping@ietf.org Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: <128.1f9ae0e1.2b4c5ecc@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mpierce1@aol.com wrote: > > The solution to the above is to state that the outbound proxy must recognize > and take action on all emergency calls, whether dialed with 911, 118, etc. or > by the use of a special button on the phone which sends a special URI. The > URI can be some new form defined within the context of the tel:url, since it > is intended as a direct replacement for a telephone number, or some other > form. The user's home domain is never responsible to handling emergency > calls. Further, all calls require the use of an outbound proxy. (The > alternative is for the phone itself to be able to perform the functions of > the outbound proxy, which requires, among other things, that it know the > entire local dialing plan. It could know this through configuration or > download of parameters when it is turned on.) Are you suggesting that it be illegal to have a portable device that doesn't use a local proxy? (E.g. a satelite phone, or an 802.11b based phone.) These are very meaningful devices to consider. And its not clear (to me) if they are even subject to any regulatory requirements about local emergency service. If I'm wandering around Iraq with my satelite phone and dial the local emergency number, is my call supposed to be routed from the satelite to some local Iraq proxy to check for local emergency numbers? Also, there are some problems with using a local proxy to provide dial plan and so resolve emergency services. tel:911 is not a valid tel uri - it must have a context, such as tel:911;phone-context=+1. However, for a mobile phone it is difficult to know what context to use. It might need to be discovered at the same time as the local proxy is selected. This is equivalent to requiring the phone to obtain a local dial plan. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 13:49:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23978 for ; Tue, 7 Jan 2003 13:49:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07J0mG09922 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 14:00:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07J0mJ09919 for ; Tue, 7 Jan 2003 14:00:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23940 for ; Tue, 7 Jan 2003 13:49:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IuLJ09770; Tue, 7 Jan 2003 13:56:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ItWJ09734 for ; Tue, 7 Jan 2003 13:55:32 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23857 for ; Tue, 7 Jan 2003 13:44:10 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h07IlOhg023842 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Jan 2003 13:47:24 -0500 (EST) Message-ID: <3E1B20D8.1000602@cs.columbia.edu> Date: Tue, 07 Jan 2003 13:47:52 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: Mpierce1@aol.com, sipping@ietf.org Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: <313680C9A886D511A06000204840E1CF030B5CD0@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CD0@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is another argument for having the end system convert locally recognized digit strings into 'sos'. My Rosen, Brian wrote: > I don't think this works. Not all dialing plans are the same, > and even if all 3G phones have the same dialing plans, that > won't be the same as, say, an enterprise telephony system. > > In most US enterprises, and for that matter, in most US college > campuses, the emergency number is 9-911. 911 would not connect I think there are attempts to change this; see http://emergency.lib.uci.edu/ or http://www.news.cornell.edu/Chronicle/97/7.24.97/911.html or http://www.med.umich.edu/medschool/faculty/handbook/phones.html for some quick Google research. I doubt that anybody sane will assign somebody extension 911. > (the 9 would be interpreted as "outside line", and the 11 would > probably be interpreted as an illegal number). In a "greenfield" > all-VoIP system, this could be changed, but in general, it can't. > A great many enterprise systems have 3 digit extensions where 1 > is a legal first digit. There are probably two pragmatic approaches: - Network-based: Don't assign 000, 08, 112, 110, 118, 119, 911 and 999 as regular numbers. 0-00 would seem to be difficult since that's the common way that you'd dial an international number from a European PBX phone. However, it should never appear as anything but the initial part of an overlap dialing string, which wouldn't be in a tel: URI to begin with. One can argue how difficult it would be to vacate the other half dozen numbers. - UA-based: The UA recognizes these numbers and then asks whether you want extension 112 or emergency. (http://www.citrus.usda.gov/Staff2001.htm has them all :-)) If it's the extension, the normal tel:112;phone-context mechanism tells the proxy that it shouldn't call the fire department. Needless to say, neither approach is particularly satisfactory. Since the outbound proxy is the one mangling extension 112 into an emergency call, it might be nice to able to ask it. Generalized, having a mechanism where you can ask a proxy what it would do with a tel URI would be nice. OPTIONS with Max-Forward plus one of the tracing mechanism discussed (Jiri's draft, say) here may come close, but seems rather complicated. Clearly, this could be part of the SIP device configuration, but that wouldn't help for a visiting device that gets its configuration from home. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 14:04:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24550 for ; Tue, 7 Jan 2003 14:04:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07JFJS11114 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 14:15:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JFGJ11109 for ; Tue, 7 Jan 2003 14:15:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24468 for ; Tue, 7 Jan 2003 14:02:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JA9J10886; Tue, 7 Jan 2003 14:10:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07J98J10835 for ; Tue, 7 Jan 2003 14:09:08 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24235 for ; Tue, 7 Jan 2003 13:57:46 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04691; Tue, 7 Jan 2003 14:01:00 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06806; Tue, 7 Jan 2003 14:01:00 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Jan 2003 14:01:00 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CD1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: Mpierce1@aol.com, sipping@ietf.org Subject: RE: [Sipping] Comments on sos draft -03 (URI) Date: Tue, 7 Jan 2003 14:00:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I agree as long as "locally recognized" is learned from some site-dependent entity (e.g. DHCP); it can't be built in. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, January 07, 2003 1:48 PM > To: Rosen, Brian > Cc: Mpierce1@aol.com; sipping@ietf.org > Subject: Re: [Sipping] Comments on sos draft -03 (URI) > > > This is another argument for having the end system convert locally > recognized digit strings into 'sos'. > > My > > Rosen, Brian wrote: > > I don't think this works. Not all dialing plans are the same, > > and even if all 3G phones have the same dialing plans, that > > won't be the same as, say, an enterprise telephony system. > > > > In most US enterprises, and for that matter, in most US college > > campuses, the emergency number is 9-911. 911 would not connect > > I think there are attempts to change this; see > http://emergency.lib.uci.edu/ or > http://www.news.cornell.edu/Chronicle/97/7.24.97/911.html or > http://www.med.umich.edu/medschool/faculty/handbook/phones.html > for some quick Google research. > > I doubt that anybody sane will assign somebody extension 911. > > > (the 9 would be interpreted as "outside line", and the 11 would > > probably be interpreted as an illegal number). In a "greenfield" > > all-VoIP system, this could be changed, but in general, it can't. > > A great many enterprise systems have 3 digit extensions where 1 > > is a legal first digit. > > There are probably two pragmatic approaches: > > - Network-based: Don't assign 000, 08, 112, 110, 118, 119, > 911 and 999 > as regular numbers. 0-00 would seem to be difficult since that's the > common way that you'd dial an international number from a > European PBX > phone. However, it should never appear as anything but the > initial part > of an overlap dialing string, which wouldn't be in a tel: URI > to begin with. > > One can argue how difficult it would be to vacate the other > half dozen > numbers. > > - UA-based: The UA recognizes these numbers and then asks whether you > want extension 112 or emergency. > (http://www.citrus.usda.gov/Staff2001.htm has them all :-)) > If it's the > extension, the normal tel:112;phone-context mechanism tells the proxy > that it shouldn't call the fire department. > > Needless to say, neither approach is particularly satisfactory. Since > the outbound proxy is the one mangling extension 112 into an > emergency > call, it might be nice to able to ask it. Generalized, having a > mechanism where you can ask a proxy what it would do with a tel URI > would be nice. OPTIONS with Max-Forward plus one of the tracing > mechanism discussed (Jiri's draft, say) here may come close, > but seems > rather complicated. > > Clearly, this could be part of the SIP device configuration, but that > wouldn't help for a visiting device that gets its > configuration from home. > > Henning > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 14:15:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25120 for ; Tue, 7 Jan 2003 14:15:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07JPv611565 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 14:25:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JPvJ11562 for ; Tue, 7 Jan 2003 14:25:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25025 for ; Tue, 7 Jan 2003 14:13:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JNIJ11460; Tue, 7 Jan 2003 14:23:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JM4J11408 for ; Tue, 7 Jan 2003 14:22:04 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24942 for ; Tue, 7 Jan 2003 14:10:42 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h07JDvhg012428 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Jan 2003 14:13:58 -0500 (EST) Message-ID: <3E1B2712.4060501@cs.columbia.edu> Date: Tue, 07 Jan 2003 14:14:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: sipping@ietf.org Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: <313680C9A886D511A06000204840E1CF030B5CD1@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CD1@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I agree as long as "locally recognized" is learned from some site-dependent > entity (e.g. DHCP); it can't be built in. While I proposed DHCP in -04, I am concerned that the strings announced by DHCP are not guaranteed to be the strings recognized by the outbound proxy. This is not a problem if DHCP also announces the outbound proxy server. Thus, this mechanism should be used only in conjunction with RFC 3361. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 14:58:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26583 for ; Tue, 7 Jan 2003 14:58:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07K9kc14785 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 15:09:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07K9kJ14782 for ; Tue, 7 Jan 2003 15:09:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26563 for ; Tue, 7 Jan 2003 14:58:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07K8SJ14705; Tue, 7 Jan 2003 15:08:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07K7fJ14581 for ; Tue, 7 Jan 2003 15:07:41 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26518 for ; Tue, 7 Jan 2003 14:56:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Tue, 7 Jan 2003 14:59:32 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24864B@zoe.office.snowshore.com> Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Thread-Index: AcK2Tx7fsfsYx14yRXSUmMADoydQZQAND8IA From: "Eric Burger" To: "Steve Fisher" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h07K7fJ14582 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit To answer the question directly: KPML only works with HTTP reporting. It would be a different language for SIP reporting. MSCML is an example of a language that uses SIP for reporting. To answer the SIP stimulus reporting question: Done INFO in the past, not planning on it again :-) NOTIFY is my leading contender, but a new method may be needed because if you do a strict reading of NOTIFY, you might not want a NOTIFY without a SUBSCRIBE. Using SUBSCRIBE as a method of pushing KPML is out and out evil (I mean wrong). KPML changes the state of the UAS. SUBSCRIBE is not supposed to have any side-effects. > -----Original Message----- > From: Steve Fisher [mailto:sfisher1@att.com] > Sent: Tuesday, January 07, 2003 8:15 AM > To: Eric Burger > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Eric, > > I've been thinking about your statement below... > > > > If we say SIP for stimulus reporting, then the diagram you drew, > > > with the implication that the signaling follows the > signaling path, > > > is what will occur. > > > > > > Is this distinction important for you? The design team > did not come > > > > to full agreement on which way to go. Compelling > arguments either > > > way welcomed. > > Could you possibly elaborate on how "SIP for stimulus reporting" would > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using > INFO? It's fairly clear from the KPML draft how HTTP would > work, but SIP > was less clear to me... > > Thanks! > Steve > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of Eric Burger > Sent: Tuesday, December 17, 2002 5:18 PM > To: Don Stanwyck > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish) > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Rajnish is 1000% correct in his interpretation. Looking at > the message > I can see how my statement isn't entirely clear. > > I am on record in this and other fora that H.248 and J.162 are the > appropriate protocols for device control. See my posts to > the speechsc > list. I should have a paste buffer with my "Don't use SIP > for low-level > peripheral device control" rant. > > When I said "It [the thing referenced as "softswitch" in Rajnish's > e-mail -- ewb] is not a media gateway controller" I meant it was not a > media gateway controller, e.g., a device control thing, which uses > device control protocols like H.248 and J.162. > > Now it's my turn for interpreting Rajnish, instead of him interpreting > me :-) I assumed that the "PSTN X" thing was a MG-MGC combination, > speaking SIP on the packet network side. E.g., the MG-MGC > interface was > a private matter, not of interest to the discussion. > > Sorry for the confusion. > > > -----Original Message----- > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > Sent: Tuesday, December 17, 2002 4:02 PM > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish) > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Don, > > I don't think Eric implied controlling a MG from a Softswitch > > via SIP in his > > comment. That particular topic has come up in this forum many > > times and as I > > recall the conclusion has always been that SIP is not meant > > for that. SIP is > > a peer-to-peer to protocol not a master-slave protcol - > > agreed. However this > > is completely orthogonal to using stimulus/markup signaling > > in SIP. I don't > > see how in-lining a KPML doc (e.g.) in a SIP message breaks > > SIP paradigm. > > > > Eric, > > In general, I would like to propose an HTTP-free alternative > > for delivery of > > stimulus signals, such as through in-lining of KPML. The > > benefits of such an > > alternative in my mind are following: > > > > - it would make it easier for SIP developers on embedded > > platforms to embrace > > markup/stimulus signaling that don't support HTTP currently > > > > - it would facilitate close coordination between announcement > > play and DTMF > > collection. Barge-in is a good example for that. The app > > can delegate the > > job to stop announcement play at barge-in to the > > Softswitch. As an aside, > > the Softswitch in my previous figure is one w/ bizarre API > > as you say :-) > > > > Rajnish > > > > -----Original Message----- > > From: Don Stanwyck [mailto:don@stanwyck.com] > > Sent: Tuesday, December 17, 2002 3:10 PM > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)' > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)' > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > RFC 3261, Section 2 reads: > > > > //START QUOTE > > > > SIP supports five facets of establishing and terminating > > multimedia communications: > > - User location: determination of the end system to be > > used for communication; > > - User availability: determination of the willingness > > of the called party to engage in communications; > > - User capabilities: determination of the media and media > > parameters to be used; > > - Session setup: "ringing", establishment of session > > parameters at both called and calling party; > > - Session management: including transfer and termination > > of sessions, modifying session parameters, and invoking > > services. > > > > SIP is not a vertically integrated communications system. > > SIP is rather > > a component that can be used with other IETF protocols to build a > > complete multimedia architecture. Typically, these > architectures will > > include protocols such as the Real-time Transport Protocol > (RTP) (RFC > > 1889 [28]) for transporting real-time data and providing > QoS feedback, > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for > > controlling > > delivery of streaming media, the Media Gateway Control > > Protocol (MEGACO) > > (RFC 3015 [30]) for controlling gateways to the Public Switched > > Telephone Network (PSTN), and the Session Description Protocol (SDP) > > (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP > > should be used in conjunction with other protocols in order > to provide > > complete services to the users. However, the basic > functionality and > > operation of SIP does not depend on any of these protocols. > > > > //END QUOTE > > > > I can't find any support in this definition of SIP for > > carrying stimulus > > signaling or for controling media gateways (comment 1 in Eric's > > comments). SIP, as defined and approved by the IETF, is not > > expected to > > do these kinds of things that other IETF protocols are designed to > > handle. > > > > Let's try to keep SIP doing the things it is designed to do > and does > > well, and not try to make it into a protocol for doing everything > > imaginable. It is already in danger of becoming too difficult to > > implement as the number of options and new headers grows. > > > > Don Stanwyck > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of Eric Burger > > > Sent: Tuesday, December 17, 2002 12:12 PM > > > To: Jain, Rajnish (Rajnish) > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs and apps? > > > > > > > > > For timelines, I would suggest asking the work group chairs. > > > We're at their mercy :-) > > > > > > Putting my ISC hat on, what is the Softswitch in your diagram? > > > 1. It is not a media gateway controller, as it talks to > > > the gateway with SIP (right answer, by the way). > > > 2. Is it a Stateless Proxy, a'la the Routing Function > > > in the ISC reference diagram? If so, that works > > > exactly as you want it to. See below for more. > > > 3. Is it an application server, a'la dynamicsoft, > > > Ubiquity, LongBoard, etc.? If so, that also works > > > exactly as you want it to. See below for more. > > > 4. Is it some kind of statefull proxy, with a bizarre, > > > proprietary API to the pre-paid application (e.g., > > > Parlay, JAIN, EXS, ...)? If so, you are on your > > > own. > > > > > > If we say "HTTP only" for stimulus reporting, the PSTN > > > gateway must be a HTTP client. The good news is the gateway > > > can communicate directly with the pre-paid application. That > > > also means the pre-paid application needs to have a HTTP > > > server. Alternatively, if the "Softswitch" is really a > > > telephony application server (case #3 above), then it > > > probably already has HTTP server capability built-in. > > > > > > If we say SIP for stimulus reporting, then the diagram you > > > drew, with the implication that the signaling follows the > > > signaling path, is what will occur. > > > > > > Is this distinction important for you? The design team did > > > not come to full agreement on which way to go. Compelling > > > arguments either way welcomed. > > > > > > > > > > -----Original Message----- > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > > Sent: Friday, December 06, 2002 4:20 PM > > > > To: Eric Burger; Jain, Rajnish (Rajnish) > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup > between complex > > > > SIP UAs and apps? > > > > > > > > > > > > Eric, > > > > > > > > Thanks for your response. Would you be able to comment on the > > > > timeline of when does the design team hope to accomplish the > > > > following: > > > > > > > > - general acceptance of the stimulus signaling, KPML etc. > > > > - standardization of app interaction fwk, KPML into an RFC > > > > > > > > Regarding an example of a PSTN switch that can be > connected to a > > > > pre-paid app over SIP-T, I don't know how much I can > disclose in > > > > front of this forum, but that is something being looked at by a > > > > few telecom gear vendors in my understanding. > > > > > > > > I wanted to bring your attention to SIP-T wrt to my > > > previous question. > > > > I believe your answer will remain the same but I just to > > wanted to > > > > re-iterate the question in different words this time, > > just to make > > > > sure we're communicating: > > > > > > > > In the setup below: > > > > Pre-paid app > > > > | > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ---- > > > > > > > > > > > > .. you would think, application interaction framework concepts > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are > > > > designed to work over the SIP-T i/f between packet-enabled PSTN > > > > switch and a Softswitch. Wouldn't you? > > > > > > > > Thanks, > > > > Rajnish > > > > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish) > > > [mailto:rajnishjain@lucent.com] > > > > > > > > The Application Interaction Framework draft talks about stimulus > > > > signaling as a way for SIP UAs to interact w/ SIP > > applications. The > > > > draft suggests use of markup languages to allow > > > applications to manage > > > > local/remote user interfaces on SIP UAs. > > > > > > > > While the draft exemplifies a UA's stimulus/markup > interaction w/ > > > > a pre-paid application server, it is not very clear to > us if the > > > > caller UA (instead of a subscriber end-point) can be a > complex UA > > > > such as the following: > > > > > > > > - SIP (enabled) Gateway > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > - PSTN Switch w/ SIP-T interface > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > and does the draft recommend stimulus/markup signaling between > > > > such complex/concentrated UAs (or apps) and SIP applications ? > > > > > > The draft is silent on it. If you manufacture media rich > > > gateways, you might say "of course". If you manufacture > > > media servers, you might say "you could if you wanted, but > > > you would be better served if you didn't." :-) > > > > > > > In other words, does the stimulus signaling apply to following > > > > scenarios ?: > > > > > > > > 1. The pre-paid caller is connected to a PSTN switch that has a > > > > SIP-T interface to the pre-paid application. > > > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse > > > and execute KPML, and report using SIP (or, yuck, http). > > > > > > Do you know of such a switch? > > > > > > > 2. The pre-paid caller is connected to a PBX (SIP > Gateway) over an > > > > > ISDN i/f, which in turn is connected to the pre-paid app. over > > > > normal SIP. > > > > > > Same issues as for the PSTN switch. > > > > > > > If yes, would the terms client-local and client-remote still be > > > > accurate, as the user here is a POTS/ISDN user? From the user's > > > > perspective, the UI would be client-remote. But from > > application's > > > > perspective the UI would be client-local (as the UI will be > > > on the PBX > > > > or PSTN switch both of which look like a UA to app server). > > > > > > It is still client-local, as the gateway/switch/PBX is a > > > local proxy for the user. If you used a media server in the > > > IP network behind the gateway/switch/PBX to execute the KPML, > > > then you would be cline-remote. > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current > > > sip Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 18:11:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02501 for ; Tue, 7 Jan 2003 18:11:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07NLuS26599 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 18:21:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NLuJ26596 for ; Tue, 7 Jan 2003 18:21:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02399 for ; Tue, 7 Jan 2003 18:09:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NEHJ26152; Tue, 7 Jan 2003 18:14:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07N98J25951 for ; Tue, 7 Jan 2003 18:09:08 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02069 for ; Tue, 7 Jan 2003 17:57:37 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h07N1SpV028656 for ; Tue, 7 Jan 2003 18:01:32 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX49678; Tue, 7 Jan 2003 18:05:48 -0500 (EST) Message-ID: <3E1B5C1E.3090801@cisco.com> Date: Tue, 07 Jan 2003 18:00:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-barnes-sipping-history-info-01.txt References: <200212231254.HAA27412@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A comment about the recording of indices... The syntax hi-index = "index" EQUAL 1*(DIGIT DOT ) permits indices of "...", "1..3", ".2" etc. These seem to be incorrect. A better syntax would be hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) The only specification I could find for how this is maintained is in Section 2.2.3, which says: In order to maintain ordering and accurately reflect forking and nesting, the index should also be included, with the last digit being incremented as the request is retargeted. ... If the index is captured at each occurrence of retargeting, a proxy can more accurately capture the logical order and nesting involved. This doesn't seem like enough to specify the maintenance of the index. Although doing this is straightforward, there ought to be some normative language about it. For instance the following are some issues about responsibility: - if a proxy receives a request with a History-Info that has an index paramter, and adds another entry as it forwards the request on, MUST it place an index param on the new entry? If so, MUST it follow the intuitive rule for deriving the new index? (I think the answer should be YES to both of these.) - if a proxy receives a request with a History-Info that has no index parameter, and it adds another entry as it forwards the request on, MAY it place an index param on the new entry? (I think it MUST NOT, because it has no way to determine a correct value.) - if a proxy receives a request with no History-Info, and creates one with an initial entry, MAY it place an index param on the new entry? (I think it MUST NOT, because again it has no way to determine a correct value.) If you buy my answers to the above, then it is the UAC that determines whether indices are used. In any case, for the indices to be useful for anything there ought to be more normative text that specifies how they are managed. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 7 22:16:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09932 for ; Tue, 7 Jan 2003 22:16:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h083RwT08678 for sipping-archive@odin.ietf.org; Tue, 7 Jan 2003 22:27:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083RvJ08675 for ; Tue, 7 Jan 2003 22:27:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09926 for ; Tue, 7 Jan 2003 22:16:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083P0J08605; Tue, 7 Jan 2003 22:25:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h083NoJ08552 for ; Tue, 7 Jan 2003 22:23:50 -0500 Received: from imo-r04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09885 for ; Tue, 7 Jan 2003 22:12:20 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v34.13.) id 7.55.3592b34d (3657); Tue, 7 Jan 2003 22:15:15 -0500 (EST) Message-ID: <55.3592b34d.2b4cf1c3@aol.com> Date: Tue, 7 Jan 2003 22:15:15 EST Subject: Re: [Sipping] Comments on sos draft -03 (URI) To: hgs@cs.columbia.edu, Brian.Rosen@marconi.com CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 6.0 for Windows XP US sub 51 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In a message dated 1/7/2003 1:48:08 PM Eastern Standard Time, hgs@cs.columbia.edu writes: I don't know what you mean by 'local area'. I don't see how I can require Starbucks to support a PSTN gateway in each of its 802.11 hot spots. Are you mandating that every LAN, every 802.11 hotspot, every IETF wireless LAN has to have: - an outbound SIP proxy server, and - a PSTN gateway that can dial 911 ? [MAP] No, but if a LAN, 802.11 hotspot, etc claims to be providing "telephone service" then it should come under the regulatory requirements and provide proper service, which I believe requires what I was describing. Of course, if someone is not claiming to provide "telephone service", then it doesn't matter what happens or if their "home domain" fails to properly handle an emergency call. Rosen, Brian wrote: > > In most US enterprises, and for that matter, in most US college > campuses, the emergency number is 9-911. 911 would not connect [HS] I think there are attempts to change this; see http://emergency.lib.uci.edu/ or http://www.news.cornell.edu/Chronicle/97/7.24.97/911.html or http://www.med.umich.edu/medschool/faculty/handbook/phones.html for some quick Google research. I doubt that anybody sane will assign somebody extension 911. [MAP] I agree fully that no one should assign an extension of 911 if they can avoid it and private systems should allow 911 to be interpreted as a call to emergency, even without prefixing it with a "9", but the point is that we can't design SIP phones, or protocols, or proxy functioning based on an assumption that no one is doing this. (Incidentally, this mean that some hotels would have to get rid of room number 911, just as some airplanes don't have a row 13.) [HS] There are probably two pragmatic approaches: - Network-based: Don't assign 000, 08, 112, 110, 118, 119, 911 and 999 as regular numbers. 0-00 would seem to be difficult since that's the common way that you'd dial an international number from a European PBX phone. However, it should never appear as anything but the initial part of an overlap dialing string, which wouldn't be in a tel: URI to begin with. [MAP] So does this mean that none of these numbers could be used as extension numbers? Or hotel room numbers? [HS] One can argue how difficult it would be to vacate the other half dozen numbers. [MAP] And one must also presume that it will never happen, and accept that these dialing strings (or numbers starting with them) will forever exist somewhere in the telephony world. Mike Pierce Artel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 04:05:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14425 for ; Wed, 8 Jan 2003 04:05:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h089GC506705 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 04:16:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h089GBJ06702 for ; Wed, 8 Jan 2003 04:16:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14413 for ; Wed, 8 Jan 2003 04:04:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h089E3J06429; Wed, 8 Jan 2003 04:14:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h089CuJ06342 for ; Wed, 8 Jan 2003 04:12:56 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14265 for ; Wed, 8 Jan 2003 04:01:16 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0896Tt21523 for ; Wed, 8 Jan 2003 11:06:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 11:04:30 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 11:04:29 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 11:04:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Wed, 8 Jan 2003 11:04:28 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE70C7@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Thread-Index: AcK2Tx7fsfsYx14yRXSUmMADoydQZQAND8IAABxHdzA= To: , Cc: X-OriginalArrivalTime: 08 Jan 2003 09:04:28.0879 (UTC) FILETIME=[F33AD5F0:01C2B6F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h089CuJ06343 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit You can report KPML using HTTP, then use SUBSCRIBE/NOTIFY for stimulus reporting. But you might need to map one to the other using an id of some sort. Presence package coupled with some publishing mechanism is a similar example. (early presence publishing was done using HTTP). Regards, Hisham > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, January 07, 2003 10:00 PM > To: Steve Fisher > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > To answer the question directly: > > KPML only works with HTTP reporting. It would be a different > language for SIP reporting. MSCML is an example of a > language that uses SIP for reporting. > > > > To answer the SIP stimulus reporting question: > > Done INFO in the past, not planning on it again :-) > > NOTIFY is my leading contender, but a new method may be > needed because if you do a strict reading of NOTIFY, you > might not want a NOTIFY without a SUBSCRIBE. > > Using SUBSCRIBE as a method of pushing KPML is out and out > evil (I mean wrong). KPML changes the state of the UAS. > SUBSCRIBE is not supposed to have any side-effects. > > > > > -----Original Message----- > > From: Steve Fisher [mailto:sfisher1@att.com] > > Sent: Tuesday, January 07, 2003 8:15 AM > > To: Eric Burger > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Eric, > > > > I've been thinking about your statement below... > > > > > > If we say SIP for stimulus reporting, then the diagram > you drew, > > > > with the implication that the signaling follows the > > signaling path, > > > > is what will occur. > > > > > > > > Is this distinction important for you? The design team > > did not come > > > > > > to full agreement on which way to go. Compelling > > arguments either > > > > way welcomed. > > > > Could you possibly elaborate on how "SIP for stimulus > reporting" would > > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you > thinking of using > > INFO? It's fairly clear from the KPML draft how HTTP would > > work, but SIP > > was less clear to me... > > > > Thanks! > > Steve > > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On Behalf > > Of Eric Burger > > Sent: Tuesday, December 17, 2002 5:18 PM > > To: Don Stanwyck > > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish) > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Rajnish is 1000% correct in his interpretation. Looking at > > the message > > I can see how my statement isn't entirely clear. > > > > I am on record in this and other fora that H.248 and J.162 are the > > appropriate protocols for device control. See my posts to > > the speechsc > > list. I should have a paste buffer with my "Don't use SIP > > for low-level > > peripheral device control" rant. > > > > When I said "It [the thing referenced as "softswitch" in Rajnish's > > e-mail -- ewb] is not a media gateway controller" I meant > it was not a > > media gateway controller, e.g., a device control thing, which uses > > device control protocols like H.248 and J.162. > > > > Now it's my turn for interpreting Rajnish, instead of him > interpreting > > me :-) I assumed that the "PSTN X" thing was a MG-MGC combination, > > speaking SIP on the packet network side. E.g., the MG-MGC > > interface was > > a private matter, not of interest to the discussion. > > > > Sorry for the confusion. > > > > > -----Original Message----- > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > Sent: Tuesday, December 17, 2002 4:02 PM > > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish) > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs > > > and apps? > > > > > > > > > Don, > > > I don't think Eric implied controlling a MG from a Softswitch > > > via SIP in his > > > comment. That particular topic has come up in this forum many > > > times and as I > > > recall the conclusion has always been that SIP is not meant > > > for that. SIP is > > > a peer-to-peer to protocol not a master-slave protcol - > > > agreed. However this > > > is completely orthogonal to using stimulus/markup signaling > > > in SIP. I don't > > > see how in-lining a KPML doc (e.g.) in a SIP message breaks > > > SIP paradigm. > > > > > > Eric, > > > In general, I would like to propose an HTTP-free alternative > > > for delivery of > > > stimulus signals, such as through in-lining of KPML. The > > > benefits of such an > > > alternative in my mind are following: > > > > > > - it would make it easier for SIP developers on embedded > > > platforms to embrace > > > markup/stimulus signaling that don't support HTTP currently > > > > > > - it would facilitate close coordination between announcement > > > play and DTMF > > > collection. Barge-in is a good example for that. The app > > > can delegate the > > > job to stop announcement play at barge-in to the > > > Softswitch. As an aside, > > > the Softswitch in my previous figure is one w/ bizarre API > > > as you say :-) > > > > > > Rajnish > > > > > > -----Original Message----- > > > From: Don Stanwyck [mailto:don@stanwyck.com] > > > Sent: Tuesday, December 17, 2002 3:10 PM > > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)' > > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)' > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs > > > and apps? > > > > > > > > > RFC 3261, Section 2 reads: > > > > > > //START QUOTE > > > > > > SIP supports five facets of establishing and terminating > > > multimedia communications: > > > - User location: determination of the end system to be > > > used for communication; > > > - User availability: determination of the willingness > > > of the called party to engage in communications; > > > - User capabilities: determination of the media and media > > > parameters to be used; > > > - Session setup: "ringing", establishment of session > > > parameters at both called and calling party; > > > - Session management: including transfer and termination > > > of sessions, modifying session parameters, and invoking > > > services. > > > > > > SIP is not a vertically integrated communications system. > > > SIP is rather > > > a component that can be used with other IETF protocols to build a > > > complete multimedia architecture. Typically, these > > architectures will > > > include protocols such as the Real-time Transport Protocol > > (RTP) (RFC > > > 1889 [28]) for transporting real-time data and providing > > QoS feedback, > > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for > > > controlling > > > delivery of streaming media, the Media Gateway Control > > > Protocol (MEGACO) > > > (RFC 3015 [30]) for controlling gateways to the Public Switched > > > Telephone Network (PSTN), and the Session Description > Protocol (SDP) > > > (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP > > > should be used in conjunction with other protocols in order > > to provide > > > complete services to the users. However, the basic > > functionality and > > > operation of SIP does not depend on any of these protocols. > > > > > > //END QUOTE > > > > > > I can't find any support in this definition of SIP for > > > carrying stimulus > > > signaling or for controling media gateways (comment 1 in Eric's > > > comments). SIP, as defined and approved by the IETF, is not > > > expected to > > > do these kinds of things that other IETF protocols are designed to > > > handle. > > > > > > Let's try to keep SIP doing the things it is designed to do > > and does > > > well, and not try to make it into a protocol for doing everything > > > imaginable. It is already in danger of becoming too difficult to > > > implement as the number of options and new headers grows. > > > > > > Don Stanwyck > > > > > > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > On Behalf Of Eric Burger > > > > Sent: Tuesday, December 17, 2002 12:12 PM > > > > To: Jain, Rajnish (Rajnish) > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > > complex SIP UAs and apps? > > > > > > > > > > > > For timelines, I would suggest asking the work group chairs. > > > > We're at their mercy :-) > > > > > > > > Putting my ISC hat on, what is the Softswitch in your diagram? > > > > 1. It is not a media gateway controller, as it talks to > > > > the gateway with SIP (right answer, by the way). > > > > 2. Is it a Stateless Proxy, a'la the Routing Function > > > > in the ISC reference diagram? If so, that works > > > > exactly as you want it to. See below for more. > > > > 3. Is it an application server, a'la dynamicsoft, > > > > Ubiquity, LongBoard, etc.? If so, that also works > > > > exactly as you want it to. See below for more. > > > > 4. Is it some kind of statefull proxy, with a bizarre, > > > > proprietary API to the pre-paid application (e.g., > > > > Parlay, JAIN, EXS, ...)? If so, you are on your > > > > own. > > > > > > > > If we say "HTTP only" for stimulus reporting, the PSTN > > > > gateway must be a HTTP client. The good news is the gateway > > > > can communicate directly with the pre-paid application. That > > > > also means the pre-paid application needs to have a HTTP > > > > server. Alternatively, if the "Softswitch" is really a > > > > telephony application server (case #3 above), then it > > > > probably already has HTTP server capability built-in. > > > > > > > > If we say SIP for stimulus reporting, then the diagram you > > > > drew, with the implication that the signaling follows the > > > > signaling path, is what will occur. > > > > > > > > Is this distinction important for you? The design team did > > > > not come to full agreement on which way to go. Compelling > > > > arguments either way welcomed. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > > > Sent: Friday, December 06, 2002 4:20 PM > > > > > To: Eric Burger; Jain, Rajnish (Rajnish) > > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup > > between complex > > > > > SIP UAs and apps? > > > > > > > > > > > > > > > Eric, > > > > > > > > > > Thanks for your response. Would you be able to comment on the > > > > > timeline of when does the design team hope to accomplish the > > > > > following: > > > > > > > > > > - general acceptance of the stimulus signaling, KPML etc. > > > > > - standardization of app interaction fwk, KPML into an RFC > > > > > > > > > > Regarding an example of a PSTN switch that can be > > connected to a > > > > > pre-paid app over SIP-T, I don't know how much I can > > disclose in > > > > > front of this forum, but that is something being > looked at by a > > > > > few telecom gear vendors in my understanding. > > > > > > > > > > I wanted to bring your attention to SIP-T wrt to my > > > > previous question. > > > > > I believe your answer will remain the same but I just to > > > wanted to > > > > > re-iterate the question in different words this time, > > > just to make > > > > > sure we're communicating: > > > > > > > > > > In the setup below: > > > > > Pre-paid app > > > > > | > > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ---- > > > > > > > > > > > > > > > .. you would think, application interaction framework > concepts > > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are > > > > > designed to work over the SIP-T i/f between > packet-enabled PSTN > > > > > switch and a Softswitch. Wouldn't you? > > > > > > > > > > Thanks, > > > > > Rajnish > > > > > > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish) > > > > [mailto:rajnishjain@lucent.com] > > > > > > > > > > The Application Interaction Framework draft talks > about stimulus > > > > > signaling as a way for SIP UAs to interact w/ SIP > > > applications. The > > > > > draft suggests use of markup languages to allow > > > > applications to manage > > > > > local/remote user interfaces on SIP UAs. > > > > > > > > > > While the draft exemplifies a UA's stimulus/markup > > interaction w/ > > > > > a pre-paid application server, it is not very clear to > > us if the > > > > > caller UA (instead of a subscriber end-point) can be a > > complex UA > > > > > such as the following: > > > > > > > > > > - SIP (enabled) Gateway > > > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > > > - PSTN Switch w/ SIP-T interface > > > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > > > and does the draft recommend stimulus/markup > signaling between > > > > > such complex/concentrated UAs (or apps) and SIP applications ? > > > > > > > > The draft is silent on it. If you manufacture media rich > > > > gateways, you might say "of course". If you manufacture > > > > media servers, you might say "you could if you wanted, but > > > > you would be better served if you didn't." :-) > > > > > > > > > In other words, does the stimulus signaling apply to following > > > > > scenarios ?: > > > > > > > > > > 1. The pre-paid caller is connected to a PSTN switch > that has a > > > > > SIP-T interface to the pre-paid application. > > > > > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse > > > > and execute KPML, and report using SIP (or, yuck, http). > > > > > > > > Do you know of such a switch? > > > > > > > > > 2. The pre-paid caller is connected to a PBX (SIP > > Gateway) over an > > > > > > > ISDN i/f, which in turn is connected to the pre-paid > app. over > > > > > normal SIP. > > > > > > > > Same issues as for the PSTN switch. > > > > > > > > > If yes, would the terms client-local and > client-remote still be > > > > > accurate, as the user here is a POTS/ISDN user? From > the user's > > > > > perspective, the UI would be client-remote. But from > > > application's > > > > > perspective the UI would be client-local (as the UI will be > > > > on the PBX > > > > > or PSTN switch both of which look like a UA to app server). > > > > > > > > It is still client-local, as the gateway/switch/PBX is a > > > > local proxy for the user. If you used a media server in the > > > > IP network behind the gateway/switch/PBX to execute the KPML, > > > > then you would be cline-remote. > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on current > > > > sip Use sip@ietf.org for new developments of core SIP > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 05:32:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15979 for ; Wed, 8 Jan 2003 05:32:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08AhvS12017 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 05:43:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08AhuJ12013 for ; Wed, 8 Jan 2003 05:43:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15960 for ; Wed, 8 Jan 2003 05:32:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08AfMJ11922; Wed, 8 Jan 2003 05:41:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Ae9J11878 for ; Wed, 8 Jan 2003 05:40:09 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15905 for ; Wed, 8 Jan 2003 05:28:30 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h08AVhB13469 for ; Wed, 8 Jan 2003 05:31:43 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 10:31:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB84@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henning Schulzrinne'" , "Drage, Keith (Keith)" Cc: "Mills, Duncan, D, CND Tech Dev, VF UK" , sipping@ietf.org Subject: RE: [Sipping] Re: Comments on revised 'sos' draft Date: Wed, 8 Jan 2003 10:31:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , see below (original snipped) Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > > > I've added a reference to this. I suppose for an 802.11 wireless base > station, the basestation MAC address would be the equivalent. Any > interest in defining this, given that the draft already lists > IEEE-802.11a and IEEE-802.11b as access-types? > There is work going on in 3GPP release 6 on using wireless LAN as an access mechanism to 3GPP. This has not yet addressed the issue of SIP users on the wireless LAN accssing the IM CN subsystem within 3GPP. There are still more fundamental architectural issues being addressed. I would expect some specification of the requirement here to eventually fall out of this, but it is too early to say yet which specification it will end up in (whether it be 3GPP or IEEE). > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 06:33:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17011 for ; Wed, 8 Jan 2003 06:33:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08BijD15543 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 06:44:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BijJ15540 for ; Wed, 8 Jan 2003 06:44:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16984 for ; Wed, 8 Jan 2003 06:32:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BhWJ15505; Wed, 8 Jan 2003 06:43:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BgYJ15464 for ; Wed, 8 Jan 2003 06:42:34 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16943 for ; Wed, 8 Jan 2003 06:30:51 -0500 (EST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h08BY6205350 for ; Wed, 8 Jan 2003 06:34:06 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 06:34:06 -0500 Message-ID: From: "Jain, Rajnish (Rajnish)" To: "'Eric Burger'" , Steve Fisher Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs a nd apps? Date: Wed, 8 Jan 2003 06:34:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Eric, Can you expand on why sending KPML w/in SUBSCRIBE is a bad idea? In other words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. A SUBSCRIBE message w/ inline KPML should be oblivious to UA session FSM. It's an orthogonal activity from UA's perspective. Upon receipt of a KPML request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF collecion and report digits to app (via NOTIFY). This shouldn't change the state of SIP session w/in UA. Rajnish -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Tuesday, January 07, 2003 3:00 PM To: Steve Fisher Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? To answer the question directly: KPML only works with HTTP reporting. It would be a different language for SIP reporting. MSCML is an example of a language that uses SIP for reporting. To answer the SIP stimulus reporting question: Done INFO in the past, not planning on it again :-) NOTIFY is my leading contender, but a new method may be needed because if you do a strict reading of NOTIFY, you might not want a NOTIFY without a SUBSCRIBE. Using SUBSCRIBE as a method of pushing KPML is out and out evil (I mean wrong). KPML changes the state of the UAS. SUBSCRIBE is not supposed to have any side-effects. > -----Original Message----- > From: Steve Fisher [mailto:sfisher1@att.com] > Sent: Tuesday, January 07, 2003 8:15 AM > To: Eric Burger > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Eric, > > I've been thinking about your statement below... > > > > If we say SIP for stimulus reporting, then the diagram you drew, > > > with the implication that the signaling follows the > signaling path, > > > is what will occur. > > > > > > Is this distinction important for you? The design team > did not come > > > > to full agreement on which way to go. Compelling > arguments either > > > way welcomed. > > Could you possibly elaborate on how "SIP for stimulus reporting" would > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using > INFO? It's fairly clear from the KPML draft how HTTP would > work, but SIP > was less clear to me... > > Thanks! > Steve > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of Eric Burger > Sent: Tuesday, December 17, 2002 5:18 PM > To: Don Stanwyck > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish) > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Rajnish is 1000% correct in his interpretation. Looking at > the message > I can see how my statement isn't entirely clear. > > I am on record in this and other fora that H.248 and J.162 are the > appropriate protocols for device control. See my posts to > the speechsc > list. I should have a paste buffer with my "Don't use SIP > for low-level > peripheral device control" rant. > > When I said "It [the thing referenced as "softswitch" in Rajnish's > e-mail -- ewb] is not a media gateway controller" I meant it was not a > media gateway controller, e.g., a device control thing, which uses > device control protocols like H.248 and J.162. > > Now it's my turn for interpreting Rajnish, instead of him interpreting > me :-) I assumed that the "PSTN X" thing was a MG-MGC combination, > speaking SIP on the packet network side. E.g., the MG-MGC > interface was > a private matter, not of interest to the discussion. > > Sorry for the confusion. > > > -----Original Message----- > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > Sent: Tuesday, December 17, 2002 4:02 PM > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish) > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Don, > > I don't think Eric implied controlling a MG from a Softswitch > > via SIP in his > > comment. That particular topic has come up in this forum many > > times and as I > > recall the conclusion has always been that SIP is not meant > > for that. SIP is > > a peer-to-peer to protocol not a master-slave protcol - > > agreed. However this > > is completely orthogonal to using stimulus/markup signaling > > in SIP. I don't > > see how in-lining a KPML doc (e.g.) in a SIP message breaks > > SIP paradigm. > > > > Eric, > > In general, I would like to propose an HTTP-free alternative > > for delivery of > > stimulus signals, such as through in-lining of KPML. The > > benefits of such an > > alternative in my mind are following: > > > > - it would make it easier for SIP developers on embedded > > platforms to embrace > > markup/stimulus signaling that don't support HTTP currently > > > > - it would facilitate close coordination between announcement > > play and DTMF > > collection. Barge-in is a good example for that. The app > > can delegate the > > job to stop announcement play at barge-in to the > > Softswitch. As an aside, > > the Softswitch in my previous figure is one w/ bizarre API > > as you say :-) > > > > Rajnish > > > > -----Original Message----- > > From: Don Stanwyck [mailto:don@stanwyck.com] > > Sent: Tuesday, December 17, 2002 3:10 PM > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)' > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)' > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > RFC 3261, Section 2 reads: > > > > //START QUOTE > > > > SIP supports five facets of establishing and terminating > > multimedia communications: > > - User location: determination of the end system to be > > used for communication; > > - User availability: determination of the willingness > > of the called party to engage in communications; > > - User capabilities: determination of the media and media > > parameters to be used; > > - Session setup: "ringing", establishment of session > > parameters at both called and calling party; > > - Session management: including transfer and termination > > of sessions, modifying session parameters, and invoking > > services. > > > > SIP is not a vertically integrated communications system. > > SIP is rather > > a component that can be used with other IETF protocols to build a > > complete multimedia architecture. Typically, these > architectures will > > include protocols such as the Real-time Transport Protocol > (RTP) (RFC > > 1889 [28]) for transporting real-time data and providing > QoS feedback, > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for > > controlling > > delivery of streaming media, the Media Gateway Control > > Protocol (MEGACO) > > (RFC 3015 [30]) for controlling gateways to the Public Switched > > Telephone Network (PSTN), and the Session Description Protocol (SDP) > > (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP > > should be used in conjunction with other protocols in order > to provide > > complete services to the users. However, the basic > functionality and > > operation of SIP does not depend on any of these protocols. > > > > //END QUOTE > > > > I can't find any support in this definition of SIP for > > carrying stimulus > > signaling or for controling media gateways (comment 1 in Eric's > > comments). SIP, as defined and approved by the IETF, is not > > expected to > > do these kinds of things that other IETF protocols are designed to > > handle. > > > > Let's try to keep SIP doing the things it is designed to do > and does > > well, and not try to make it into a protocol for doing everything > > imaginable. It is already in danger of becoming too difficult to > > implement as the number of options and new headers grows. > > > > Don Stanwyck > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of Eric Burger > > > Sent: Tuesday, December 17, 2002 12:12 PM > > > To: Jain, Rajnish (Rajnish) > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs and apps? > > > > > > > > > For timelines, I would suggest asking the work group chairs. > > > We're at their mercy :-) > > > > > > Putting my ISC hat on, what is the Softswitch in your diagram? > > > 1. It is not a media gateway controller, as it talks to > > > the gateway with SIP (right answer, by the way). > > > 2. Is it a Stateless Proxy, a'la the Routing Function > > > in the ISC reference diagram? If so, that works > > > exactly as you want it to. See below for more. > > > 3. Is it an application server, a'la dynamicsoft, > > > Ubiquity, LongBoard, etc.? If so, that also works > > > exactly as you want it to. See below for more. > > > 4. Is it some kind of statefull proxy, with a bizarre, > > > proprietary API to the pre-paid application (e.g., > > > Parlay, JAIN, EXS, ...)? If so, you are on your > > > own. > > > > > > If we say "HTTP only" for stimulus reporting, the PSTN > > > gateway must be a HTTP client. The good news is the gateway > > > can communicate directly with the pre-paid application. That > > > also means the pre-paid application needs to have a HTTP > > > server. Alternatively, if the "Softswitch" is really a > > > telephony application server (case #3 above), then it > > > probably already has HTTP server capability built-in. > > > > > > If we say SIP for stimulus reporting, then the diagram you > > > drew, with the implication that the signaling follows the > > > signaling path, is what will occur. > > > > > > Is this distinction important for you? The design team did > > > not come to full agreement on which way to go. Compelling > > > arguments either way welcomed. > > > > > > > > > > -----Original Message----- > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > > Sent: Friday, December 06, 2002 4:20 PM > > > > To: Eric Burger; Jain, Rajnish (Rajnish) > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup > between complex > > > > SIP UAs and apps? > > > > > > > > > > > > Eric, > > > > > > > > Thanks for your response. Would you be able to comment on the > > > > timeline of when does the design team hope to accomplish the > > > > following: > > > > > > > > - general acceptance of the stimulus signaling, KPML etc. > > > > - standardization of app interaction fwk, KPML into an RFC > > > > > > > > Regarding an example of a PSTN switch that can be > connected to a > > > > pre-paid app over SIP-T, I don't know how much I can > disclose in > > > > front of this forum, but that is something being looked at by a > > > > few telecom gear vendors in my understanding. > > > > > > > > I wanted to bring your attention to SIP-T wrt to my > > > previous question. > > > > I believe your answer will remain the same but I just to > > wanted to > > > > re-iterate the question in different words this time, > > just to make > > > > sure we're communicating: > > > > > > > > In the setup below: > > > > Pre-paid app > > > > | > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ---- > > > > > > > > > > > > .. you would think, application interaction framework concepts > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are > > > > designed to work over the SIP-T i/f between packet-enabled PSTN > > > > switch and a Softswitch. Wouldn't you? > > > > > > > > Thanks, > > > > Rajnish > > > > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish) > > > [mailto:rajnishjain@lucent.com] > > > > > > > > The Application Interaction Framework draft talks about stimulus > > > > signaling as a way for SIP UAs to interact w/ SIP > > applications. The > > > > draft suggests use of markup languages to allow > > > applications to manage > > > > local/remote user interfaces on SIP UAs. > > > > > > > > While the draft exemplifies a UA's stimulus/markup > interaction w/ > > > > a pre-paid application server, it is not very clear to > us if the > > > > caller UA (instead of a subscriber end-point) can be a > complex UA > > > > such as the following: > > > > > > > > - SIP (enabled) Gateway > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > - PSTN Switch w/ SIP-T interface > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > and does the draft recommend stimulus/markup signaling between > > > > such complex/concentrated UAs (or apps) and SIP applications ? > > > > > > The draft is silent on it. If you manufacture media rich > > > gateways, you might say "of course". If you manufacture > > > media servers, you might say "you could if you wanted, but > > > you would be better served if you didn't." :-) > > > > > > > In other words, does the stimulus signaling apply to following > > > > scenarios ?: > > > > > > > > 1. The pre-paid caller is connected to a PSTN switch that has a > > > > SIP-T interface to the pre-paid application. > > > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse > > > and execute KPML, and report using SIP (or, yuck, http). > > > > > > Do you know of such a switch? > > > > > > > 2. The pre-paid caller is connected to a PBX (SIP > Gateway) over an > > > > > ISDN i/f, which in turn is connected to the pre-paid app. over > > > > normal SIP. > > > > > > Same issues as for the PSTN switch. > > > > > > > If yes, would the terms client-local and client-remote still be > > > > accurate, as the user here is a POTS/ISDN user? From the user's > > > > perspective, the UI would be client-remote. But from > > application's > > > > perspective the UI would be client-local (as the UI will be > > > on the PBX > > > > or PSTN switch both of which look like a UA to app server). > > > > > > It is still client-local, as the gateway/switch/PBX is a > > > local proxy for the user. If you used a media server in the > > > IP network behind the gateway/switch/PBX to execute the KPML, > > > then you would be cline-remote. > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current > > > sip Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 08:53:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19797 for ; Wed, 8 Jan 2003 08:53:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08E4Ee22881 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 09:04:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08E4DJ22878 for ; Wed, 8 Jan 2003 09:04:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19789 for ; Wed, 8 Jan 2003 08:52:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08E2pJ22832; Wed, 8 Jan 2003 09:02:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08E1OJ22732 for ; Wed, 8 Jan 2003 09:01:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19584; Wed, 8 Jan 2003 08:49:38 -0500 (EST) Message-Id: <200301081349.IAA19584@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 08 Jan 2003 08:49:38 -0500 Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIME media types for DPNSS Objects Author(s) : R. Mukundan et al. Filename : draft-mukundan-sipping-dpnss-00.txt Pages : 9 Date : 2003-1-7 This document describes MIME type for application/DPNSS objects for use in SIP [3] applications, according to the rules defined in RFC 2048 [4]. These types can be used to identify Digital Private Network Signaling System 1 (DPNSS 1) [2] objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to DPNSS based Private Networks. RFC 3204 [9] addresses a similar need for ISUP and QSIG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mukundan-sipping-dpnss-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mukundan-sipping-dpnss-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-7160918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mukundan-sipping-dpnss-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mukundan-sipping-dpnss-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-7160918.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 09:06:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20157 for ; Wed, 8 Jan 2003 09:06:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08EHfu24140 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 09:17:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EHfJ24137 for ; Wed, 8 Jan 2003 09:17:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20046 for ; Wed, 8 Jan 2003 09:01:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EC7J23903; Wed, 8 Jan 2003 09:12:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EBuJ23876 for ; Wed, 8 Jan 2003 09:11:56 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19979 for ; Wed, 8 Jan 2003 09:00:09 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08E5Ot00852 for ; Wed, 8 Jan 2003 16:05:24 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 16:03:25 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 16:03:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Wed, 8 Jan 2003 16:03:23 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE70D2@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Thread-Index: AcK3Cv1oSugmyIh5SG2i6x1kj1m4SgAEvC1g To: , , Cc: X-OriginalArrivalTime: 08 Jan 2003 14:03:25.0037 (UTC) FILETIME=[B60359D0:01C2B71E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08EBuJ23877 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The body of a SUBSCRIBE should be used for things like filtering. Something related to the subscription itself. Putting KMPL in the body of SUBSCRIBE is considered as a form of tunnelling, IMO. We try to keep a use of a certain SIP method, header, or whatever to a minimum, preferably one. Bodies of INVITEs typically carry information about the session. KPML, I would consider, a type of session description. Regards, Hisham > -----Original Message----- > From: ext Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > Sent: Wednesday, January 08, 2003 1:34 PM > To: 'Eric Burger'; Steve Fisher > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Eric, > Can you expand on why sending KPML w/in SUBSCRIBE is a bad > idea? In other > words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. > > A SUBSCRIBE message w/ inline KPML should be oblivious to UA > session FSM. > It's an orthogonal activity from UA's perspective. Upon > receipt of a KPML > request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF > collecion and > report digits to app (via NOTIFY). This shouldn't change the > state of SIP > session w/in UA. > > Rajnish > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, January 07, 2003 3:00 PM > To: Steve Fisher > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > To answer the question directly: > > KPML only works with HTTP reporting. It would be a different > language for SIP reporting. MSCML is an example of a > language that uses SIP for reporting. > > > > To answer the SIP stimulus reporting question: > > Done INFO in the past, not planning on it again :-) > > NOTIFY is my leading contender, but a new method may be > needed because if you do a strict reading of NOTIFY, you > might not want a NOTIFY without a SUBSCRIBE. > > Using SUBSCRIBE as a method of pushing KPML is out and out > evil (I mean wrong). KPML changes the state of the UAS. > SUBSCRIBE is not supposed to have any side-effects. > > > > > -----Original Message----- > > From: Steve Fisher [mailto:sfisher1@att.com] > > Sent: Tuesday, January 07, 2003 8:15 AM > > To: Eric Burger > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Eric, > > > > I've been thinking about your statement below... > > > > > > If we say SIP for stimulus reporting, then the diagram > you drew, > > > > with the implication that the signaling follows the > > signaling path, > > > > is what will occur. > > > > > > > > Is this distinction important for you? The design team > > did not come > > > > > > to full agreement on which way to go. Compelling > > arguments either > > > > way welcomed. > > > > Could you possibly elaborate on how "SIP for stimulus > reporting" would > > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you > thinking of using > > INFO? It's fairly clear from the KPML draft how HTTP would > > work, but SIP > > was less clear to me... > > > > Thanks! > > Steve > > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On Behalf > > Of Eric Burger > > Sent: Tuesday, December 17, 2002 5:18 PM > > To: Don Stanwyck > > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish) > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Rajnish is 1000% correct in his interpretation. Looking at > > the message > > I can see how my statement isn't entirely clear. > > > > I am on record in this and other fora that H.248 and J.162 are the > > appropriate protocols for device control. See my posts to > > the speechsc > > list. I should have a paste buffer with my "Don't use SIP > > for low-level > > peripheral device control" rant. > > > > When I said "It [the thing referenced as "softswitch" in Rajnish's > > e-mail -- ewb] is not a media gateway controller" I meant > it was not a > > media gateway controller, e.g., a device control thing, which uses > > device control protocols like H.248 and J.162. > > > > Now it's my turn for interpreting Rajnish, instead of him > interpreting > > me :-) I assumed that the "PSTN X" thing was a MG-MGC combination, > > speaking SIP on the packet network side. E.g., the MG-MGC > > interface was > > a private matter, not of interest to the discussion. > > > > Sorry for the confusion. > > > > > -----Original Message----- > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > Sent: Tuesday, December 17, 2002 4:02 PM > > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish) > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs > > > and apps? > > > > > > > > > Don, > > > I don't think Eric implied controlling a MG from a Softswitch > > > via SIP in his > > > comment. That particular topic has come up in this forum many > > > times and as I > > > recall the conclusion has always been that SIP is not meant > > > for that. SIP is > > > a peer-to-peer to protocol not a master-slave protcol - > > > agreed. However this > > > is completely orthogonal to using stimulus/markup signaling > > > in SIP. I don't > > > see how in-lining a KPML doc (e.g.) in a SIP message breaks > > > SIP paradigm. > > > > > > Eric, > > > In general, I would like to propose an HTTP-free alternative > > > for delivery of > > > stimulus signals, such as through in-lining of KPML. The > > > benefits of such an > > > alternative in my mind are following: > > > > > > - it would make it easier for SIP developers on embedded > > > platforms to embrace > > > markup/stimulus signaling that don't support HTTP currently > > > > > > - it would facilitate close coordination between announcement > > > play and DTMF > > > collection. Barge-in is a good example for that. The app > > > can delegate the > > > job to stop announcement play at barge-in to the > > > Softswitch. As an aside, > > > the Softswitch in my previous figure is one w/ bizarre API > > > as you say :-) > > > > > > Rajnish > > > > > > -----Original Message----- > > > From: Don Stanwyck [mailto:don@stanwyck.com] > > > Sent: Tuesday, December 17, 2002 3:10 PM > > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)' > > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)' > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs > > > and apps? > > > > > > > > > RFC 3261, Section 2 reads: > > > > > > //START QUOTE > > > > > > SIP supports five facets of establishing and terminating > > > multimedia communications: > > > - User location: determination of the end system to be > > > used for communication; > > > - User availability: determination of the willingness > > > of the called party to engage in communications; > > > - User capabilities: determination of the media and media > > > parameters to be used; > > > - Session setup: "ringing", establishment of session > > > parameters at both called and calling party; > > > - Session management: including transfer and termination > > > of sessions, modifying session parameters, and invoking > > > services. > > > > > > SIP is not a vertically integrated communications system. > > > SIP is rather > > > a component that can be used with other IETF protocols to build a > > > complete multimedia architecture. Typically, these > > architectures will > > > include protocols such as the Real-time Transport Protocol > > (RTP) (RFC > > > 1889 [28]) for transporting real-time data and providing > > QoS feedback, > > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for > > > controlling > > > delivery of streaming media, the Media Gateway Control > > > Protocol (MEGACO) > > > (RFC 3015 [30]) for controlling gateways to the Public Switched > > > Telephone Network (PSTN), and the Session Description > Protocol (SDP) > > > (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP > > > should be used in conjunction with other protocols in order > > to provide > > > complete services to the users. However, the basic > > functionality and > > > operation of SIP does not depend on any of these protocols. > > > > > > //END QUOTE > > > > > > I can't find any support in this definition of SIP for > > > carrying stimulus > > > signaling or for controling media gateways (comment 1 in Eric's > > > comments). SIP, as defined and approved by the IETF, is not > > > expected to > > > do these kinds of things that other IETF protocols are designed to > > > handle. > > > > > > Let's try to keep SIP doing the things it is designed to do > > and does > > > well, and not try to make it into a protocol for doing everything > > > imaginable. It is already in danger of becoming too difficult to > > > implement as the number of options and new headers grows. > > > > > > Don Stanwyck > > > > > > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > On Behalf Of Eric Burger > > > > Sent: Tuesday, December 17, 2002 12:12 PM > > > > To: Jain, Rajnish (Rajnish) > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > > complex SIP UAs and apps? > > > > > > > > > > > > For timelines, I would suggest asking the work group chairs. > > > > We're at their mercy :-) > > > > > > > > Putting my ISC hat on, what is the Softswitch in your diagram? > > > > 1. It is not a media gateway controller, as it talks to > > > > the gateway with SIP (right answer, by the way). > > > > 2. Is it a Stateless Proxy, a'la the Routing Function > > > > in the ISC reference diagram? If so, that works > > > > exactly as you want it to. See below for more. > > > > 3. Is it an application server, a'la dynamicsoft, > > > > Ubiquity, LongBoard, etc.? If so, that also works > > > > exactly as you want it to. See below for more. > > > > 4. Is it some kind of statefull proxy, with a bizarre, > > > > proprietary API to the pre-paid application (e.g., > > > > Parlay, JAIN, EXS, ...)? If so, you are on your > > > > own. > > > > > > > > If we say "HTTP only" for stimulus reporting, the PSTN > > > > gateway must be a HTTP client. The good news is the gateway > > > > can communicate directly with the pre-paid application. That > > > > also means the pre-paid application needs to have a HTTP > > > > server. Alternatively, if the "Softswitch" is really a > > > > telephony application server (case #3 above), then it > > > > probably already has HTTP server capability built-in. > > > > > > > > If we say SIP for stimulus reporting, then the diagram you > > > > drew, with the implication that the signaling follows the > > > > signaling path, is what will occur. > > > > > > > > Is this distinction important for you? The design team did > > > > not come to full agreement on which way to go. Compelling > > > > arguments either way welcomed. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > > > Sent: Friday, December 06, 2002 4:20 PM > > > > > To: Eric Burger; Jain, Rajnish (Rajnish) > > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup > > between complex > > > > > SIP UAs and apps? > > > > > > > > > > > > > > > Eric, > > > > > > > > > > Thanks for your response. Would you be able to comment on the > > > > > timeline of when does the design team hope to accomplish the > > > > > following: > > > > > > > > > > - general acceptance of the stimulus signaling, KPML etc. > > > > > - standardization of app interaction fwk, KPML into an RFC > > > > > > > > > > Regarding an example of a PSTN switch that can be > > connected to a > > > > > pre-paid app over SIP-T, I don't know how much I can > > disclose in > > > > > front of this forum, but that is something being > looked at by a > > > > > few telecom gear vendors in my understanding. > > > > > > > > > > I wanted to bring your attention to SIP-T wrt to my > > > > previous question. > > > > > I believe your answer will remain the same but I just to > > > wanted to > > > > > re-iterate the question in different words this time, > > > just to make > > > > > sure we're communicating: > > > > > > > > > > In the setup below: > > > > > Pre-paid app > > > > > | > > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ---- > > > > > > > > > > > > > > > .. you would think, application interaction framework > concepts > > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are > > > > > designed to work over the SIP-T i/f between > packet-enabled PSTN > > > > > switch and a Softswitch. Wouldn't you? > > > > > > > > > > Thanks, > > > > > Rajnish > > > > > > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish) > > > > [mailto:rajnishjain@lucent.com] > > > > > > > > > > The Application Interaction Framework draft talks > about stimulus > > > > > signaling as a way for SIP UAs to interact w/ SIP > > > applications. The > > > > > draft suggests use of markup languages to allow > > > > applications to manage > > > > > local/remote user interfaces on SIP UAs. > > > > > > > > > > While the draft exemplifies a UA's stimulus/markup > > interaction w/ > > > > > a pre-paid application server, it is not very clear to > > us if the > > > > > caller UA (instead of a subscriber end-point) can be a > > complex UA > > > > > such as the following: > > > > > > > > > > - SIP (enabled) Gateway > > > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > > > - PSTN Switch w/ SIP-T interface > > > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > > > and does the draft recommend stimulus/markup > signaling between > > > > > such complex/concentrated UAs (or apps) and SIP applications ? > > > > > > > > The draft is silent on it. If you manufacture media rich > > > > gateways, you might say "of course". If you manufacture > > > > media servers, you might say "you could if you wanted, but > > > > you would be better served if you didn't." :-) > > > > > > > > > In other words, does the stimulus signaling apply to following > > > > > scenarios ?: > > > > > > > > > > 1. The pre-paid caller is connected to a PSTN switch > that has a > > > > > SIP-T interface to the pre-paid application. > > > > > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse > > > > and execute KPML, and report using SIP (or, yuck, http). > > > > > > > > Do you know of such a switch? > > > > > > > > > 2. The pre-paid caller is connected to a PBX (SIP > > Gateway) over an > > > > > > > ISDN i/f, which in turn is connected to the pre-paid > app. over > > > > > normal SIP. > > > > > > > > Same issues as for the PSTN switch. > > > > > > > > > If yes, would the terms client-local and > client-remote still be > > > > > accurate, as the user here is a POTS/ISDN user? From > the user's > > > > > perspective, the UI would be client-remote. But from > > > application's > > > > > perspective the UI would be client-local (as the UI will be > > > > on the PBX > > > > > or PSTN switch both of which look like a UA to app server). > > > > > > > > It is still client-local, as the gateway/switch/PBX is a > > > > local proxy for the user. If you used a media server in the > > > > IP network behind the gateway/switch/PBX to execute the KPML, > > > > then you would be cline-remote. > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on current > > > > sip Use sip@ietf.org for new developments of core SIP > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 09:39:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21179 for ; Wed, 8 Jan 2003 09:39:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Eonx26510 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 09:50:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EonJ26507 for ; Wed, 8 Jan 2003 09:50:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21165 for ; Wed, 8 Jan 2003 09:38:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EnWJ26429; Wed, 8 Jan 2003 09:49:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08EmxJ26383 for ; Wed, 8 Jan 2003 09:48:59 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21154 for ; Wed, 8 Jan 2003 09:37:13 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h08EeR91005302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Jan 2003 09:40:27 -0500 (EST) Message-ID: <3E1C3873.8000503@cs.columbia.edu> Date: Wed, 08 Jan 2003 09:40:51 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: Brian.Rosen@marconi.com, sipping@ietf.org Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: <55.3592b34d.2b4cf1c3@aol.com> In-Reply-To: <55.3592b34d.2b4cf1c3@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [MAP] No, but if a LAN, 802.11 hotspot, etc claims to be providing "telephone > service" then it should come under the regulatory requirements and provide > proper service, which I believe requires what I was describing. Of course, if > someone is not claiming to provide "telephone service", then it doesn't > matter what happens or if their "home domain" fails to properly handle an > emergency call. I have control over my home domain, so it makes sense to put more responsibility on it. LANs shouldn't have to provide 'telephone service'; things should work if they provide IP transport. That's the Internet approach. > [MAP] I agree fully that no one should assign an extension of 911 if they can > avoid it and private systems should allow 911 to be interpreted as a call to > emergency, even without prefixing it with a "9", but the point is that we > can't design SIP phones, or protocols, or proxy functioning based on an > assumption that no one is doing this. (Incidentally, this mean that some > hotels would have to get rid of room number 911, just as some airplanes don't > have a row 13.) I agree that this isn't ideal. However, in practice, we probably will have two cases that may make this point moot: - The hotel or business has its own VoIP phone system. In that case, with the DHCP option outlined in the 04 draft, the device can discover both the outbound proxy and the local emergency numbers. - If a business has extensions, but no local SIP service (say, just a local wireless LAN), the issue doesn't arise, since you'd have to dial the E.164 number anyway. In that case, the default lists of numbers kicks in. I think this covers the practically useful cases; I will change the 04 draft to only suggest using the default list if there's no local knowledge. (Since, in that case, the extension problem won't appear to begin with.) The DHCP advertisement should advertise the local emergency number, but also all of the 'customary' emergency numbers that are not used for non-emergency uses. In other words, if a hotel in Europe doesn't have room 911, it should allow this as an emergency number, to accomodate the US or Canadian traveler. This is not perfect for the traveler (since some of his familiar numbers may no longer work), but my hope is that most SIP devices will come equipped with an 'SOS' button which avoids the whole mess. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 09:58:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21639 for ; Wed, 8 Jan 2003 09:58:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08FA8O27994 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 10:10:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FA8J27991 for ; Wed, 8 Jan 2003 10:10:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21618 for ; Wed, 8 Jan 2003 09:57:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08F3KJ27106; Wed, 8 Jan 2003 10:03:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08F2VJ27063 for ; Wed, 8 Jan 2003 10:02:32 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21447 for ; Wed, 8 Jan 2003 09:50:45 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08ErVu13367; Wed, 8 Jan 2003 09:53:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:53:32 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E10B@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Comments on sos draft -0 Date: Wed, 8 Jan 2003 09:53:32 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , A comment on one point only. > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, January 06, 2003 10:56 AM > To: 'Henning Schulzrinne'; 'sipping@ietf.org' > Subject: [Sipping] Comments on sos draft -0 > [snip] > > 6) section 3 (Emergency URI), 3rd paragraph: use of > "phone-context". Is it appropriate to use phone context in > any emergency call. In 3GPP, any use of one of the numbers > from the list stored in the phone is an emergency call, no > matter where it originates from. If my understanding of > phone-context is correct, it SHOULD NOT be used, as it could > result in failure to deliver an emergency call. > [PTT] My company has a scheme where "3333" on the internal network reaches an internal emergency response centre who then direct the call externally if required. This was introduced to ensure that emergency vehicles are directed to the right building and building entrance. It might be conceivable under such an arrangement to have a phone-context in the original Request-URI. [snip] > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 10:00:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21677 for ; Wed, 8 Jan 2003 10:00:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08FBrx28066 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 10:11:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FBqJ28063 for ; Wed, 8 Jan 2003 10:11:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21644 for ; Wed, 8 Jan 2003 09:59:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FAFJ28014; Wed, 8 Jan 2003 10:10:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08F9sJ27962 for ; Wed, 8 Jan 2003 10:09:54 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21632 for ; Wed, 8 Jan 2003 09:58:06 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08F1L606467; Wed, 8 Jan 2003 07:01:21 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08F1Xd18062; Wed, 8 Jan 2003 09:01:33 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 09:01:20 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CBC9@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Paul Kyzivat'" , sipping@ietf.org Subject: RE: [Sipping] I-D ACTION:draft-barnes-sipping-history-info-01.txt Date: Wed, 8 Jan 2003 09:01:18 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Paul, Thanks so much for your constructive comments. My specific responses are embedded below [MB] and I welcome further discussion on these points. In general, as you mention, the normative text around the index is quite lacking and I will definitely work to improve that including your concerns in the next version. Regards, Mary. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, January 07, 2003 5:01 PM To: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-barnes-sipping-history-info-01.txt A comment about the recording of indices... The syntax hi-index = "index" EQUAL 1*(DIGIT DOT ) permits indices of "...", "1..3", ".2" etc. These seem to be incorrect. [MB] Yes, you are correct. This is wrong and your proposed syntax is what was intended. A better syntax would be hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) The only specification I could find for how this is maintained is in Section 2.2.3, which says: In order to maintain ordering and accurately reflect forking and nesting, the index should also be included, with the last digit being incremented as the request is retargeted. ... If the index is captured at each occurrence of retargeting, a proxy can more accurately capture the logical order and nesting involved. This doesn't seem like enough to specify the maintenance of the index. Although doing this is straightforward, there ought to be some normative language about it. For instance the following are some issues about responsibility: - if a proxy receives a request with a History-Info that has an index paramter, and adds another entry as it forwards the request on, MUST it place an index param on the new entry? If so, MUST it follow the intuitive rule for deriving the new index? (I think the answer should be YES to both of these.) [MB] I think I also agree that these both should be yes. Although, I think that we may have to specify it as SHOULD (or RECOMMENDED) due to the optionality aspects of HI (subject to local policy, etc.) - if a proxy receives a request with a History-Info that has no index parameter, and it adds another entry as it forwards the request on, MAY it place an index param on the new entry? (I think it MUST NOT, because it has no way to determine a correct value.) [MB] Another good question. I agree it would be much simpler to suggest that the proxy SHOULD NOT add an index if there was HI entries without an index. The MUST NOT I think definitely needs to be documented is that the proxy MUST NOT add an index to a previous index (i.e. MUST NOT attempt to correct the previous lack of an index). It should be up to an end application that receives HI entries that might require an index to use whatever algorithm might be appropriate to add the indices. - if a proxy receives a request with no History-Info, and creates one with an initial entry, MAY it place an index param on the new entry? (I think it MUST NOT, because again it has no way to determine a correct value.) If you buy my answers to the above, then it is the UAC that determines whether indices are used. [MB] I agree, this is the way that it SHOULD work and with the approach that the UAC does add the initial entry prior to sending the request, this would work quite well. The only problem arises in the case of a proxy that perhaps only needs the information within its domain, but local policy requires the indices, then it's perhaps not unreasonable to just start with the entries that it adds itself. So, my answer to this 3rd point is that it would be a MAY, but I'm open to further discussion on this. In any case, for the indices to be useful for anything there ought to be more normative text that specifies how they are managed. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 11:32:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24069 for ; Wed, 8 Jan 2003 11:32:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Ghxv02110 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 11:43:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GhxJ02107 for ; Wed, 8 Jan 2003 11:43:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23972 for ; Wed, 8 Jan 2003 11:31:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GgFJ01953; Wed, 8 Jan 2003 11:42:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GeSJ01762 for ; Wed, 8 Jan 2003 11:40:28 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23841 for ; Wed, 8 Jan 2003 11:28:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Wed, 8 Jan 2003 11:31:55 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2DF65E@zoe.office.snowshore.com> Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Thread-Index: AcK3Cv1oSugmyIh5SG2i6x1kj1m4SgAEvC1gAAVd8UA= From: "Eric Burger" To: , , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08GeSJ01763 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Precisely. The "state" I was referring to is not the state of the SIP session, but the state of the UAS. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, January 08, 2003 9:03 AM > To: rajnishjain@lucent.com; Eric Burger; sfisher1@att.com > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > The body of a SUBSCRIBE should be used for things like > filtering. Something related to the subscription itself. > Putting KMPL in the body of SUBSCRIBE is considered as a form > of tunnelling, IMO. We try to keep a use of a certain SIP > method, header, or whatever to a minimum, preferably one. > > Bodies of INVITEs typically carry information about the > session. KPML, I would consider, a type of session description. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > Sent: Wednesday, January 08, 2003 1:34 PM > > To: 'Eric Burger'; Steve Fisher > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Eric, > > Can you expand on why sending KPML w/in SUBSCRIBE is a bad > > idea? In other > > words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. > > > > A SUBSCRIBE message w/ inline KPML should be oblivious to UA > > session FSM. > > It's an orthogonal activity from UA's perspective. Upon > > receipt of a KPML > > request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF > > collecion and > > report digits to app (via NOTIFY). This shouldn't change the > > state of SIP > > session w/in UA. > > > > Rajnish > > > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Tuesday, January 07, 2003 3:00 PM > > To: Steve Fisher > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > To answer the question directly: > > > > KPML only works with HTTP reporting. It would be a different > > language for SIP reporting. MSCML is an example of a > > language that uses SIP for reporting. > > > > > > > > To answer the SIP stimulus reporting question: > > > > Done INFO in the past, not planning on it again :-) > > > > NOTIFY is my leading contender, but a new method may be > > needed because if you do a strict reading of NOTIFY, you > > might not want a NOTIFY without a SUBSCRIBE. > > > > Using SUBSCRIBE as a method of pushing KPML is out and out > > evil (I mean wrong). KPML changes the state of the UAS. > > SUBSCRIBE is not supposed to have any side-effects. > > > > > > > > > -----Original Message----- > > > From: Steve Fisher [mailto:sfisher1@att.com] > > > Sent: Tuesday, January 07, 2003 8:15 AM > > > To: Eric Burger > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs > > > and apps? > > > > > > > > > Eric, > > > > > > I've been thinking about your statement below... > > > > > > > > If we say SIP for stimulus reporting, then the diagram > > you drew, > > > > > with the implication that the signaling follows the > > > signaling path, > > > > > is what will occur. > > > > > > > > > > Is this distinction important for you? The design team > > > did not come > > > > > > > > to full agreement on which way to go. Compelling > > > arguments either > > > > > way welcomed. > > > > > > Could you possibly elaborate on how "SIP for stimulus > > reporting" would > > > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you > > thinking of using > > > INFO? It's fairly clear from the KPML draft how HTTP would > > > work, but SIP > > > was less clear to me... > > > > > > Thanks! > > > Steve > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org > > [mailto:sipping-admin@ietf.org] On Behalf > > > Of Eric Burger > > > Sent: Tuesday, December 17, 2002 5:18 PM > > > To: Don Stanwyck > > > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish) > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs > > > and apps? > > > > > > > > > Rajnish is 1000% correct in his interpretation. Looking at > > > the message > > > I can see how my statement isn't entirely clear. > > > > > > I am on record in this and other fora that H.248 and J.162 are the > > > appropriate protocols for device control. See my posts to > > > the speechsc > > > list. I should have a paste buffer with my "Don't use SIP > > > for low-level > > > peripheral device control" rant. > > > > > > When I said "It [the thing referenced as "softswitch" in Rajnish's > > > e-mail -- ewb] is not a media gateway controller" I meant > > it was not a > > > media gateway controller, e.g., a device control thing, which uses > > > device control protocols like H.248 and J.162. > > > > > > Now it's my turn for interpreting Rajnish, instead of him > > interpreting > > > me :-) I assumed that the "PSTN X" thing was a MG-MGC > combination, > > > speaking SIP on the packet network side. E.g., the MG-MGC > > > interface was > > > a private matter, not of interest to the discussion. > > > > > > Sorry for the confusion. > > > > > > > -----Original Message----- > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > > Sent: Tuesday, December 17, 2002 4:02 PM > > > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish) > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > > complex SIP UAs > > > > and apps? > > > > > > > > > > > > Don, > > > > I don't think Eric implied controlling a MG from a Softswitch > > > > via SIP in his > > > > comment. That particular topic has come up in this forum many > > > > times and as I > > > > recall the conclusion has always been that SIP is not meant > > > > for that. SIP is > > > > a peer-to-peer to protocol not a master-slave protcol - > > > > agreed. However this > > > > is completely orthogonal to using stimulus/markup signaling > > > > in SIP. I don't > > > > see how in-lining a KPML doc (e.g.) in a SIP message breaks > > > > SIP paradigm. > > > > > > > > Eric, > > > > In general, I would like to propose an HTTP-free alternative > > > > for delivery of > > > > stimulus signals, such as through in-lining of KPML. The > > > > benefits of such an > > > > alternative in my mind are following: > > > > > > > > - it would make it easier for SIP developers on embedded > > > > platforms to embrace > > > > markup/stimulus signaling that don't support HTTP currently > > > > > > > > - it would facilitate close coordination between announcement > > > > play and DTMF > > > > collection. Barge-in is a good example for that. The app > > > > can delegate the > > > > job to stop announcement play at barge-in to the > > > > Softswitch. As an aside, > > > > the Softswitch in my previous figure is one w/ bizarre API > > > > as you say :-) > > > > > > > > Rajnish > > > > > > > > -----Original Message----- > > > > From: Don Stanwyck [mailto:don@stanwyck.com] > > > > Sent: Tuesday, December 17, 2002 3:10 PM > > > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)' > > > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)' > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > > complex SIP UAs > > > > and apps? > > > > > > > > > > > > RFC 3261, Section 2 reads: > > > > > > > > //START QUOTE > > > > > > > > SIP supports five facets of establishing and terminating > > > > multimedia communications: > > > > - User location: determination of the end system to be > > > > used for communication; > > > > - User availability: determination of the willingness > > > > of the called party to engage in communications; > > > > - User capabilities: determination of the media and media > > > > parameters to be used; > > > > - Session setup: "ringing", establishment of session > > > > parameters at both called and calling party; > > > > - Session management: including transfer and termination > > > > of sessions, modifying session parameters, and invoking > > > > services. > > > > > > > > SIP is not a vertically integrated communications system. > > > > SIP is rather > > > > a component that can be used with other IETF protocols > to build a > > > > complete multimedia architecture. Typically, these > > > architectures will > > > > include protocols such as the Real-time Transport Protocol > > > (RTP) (RFC > > > > 1889 [28]) for transporting real-time data and providing > > > QoS feedback, > > > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for > > > > controlling > > > > delivery of streaming media, the Media Gateway Control > > > > Protocol (MEGACO) > > > > (RFC 3015 [30]) for controlling gateways to the Public Switched > > > > Telephone Network (PSTN), and the Session Description > > Protocol (SDP) > > > > (RFC 2327 [1]) for describing multimedia sessions. > Therefore, SIP > > > > should be used in conjunction with other protocols in order > > > to provide > > > > complete services to the users. However, the basic > > > functionality and > > > > operation of SIP does not depend on any of these protocols. > > > > > > > > //END QUOTE > > > > > > > > I can't find any support in this definition of SIP for > > > > carrying stimulus > > > > signaling or for controling media gateways (comment 1 in Eric's > > > > comments). SIP, as defined and approved by the IETF, is not > > > > expected to > > > > do these kinds of things that other IETF protocols are > designed to > > > > handle. > > > > > > > > Let's try to keep SIP doing the things it is designed to do > > > and does > > > > well, and not try to make it into a protocol for doing > everything > > > > imaginable. It is already in danger of becoming too > difficult to > > > > implement as the number of options and new headers grows. > > > > > > > > Don Stanwyck > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > > On Behalf Of Eric Burger > > > > > Sent: Tuesday, December 17, 2002 12:12 PM > > > > > To: Jain, Rajnish (Rajnish) > > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > > > complex SIP UAs and apps? > > > > > > > > > > > > > > > For timelines, I would suggest asking the work group chairs. > > > > > We're at their mercy :-) > > > > > > > > > > Putting my ISC hat on, what is the Softswitch in your diagram? > > > > > 1. It is not a media gateway controller, as it talks to > > > > > the gateway with SIP (right answer, by the way). > > > > > 2. Is it a Stateless Proxy, a'la the Routing Function > > > > > in the ISC reference diagram? If so, that works > > > > > exactly as you want it to. See below for more. > > > > > 3. Is it an application server, a'la dynamicsoft, > > > > > Ubiquity, LongBoard, etc.? If so, that also works > > > > > exactly as you want it to. See below for more. > > > > > 4. Is it some kind of statefull proxy, with a bizarre, > > > > > proprietary API to the pre-paid application (e.g., > > > > > Parlay, JAIN, EXS, ...)? If so, you are on your > > > > > own. > > > > > > > > > > If we say "HTTP only" for stimulus reporting, the PSTN > > > > > gateway must be a HTTP client. The good news is the gateway > > > > > can communicate directly with the pre-paid application. That > > > > > also means the pre-paid application needs to have a HTTP > > > > > server. Alternatively, if the "Softswitch" is really a > > > > > telephony application server (case #3 above), then it > > > > > probably already has HTTP server capability built-in. > > > > > > > > > > If we say SIP for stimulus reporting, then the diagram you > > > > > drew, with the implication that the signaling follows the > > > > > signaling path, is what will occur. > > > > > > > > > > Is this distinction important for you? The design team did > > > > > not come to full agreement on which way to go. Compelling > > > > > arguments either way welcomed. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jain, Rajnish (Rajnish) > [mailto:rajnishjain@lucent.com] > > > > > > Sent: Friday, December 06, 2002 4:20 PM > > > > > > To: Eric Burger; Jain, Rajnish (Rajnish) > > > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup > > > between complex > > > > > > SIP UAs and apps? > > > > > > > > > > > > > > > > > > Eric, > > > > > > > > > > > > Thanks for your response. Would you be able to > comment on the > > > > > > timeline of when does the design team hope to accomplish the > > > > > > following: > > > > > > > > > > > > - general acceptance of the stimulus signaling, KPML etc. > > > > > > - standardization of app interaction fwk, KPML into an RFC > > > > > > > > > > > > Regarding an example of a PSTN switch that can be > > > connected to a > > > > > > pre-paid app over SIP-T, I don't know how much I can > > > disclose in > > > > > > front of this forum, but that is something being > > looked at by a > > > > > > few telecom gear vendors in my understanding. > > > > > > > > > > > > I wanted to bring your attention to SIP-T wrt to my > > > > > previous question. > > > > > > I believe your answer will remain the same but I just to > > > > wanted to > > > > > > re-iterate the question in different words this time, > > > > just to make > > > > > > sure we're communicating: > > > > > > > > > > > > In the setup below: > > > > > > Pre-paid app > > > > > > | > > > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ---- > > > > > > > > > > > > > > > > > > .. you would think, application interaction framework > > concepts > > > > > > such as stimulus signaling, user-inetrfaces and > KPML etc. are > > > > > > designed to work over the SIP-T i/f between > > packet-enabled PSTN > > > > > > switch and a Softswitch. Wouldn't you? > > > > > > > > > > > > Thanks, > > > > > > Rajnish > > > > > > > > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish) > > > > > [mailto:rajnishjain@lucent.com] > > > > > > > > > > > > The Application Interaction Framework draft talks > > about stimulus > > > > > > signaling as a way for SIP UAs to interact w/ SIP > > > > applications. The > > > > > > draft suggests use of markup languages to allow > > > > > applications to manage > > > > > > local/remote user interfaces on SIP UAs. > > > > > > > > > > > > While the draft exemplifies a UA's stimulus/markup > > > interaction w/ > > > > > > a pre-paid application server, it is not very clear to > > > us if the > > > > > > caller UA (instead of a subscriber end-point) can be a > > > complex UA > > > > > > such as the following: > > > > > > > > > > > > - SIP (enabled) Gateway > > > > > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > > > > > - PSTN Switch w/ SIP-T interface > > > > > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > > > > > and does the draft recommend stimulus/markup > > signaling between > > > > > > such complex/concentrated UAs (or apps) and SIP > applications ? > > > > > > > > > > The draft is silent on it. If you manufacture media rich > > > > > gateways, you might say "of course". If you manufacture > > > > > media servers, you might say "you could if you wanted, but > > > > > you would be better served if you didn't." :-) > > > > > > > > > > > In other words, does the stimulus signaling apply > to following > > > > > > scenarios ?: > > > > > > > > > > > > 1. The pre-paid caller is connected to a PSTN switch > > that has a > > > > > > SIP-T interface to the pre-paid application. > > > > > > > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse > > > > > and execute KPML, and report using SIP (or, yuck, http). > > > > > > > > > > Do you know of such a switch? > > > > > > > > > > > 2. The pre-paid caller is connected to a PBX (SIP > > > Gateway) over an > > > > > > > > > ISDN i/f, which in turn is connected to the pre-paid > > app. over > > > > > > normal SIP. > > > > > > > > > > Same issues as for the PSTN switch. > > > > > > > > > > > If yes, would the terms client-local and > > client-remote still be > > > > > > accurate, as the user here is a POTS/ISDN user? From > > the user's > > > > > > perspective, the UI would be client-remote. But from > > > > application's > > > > > > perspective the UI would be client-local (as the UI will be > > > > > on the PBX > > > > > > or PSTN switch both of which look like a UA to app server). > > > > > > > > > > It is still client-local, as the gateway/switch/PBX is a > > > > > local proxy for the user. If you used a media server in the > > > > > IP network behind the gateway/switch/PBX to execute the KPML, > > > > > then you would be cline-remote. > > > > > _______________________________________________ > > > > > Sipping mailing list > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on current > > > > > sip Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 15:08:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05166 for ; Wed, 8 Jan 2003 15:08:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08KJaO18677 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 15:19:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KJaJ18674 for ; Wed, 8 Jan 2003 15:19:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05019 for ; Wed, 8 Jan 2003 15:05:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KEGJ18466; Wed, 8 Jan 2003 15:14:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KBIJ18360 for ; Wed, 8 Jan 2003 15:11:18 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04723 for ; Wed, 8 Jan 2003 14:59:25 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21138 for ; Wed, 8 Jan 2003 15:02:40 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA26615 for ; Wed, 8 Jan 2003 15:02:41 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Jan 2003 15:02:40 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Wed, 8 Jan 2003 15:02:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , After all of this, I propose the following: 1. We add the possibility of a callerId string to a tel uri: telephone-uri = "tel:" [callerIdName LWS] subscriber callerIdName = quoted-string 2. Gateways accept or send sip uris of the form: sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; port=3 or tel uris of the form: tel:"Alice Toklas" +14125551212; port=3 or "ordinary" sip uri's with extra information in a separate header of the form:
+14125551212; port=3 where
could be "P-Asserted-Identity", or it could be a new header we define for the purpose. Then, we have the following possibilities: SIP device to gateway (outgoing) call To a phone number use the phone number in the Request-URI & To:, probably in a tel URI, or maybe phonenumber@localdomain; user=phone use normal sip URI in From: If a translator is available, it may assert the phone number for the identity in the From: using
proxy may rewrite the Request-URI in the form of sip: phone@gateway;user=phone;port=portnum To a sip URI use the sip uri in the Request-URI and To: use normal sip URI in From: proxy rewrites Request-URI, due to forwarding behavior, ENUM lookup, etc, resulting in a tel URI or a user=phone sip uri. If necessary, a local incoming proxy can rewrite it to add the port parameter to the Request-URI based on the From: If a translator is available, it may assert the phone number for the identity in the From: using the
Gateway to SIP device (incoming call) With mapping use the mapped uri in the Request-URI & To: (optionally) supply called number using
This might be needed when multiple called numbers map to the same uri. use sip:"callerId" phone@gateway; port=portnum or a tel: uri in From: Without mapping use a provisioned (per port) URI, a tel uri with the called number, or a sip uri with calledNumber@localdomain; user=phone in the Request-URI & To:. Gateways should support all 3, choice should be made by provisioning. use sip:"callerId" phone@gateway; port=portnum or tel uri in From: proxy will rewrite the Request-URI with the correct sip URI associated with the called number Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 15:39:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06482 for ; Wed, 8 Jan 2003 15:39:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08KoQi20409 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 15:50:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KoPJ20406 for ; Wed, 8 Jan 2003 15:50:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06420 for ; Wed, 8 Jan 2003 15:38:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KlSJ20308; Wed, 8 Jan 2003 15:47:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KkcJ20281 for ; Wed, 8 Jan 2003 15:46:38 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06367 for ; Wed, 8 Jan 2003 15:34:45 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h08Kcg0q024274; Wed, 8 Jan 2003 15:38:43 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX55812; Wed, 8 Jan 2003 15:43:02 -0500 (EST) Message-ID: <3E1C8C28.4030802@cisco.com> Date: Wed, 08 Jan 2003 15:38:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, A few initial comments. More later when I get time to think about it. - I'm not sure of the advisability of adding caller name to the tel uri. If you do it, I don't like that way. Would prefer a tel: parameter, as in tel:+14125551212;caller-name="Alice Toklas" - I don't think the port should be a sip uri parameter. It is very telephony oriented, so I think it is better as a tel: uri parameter. Paul Rosen, Brian wrote: > After all of this, I propose the following: > > 1. We add the possibility of a callerId string to a tel uri: > telephone-uri = "tel:" [callerIdName LWS] subscriber > callerIdName = quoted-string > > 2. Gateways accept or send sip uris of the form: > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; port=3 > or tel uris of the form: > tel:"Alice Toklas" +14125551212; port=3 > or "ordinary" sip uri's with extra information in a separate header > of the form: >
+14125551212; port=3 > > where
could be "P-Asserted-Identity", or it could be a new > header we define for the purpose. > > Then, we have the following possibilities: > > SIP device to gateway (outgoing) call > To a phone number > use the phone number in the Request-URI & To:, probably > in a tel URI, or maybe phonenumber@localdomain; user=phone > > use normal sip URI in From: > > If a translator is available, it may assert the phone number > for the identity in the From: using
> > proxy may rewrite the Request-URI in the form of > sip: phone@gateway;user=phone;port=portnum > > To a sip URI > use the sip uri in the Request-URI and To: > use normal sip URI in From: > > proxy rewrites Request-URI, due to forwarding behavior, > ENUM lookup, etc, resulting in a tel URI or a user=phone sip > uri. If necessary, a local incoming proxy can rewrite it to > add the port parameter to the Request-URI based on the From: > > If a translator is available, it may assert the phone number > for the identity in the From: using the
> > Gateway to SIP device (incoming call) > With mapping > use the mapped uri in the Request-URI & To: > > (optionally) supply called number using
> This might be needed when multiple called numbers > map to the same uri. > > use sip:"callerId" phone@gateway; port=portnum or > a tel: uri in From: > > Without mapping > use a provisioned (per port) URI, a tel uri with the called > number, or a sip uri with calledNumber@localdomain; user=phone > in the Request-URI & To:. Gateways should support all 3, > choice should be made by provisioning. > > use sip:"callerId" phone@gateway; port=portnum or tel > uri in From: > > proxy will rewrite the Request-URI with the correct sip URI > associated with the called number > > Brian > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 17:29:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10090 for ; Wed, 8 Jan 2003 17:29:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08MemI28492 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 17:40:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MemJ28489 for ; Wed, 8 Jan 2003 17:40:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10030 for ; Wed, 8 Jan 2003 17:28:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MbiJ28368; Wed, 8 Jan 2003 17:37:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MaNJ27715 for ; Wed, 8 Jan 2003 17:36:23 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09914 for ; Wed, 8 Jan 2003 17:24:28 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h08MRI807288; Wed, 8 Jan 2003 22:27:18 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 17:29:39 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB4FF@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Rosen, Brian'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Wed, 8 Jan 2003 17:29:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Some notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, January 07, 2003 7:12 AM > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > I think Reply-To is a so-so place to put a second identity. > I think it's problematic to have a From have the "real" > SIP URI and the Reply-To have the "real" tel URI. It > warps the definition of Reply-To. > What I suggested was that the From header hold the URI of the gateway - not the 'real' SIP URI of the user - for PSTN-to-SIP calls. The From address in this instance is not the address to which you should reply if you want to reach the initiator of the session later. The tel URL of that user is in fact the URI to which you should reply. I think this is a good place to put it for this case, and it doesn't warp the Reply-To header in any way that I can see. This is completely unrelated to where one would put the 'real' SIP URI of the user. > It also has a serious problem that a proxy can't add it. I think you mean that you want the proxy to be able to add a telephone number to a request for a SIP-to-PSTN call, or maybe to add a SIP URI representing the originating user to a request for a PSTN-to-SIP call (though this latter one is difficult - how would a user authenticate themselves to an auth service through a PSTN gateway?). I agree that Reply-To is not a good candidate for this usage - this is where it has been argued that P-Asserted-Identity is a good candidate. There are some minor issues with this (such as how a proxy knows when and why to add identities, and how authentication for particular identifies is managed), but I think that if a proxy asserts an identity, it can and should use the identity mechanisms we've already defined, which were designed specifically with proxies in mind. However, there are some reasons to ask whether or not proxies are always the best entities to decide when synonym identities should be added to a request. > One of the requirements I have is that a proxy be able to > do the translation. Not every gateway can hold all the tables > required for this kind of translation, and I don't think > we want to force every gateway to have the tables. > The whole issue of who should do 'translation' by various entities is a little problematic, and ultimately this problem should be separable from the selection of the headers we might use to express the results of translation. Personally, I think ENUM is the right way to do telephone number to URI translations - however, it is not servicable for the reverse, for URI to telephone number translations. Having some kind of 'reverse ENUM' for this purpose has been the subject of much speculation in ENUM circles, but it currently is not well understood how it would work. ENUM is best performed by the initiator of the session, rather than an intermediary, for various reasons that are enumerated in sipping-e164-02. Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is the right place to do an ENUM query. This does not require the gateway to have any tables, or what have you. Intermediaries can also query ENUM and apply the results to a message, even if it is sub-optimal for them to do so. > I think your proposals on identity will not work unless > the signer can be a proxy which later in the routing > than my proxy that does the translation. Well, an authentication service, as I describe it, does the signing after a request has been generated, yes. If a later proxy wants to shove some (authenticated) information into the request afterwards, that isn't possible unless is supplies a separate signed body. > If the gateway > does the translation, then in theory there would have to be > a trust relationship between the PSTN and the gateway. There is always, in effect, a trust relationship between the PSTN and a gateway. The gateway is a node on the PSTN (whether it is a privileged node, like an SS7 gateway, or a user node, like a CAS gateway), and nodes have a certain defined trust relationship with the PSTN. I think the gateway is one of the better candidates to do ENUM, and possibly to perform the reverse operation (however that would work). > That won't work for an enterprise gateway, although I'm not > sure that's a practical problem, because if the gateway > translated, the PSTN is going to check that the number > the gateway asserted is one of the identities that loop > is allocated (PRIs have ranges). > Presumably, gateways shouldn't trust authentication services that might give them improper information. In fact, there are numerous restrictions surrounding what sorts of phone numbers should be sent over many sorts of ISUP trunks as well (as well as rules about when a CgPN must be present, as opposed to may be present). An proxy or user agent that supplies originating telephone numbers for SIP-to-PSTN calls should expect gateways to validate them, and there should be some way to accomodate cases in which the gateway cannot transmit these numbers to the PSTN, since it may be difficult for a proxy to determine what sort of gateway a request will ultimately land on (which is one of the reasons why proxies might not be the best place for synonym identities to be managed). > I don't see how ENUM is useful with identity assertion, > although it's clearly applicable to the proxy that > translates a SIP URI into a phone number or vice versa in > the Request URI. It doesn't assert identity itself, certainly. The one place in which it is conceivably useful for identity assertion is that ENUM could be queried for a URI associated with the calling party's number in a PSTN-to-SIP call. This could be useful for a number of reasons - that URI could be stuck in a header to indicate a SIP URI for the end user that is more explicit or recognizable than their telephone number. > > Brian > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Tuesday, January 07, 2003 6:35 AM > > To: 'Rosen, Brian'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' > > Cc: 'sipping@ietf.org' > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > First, it is possible, with the long-term identity mechanism, > > to assert two > > identities in an authenticated identity body. So, you could > > have headers > > corresponding to a telephone number and a SIP URI of a > > gateway or a user - > > it strikes me that a telephone number is a good Reply-To, > > actually, when a > > call comes from a gateway (originating in the PSTN, say) and > > the From header > > field contains a SIP URI for the gateway, perhaps including > some port > > information. The identity that the gateway which handles a > > PSTN-SIP call > > would assert needs to be its own, and recipients of calls > > from gateways need > > to trust the telephone number provided by the gateway or not > > accordingly > > (i.e. a signature from att.com vouching for such a request should be > > acceptable). > > > > Technologies like ENUM (when/where available) could enable > gateways to > > convert originating telephone numbers into URIs. Of course, > a gateway > > wouldn't be able to assert that identity to an intermediary > unless it > > possessed credentials appropriate to that URI, which is unlikely. > > > > For outbound calls (SIP-PSTN), the gateway may or may not be > > able to map > > (authenticated) SIP URIs representing originators to > > appropriate telephone > > numbers via some sort of local tables as you suggested. If > > not, might also > > pick a number from a pool, sure. The question of whether some > > authentication > > service should be able to assert an originating telephone > > number (in an > > authenticated identity body, say) that a gateway will use is > > also a trust > > question - it is possible to put the tel URL in the AIB. If > > the gateway has > > a reason to trust the authentication service, then certainly > > it should send > > that number to the PSTN (when the protocol allows gateways > to supply a > > number, like with ISUP or Q.931). The gateway would be very > > ill advised to > > take just any authentication service's word on this matter, though. > > > > The target of the calls for the PSTN should be identified > > with a telephone > > number - at least, by the time the call arrives a gateway, > > it's Request-URI > > should contain a tel URL or a SIP URI with a tel URL > > component. Whether the > > originating UAC sets the To header field to a tel URL or a > > subsequent proxy > > retargets the request doesn't seem to make much difference. > > ENUM can also > > play a pretty obvious role here. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Monday, January 06, 2003 1:22 PM > > > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, > Brian; 'Henning > > > Schulzrinne' > > > Cc: 'sipping@ietf.org' > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > I agree with this. I'm confused by those who seem to think that > > > P-Asserted-Identity is needed when the long term solution is > > > fully baked. If the UA knows its identity, which seems > > > reasonable, then it can "assert" it, and have that assertion > > > validated by a trusted entity using cryptographic means. > > > That is the fundamental idea I get out of Jon's proposal. > > > The only circumstance where that won't work is where the > > > UA doesn't know its identity. I don't see that as a problem > > > on any network I'm aware of, but ...... keep reading. > > > > > > I do think there is a problem which this whole thread talks about. > > > The basic reality is that many users of SIP UAs will have two > > > identities - a SIP URI and a telephone number. It may be > > > necessary to assert both identities in one call, because the > > > originator of the call does not know which identity may be > > > needed. There is no current header to do this. I think that > > > it is advantageous to have a proxy be able to assert the phone > > > number. Otherwise EVERY UA will have to be able to understand > > > that two identities are possible, know them both by some > > > unspecified means, and assert them in every call on every UA. > > > This seems unreasonable. I'm not sure that there is a reason > > > to have both identities validated, but there could be. > > > > > > Brian > > > > -----Original Message----- > > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > > Sent: Monday, January 06, 2003 2:06 PM > > > > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne' > > > > Cc: 'sipping@ietf.org' > > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > > RFC3325 was 'short-term' because it was achievable in the > > > > short-term and has > > > > a more limited (but still useful) applicability. The > > > > long-term identity > > > > solution must be a superset of the functionality of > > > > short-term - it must > > > > address the short-term scope of applicability, but also > > > > encompass general > > > > needs for network assertion (which SIP does have). > > > > Accordingly, it takes > > > > longer to develop. At such a time as there is a workable > > > > long-term solution, > > > > it would be pointless to allow both to be SIP standards > > > > except as part of a > > > > transition plan. So in that sense, I disagree - one is a > > > > short-term solution > > > > of the other. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > > > Sent: Friday, January 03, 2003 8:20 AM > > > > > To: Rosen, Brian; 'Henning Schulzrinne' > > > > > Cc: 'sipping@ietf.org' > > > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > Network asserted identity (RFC 3325) is the real network > > > > > asserted identity. It is a P header not because it is > > > > > preliminary, but because the whole idea of network assertion > > > > > is not generally applicable to all SIP architectures. For RFC > > > > > 3325 a trust domain needs to exist between proxies that use > > > > > the P-Asserted-Identity in order to guarantee the privacy, > > > > > this does not exist in all SIP networks. In does in 3GPP and > > > > > therefore 3GPP are using RFC 3325. > > > > > > > > > > If you want to let the 1et outbound proxy assert identity on > > > > > your behalf then use RFC 3325. If you want to let application > > > > > servers with whom you have a secure relationship assert your > > > > > identity, then use Jon Petersons drafts, when they eventually > > > > > become RFCs. > > > > > > > > > > One is not a short term solution for the other. > > > > > > > > > > Keith > > > > > > > > > > Keith Drage > > > > > Lucent Technologies > > > > > Tel: +44 1793 776249 > > > > > Email: drage@lucent.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Sent: 02 January 2003 20:49 > > > > > > To: 'Henning Schulzrinne' > > > > > > Cc: 'sipping@ietf.org' > > > > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > > > > Yeah, I actually thought of just allowing a display > > name in the > > > > > > Request URI and using that, but it seems so foolish to make > > > > > a change, > > > > > > and have that change not be exactly what we needed. > > > > > > > > > > > > We could use NAI. I suppose we could use a > > P-Asserted-Identity > > > > > > with a tel URI: > > > > > > P-Asserted-Identity tel:+17247426826 > > > > > > > > > > > > What do we do when the "real" NAI happens? > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > > Sent: Thursday, January 02, 2003 3:10 PM > > > > > > > To: Rosen, Brian > > > > > > > Cc: 'sipping@ietf.org' > > > > > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > > > > > > > > I'd like to get a new header for the calling > > party number on > > > > > > > > an outbound call. That way, the translator can be > > > a proxy and > > > > > > > > add the header. I'd recommend that gateways allow > > > the number > > > > > > > > to be in the From. > > > > > > > > > > > > > > Generalized, you want something like the Request-URI > > > > that can be > > > > > > > modified or inserted. How about the NAI stuff? > > > > > > > > > > > > > _______________________________________________ > > > > > > Sipping mailing list > > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > > This list is for NEW development of the application of SIP > > > > > > Use sip-implementors@cs.columbia.edu for questions on > > > current sip > > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 17:31:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10246 for ; Wed, 8 Jan 2003 17:31:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08MgiB28663 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 17:42:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MgiJ28660 for ; Wed, 8 Jan 2003 17:42:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10172 for ; Wed, 8 Jan 2003 17:30:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Me7J28481; Wed, 8 Jan 2003 17:40:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08McjJ28380 for ; Wed, 8 Jan 2003 17:38:45 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09951 for ; Wed, 8 Jan 2003 17:26:51 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h08MTw807347; Wed, 8 Jan 2003 22:29:58 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 17:32:19 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB501@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Paul Kyzivat'" , "Rosen, Brian" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Wed, 8 Jan 2003 17:32:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , On the subject of a 'port' parameter, I agree this is best as a tel URL parameter. In fact, I suggest that the trunk group tel URL parameter currently under development in IPTEL might be sufficient for expressing port information. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, January 08, 2003 12:38 PM > To: Rosen, Brian > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] URIs for Gateways > > > Brian, > > A few initial comments. More later when I get time to think about it. > > - I'm not sure of the advisability of adding caller name to > the tel uri. > If you do it, I don't like that way. Would prefer a tel: > parameter, as in > tel:+14125551212;caller-name="Alice Toklas" > > - I don't think the port should be a sip uri parameter. It is very > telephony oriented, so I think it is better as a tel: uri parameter. > > Paul > > Rosen, Brian wrote: > > After all of this, I propose the following: > > > > 1. We add the possibility of a callerId string to a tel uri: > > telephone-uri = "tel:" [callerIdName LWS] subscriber > > callerIdName = quoted-string > > > > 2. Gateways accept or send sip uris of the form: > > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; > user=phone; port=3 > > or tel uris of the form: > > tel:"Alice Toklas" +14125551212; port=3 > > or "ordinary" sip uri's with extra information in a separate header > > of the form: > >
+14125551212; port=3 > > > > where
could be "P-Asserted-Identity", or it could be a new > > header we define for the purpose. > > > > Then, we have the following possibilities: > > > > SIP device to gateway (outgoing) call > > To a phone number > > use the phone number in the Request-URI & To:, probably > > in a tel URI, or maybe phonenumber@localdomain; user=phone > > > > use normal sip URI in From: > > > > If a translator is available, it may assert the phone number > > for the identity in the From: using
> > > > proxy may rewrite the Request-URI in the form of > > sip: phone@gateway;user=phone;port=portnum > > > > To a sip URI > > use the sip uri in the Request-URI and To: > > use normal sip URI in From: > > > > proxy rewrites Request-URI, due to forwarding behavior, > > ENUM lookup, etc, resulting in a tel URI or a user=phone sip > > uri. If necessary, a local incoming proxy can rewrite it to > > add the port parameter to the Request-URI based on the From: > > > > If a translator is available, it may assert the phone number > > for the identity in the From: using the
> > > > Gateway to SIP device (incoming call) > > With mapping > > use the mapped uri in the Request-URI & To: > > > > (optionally) supply called number using
> > This might be needed when multiple called numbers > > map to the same uri. > > > > use sip:"callerId" phone@gateway; port=portnum or > > a tel: uri in From: > > > > Without mapping > > use a provisioned (per port) URI, a tel uri with the called > > number, or a sip uri with calledNumber@localdomain; > user=phone > > in the Request-URI & To:. Gateways should support all 3, > > choice should be made by provisioning. > > > > use sip:"callerId" phone@gateway; port=portnum or tel > > uri in From: > > > > proxy will rewrite the Request-URI with the correct sip URI > > associated with the called number > > > > Brian > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 8 18:13:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12715 for ; Wed, 8 Jan 2003 18:13:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08NOqV30989 for sipping-archive@odin.ietf.org; Wed, 8 Jan 2003 18:24:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08NOqJ30986 for ; Wed, 8 Jan 2003 18:24:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12692 for ; Wed, 8 Jan 2003 18:12:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08NMGJ30902; Wed, 8 Jan 2003 18:22:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08NLQJ30869 for ; Wed, 8 Jan 2003 18:21:26 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12611 for ; Wed, 8 Jan 2003 18:09:29 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h08NDCEt017091; Wed, 8 Jan 2003 18:13:12 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX57214; Wed, 8 Jan 2003 18:17:32 -0500 (EST) Message-ID: <3E1CB05E.2080004@cisco.com> Date: Wed, 08 Jan 2003 18:12:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Rosen, Brian'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <15A2739B7DAA624D8091C65981D7DA815EB4FF@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is interesting. I wonder how many SIP UAs do anything with the Reply-To header? At a minimum, I think there is a *lot* of best-practice to work out so that phone displays of who is calling, and automatic callback functions on phones "do the right thing" with all the various combinations of From, Reply-To, NAI, etc. Perhaps Brian is doing the right thing by starting down this path. In your example, if I am the recipient of the call, I will want my phone to display the Reply-To address, and use that for any kind of automated callback it might do. I probably have no interest in seeing the From address at all. But I have the feeling there are other (non-gateway) use cases where this may not be the case. For instance, I may be able to provide credentials that authenticate my From address, but want callbacks to go someplace else that I can't authenticate. The recipient may be unwilling to display an unauthenticated caller identity. Paul Peterson, Jon wrote: > Some notes below. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>Sent: Tuesday, January 07, 2003 7:12 AM >>To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' >>Cc: 'sipping@ietf.org' >>Subject: RE: [Sipping] URIs for Gateways >> >> >>I think Reply-To is a so-so place to put a second identity. >>I think it's problematic to have a From have the "real" >>SIP URI and the Reply-To have the "real" tel URI. It >>warps the definition of Reply-To. >> > > > What I suggested was that the From header hold the URI of the gateway - not > the 'real' SIP URI of the user - for PSTN-to-SIP calls. The From address in > this instance is not the address to which you should reply if you want to > reach the initiator of the session later. The tel URL of that user is in > fact the URI to which you should reply. I think this is a good place to put > it for this case, and it doesn't warp the Reply-To header in any way that I > can see. This is completely unrelated to where one would put the 'real' SIP > URI of the user. > > >>It also has a serious problem that a proxy can't add it. > > > I think you mean that you want the proxy to be able to add a telephone > number to a request for a SIP-to-PSTN call, or maybe to add a SIP URI > representing the originating user to a request for a PSTN-to-SIP call > (though this latter one is difficult - how would a user authenticate > themselves to an auth service through a PSTN gateway?). I agree that > Reply-To is not a good candidate for this usage - this is where it has been > argued that P-Asserted-Identity is a good candidate. > > There are some minor issues with this (such as how a proxy knows when and > why to add identities, and how authentication for particular identifies is > managed), but I think that if a proxy asserts an identity, it can and should > use the identity mechanisms we've already defined, which were designed > specifically with proxies in mind. However, there are some reasons to ask > whether or not proxies are always the best entities to decide when synonym > identities should be added to a request. > > >>One of the requirements I have is that a proxy be able to >>do the translation. Not every gateway can hold all the tables >>required for this kind of translation, and I don't think >>we want to force every gateway to have the tables. >> > > > The whole issue of who should do 'translation' by various entities is a > little problematic, and ultimately this problem should be separable from the > selection of the headers we might use to express the results of translation. > Personally, I think ENUM is the right way to do telephone number to URI > translations - however, it is not servicable for the reverse, for URI to > telephone number translations. Having some kind of 'reverse ENUM' for this > purpose has been the subject of much speculation in ENUM circles, but it > currently is not well understood how it would work. > > ENUM is best performed by the initiator of the session, rather than an > intermediary, for various reasons that are enumerated in sipping-e164-02. > Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is the right > place to do an ENUM query. This does not require the gateway to have any > tables, or what have you. Intermediaries can also query ENUM and apply the > results to a message, even if it is sub-optimal for them to do so. > > >>I think your proposals on identity will not work unless >>the signer can be a proxy which later in the routing >>than my proxy that does the translation. > > > Well, an authentication service, as I describe it, does the signing after a > request has been generated, yes. If a later proxy wants to shove some > (authenticated) information into the request afterwards, that isn't possible > unless is supplies a separate signed body. > > >>If the gateway >>does the translation, then in theory there would have to be >>a trust relationship between the PSTN and the gateway. > > > There is always, in effect, a trust relationship between the PSTN and a > gateway. The gateway is a node on the PSTN (whether it is a privileged node, > like an SS7 gateway, or a user node, like a CAS gateway), and nodes have a > certain defined trust relationship with the PSTN. I think the gateway is one > of the better candidates to do ENUM, and possibly to perform the reverse > operation (however that would work). > > >>That won't work for an enterprise gateway, although I'm not >>sure that's a practical problem, because if the gateway >>translated, the PSTN is going to check that the number >>the gateway asserted is one of the identities that loop >>is allocated (PRIs have ranges). >> > > > Presumably, gateways shouldn't trust authentication services that might give > them improper information. In fact, there are numerous restrictions > surrounding what sorts of phone numbers should be sent over many sorts of > ISUP trunks as well (as well as rules about when a CgPN must be present, as > opposed to may be present). An proxy or user agent that supplies originating > telephone numbers for SIP-to-PSTN calls should expect gateways to validate > them, and there should be some way to accomodate cases in which the gateway > cannot transmit these numbers to the PSTN, since it may be difficult for a > proxy to determine what sort of gateway a request will ultimately land on > (which is one of the reasons why proxies might not be the best place for > synonym identities to be managed). > > >>I don't see how ENUM is useful with identity assertion, >>although it's clearly applicable to the proxy that >>translates a SIP URI into a phone number or vice versa in >>the Request URI. > > > It doesn't assert identity itself, certainly. The one place in which it is > conceivably useful for identity assertion is that ENUM could be queried for > a URI associated with the calling party's number in a PSTN-to-SIP call. This > could be useful for a number of reasons - that URI could be stuck in a > header to indicate a SIP URI for the end user that is more explicit or > recognizable than their telephone number. > > >>Brian >> >> >>>-----Original Message----- >>>From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>Sent: Tuesday, January 07, 2003 6:35 AM >>>To: 'Rosen, Brian'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' >>>Cc: 'sipping@ietf.org' >>>Subject: RE: [Sipping] URIs for Gateways >>> >>> >>> >>>First, it is possible, with the long-term identity mechanism, >>>to assert two >>>identities in an authenticated identity body. So, you could >>>have headers >>>corresponding to a telephone number and a SIP URI of a >>>gateway or a user - >>>it strikes me that a telephone number is a good Reply-To, >>>actually, when a >>>call comes from a gateway (originating in the PSTN, say) and >>>the From header >>>field contains a SIP URI for the gateway, perhaps including >> >>some port >> >>>information. The identity that the gateway which handles a >>>PSTN-SIP call >>>would assert needs to be its own, and recipients of calls >>>from gateways need >>>to trust the telephone number provided by the gateway or not >>>accordingly >>>(i.e. a signature from att.com vouching for such a request should be >>>acceptable). >>> >>>Technologies like ENUM (when/where available) could enable >> >>gateways to >> >>>convert originating telephone numbers into URIs. Of course, >> >>a gateway >> >>>wouldn't be able to assert that identity to an intermediary >> >>unless it >> >>>possessed credentials appropriate to that URI, which is unlikely. >>> >>>For outbound calls (SIP-PSTN), the gateway may or may not be >>>able to map >>>(authenticated) SIP URIs representing originators to >>>appropriate telephone >>>numbers via some sort of local tables as you suggested. If >>>not, might also >>>pick a number from a pool, sure. The question of whether some >>>authentication >>>service should be able to assert an originating telephone >>>number (in an >>>authenticated identity body, say) that a gateway will use is >>>also a trust >>>question - it is possible to put the tel URL in the AIB. If >>>the gateway has >>>a reason to trust the authentication service, then certainly >>>it should send >>>that number to the PSTN (when the protocol allows gateways >> >>to supply a >> >>>number, like with ISUP or Q.931). The gateway would be very >>>ill advised to >>>take just any authentication service's word on this matter, though. >>> >>>The target of the calls for the PSTN should be identified >>>with a telephone >>>number - at least, by the time the call arrives a gateway, >>>it's Request-URI >>>should contain a tel URL or a SIP URI with a tel URL >>>component. Whether the >>>originating UAC sets the To header field to a tel URL or a >>>subsequent proxy >>>retargets the request doesn't seem to make much difference. >>>ENUM can also >>>play a pretty obvious role here. >>> >>>Jon Peterson >>>NeuStar, Inc. >>> >>> >>>>-----Original Message----- >>>>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>>Sent: Monday, January 06, 2003 1:22 PM >>>>To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, >>> >>Brian; 'Henning >> >>>>Schulzrinne' >>>>Cc: 'sipping@ietf.org' >>>>Subject: RE: [Sipping] URIs for Gateways >>>> >>>> >>>>I agree with this. I'm confused by those who seem to think that >>>>P-Asserted-Identity is needed when the long term solution is >>>>fully baked. If the UA knows its identity, which seems >>>>reasonable, then it can "assert" it, and have that assertion >>>>validated by a trusted entity using cryptographic means. >>>>That is the fundamental idea I get out of Jon's proposal. >>>>The only circumstance where that won't work is where the >>>>UA doesn't know its identity. I don't see that as a problem >>>>on any network I'm aware of, but ...... keep reading. >>>> >>>>I do think there is a problem which this whole thread talks about. >>>>The basic reality is that many users of SIP UAs will have two >>>>identities - a SIP URI and a telephone number. It may be >>>>necessary to assert both identities in one call, because the >>>>originator of the call does not know which identity may be >>>>needed. There is no current header to do this. I think that >>>>it is advantageous to have a proxy be able to assert the phone >>>>number. Otherwise EVERY UA will have to be able to understand >>>>that two identities are possible, know them both by some >>>>unspecified means, and assert them in every call on every UA. >>>>This seems unreasonable. I'm not sure that there is a reason >>>>to have both identities validated, but there could be. >>>> >>>>Brian >>>> >>>>>-----Original Message----- >>>>>From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>>>Sent: Monday, January 06, 2003 2:06 PM >>>>>To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne' >>>>>Cc: 'sipping@ietf.org' >>>>>Subject: RE: [Sipping] URIs for Gateways >>>>> >>>>> >>>>> >>>>>RFC3325 was 'short-term' because it was achievable in the >>>>>short-term and has >>>>>a more limited (but still useful) applicability. The >>>>>long-term identity >>>>>solution must be a superset of the functionality of >>>>>short-term - it must >>>>>address the short-term scope of applicability, but also >>>>>encompass general >>>>>needs for network assertion (which SIP does have). >>>>>Accordingly, it takes >>>>>longer to develop. At such a time as there is a workable >>>>>long-term solution, >>>>>it would be pointless to allow both to be SIP standards >>>>>except as part of a >>>>>transition plan. So in that sense, I disagree - one is a >>>>>short-term solution >>>>>of the other. >>>>> >>>>>Jon Peterson >>>>>NeuStar, Inc. >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>>>>>Sent: Friday, January 03, 2003 8:20 AM >>>>>>To: Rosen, Brian; 'Henning Schulzrinne' >>>>>>Cc: 'sipping@ietf.org' >>>>>>Subject: RE: [Sipping] URIs for Gateways >>>>>> >>>>>> >>>>>>Network asserted identity (RFC 3325) is the real network >>>>>>asserted identity. It is a P header not because it is >>>>>>preliminary, but because the whole idea of network assertion >>>>>>is not generally applicable to all SIP architectures. For RFC >>>>>>3325 a trust domain needs to exist between proxies that use >>>>>>the P-Asserted-Identity in order to guarantee the privacy, >>>>>>this does not exist in all SIP networks. In does in 3GPP and >>>>>>therefore 3GPP are using RFC 3325. >>>>>> >>>>>>If you want to let the 1et outbound proxy assert identity on >>>>>>your behalf then use RFC 3325. If you want to let application >>>>>>servers with whom you have a secure relationship assert your >>>>>>identity, then use Jon Petersons drafts, when they eventually >>>>>>become RFCs. >>>>>> >>>>>>One is not a short term solution for the other. >>>>>> >>>>>>Keith >>>>>> >>>>>>Keith Drage >>>>>>Lucent Technologies >>>>>>Tel: +44 1793 776249 >>>>>>Email: drage@lucent.com >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>>>>>Sent: 02 January 2003 20:49 >>>>>>>To: 'Henning Schulzrinne' >>>>>>>Cc: 'sipping@ietf.org' >>>>>>>Subject: RE: [Sipping] URIs for Gateways >>>>>>> >>>>>>> >>>>>>>Yeah, I actually thought of just allowing a display >>>>>> >>>name in the >>> >>>>>>>Request URI and using that, but it seems so foolish to make >>>>>> >>>>>>a change, >>>>>> >>>>>>>and have that change not be exactly what we needed. >>>>>>> >>>>>>>We could use NAI. I suppose we could use a >>>>>> >>>P-Asserted-Identity >>> >>>>>>>with a tel URI: >>>>>>>P-Asserted-Identity tel:+17247426826 >>>>>>> >>>>>>>What do we do when the "real" NAI happens? >>>>>>> >>>>>>>Brian >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>>Sent: Thursday, January 02, 2003 3:10 PM >>>>>>>>To: Rosen, Brian >>>>>>>>Cc: 'sipping@ietf.org' >>>>>>>>Subject: Re: [Sipping] URIs for Gateways >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>I'd like to get a new header for the calling >>>>>>>> >>>party number on >>> >>>>>>>>>an outbound call. That way, the translator can be >>>>>>>> >>>>a proxy and >>>> >>>>>>>>>add the header. I'd recommend that gateways allow >>>>>>>> >>>>the number >>>> >>>>>>>>>to be in the From. >>>>>>>> >>>>>>>>Generalized, you want something like the Request-URI >>>>>>> >>>>>that can be >>>>> >>>>>>>>modified or inserted. How about the NAI stuff? >>>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Sipping mailing list >>>>>> >>>>>https://www1.ietf.org/mailman/listinfo/sipping >>>>> >>>>>>>This list is for NEW development of the application of SIP >>>>>>>Use sip-implementors@cs.columbia.edu for questions on >>>>>> >>>>current sip >>>> >>>>>>>Use sip@ietf.org for new developments of core SIP >>>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Sipping mailing list >>>>> >>>>https://www1.ietf.org/mailman/listinfo/sipping >>>> >>>>>>This list is for NEW development of the application of SIP >>>>>>Use sip-implementors@cs.columbia.edu for questions on >>>>> >>>current sip >>> >>>>>>Use sip@ietf.org for new developments of core SIP >>>>>> >>>>> >>>>>_______________________________________________ >>>>>Sipping mailing list >>>> >>>https://www1.ietf.org/mailman/listinfo/sipping >>> >>>>>This list is for NEW development of the application of SIP >>>>>Use sip-implementors@cs.columbia.edu for questions on >>>> >>current sip >> >>>>>Use sip@ietf.org for new developments of core SIP >>>>> >>>> > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 00:26:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20454 for ; Thu, 9 Jan 2003 00:26:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h095c5918604 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 00:38:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095c5J18601 for ; Thu, 9 Jan 2003 00:38:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20446 for ; Thu, 9 Jan 2003 00:25:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095ZbJ17906; Thu, 9 Jan 2003 00:35:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095YLJ17854 for ; Thu, 9 Jan 2003 00:34:21 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20323 for ; Thu, 9 Jan 2003 00:22:17 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h095PXFp021861 for ; Wed, 8 Jan 2003 21:25:33 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-141-97.cisco.com [128.107.141.97]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id HTL00004; Wed, 8 Jan 2003 21:26:06 -0800 (PST) From: "Cullen Jennings" To: Subject: RE: [Sipping] URIs for Gateways Date: Wed, 8 Jan 2003 21:25:33 -0800 Message-ID: <002301c2b79f$882feb00$618d6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <15A2739B7DAA624D8091C65981D7DA815EB501@stntexch2.va.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We should roll it into the same work either way. > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Peterson, Jon > Sent: Wednesday, January 08, 2003 2:32 PM > To: 'Paul Kyzivat'; Rosen, Brian > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > > On the subject of a 'port' parameter, I agree this is best as > a tel URL parameter. In fact, I suggest that the trunk group > tel URL parameter currently under development in IPTEL might > be sufficient for expressing port information. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, January 08, 2003 12:38 PM > > To: Rosen, Brian > > Cc: 'sipping@ietf.org' > > Subject: Re: [Sipping] URIs for Gateways > > > > > > Brian, > > > > A few initial comments. More later when I get time to think > about it. > > > > - I'm not sure of the advisability of adding caller name to > > the tel uri. > > If you do it, I don't like that way. Would prefer a tel: > > parameter, as in > > tel:+14125551212;caller-name="Alice Toklas" > > > > - I don't think the port should be a sip uri parameter. It is very > > telephony oriented, so I think it is better as a tel: uri parameter. > > > > Paul > > > > Rosen, Brian wrote: > > > After all of this, I propose the following: > > > > > > 1. We add the possibility of a callerId string to a tel uri: > > > telephone-uri = "tel:" [callerIdName LWS] subscriber > > > callerIdName = quoted-string > > > > > > 2. Gateways accept or send sip uris of the form: > > > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; > > user=phone; port=3 > > > or tel uris of the form: > > > tel:"Alice Toklas" +14125551212; port=3 > > > or "ordinary" sip uri's with extra information in a > separate header > > > of the form: > > >
+14125551212; port=3 > > > > > > where
could be "P-Asserted-Identity", or it > could be a new > > > header we define for the purpose. > > > > > > Then, we have the following possibilities: > > > > > > SIP device to gateway (outgoing) call > > > To a phone number > > > use the phone number in the Request-URI & To:, probably > > > in a tel URI, or maybe phonenumber@localdomain; user=phone > > > > > > use normal sip URI in From: > > > > > > If a translator is available, it may assert the > phone number > > > for the identity in the From: using
> > > > > > proxy may rewrite the Request-URI in the form of > > > sip: phone@gateway;user=phone;port=portnum > > > > > > To a sip URI > > > use the sip uri in the Request-URI and To: > > > use normal sip URI in From: > > > > > > proxy rewrites Request-URI, due to forwarding behavior, > > > ENUM lookup, etc, resulting in a tel URI or a > user=phone sip > > > uri. If necessary, a local incoming proxy can > rewrite it to > > > add the port parameter to the Request-URI based > on the From: > > > > > > If a translator is available, it may assert the > phone number > > > for the identity in the From: using the
> > > > > > Gateway to SIP device (incoming call) > > > With mapping > > > use the mapped uri in the Request-URI & To: > > > > > > (optionally) supply called number using
> > > This might be needed when multiple called numbers > > > map to the same uri. > > > > > > use sip:"callerId" phone@gateway; port=portnum or > > > a tel: uri in From: > > > > > > Without mapping > > > use a provisioned (per port) URI, a tel uri with > the called > > > number, or a sip uri with calledNumber@localdomain; > > user=phone > > > in the Request-URI & To:. Gateways should support all 3, > > > choice should be made by provisioning. > > > > > > use sip:"callerId" phone@gateway; port=portnum or tel > > > uri in From: > > > > > > proxy will rewrite the Request-URI with the > correct sip URI > > > associated with the called number > > > > > > Brian > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list > is for NEW development of the application of SIP Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 00:30:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20514 for ; Thu, 9 Jan 2003 00:30:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h095gPR18768 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 00:42:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095gPJ18765 for ; Thu, 9 Jan 2003 00:42:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20500 for ; Thu, 9 Jan 2003 00:30:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095e7J18694; Thu, 9 Jan 2003 00:40:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h095d2J18632 for ; Thu, 9 Jan 2003 00:39:02 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20470 for ; Thu, 9 Jan 2003 00:26:59 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h095U9Fp023429; Wed, 8 Jan 2003 21:30:09 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-141-97.cisco.com [128.107.141.97]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id HTL00072; Wed, 8 Jan 2003 21:30:42 -0800 (PST) From: "Cullen Jennings" To: "'Paul Kyzivat'" , "'Rosen, Brian'" Cc: Subject: RE: [Sipping] URIs for Gateways Date: Wed, 8 Jan 2003 21:30:09 -0800 Message-ID: <002401c2b7a0$2cc05dd0$618d6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3E1C8C28.4030802@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The port names a specific resource on the GW (similar to a trunk group) so if it is in a SIP URL, I think it should be in the user portion. This matches up perfectly with just defining it in the tel URL then let the normal tel to sip translation rules apply to how looks in a SIP URL. > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Paul Kyzivat > Sent: Wednesday, January 08, 2003 12:38 PM > To: Rosen, Brian > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] URIs for Gateways > > > Brian, > > A few initial comments. More later when I get time to think about it. > > - I'm not sure of the advisability of adding caller name to > the tel uri. > If you do it, I don't like that way. Would prefer a tel: > parameter, as in > tel:+14125551212;caller-name="Alice Toklas" > > - I don't think the port should be a sip uri parameter. It is very > telephony oriented, so I think it is better as a tel: uri parameter. > > Paul > > Rosen, Brian wrote: > > After all of this, I propose the following: > > > > 1. We add the possibility of a callerId string to a tel uri: > > telephone-uri = "tel:" [callerIdName LWS] subscriber > > callerIdName = quoted-string > > > > 2. Gateways accept or send sip uris of the form: > > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; > > port=3 or tel uris of the form: > > tel:"Alice Toklas" +14125551212; port=3 > > or "ordinary" sip uri's with extra information in a separate header > > of the form: > >
+14125551212; port=3 > > > > where
could be "P-Asserted-Identity", or it could be a new > > header we define for the purpose. > > > > Then, we have the following possibilities: > > > > SIP device to gateway (outgoing) call > > To a phone number > > use the phone number in the Request-URI & To:, probably > > in a tel URI, or maybe phonenumber@localdomain; user=phone > > > > use normal sip URI in From: > > > > If a translator is available, it may assert the phone number > > for the identity in the From: using
> > > > proxy may rewrite the Request-URI in the form of > > sip: phone@gateway;user=phone;port=portnum > > > > To a sip URI > > use the sip uri in the Request-URI and To: > > use normal sip URI in From: > > > > proxy rewrites Request-URI, due to forwarding behavior, > > ENUM lookup, etc, resulting in a tel URI or a user=phone sip > > uri. If necessary, a local incoming proxy can rewrite it to > > add the port parameter to the Request-URI based on the From: > > > > If a translator is available, it may assert the phone number > > for the identity in the From: using the
> > > > Gateway to SIP device (incoming call) > > With mapping > > use the mapped uri in the Request-URI & To: > > > > (optionally) supply called number using
> > This might be needed when multiple called numbers > > map to the same uri. > > > > use sip:"callerId" phone@gateway; port=portnum or > > a tel: uri in From: > > > > Without mapping > > use a provisioned (per port) URI, a tel uri with the called > > number, or a sip uri with calledNumber@localdomain; > user=phone > > in the Request-URI & To:. Gateways should support all 3, > > choice should be made by provisioning. > > > > use sip:"callerId" phone@gateway; port=portnum or tel > > uri in From: > > > > proxy will rewrite the Request-URI with the correct sip URI > > associated with the called number > > > > Brian > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 02:11:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02227 for ; Thu, 9 Jan 2003 02:11:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097NTo31768 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 02:23:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097NTJ31765 for ; Thu, 9 Jan 2003 02:23:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02220 for ; Thu, 9 Jan 2003 02:11:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097KvJ31676; Thu, 9 Jan 2003 02:20:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DPJJ18931 for ; Tue, 7 Jan 2003 08:25:19 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11672 for ; Tue, 7 Jan 2003 08:14:03 -0500 (EST) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h07DHJYt007365 for ; Tue, 7 Jan 2003 07:17:20 -0600 (CST) Received: from fisherlatitude ([135.210.110.158]) by maillennium.att.com (mailgw1) with SMTP id <20030107131651gw100ksckpe>; Tue, 7 Jan 2003 13:16:51 +0000 From: "Steve Fisher" To: "'Eric Burger'" Cc: Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Tue, 7 Jan 2003 08:15:25 -0500 Message-ID: <000001c2b64e$d778fcd0$9e6ed287@fisherlatitude> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D097BAF@zoe.office.snowshore.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, I've been thinking about your statement below... > > If we say SIP for stimulus reporting, then the diagram you drew, > > with the implication that the signaling follows the signaling path, > > is what will occur. > > > > Is this distinction important for you? The design team did not come > > to full agreement on which way to go. Compelling arguments either > > way welcomed. Could you possibly elaborate on how "SIP for stimulus reporting" would work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using INFO? It's fairly clear from the KPML draft how HTTP would work, but SIP was less clear to me... Thanks! Steve -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, December 17, 2002 5:18 PM To: Don Stanwyck Cc: sipping@ietf.org; Jain, Rajnish (Rajnish) Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Rajnish is 1000% correct in his interpretation. Looking at the message I can see how my statement isn't entirely clear. I am on record in this and other fora that H.248 and J.162 are the appropriate protocols for device control. See my posts to the speechsc list. I should have a paste buffer with my "Don't use SIP for low-level peripheral device control" rant. When I said "It [the thing referenced as "softswitch" in Rajnish's e-mail -- ewb] is not a media gateway controller" I meant it was not a media gateway controller, e.g., a device control thing, which uses device control protocols like H.248 and J.162. Now it's my turn for interpreting Rajnish, instead of him interpreting me :-) I assumed that the "PSTN X" thing was a MG-MGC combination, speaking SIP on the packet network side. E.g., the MG-MGC interface was a private matter, not of interest to the discussion. Sorry for the confusion. > -----Original Message----- > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > Sent: Tuesday, December 17, 2002 4:02 PM > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish) > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Don, > I don't think Eric implied controlling a MG from a Softswitch > via SIP in his > comment. That particular topic has come up in this forum many > times and as I > recall the conclusion has always been that SIP is not meant > for that. SIP is > a peer-to-peer to protocol not a master-slave protcol - > agreed. However this > is completely orthogonal to using stimulus/markup signaling > in SIP. I don't > see how in-lining a KPML doc (e.g.) in a SIP message breaks > SIP paradigm. > > Eric, > In general, I would like to propose an HTTP-free alternative > for delivery of > stimulus signals, such as through in-lining of KPML. The > benefits of such an > alternative in my mind are following: > > - it would make it easier for SIP developers on embedded > platforms to embrace > markup/stimulus signaling that don't support HTTP currently > > - it would facilitate close coordination between announcement > play and DTMF > collection. Barge-in is a good example for that. The app > can delegate the > job to stop announcement play at barge-in to the > Softswitch. As an aside, > the Softswitch in my previous figure is one w/ bizarre API > as you say :-) > > Rajnish > > -----Original Message----- > From: Don Stanwyck [mailto:don@stanwyck.com] > Sent: Tuesday, December 17, 2002 3:10 PM > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)' > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)' > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > RFC 3261, Section 2 reads: > > //START QUOTE > > SIP supports five facets of establishing and terminating > multimedia communications: > - User location: determination of the end system to be > used for communication; > - User availability: determination of the willingness > of the called party to engage in communications; > - User capabilities: determination of the media and media > parameters to be used; > - Session setup: "ringing", establishment of session > parameters at both called and calling party; > - Session management: including transfer and termination > of sessions, modifying session parameters, and invoking > services. > > SIP is not a vertically integrated communications system. > SIP is rather > a component that can be used with other IETF protocols to build a > complete multimedia architecture. Typically, these architectures will > include protocols such as the Real-time Transport Protocol (RTP) (RFC > 1889 [28]) for transporting real-time data and providing QoS feedback, > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for > controlling > delivery of streaming media, the Media Gateway Control > Protocol (MEGACO) > (RFC 3015 [30]) for controlling gateways to the Public Switched > Telephone Network (PSTN), and the Session Description Protocol (SDP) > (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP > should be used in conjunction with other protocols in order to provide > complete services to the users. However, the basic functionality and > operation of SIP does not depend on any of these protocols. > > //END QUOTE > > I can't find any support in this definition of SIP for > carrying stimulus > signaling or for controling media gateways (comment 1 in Eric's > comments). SIP, as defined and approved by the IETF, is not > expected to > do these kinds of things that other IETF protocols are designed to > handle. > > Let's try to keep SIP doing the things it is designed to do and does > well, and not try to make it into a protocol for doing everything > imaginable. It is already in danger of becoming too difficult to > implement as the number of options and new headers grows. > > Don Stanwyck > > > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Eric Burger > > Sent: Tuesday, December 17, 2002 12:12 PM > > To: Jain, Rajnish (Rajnish) > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs and apps? > > > > > > For timelines, I would suggest asking the work group chairs. > > We're at their mercy :-) > > > > Putting my ISC hat on, what is the Softswitch in your diagram? > > 1. It is not a media gateway controller, as it talks to > > the gateway with SIP (right answer, by the way). > > 2. Is it a Stateless Proxy, a'la the Routing Function > > in the ISC reference diagram? If so, that works > > exactly as you want it to. See below for more. > > 3. Is it an application server, a'la dynamicsoft, > > Ubiquity, LongBoard, etc.? If so, that also works > > exactly as you want it to. See below for more. > > 4. Is it some kind of statefull proxy, with a bizarre, > > proprietary API to the pre-paid application (e.g., > > Parlay, JAIN, EXS, ...)? If so, you are on your > > own. > > > > If we say "HTTP only" for stimulus reporting, the PSTN > > gateway must be a HTTP client. The good news is the gateway > > can communicate directly with the pre-paid application. That > > also means the pre-paid application needs to have a HTTP > > server. Alternatively, if the "Softswitch" is really a > > telephony application server (case #3 above), then it > > probably already has HTTP server capability built-in. > > > > If we say SIP for stimulus reporting, then the diagram you > > drew, with the implication that the signaling follows the > > signaling path, is what will occur. > > > > Is this distinction important for you? The design team did > > not come to full agreement on which way to go. Compelling > > arguments either way welcomed. > > > > > > > -----Original Message----- > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > Sent: Friday, December 06, 2002 4:20 PM > > > To: Eric Burger; Jain, Rajnish (Rajnish) > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex > > > SIP UAs and apps? > > > > > > > > > Eric, > > > > > > Thanks for your response. Would you be able to comment on the > > > timeline of when does the design team hope to accomplish the > > > following: > > > > > > - general acceptance of the stimulus signaling, KPML etc. > > > - standardization of app interaction fwk, KPML into an RFC > > > > > > Regarding an example of a PSTN switch that can be connected to a > > > pre-paid app over SIP-T, I don't know how much I can disclose in > > > front of this forum, but that is something being looked at by a > > > few telecom gear vendors in my understanding. > > > > > > I wanted to bring your attention to SIP-T wrt to my > > previous question. > > > I believe your answer will remain the same but I just to > wanted to > > > re-iterate the question in different words this time, > just to make > > > sure we're communicating: > > > > > > In the setup below: > > > Pre-paid app > > > | > > > POTS ---- PSTN X <---SIP-T---> Softswitch ---- > > > > > > > > > .. you would think, application interaction framework concepts > > > such as stimulus signaling, user-inetrfaces and KPML etc. are > > > designed to work over the SIP-T i/f between packet-enabled PSTN > > > switch and a Softswitch. Wouldn't you? > > > > > > Thanks, > > > Rajnish > > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish) > > [mailto:rajnishjain@lucent.com] > > > > > > The Application Interaction Framework draft talks about stimulus > > > signaling as a way for SIP UAs to interact w/ SIP > applications. The > > > draft suggests use of markup languages to allow > > applications to manage > > > local/remote user interfaces on SIP UAs. > > > > > > While the draft exemplifies a UA's stimulus/markup interaction w/ > > > a pre-paid application server, it is not very clear to us if the > > > caller UA (instead of a subscriber end-point) can be a complex UA > > > such as the following: > > > > > > - SIP (enabled) Gateway > > > > Why not? It does SIP. It may do tone detection. > > > > > - PSTN Switch w/ SIP-T interface > > > > Why not? It does SIP. It may do tone detection. > > > > > and does the draft recommend stimulus/markup signaling between > > > such complex/concentrated UAs (or apps) and SIP applications ? > > > > The draft is silent on it. If you manufacture media rich > > gateways, you might say "of course". If you manufacture > > media servers, you might say "you could if you wanted, but > > you would be better served if you didn't." :-) > > > > > In other words, does the stimulus signaling apply to following > > > scenarios ?: > > > > > > 1. The pre-paid caller is connected to a PSTN switch that has a > > > SIP-T interface to the pre-paid application. > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse > > and execute KPML, and report using SIP (or, yuck, http). > > > > Do you know of such a switch? > > > > > 2. The pre-paid caller is connected to a PBX (SIP Gateway) over an > > > ISDN i/f, which in turn is connected to the pre-paid app. over > > > normal SIP. > > > > Same issues as for the PSTN switch. > > > > > If yes, would the terms client-local and client-remote still be > > > accurate, as the user here is a POTS/ISDN user? From the user's > > > perspective, the UI would be client-remote. But from > application's > > > perspective the UI would be client-local (as the UI will be > > on the PBX > > > or PSTN switch both of which look like a UA to app server). > > > > It is still client-local, as the gateway/switch/PBX is a > > local proxy for the user. If you used a media server in the > > IP network behind the gateway/switch/PBX to execute the KPML, > > then you would be cline-remote. > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 02:13:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02290 for ; Thu, 9 Jan 2003 02:13:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097POi31868 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 02:25:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097POJ31865 for ; Thu, 9 Jan 2003 02:25:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02279 for ; Thu, 9 Jan 2003 02:13:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097MnJ31753; Thu, 9 Jan 2003 02:22:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080caJ31939 for ; Tue, 7 Jan 2003 19:38:36 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05147 for ; Tue, 7 Jan 2003 19:27:06 -0500 (EST) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h080UNYt013379 for ; Tue, 7 Jan 2003 18:30:23 -0600 (CST) Received: from fisherlatitude ([135.210.40.96]) by maillennium.att.com (mailgw1) with SMTP id <20030108002954gw100ksh3ue>; Wed, 8 Jan 2003 00:29:54 +0000 From: "Steve Fisher" To: "'Eric Burger'" Cc: Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Tue, 7 Jan 2003 19:28:28 -0500 Message-ID: <000801c2b6ac$dd919150$6028d287@fisherlatitude> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D24864B@zoe.office.snowshore.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, thanks for the quick response! Do you have a sense when the design team will decide about SIP or HTTP reporting? Also, do you have any more thoughts as to how the SIP version would work? Steve Fisher Division Manager AT&T Labs -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Tuesday, January 07, 2003 3:00 PM To: Steve Fisher Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? To answer the question directly: KPML only works with HTTP reporting. It would be a different language for SIP reporting. MSCML is an example of a language that uses SIP for reporting. To answer the SIP stimulus reporting question: Done INFO in the past, not planning on it again :-) NOTIFY is my leading contender, but a new method may be needed because if you do a strict reading of NOTIFY, you might not want a NOTIFY without a SUBSCRIBE. Using SUBSCRIBE as a method of pushing KPML is out and out evil (I mean wrong). KPML changes the state of the UAS. SUBSCRIBE is not supposed to have any side-effects. > -----Original Message----- > From: Steve Fisher [mailto:sfisher1@att.com] > Sent: Tuesday, January 07, 2003 8:15 AM > To: Eric Burger > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Eric, > > I've been thinking about your statement below... > > > > If we say SIP for stimulus reporting, then the diagram you drew, > > > with the implication that the signaling follows the > signaling path, > > > is what will occur. > > > > > > Is this distinction important for you? The design team > did not come > > > > to full agreement on which way to go. Compelling > arguments either > > > way welcomed. > > Could you possibly elaborate on how "SIP for stimulus reporting" would > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using > INFO? It's fairly clear from the KPML draft how HTTP would work, but > SIP was less clear to me... > > Thanks! > Steve > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of Eric Burger > Sent: Tuesday, December 17, 2002 5:18 PM > To: Don Stanwyck > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish) > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Rajnish is 1000% correct in his interpretation. Looking at > the message > I can see how my statement isn't entirely clear. > > I am on record in this and other fora that H.248 and J.162 are the > appropriate protocols for device control. See my posts to the > speechsc list. I should have a paste buffer with my "Don't use SIP > for low-level > peripheral device control" rant. > > When I said "It [the thing referenced as "softswitch" in Rajnish's > e-mail -- ewb] is not a media gateway controller" I meant it was not a > media gateway controller, e.g., a device control thing, which uses > device control protocols like H.248 and J.162. > > Now it's my turn for interpreting Rajnish, instead of him interpreting > me :-) I assumed that the "PSTN X" thing was a MG-MGC combination, > speaking SIP on the packet network side. E.g., the MG-MGC interface > was a private matter, not of interest to the discussion. > > Sorry for the confusion. > > > -----Original Message----- > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > Sent: Tuesday, December 17, 2002 4:02 PM > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish) > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP > > UAs and apps? > > > > > > Don, > > I don't think Eric implied controlling a MG from a Softswitch via > > SIP in his comment. That particular topic has come up in this forum > > many times and as I > > recall the conclusion has always been that SIP is not meant > > for that. SIP is > > a peer-to-peer to protocol not a master-slave protcol - > > agreed. However this > > is completely orthogonal to using stimulus/markup signaling > > in SIP. I don't > > see how in-lining a KPML doc (e.g.) in a SIP message breaks > > SIP paradigm. > > > > Eric, > > In general, I would like to propose an HTTP-free alternative for > > delivery of stimulus signals, such as through in-lining of KPML. The > > benefits of such an > > alternative in my mind are following: > > > > - it would make it easier for SIP developers on embedded platforms > > to embrace > > markup/stimulus signaling that don't support HTTP currently > > > > - it would facilitate close coordination between announcement play > > and DTMF > > collection. Barge-in is a good example for that. The app > > can delegate the > > job to stop announcement play at barge-in to the > > Softswitch. As an aside, > > the Softswitch in my previous figure is one w/ bizarre API > > as you say :-) > > > > Rajnish > > > > -----Original Message----- > > From: Don Stanwyck [mailto:don@stanwyck.com] > > Sent: Tuesday, December 17, 2002 3:10 PM > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)' > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)' > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP > > UAs and apps? > > > > > > RFC 3261, Section 2 reads: > > > > //START QUOTE > > > > SIP supports five facets of establishing and terminating multimedia > > communications: > > - User location: determination of the end system to be > > used for communication; > > - User availability: determination of the willingness > > of the called party to engage in communications; > > - User capabilities: determination of the media and media > > parameters to be used; > > - Session setup: "ringing", establishment of session > > parameters at both called and calling party; > > - Session management: including transfer and termination > > of sessions, modifying session parameters, and invoking > > services. > > > > SIP is not a vertically integrated communications system. SIP is > > rather a component that can be used with other IETF protocols to > > build a complete multimedia architecture. Typically, these > architectures will > > include protocols such as the Real-time Transport Protocol > (RTP) (RFC > > 1889 [28]) for transporting real-time data and providing > QoS feedback, > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for > > controlling > > delivery of streaming media, the Media Gateway Control > > Protocol (MEGACO) > > (RFC 3015 [30]) for controlling gateways to the Public Switched > > Telephone Network (PSTN), and the Session Description Protocol (SDP) > > (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP > > should be used in conjunction with other protocols in order > to provide > > complete services to the users. However, the basic > functionality and > > operation of SIP does not depend on any of these protocols. > > > > //END QUOTE > > > > I can't find any support in this definition of SIP for carrying > > stimulus signaling or for controling media gateways (comment 1 in > > Eric's comments). SIP, as defined and approved by the IETF, is not > > expected to > > do these kinds of things that other IETF protocols are designed to > > handle. > > > > Let's try to keep SIP doing the things it is designed to do > and does > > well, and not try to make it into a protocol for doing everything > > imaginable. It is already in danger of becoming too difficult to > > implement as the number of options and new headers grows. > > > > Don Stanwyck > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > > > Behalf Of Eric Burger > > > Sent: Tuesday, December 17, 2002 12:12 PM > > > To: Jain, Rajnish (Rajnish) > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > complex SIP UAs and apps? > > > > > > > > > For timelines, I would suggest asking the work group chairs. We're > > > at their mercy :-) > > > > > > Putting my ISC hat on, what is the Softswitch in your diagram? > > > 1. It is not a media gateway controller, as it talks to > > > the gateway with SIP (right answer, by the way). > > > 2. Is it a Stateless Proxy, a'la the Routing Function > > > in the ISC reference diagram? If so, that works > > > exactly as you want it to. See below for more. > > > 3. Is it an application server, a'la dynamicsoft, > > > Ubiquity, LongBoard, etc.? If so, that also works > > > exactly as you want it to. See below for more. > > > 4. Is it some kind of statefull proxy, with a bizarre, > > > proprietary API to the pre-paid application (e.g., > > > Parlay, JAIN, EXS, ...)? If so, you are on your > > > own. > > > > > > If we say "HTTP only" for stimulus reporting, the PSTN gateway > > > must be a HTTP client. The good news is the gateway can > > > communicate directly with the pre-paid application. That also > > > means the pre-paid application needs to have a HTTP server. > > > Alternatively, if the "Softswitch" is really a telephony > > > application server (case #3 above), then it probably already has > > > HTTP server capability built-in. > > > > > > If we say SIP for stimulus reporting, then the diagram you drew, > > > with the implication that the signaling follows the signaling > > > path, is what will occur. > > > > > > Is this distinction important for you? The design team did not > > > come to full agreement on which way to go. Compelling arguments > > > either way welcomed. > > > > > > > > > > -----Original Message----- > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > > Sent: Friday, December 06, 2002 4:20 PM > > > > To: Eric Burger; Jain, Rajnish (Rajnish) > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup > between complex > > > > SIP UAs and apps? > > > > > > > > > > > > Eric, > > > > > > > > Thanks for your response. Would you be able to comment on the > > > > timeline of when does the design team hope to accomplish the > > > > following: > > > > > > > > - general acceptance of the stimulus signaling, KPML etc. > > > > - standardization of app interaction fwk, KPML into an RFC > > > > > > > > Regarding an example of a PSTN switch that can be > connected to a > > > > pre-paid app over SIP-T, I don't know how much I can > disclose in > > > > front of this forum, but that is something being looked at by a > > > > few telecom gear vendors in my understanding. > > > > > > > > I wanted to bring your attention to SIP-T wrt to my > > > previous question. > > > > I believe your answer will remain the same but I just to > > wanted to > > > > re-iterate the question in different words this time, > > just to make > > > > sure we're communicating: > > > > > > > > In the setup below: > > > > Pre-paid app > > > > | > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ---- > > > > > > > > > > > > .. you would think, application interaction framework concepts > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are > > > > designed to work over the SIP-T i/f between packet-enabled PSTN > > > > switch and a Softswitch. Wouldn't you? > > > > > > > > Thanks, > > > > Rajnish > > > > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish) > > > [mailto:rajnishjain@lucent.com] > > > > > > > > The Application Interaction Framework draft talks about stimulus > > > > signaling as a way for SIP UAs to interact w/ SIP > > applications. The > > > > draft suggests use of markup languages to allow > > > applications to manage > > > > local/remote user interfaces on SIP UAs. > > > > > > > > While the draft exemplifies a UA's stimulus/markup > interaction w/ > > > > a pre-paid application server, it is not very clear to > us if the > > > > caller UA (instead of a subscriber end-point) can be a > complex UA > > > > such as the following: > > > > > > > > - SIP (enabled) Gateway > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > - PSTN Switch w/ SIP-T interface > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > and does the draft recommend stimulus/markup signaling between > > > > such complex/concentrated UAs (or apps) and SIP applications ? > > > > > > The draft is silent on it. If you manufacture media rich > > > gateways, you might say "of course". If you manufacture media > > > servers, you might say "you could if you wanted, but you would be > > > better served if you didn't." :-) > > > > > > > In other words, does the stimulus signaling apply to following > > > > scenarios ?: > > > > > > > > 1. The pre-paid caller is connected to a PSTN switch that has a > > > > SIP-T interface to the pre-paid application. > > > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse and > > > execute KPML, and report using SIP (or, yuck, http). > > > > > > Do you know of such a switch? > > > > > > > 2. The pre-paid caller is connected to a PBX (SIP > Gateway) over an > > > > > ISDN i/f, which in turn is connected to the pre-paid app. over > > > > normal SIP. > > > > > > Same issues as for the PSTN switch. > > > > > > > If yes, would the terms client-local and client-remote still be > > > > accurate, as the user here is a POTS/ISDN user? From the user's > > > > perspective, the UI would be client-remote. But from > > application's > > > > perspective the UI would be client-local (as the UI will be > > > on the PBX > > > > or PSTN switch both of which look like a UA to app server). > > > > > > It is still client-local, as the gateway/switch/PBX is a local > > > proxy for the user. If you used a media server in the IP network > > > behind the gateway/switch/PBX to execute the KPML, then you would > > > be cline-remote. _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 02:16:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02345 for ; Thu, 9 Jan 2003 02:16:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097S1R32427 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 02:28:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097S0J32424 for ; Thu, 9 Jan 2003 02:28:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02334 for ; Thu, 9 Jan 2003 02:15:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097OdJ31834; Thu, 9 Jan 2003 02:24:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FhDJ30112 for ; Wed, 8 Jan 2003 10:43:13 -0500 Received: from almso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22415 for ; Wed, 8 Jan 2003 10:31:25 -0500 (EST) Received: from maillennium.att.com ([135.25.114.99]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h08FYXDG008924 for ; Wed, 8 Jan 2003 10:34:33 -0500 (EST) Received: from fisherlatitude (fisher-latitude.mt.att.com[135.91.66.75]) by maillennium.att.com (mailgw1) with SMTP id <20030108153405gw100ksd7re>; Wed, 8 Jan 2003 15:34:05 +0000 From: "Steve Fisher" To: Cc: Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Wed, 8 Jan 2003 10:32:34 -0500 Message-ID: <000201c2b72b$2aa88880$96f1fea9@fisherlatitude> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE70D2@esebe019.ntc.nokia.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that KPML is a type of session description, and, in addition, is something an application will likely want established at the beginning of the dialog. Setting up the KPML in a SUBSCRIBE seems like it might result in a race condition, where there would be some period of time in which the "triggers" were not set. Is it true that the current thinking for SIP Reporting is that the KPML (or something like it) would be "inlined" in the SIP INVITE/OK/ACK exchange, using a mechanism similar to that described in draft-jennings-sip-app-info-00? Would this then establish a subscription? Steve -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Wednesday, January 08, 2003 9:03 AM To: rajnishjain@lucent.com; eburger@snowshore.com; sfisher1@att.com Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? The body of a SUBSCRIBE should be used for things like filtering. Something related to the subscription itself. Putting KMPL in the body of SUBSCRIBE is considered as a form of tunnelling, IMO. We try to keep a use of a certain SIP method, header, or whatever to a minimum, preferably one. Bodies of INVITEs typically carry information about the session. KPML, I would consider, a type of session description. Regards, Hisham > -----Original Message----- > From: ext Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > Sent: Wednesday, January 08, 2003 1:34 PM > To: 'Eric Burger'; Steve Fisher > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Eric, > Can you expand on why sending KPML w/in SUBSCRIBE is a bad > idea? In other > words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. > > A SUBSCRIBE message w/ inline KPML should be oblivious to UA > session FSM. > It's an orthogonal activity from UA's perspective. Upon > receipt of a KPML > request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF > collecion and > report digits to app (via NOTIFY). This shouldn't change the > state of SIP > session w/in UA. > > Rajnish > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, January 07, 2003 3:00 PM > To: Steve Fisher > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > To answer the question directly: > > KPML only works with HTTP reporting. It would be a different > language for SIP reporting. MSCML is an example of a > language that uses SIP for reporting. > > > > To answer the SIP stimulus reporting question: > > Done INFO in the past, not planning on it again :-) > > NOTIFY is my leading contender, but a new method may be > needed because if you do a strict reading of NOTIFY, you > might not want a NOTIFY without a SUBSCRIBE. > > Using SUBSCRIBE as a method of pushing KPML is out and out > evil (I mean wrong). KPML changes the state of the UAS. > SUBSCRIBE is not supposed to have any side-effects. > > > > > -----Original Message----- > > From: Steve Fisher [mailto:sfisher1@att.com] > > Sent: Tuesday, January 07, 2003 8:15 AM > > To: Eric Burger > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Eric, > > > > I've been thinking about your statement below... > > > > > > If we say SIP for stimulus reporting, then the diagram > you drew, > > > > with the implication that the signaling follows the > > signaling path, > > > > is what will occur. > > > > > > > > Is this distinction important for you? The design team > > did not come > > > > > > to full agreement on which way to go. Compelling > > arguments either > > > > way welcomed. > > > > Could you possibly elaborate on how "SIP for stimulus > reporting" would > > work? Are you thinking of SUBSCRIBE/NOTIFY? Are you > thinking of using > > INFO? It's fairly clear from the KPML draft how HTTP would > > work, but SIP > > was less clear to me... > > > > Thanks! > > Steve > > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On Behalf > > Of Eric Burger > > Sent: Tuesday, December 17, 2002 5:18 PM > > To: Don Stanwyck > > Cc: sipping@ietf.org; Jain, Rajnish (Rajnish) > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > complex SIP UAs > > and apps? > > > > > > Rajnish is 1000% correct in his interpretation. Looking at > > the message > > I can see how my statement isn't entirely clear. > > > > I am on record in this and other fora that H.248 and J.162 are the > > appropriate protocols for device control. See my posts to the > > speechsc list. I should have a paste buffer with my "Don't use SIP > > for low-level > > peripheral device control" rant. > > > > When I said "It [the thing referenced as "softswitch" in Rajnish's > > e-mail -- ewb] is not a media gateway controller" I meant > it was not a > > media gateway controller, e.g., a device control thing, which uses > > device control protocols like H.248 and J.162. > > > > Now it's my turn for interpreting Rajnish, instead of him > interpreting > > me :-) I assumed that the "PSTN X" thing was a MG-MGC combination, > > speaking SIP on the packet network side. E.g., the MG-MGC interface > > was a private matter, not of interest to the discussion. > > > > Sorry for the confusion. > > > > > -----Original Message----- > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > Sent: Tuesday, December 17, 2002 4:02 PM > > > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish) > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex > > > SIP UAs and apps? > > > > > > > > > Don, > > > I don't think Eric implied controlling a MG from a Softswitch via > > > SIP in his comment. That particular topic has come up in this > > > forum many times and as I > > > recall the conclusion has always been that SIP is not meant > > > for that. SIP is > > > a peer-to-peer to protocol not a master-slave protcol - > > > agreed. However this > > > is completely orthogonal to using stimulus/markup signaling > > > in SIP. I don't > > > see how in-lining a KPML doc (e.g.) in a SIP message breaks > > > SIP paradigm. > > > > > > Eric, > > > In general, I would like to propose an HTTP-free alternative for > > > delivery of stimulus signals, such as through in-lining of KPML. > > > The benefits of such an > > > alternative in my mind are following: > > > > > > - it would make it easier for SIP developers on embedded platforms > > > to embrace > > > markup/stimulus signaling that don't support HTTP currently > > > > > > - it would facilitate close coordination between announcement play > > > and DTMF > > > collection. Barge-in is a good example for that. The app > > > can delegate the > > > job to stop announcement play at barge-in to the > > > Softswitch. As an aside, > > > the Softswitch in my previous figure is one w/ bizarre API > > > as you say :-) > > > > > > Rajnish > > > > > > -----Original Message----- > > > From: Don Stanwyck [mailto:don@stanwyck.com] > > > Sent: Tuesday, December 17, 2002 3:10 PM > > > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)' > > > Cc: sipping@ietf.org; 'Twomey, Michael S (Michael)' > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex > > > SIP UAs and apps? > > > > > > > > > RFC 3261, Section 2 reads: > > > > > > //START QUOTE > > > > > > SIP supports five facets of establishing and terminating > > > multimedia communications: > > > - User location: determination of the end system to be > > > used for communication; > > > - User availability: determination of the willingness > > > of the called party to engage in communications; > > > - User capabilities: determination of the media and media > > > parameters to be used; > > > - Session setup: "ringing", establishment of session > > > parameters at both called and calling party; > > > - Session management: including transfer and termination > > > of sessions, modifying session parameters, and invoking > > > services. > > > > > > SIP is not a vertically integrated communications system. SIP is > > > rather a component that can be used with other IETF protocols to > > > build a complete multimedia architecture. Typically, these > > architectures will > > > include protocols such as the Real-time Transport Protocol > > (RTP) (RFC > > > 1889 [28]) for transporting real-time data and providing > > QoS feedback, > > > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for > > > controlling > > > delivery of streaming media, the Media Gateway Control > > > Protocol (MEGACO) > > > (RFC 3015 [30]) for controlling gateways to the Public Switched > > > Telephone Network (PSTN), and the Session Description > Protocol (SDP) > > > (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP > > > should be used in conjunction with other protocols in order > > to provide > > > complete services to the users. However, the basic > > functionality and > > > operation of SIP does not depend on any of these protocols. > > > > > > //END QUOTE > > > > > > I can't find any support in this definition of SIP for carrying > > > stimulus signaling or for controling media gateways (comment 1 in > > > Eric's comments). SIP, as defined and approved by the IETF, is > > > not expected to > > > do these kinds of things that other IETF protocols are designed to > > > handle. > > > > > > Let's try to keep SIP doing the things it is designed to do > > and does > > > well, and not try to make it into a protocol for doing everything > > > imaginable. It is already in danger of becoming too difficult to > > > implement as the number of options and new headers grows. > > > > > > Don Stanwyck > > > > > > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > > > > Behalf Of Eric Burger > > > > Sent: Tuesday, December 17, 2002 12:12 PM > > > > To: Jain, Rajnish (Rajnish) > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup between > > > > complex SIP UAs and apps? > > > > > > > > > > > > For timelines, I would suggest asking the work group chairs. > > > > We're at their mercy :-) > > > > > > > > Putting my ISC hat on, what is the Softswitch in your diagram? > > > > 1. It is not a media gateway controller, as it talks to > > > > the gateway with SIP (right answer, by the way). > > > > 2. Is it a Stateless Proxy, a'la the Routing Function > > > > in the ISC reference diagram? If so, that works > > > > exactly as you want it to. See below for more. > > > > 3. Is it an application server, a'la dynamicsoft, > > > > Ubiquity, LongBoard, etc.? If so, that also works > > > > exactly as you want it to. See below for more. > > > > 4. Is it some kind of statefull proxy, with a bizarre, > > > > proprietary API to the pre-paid application (e.g., > > > > Parlay, JAIN, EXS, ...)? If so, you are on your > > > > own. > > > > > > > > If we say "HTTP only" for stimulus reporting, the PSTN gateway > > > > must be a HTTP client. The good news is the gateway can > > > > communicate directly with the pre-paid application. That also > > > > means the pre-paid application needs to have a HTTP server. > > > > Alternatively, if the "Softswitch" is really a telephony > > > > application server (case #3 above), then it probably already has > > > > HTTP server capability built-in. > > > > > > > > If we say SIP for stimulus reporting, then the diagram you drew, > > > > with the implication that the signaling follows the signaling > > > > path, is what will occur. > > > > > > > > Is this distinction important for you? The design team did not > > > > come to full agreement on which way to go. Compelling arguments > > > > either way welcomed. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] > > > > > Sent: Friday, December 06, 2002 4:20 PM > > > > > To: Eric Burger; Jain, Rajnish (Rajnish) > > > > > Cc: sipping@ietf.org; Twomey, Michael S (Michael) > > > > > Subject: RE: [Sipping] Stimulus Signaling/Markup > > between complex > > > > > SIP UAs and apps? > > > > > > > > > > > > > > > Eric, > > > > > > > > > > Thanks for your response. Would you be able to comment on the > > > > > timeline of when does the design team hope to accomplish the > > > > > following: > > > > > > > > > > - general acceptance of the stimulus signaling, KPML etc. > > > > > - standardization of app interaction fwk, KPML into an RFC > > > > > > > > > > Regarding an example of a PSTN switch that can be > > connected to a > > > > > pre-paid app over SIP-T, I don't know how much I can > > disclose in > > > > > front of this forum, but that is something being > looked at by a > > > > > few telecom gear vendors in my understanding. > > > > > > > > > > I wanted to bring your attention to SIP-T wrt to my > > > > previous question. > > > > > I believe your answer will remain the same but I just to > > > wanted to > > > > > re-iterate the question in different words this time, > > > just to make > > > > > sure we're communicating: > > > > > > > > > > In the setup below: > > > > > Pre-paid app > > > > > | > > > > > POTS ---- PSTN X <---SIP-T---> Softswitch ---- > > > > > > > > > > > > > > > .. you would think, application interaction framework > concepts > > > > > such as stimulus signaling, user-inetrfaces and KPML etc. are > > > > > designed to work over the SIP-T i/f between > packet-enabled PSTN > > > > > switch and a Softswitch. Wouldn't you? > > > > > > > > > > Thanks, > > > > > Rajnish > > > > > > > > > > > -----Original Message----- From: Jain, Rajnish (Rajnish) > > > > [mailto:rajnishjain@lucent.com] > > > > > > > > > > The Application Interaction Framework draft talks > about stimulus > > > > > signaling as a way for SIP UAs to interact w/ SIP > > > applications. The > > > > > draft suggests use of markup languages to allow > > > > applications to manage > > > > > local/remote user interfaces on SIP UAs. > > > > > > > > > > While the draft exemplifies a UA's stimulus/markup > > interaction w/ > > > > > a pre-paid application server, it is not very clear to > > us if the > > > > > caller UA (instead of a subscriber end-point) can be a > > complex UA > > > > > such as the following: > > > > > > > > > > - SIP (enabled) Gateway > > > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > > > - PSTN Switch w/ SIP-T interface > > > > > > > > Why not? It does SIP. It may do tone detection. > > > > > > > > > and does the draft recommend stimulus/markup > signaling between > > > > > such complex/concentrated UAs (or apps) and SIP applications ? > > > > > > > > The draft is silent on it. If you manufacture media rich > > > > gateways, you might say "of course". If you manufacture media > > > > servers, you might say "you could if you wanted, but you would > > > > be better served if you didn't." :-) > > > > > > > > > In other words, does the stimulus signaling apply to following > > > > > scenarios ?: > > > > > > > > > > 1. The pre-paid caller is connected to a PSTN switch > that has a > > > > > SIP-T interface to the pre-paid application. > > > > > > > > Yes, so long as the PSTN switch is SIP-aware, able to parse and > > > > execute KPML, and report using SIP (or, yuck, http). > > > > > > > > Do you know of such a switch? > > > > > > > > > 2. The pre-paid caller is connected to a PBX (SIP > > Gateway) over an > > > > > > > ISDN i/f, which in turn is connected to the pre-paid > app. over > > > > > normal SIP. > > > > > > > > Same issues as for the PSTN switch. > > > > > > > > > If yes, would the terms client-local and > client-remote still be > > > > > accurate, as the user here is a POTS/ISDN user? From > the user's > > > > > perspective, the UI would be client-remote. But from > > > application's > > > > > perspective the UI would be client-local (as the UI will be > > > > on the PBX > > > > > or PSTN switch both of which look like a UA to app server). > > > > > > > > It is still client-local, as the gateway/switch/PBX is a local > > > > proxy for the user. If you used a media server in the IP > > > > network behind the gateway/switch/PBX to execute the KPML, then > > > > you would be cline-remote. > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP Use > > > > sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 02:49:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02973 for ; Thu, 9 Jan 2003 02:49:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0980g002316 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 03:00:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0980gJ02313 for ; Thu, 9 Jan 2003 03:00:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02968 for ; Thu, 9 Jan 2003 02:48:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097wLJ02215; Thu, 9 Jan 2003 02:58:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097vlJ02160 for ; Thu, 9 Jan 2003 02:57:47 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02953 for ; Thu, 9 Jan 2003 02:45:40 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18WXQu-0003Vh-00; Thu, 09 Jan 2003 09:48:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15901.10600.528257.26668@harjus.eng.song.fi> Date: Thu, 9 Jan 2003 09:48:56 +0200 To: "Rosen, Brian" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit brian, you can program your sip/ss7 gw whatever way you like to map phone numbers and sip uris. there is no need to standardize anything new now that we already have asserted identity to place the phone number in case the user is using a from uri which is either anonymous or does not contain callers phone number. the mappings themselves are a local matter of your domain. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 07:13:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07637 for ; Thu, 9 Jan 2003 07:13:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09CPdl18796 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 07:25:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CPcJ18793 for ; Thu, 9 Jan 2003 07:25:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07613 for ; Thu, 9 Jan 2003 07:12:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CMfJ18689; Thu, 9 Jan 2003 07:22:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CLcJ18612 for ; Thu, 9 Jan 2003 07:21:39 -0500 Received: from igate2.vodafone.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07569 for ; Thu, 9 Jan 2003 07:09:24 -0500 (EST) Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id MAA26538; Thu, 9 Jan 2003 12:12:38 GMT Received: from putney.vfl.vodafone (putney [10.33.112.118]) by mailguard3 (4.6.1.123) with ESMTP id ; Thu, 09 Jan 2003 12:16:42 GMT Received: from ukwmxc01.vf-uk.internal.vodafone.com (UKWMXC01.vfl.vodafone [10.33.126.160]) by putney.vfl.vodafone with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YL9AGRDS; Thu, 9 Jan 2003 12:11:10 -0000 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 9 Jan 2003 12:11:02 +0000 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 9 Jan 2003 12:11:02 +0000 content-class: urn:content-classes:message Subject: RE: [Sipping] New -sos- draft (04) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 9 Jan 2003 12:11:02 -0000 Message-ID: Thread-Topic: [Sipping] New -sos- draft (04) Thread-Index: AcK18/qMaXCEjsrIQSiXUcpCd4sMFwB1mO5A From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Henning Schulzrinne" , X-OriginalArrivalTime: 09 Jan 2003 12:11:02.0582 (UTC) FILETIME=[2D9C1D60:01C2B7D8] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h09CLeJ18614 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Henning, A very very minor comment in case you revise the draft again: In section 3.2 you talk about 118 being an ambiguous number, i.e. a collision exists between a Japanese emergency number and a UK directory services number. I think it is actually Finland that uses 118 as a directory services number, not the UK. Another well known collision exists for 192 which is currently one of the UK's directory services number and is also an emergency number in Brazil. Regards, Duncan -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: 07 January 2003 02:13 To: 'sipping@ietf.org' Subject: [Sipping] New -sos- draft (04) http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-sos-04.txt will be submitted shortly, hopefully reflecting the comments received. Additional comments are most welcome. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 07:50:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08258 for ; Thu, 9 Jan 2003 07:50:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09D2V020782 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 08:02:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09D2VJ20779 for ; Thu, 9 Jan 2003 08:02:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08193 for ; Thu, 9 Jan 2003 07:49:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CxGJ20600; Thu, 9 Jan 2003 07:59:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CvdJ20491 for ; Thu, 9 Jan 2003 07:57:39 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08092 for ; Thu, 9 Jan 2003 07:45:27 -0500 (EST) Received: from cs.columbia.edu ([12.92.125.222]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030109124842.FRKY9286.mtiwmhc11.worldnet.att.net@cs.columbia.edu>; Thu, 9 Jan 2003 12:48:42 +0000 Message-ID: <3E1D6F18.1000506@cs.columbia.edu> Date: Thu, 09 Jan 2003 07:46:16 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mills, Duncan, D, CND Tech Dev, VF UK" CC: sipping@ietf.org Subject: Re: [Sipping] New -sos- draft (04) References: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Mills, Duncan, D, CND Tech Dev, VF UK wrote: > Henning, > > A very very minor comment in case you revise the draft again: > > In section 3.2 you talk about 118 being an ambiguous number, i.e. a > collision exists between a Japanese emergency number and a UK > directory services number. I think it is actually Finland that uses > 118 as a directory services number, not the UK. Thanks for catching this. I had been confused by the new 118XXX numbers in the UK; see http://www.oftel.gov.uk/publications/consumer/2002/dq1202.htm. These 118XXX numbers would obviously not collide. > > Another well known collision exists for 192 which is currently one of > the UK's directory services number and is also an emergency number in > Brazil. Apparently, according to the Oftel page above, this number is to be withdrawn. ("After the last weekend in August 2003 the existing DQ numbers such as 192 will no longer work – only the 118 numbers will be available.") Fortunately, 192 isn't on the list of 'default' emergency numbers. > > Regards, > > Duncan > > > > > > -----Original Message----- From: Henning Schulzrinne > [mailto:hgs@cs.columbia.edu] Sent: 07 January 2003 02:13 To: > 'sipping@ietf.org' Subject: [Sipping] New -sos- draft (04) > > > http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-sos-04.txt > > > will be submitted shortly, hopefully reflecting the comments > received. Additional comments are most welcome. > > Henning > > _______________________________________________ Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW > development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW > development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 09:18:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10562 for ; Thu, 9 Jan 2003 09:18:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09ETiM25820 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 09:29:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ETiJ25817 for ; Thu, 9 Jan 2003 09:29:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10543 for ; Thu, 9 Jan 2003 09:17:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ESSJ25759; Thu, 9 Jan 2003 09:28:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EQpJ25669 for ; Thu, 9 Jan 2003 09:26:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10318; Thu, 9 Jan 2003 09:14:37 -0500 (EST) Message-Id: <200301091414.JAA10318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 09 Jan 2003 09:14:37 -0500 Subject: [Sipping] I-D ACTION:draft-miller-sip-tcap-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Carrying TCAP in SIP Messages (SIP-TCAP) Author(s) : F. Miller et al. Filename : draft-miller-sip-tcap-00.txt Pages : 0 Date : 2003-1-8 SIP-TCAP is a mechanism by which an XML representation of TCAP messages can be transported in the body of SIP INFO messages. This mechanism can be used to allow SIP elements to access features implemented by PSTN equipment without having to implement the binary TCAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-miller-sip-tcap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-miller-sip-tcap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-9092045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-miller-sip-tcap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-miller-sip-tcap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092045.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 09:24:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11033 for ; Thu, 9 Jan 2003 09:24:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09EaIw26112 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 09:36:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EaHJ26109 for ; Thu, 9 Jan 2003 09:36:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10918 for ; Thu, 9 Jan 2003 09:24:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EZ4J26019; Thu, 9 Jan 2003 09:35:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EYHJ25972 for ; Thu, 9 Jan 2003 09:34:17 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10613 for ; Thu, 9 Jan 2003 09:22:03 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21058; Thu, 9 Jan 2003 09:25:19 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06508; Thu, 9 Jan 2003 09:25:19 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Jan 2003 09:25:18 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CEC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Thu, 9 Jan 2003 09:25:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > - I'm not sure of the advisability of adding caller name to > the tel uri. > If you do it, I don't like that way. Would prefer a tel: > parameter, as in > tel:+14125551212;caller-name="Alice Toklas" I don't see that it matters much at all. I can deal with either > > - I don't think the port should be a sip uri parameter. It is very > telephony oriented, so I think it is better as a tel: uri parameter. It's often the case that routing decisions on which gateway gets a call is made prior to the next-to-last proxy. To make that work, you have to rewrite the Request-URI to a form of phonenumber@gateway so that subsequent proxies route correctly. Therefore, I think you need the parameter in both Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 09:52:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13187 for ; Thu, 9 Jan 2003 09:52:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09F4aA28578 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:04:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09F4aJ28575 for ; Thu, 9 Jan 2003 10:04:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13150 for ; Thu, 9 Jan 2003 09:52:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09F3AJ28510; Thu, 9 Jan 2003 10:03:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09F2TJ28425 for ; Thu, 9 Jan 2003 10:02:29 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13078 for ; Thu, 9 Jan 2003 09:50:13 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09Es7YK019363 for ; Thu, 9 Jan 2003 09:54:08 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX59874; Thu, 9 Jan 2003 09:58:27 -0500 (EST) Message-ID: <3E1D8CE5.6050308@cisco.com> Date: Thu, 09 Jan 2003 09:53:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'sipping@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have a few comments about draft-schulzrinne-sipping-sos-04.txt. (I haven't been following this work very closely, so perhaps some of these pertain to things that were in earlier drafts.) I must say, these are really messy problems, so I am glad you are working on them. Section 3.2 says: ... a UAC MAY use a "tel" URI [3,4] without phone-context, such as tel:911 tel:112 The latest and greatest definition of the tel: uri that I can find is draft-antti-rfc2806bis-07.txt. According to that, the above tel: uris are syntactically incorrect. Either the number must be global or else it must contain a phone-context parameter. Are there plans to change the definition of the tel uri, or is this language going to change? In the case of a UAC that is using a local outbound proxy, is it required that the UAC specifically recognize these strings and deliver them to the proxy, or is it sufficient for it to deliver any and all dialed digit strings to the proxy as tel uris without attempting to recognize them itself? Is it sufficient to determine that the dialed number is complete by timeout on the input rather than by recognition? Section 5 specifies that the UAC should insert location information into emergency calls. However, presumably location information should in general not be placed in non-emergency calls, so it is important that the UAC realize it is making an emergency call. In the case of dialed digit strings, it may only be the outbound proxy that can determine if the call is an emergency call. One way to handle this would be for the local outbound proxy to redirect requests to tel: emergency numbers to the corresponding sip:sos number. Then the UAC would be able to positively determine this is an emergency call and include the location information. Section 9 says: We propose a new DHCP option that enumerates the valid local emergency identifiers, as a list of "tel", "sip" or "sips" URIs. This doesn't seem sufficient. Most phone-like devices have provision for entering primarily sequences of digits, not tel: uris. It is up to the phone to translate a digit sequence into a valid uri. In general this requires some sort of dial plan. Without the dial plan, the phone may well not be able to generate anything that matches one of the specified tel uris. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:03:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13618 for ; Thu, 9 Jan 2003 10:03:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FElM29668 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:14:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FElJ29665 for ; Thu, 9 Jan 2003 10:14:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13597 for ; Thu, 9 Jan 2003 10:02:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FDXJ29617; Thu, 9 Jan 2003 10:13:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FBgJ29537 for ; Thu, 9 Jan 2003 10:11:42 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13395 for ; Thu, 9 Jan 2003 09:59:26 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23798; Thu, 9 Jan 2003 10:02:42 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13128; Thu, 9 Jan 2003 10:02:39 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Jan 2003 10:02:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CED@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Thu, 9 Jan 2003 10:02:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Note below > What I suggested was that the From header hold the URI of the > gateway - not > the 'real' SIP URI of the user - for PSTN-to-SIP calls. The > From address in > this instance is not the address to which you should reply if > you want to > reach the initiator of the session later. The tel URL of that > user is in > fact the URI to which you should reply. I think this is a > good place to put > it for this case, and it doesn't warp the Reply-To header in > any way that I > can see. This is completely unrelated to where one would put > the 'real' SIP > URI of the user. I see how it works in this case, but only if the UA knows both identities. In some cases it doesn't now, but I think we might reasonably ask whether it should (ie the BCP I propose could state that gateways should know the telephone number it is connected to, and fill in From and Reply To as you suggest). We want to build systems where a proxy knows this, and doesn't rely on the gateway. Basically, we have ONE place that maintains the phone-number-to-user and phone-number- to-port-on-gateway information, and all tel URIs are routed through that proxy. It adds mappings and decides on which gateway will get the call. UAs don't know the mapping, gateways don't know the mapping, only the one proxy knows. We now have mechanisms that attempt to keep gateway mapping systems accurate from the one database. It takes vendor specific code in the proxy that knows how to manipulate the management port of each gateway in order to maintain the mappings. That's not a good system design, even if it does work. > > > It also has a serious problem that a proxy can't add it. > > I think you mean that you want the proxy to be able to add a telephone > number to a request for a SIP-to-PSTN call, or maybe to add a SIP URI > representing the originating user to a request for a PSTN-to-SIP call > (though this latter one is difficult - how would a user authenticate > themselves to an auth service through a PSTN gateway?). I agree that > Reply-To is not a good candidate for this usage - this is > where it has been > argued that P-Asserted-Identity is a good candidate. Yes, you see what I mean. Yes P-A-I would work, although this use does not meet the definition of P-A-I. I'm also bothered that we use two different headers for what I think is the same thing (holding both a sip URI and a tel URI in the sip message for the "From" identity). > > There are some minor issues with this (such as how a proxy > knows when and > why to add identities, and how authentication for particular > identifies is > managed), but I think that if a proxy asserts an identity, it > can and should > use the identity mechanisms we've already defined, which were designed > specifically with proxies in mind. However, there are some > reasons to ask > whether or not proxies are always the best entities to decide > when synonym > identities should be added to a request. I agree that authentication in this case is a little tricky, but I don't think it's very hard. > > > One of the requirements I have is that a proxy be able to > > do the translation. Not every gateway can hold all the tables > > required for this kind of translation, and I don't think > > we want to force every gateway to have the tables. > > > > The whole issue of who should do 'translation' by various > entities is a > little problematic, and ultimately this problem should be > separable from the > selection of the headers we might use to express the results > of translation. > Personally, I think ENUM is the right way to do telephone > number to URI > translations - however, it is not servicable for the reverse, > for URI to > telephone number translations. Having some kind of 'reverse > ENUM' for this > purpose has been the subject of much speculation in ENUM > circles, but it > currently is not well understood how it would work. This is only true for Service Provider gateways. It is not true for enterprise gateways. You would not want to use the currently defined ENUM, because it would require that every enterprise publish their internal mappings in the global ENUM DNS. That is not acceptable, and there are no mechanisms to do that (it implies that, for example, an enterprise tells it's SP what the SIP URI associated with each extension is). > > ENUM is best performed by the initiator of the session, rather than an > intermediary, for various reasons that are enumerated in > sipping-e164-02. > Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is > the right > place to do an ENUM query. This does not require the gateway > to have any > tables, or what have you. Intermediaries can also query ENUM > and apply the > results to a message, even if it is sub-optimal for them to do so. When ENUM is used, I agree, best at the gateway, less optimal in an intermediary (proxy). > > > I think your proposals on identity will not work unless > > the signer can be a proxy which later in the routing > > than my proxy that does the translation. > > Well, an authentication service, as I describe it, does the > signing after a > request has been generated, yes. If a later proxy wants to shove some > (authenticated) information into the request afterwards, that > isn't possible > unless is supplies a separate signed body. It would be ugly, but possible, for an authentication to be performed first on From/To/Reply-To and then subsequently on P-A-I. The idea of authenticating cryptographically the P-A-I header amuses me. > > > If the gateway > > does the translation, then in theory there would have to be > > a trust relationship between the PSTN and the gateway. > > There is always, in effect, a trust relationship between the > PSTN and a > gateway. The gateway is a node on the PSTN (whether it is a > privileged node, > like an SS7 gateway, or a user node, like a CAS gateway), and > nodes have a > certain defined trust relationship with the PSTN. I think the > gateway is one > of the better candidates to do ENUM, and possibly to perform > the reverse > operation (however that would work). Do SPs really trust CAS gateways? I didn't think it's true, although I don't know what actually happens if the gateway supplies a calling number that is not one of it's assigned DNs. I'm pretty sure it's NOT true of PRI gateways, but don't really know. I don't think that it matters for this discussion. See above for routing issues that argue against the gateway doing the mapping, at least for an enterprise system. > > > That won't work for an enterprise gateway, although I'm not > > sure that's a practical problem, because if the gateway > > translated, the PSTN is going to check that the number > > the gateway asserted is one of the identities that loop > > is allocated (PRIs have ranges). > > > > Presumably, gateways shouldn't trust authentication services > that might give > them improper information. In fact, there are numerous restrictions > surrounding what sorts of phone numbers should be sent over > many sorts of > ISUP trunks as well (as well as rules about when a CgPN must > be present, as > opposed to may be present). An proxy or user agent that > supplies originating > telephone numbers for SIP-to-PSTN calls should expect > gateways to validate > them, and there should be some way to accomodate cases in > which the gateway > cannot transmit these numbers to the PSTN, since it may be > difficult for a > proxy to determine what sort of gateway a request will > ultimately land on > (which is one of the reasons why proxies might not be the > best place for > synonym identities to be managed). > > > I don't see how ENUM is useful with identity assertion, > > although it's clearly applicable to the proxy that > > translates a SIP URI into a phone number or vice versa in > > the Request URI. > > It doesn't assert identity itself, certainly. The one place > in which it is > conceivably useful for identity assertion is that ENUM could > be queried for > a URI associated with the calling party's number in a > PSTN-to-SIP call. This > could be useful for a number of reasons - that URI could be stuck in a > header to indicate a SIP URI for the end user that is more explicit or > recognizable than their telephone number. Agree. This could be useful. What header? > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:04:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13657 for ; Thu, 9 Jan 2003 10:04:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FGOq29752 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:16:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FGOJ29749 for ; Thu, 9 Jan 2003 10:16:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13646 for ; Thu, 9 Jan 2003 10:03:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FF4J29711; Thu, 9 Jan 2003 10:15:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FEhJ29661 for ; Thu, 9 Jan 2003 10:14:43 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13592 for ; Thu, 9 Jan 2003 10:02:27 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23977; Thu, 9 Jan 2003 10:05:43 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14170; Thu, 9 Jan 2003 10:05:43 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Jan 2003 10:05:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CEE@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , "'Paul Kyzivat'" Cc: sipping@ietf.org Subject: RE: [Sipping] URIs for Gateways Date: Thu, 9 Jan 2003 10:05:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I don't think this works if I'm understanding you I have a tel uri like tel:+14125551212. I translate that to sip:14125551212@gateway.atlanta.com; user=phone Where does the port number go? Brian > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, January 09, 2003 12:30 AM > To: 'Paul Kyzivat'; 'Rosen, Brian' > Cc: sipping@ietf.org > Subject: RE: [Sipping] URIs for Gateways > > > > The port names a specific resource on the GW (similar to a > trunk group) > so if it is in a SIP URL, I think it should be in the user > portion. This > matches up perfectly with just defining it in the tel URL then let the > normal tel to sip translation rules apply to how looks in a SIP URL. > > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Paul Kyzivat > > Sent: Wednesday, January 08, 2003 12:38 PM > > To: Rosen, Brian > > Cc: 'sipping@ietf.org' > > Subject: Re: [Sipping] URIs for Gateways > > > > > > Brian, > > > > A few initial comments. More later when I get time to think > about it. > > > > - I'm not sure of the advisability of adding caller name to > > the tel uri. > > If you do it, I don't like that way. Would prefer a tel: > > parameter, as in > > tel:+14125551212;caller-name="Alice Toklas" > > > > - I don't think the port should be a sip uri parameter. It is very > > telephony oriented, so I think it is better as a tel: uri parameter. > > > > Paul > > > > Rosen, Brian wrote: > > > After all of this, I propose the following: > > > > > > 1. We add the possibility of a callerId string to a tel uri: > > > telephone-uri = "tel:" [callerIdName LWS] subscriber > > > callerIdName = quoted-string > > > > > > 2. Gateways accept or send sip uris of the form: > > > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; > > > port=3 or tel uris of the form: > > > tel:"Alice Toklas" +14125551212; port=3 > > > or "ordinary" sip uri's with extra information in a > separate header > > > of the form: > > >
+14125551212; port=3 > > > > > > where
could be "P-Asserted-Identity", or it > could be a new > > > header we define for the purpose. > > > > > > Then, we have the following possibilities: > > > > > > SIP device to gateway (outgoing) call > > > To a phone number > > > use the phone number in the Request-URI & To:, probably > > > in a tel URI, or maybe phonenumber@localdomain; user=phone > > > > > > use normal sip URI in From: > > > > > > If a translator is available, it may assert the > phone number > > > for the identity in the From: using
> > > > > > proxy may rewrite the Request-URI in the form of > > > sip: phone@gateway;user=phone;port=portnum > > > > > > To a sip URI > > > use the sip uri in the Request-URI and To: > > > use normal sip URI in From: > > > > > > proxy rewrites Request-URI, due to forwarding behavior, > > > ENUM lookup, etc, resulting in a tel URI or a > user=phone sip > > > uri. If necessary, a local incoming proxy can > rewrite it to > > > add the port parameter to the Request-URI based > on the From: > > > > > > If a translator is available, it may assert the > phone number > > > for the identity in the From: using the
> > > > > > Gateway to SIP device (incoming call) > > > With mapping > > > use the mapped uri in the Request-URI & To: > > > > > > (optionally) supply called number using
> > > This might be needed when multiple called numbers > > > map to the same uri. > > > > > > use sip:"callerId" phone@gateway; port=portnum or > > > a tel: uri in From: > > > > > > Without mapping > > > use a provisioned (per port) URI, a tel uri with > the called > > > number, or a sip uri with calledNumber@localdomain; > > user=phone > > > in the Request-URI & To:. Gateways should support all 3, > > > choice should be made by provisioning. > > > > > > use sip:"callerId" phone@gateway; port=portnum or tel > > > uri in From: > > > > > > proxy will rewrite the Request-URI with the > correct sip URI > > > associated with the called number > > > > > > Brian > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:09:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13835 for ; Thu, 9 Jan 2003 10:09:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FLfk30122 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:21:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FLfJ30117 for ; Thu, 9 Jan 2003 10:21:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13809 for ; Thu, 9 Jan 2003 10:09:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FK8J29999; Thu, 9 Jan 2003 10:20:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FJUJ29926 for ; Thu, 9 Jan 2003 10:19:30 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13766 for ; Thu, 9 Jan 2003 10:07:14 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h09FAVAv006913; Thu, 9 Jan 2003 16:10:31 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGM07TNN; Thu, 9 Jan 2003 16:10:30 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h09FAVu4009243; Thu, 9 Jan 2003 17:10:31 +0200 (EET) Message-ID: <3E1D90ED.A8157681@lmf.ericsson.se> Date: Thu, 09 Jan 2003 17:10:37 +0200 X-Sybari-Trust: 9fbbc6c2 1864f774 d5511081 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Cullen Jennings'" , "'Paul Kyzivat'" , sipping@ietf.org Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5CEE@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > I don't think this works if I'm understanding you > > I have a tel uri like tel:+14125551212. I translate that > to sip:14125551212@gateway.atlanta.com; user=phone > Where does the port number go? Into the user part. The URI would look like: sip:14125551212;port=3@gateway.atlanta.com;user=phone Regards, Christer Holmberg Ericsson Finland > > > Brian > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Thursday, January 09, 2003 12:30 AM > > To: 'Paul Kyzivat'; 'Rosen, Brian' > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > The port names a specific resource on the GW (similar to a > > trunk group) > > so if it is in a SIP URL, I think it should be in the user > > portion. This > > matches up perfectly with just defining it in the tel URL then let the > > normal tel to sip translation rules apply to how looks in a SIP URL. > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of Paul Kyzivat > > > Sent: Wednesday, January 08, 2003 12:38 PM > > > To: Rosen, Brian > > > Cc: 'sipping@ietf.org' > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > Brian, > > > > > > A few initial comments. More later when I get time to think > > about it. > > > > > > - I'm not sure of the advisability of adding caller name to > > > the tel uri. > > > If you do it, I don't like that way. Would prefer a tel: > > > parameter, as in > > > tel:+14125551212;caller-name="Alice Toklas" > > > > > > - I don't think the port should be a sip uri parameter. It is very > > > telephony oriented, so I think it is better as a tel: uri parameter. > > > > > > Paul > > > > > > Rosen, Brian wrote: > > > > After all of this, I propose the following: > > > > > > > > 1. We add the possibility of a callerId string to a tel uri: > > > > telephone-uri = "tel:" [callerIdName LWS] subscriber > > > > callerIdName = quoted-string > > > > > > > > 2. Gateways accept or send sip uris of the form: > > > > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; > > > > port=3 or tel uris of the form: > > > > tel:"Alice Toklas" +14125551212; port=3 > > > > or "ordinary" sip uri's with extra information in a > > separate header > > > > of the form: > > > >
+14125551212; port=3 > > > > > > > > where
could be "P-Asserted-Identity", or it > > could be a new > > > > header we define for the purpose. > > > > > > > > Then, we have the following possibilities: > > > > > > > > SIP device to gateway (outgoing) call > > > > To a phone number > > > > use the phone number in the Request-URI & To:, probably > > > > in a tel URI, or maybe phonenumber@localdomain; user=phone > > > > > > > > use normal sip URI in From: > > > > > > > > If a translator is available, it may assert the > > phone number > > > > for the identity in the From: using
> > > > > > > > proxy may rewrite the Request-URI in the form of > > > > sip: phone@gateway;user=phone;port=portnum > > > > > > > > To a sip URI > > > > use the sip uri in the Request-URI and To: > > > > use normal sip URI in From: > > > > > > > > proxy rewrites Request-URI, due to forwarding behavior, > > > > ENUM lookup, etc, resulting in a tel URI or a > > user=phone sip > > > > uri. If necessary, a local incoming proxy can > > rewrite it to > > > > add the port parameter to the Request-URI based > > on the From: > > > > > > > > If a translator is available, it may assert the > > phone number > > > > for the identity in the From: using the
> > > > > > > > Gateway to SIP device (incoming call) > > > > With mapping > > > > use the mapped uri in the Request-URI & To: > > > > > > > > (optionally) supply called number using
> > > > This might be needed when multiple called numbers > > > > map to the same uri. > > > > > > > > use sip:"callerId" phone@gateway; port=portnum or > > > > a tel: uri in From: > > > > > > > > Without mapping > > > > use a provisioned (per port) URI, a tel uri with > > the called > > > > number, or a sip uri with calledNumber@localdomain; > > > user=phone > > > > in the Request-URI & To:. Gateways should support all 3, > > > > choice should be made by provisioning. > > > > > > > > use sip:"callerId" phone@gateway; port=portnum or tel > > > > uri in From: > > > > > > > > proxy will rewrite the Request-URI with the > > correct sip URI > > > > associated with the called number > > > > > > > > Brian > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP Use > > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > > sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current > > > sip Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:12:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13949 for ; Thu, 9 Jan 2003 10:12:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FNqM30336 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:23:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FNqJ30333 for ; Thu, 9 Jan 2003 10:23:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13896 for ; Thu, 9 Jan 2003 10:11:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FMVJ30203; Thu, 9 Jan 2003 10:22:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FLfJ30120 for ; Thu, 9 Jan 2003 10:21:41 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13812 for ; Thu, 9 Jan 2003 10:09:25 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09FDNKa023463; Thu, 9 Jan 2003 10:13:23 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX60053; Thu, 9 Jan 2003 10:17:42 -0500 (EST) Message-ID: <3E1D9168.1020606@cisco.com> Date: Thu, 09 Jan 2003 10:12:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5CEC@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: >>- I don't think the port should be a sip uri parameter. It is very >>telephony oriented, so I think it is better as a tel: uri parameter. > > It's often the case that routing decisions on which gateway gets a > call is made prior to the next-to-last proxy. To make that work, you > have to rewrite the Request-URI to a form of phonenumber@gateway > so that subsequent proxies route correctly. Therefore, I think you > need the parameter in both Why does that change anything? All the parameters of a tel uri are mapped to parameters in the user part of a sip uri with user=phone. So the following sequence of addresses should be fine while transiting a series of proxies: tel:+16025551212 sip:+16025551212@gw1.acme.com;user=phone sip:+16025551212;port=37@gw3.provider.com;user=phone Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:12:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13951 for ; Thu, 9 Jan 2003 10:12:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FNsh30352 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:23:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FNsJ30349 for ; Thu, 9 Jan 2003 10:23:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13851 for ; Thu, 9 Jan 2003 10:10:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FL4J30075; Thu, 9 Jan 2003 10:21:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FKkJ30055 for ; Thu, 9 Jan 2003 10:20:46 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13798 for ; Thu, 9 Jan 2003 10:08:30 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24358; Thu, 9 Jan 2003 10:11:46 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14956; Thu, 9 Jan 2003 10:11:47 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Jan 2003 10:11:46 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CEF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" , "'sipping@ietf.org'" Date: Thu, 9 Jan 2003 10:11:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This comes up a lot. I think we should decide. Who translates a dial string into a tel uri? tel uris, as of now, explicitly don't handle dialing strings, only dialed numbers. In essentially all existing systems, phones don't have dialing plans in them; central elements map dialing strings to dialed numbers. What's our story? Does every UA that has a dial pad have to have a dialing plan loaded in it that maps dialing strings to dialed numbers, or does a proxy server do it? If it's the former, then how do we standardize the mapping? If it's the latter, then how does a UA send a dialing string? Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, January 09, 2003 9:53 AM > To: 'sipping@ietf.org' > Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > I have a few comments about draft-schulzrinne-sipping-sos-04.txt. > (I haven't been following this work very closely, so perhaps some of > these pertain to things that were in earlier drafts.) > > I must say, these are really messy problems, so I am glad you are > working on them. > > Section 3.2 says: > > ... a UAC MAY use a "tel" URI [3,4] without phone-context, such as > > tel:911 > tel:112 > > The latest and greatest definition of the tel: uri that I can find is > draft-antti-rfc2806bis-07.txt. According to that, the above tel: uris > are syntactically incorrect. Either the number must be global > or else it > must contain a phone-context parameter. > > Are there plans to change the definition of the tel uri, or is this > language going to change? > > In the case of a UAC that is using a local outbound proxy, is it > required that the UAC specifically recognize these strings > and deliver > them to the proxy, or is it sufficient for it to deliver any and all > dialed digit strings to the proxy as tel uris without attempting to > recognize them itself? Is it sufficient to determine that the dialed > number is complete by timeout on the input rather than by recognition? > > Section 5 specifies that the UAC should insert location > information into > emergency calls. However, presumably location information should in > general not be placed in non-emergency calls, so it is important that > the UAC realize it is making an emergency call. In the case of dialed > digit strings, it may only be the outbound proxy that can > determine if > the call is an emergency call. One way to handle this would > be for the > local outbound proxy to redirect requests to tel: emergency > numbers to > the corresponding sip:sos number. Then the UAC would be able to > positively determine this is an emergency call and include > the location > information. > > Section 9 says: > > We propose a new DHCP option that enumerates the valid local > emergency identifiers, as a list of "tel", "sip" or "sips" URIs. > > This doesn't seem sufficient. Most phone-like devices have > provision for > entering primarily sequences of digits, not tel: uris. It is > up to the > phone to translate a digit sequence into a valid uri. In general this > requires some sort of dial plan. Without the dial plan, the phone may > well not be able to generate anything that matches one of the > specified > tel uris. > > Paul > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13973 for ; Thu, 9 Jan 2003 10:12:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FOXm30393 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:24:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FOXJ30390 for ; Thu, 9 Jan 2003 10:24:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13929 for ; Thu, 9 Jan 2003 10:11:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FN5J30270; Thu, 9 Jan 2003 10:23:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FM9J30166 for ; Thu, 9 Jan 2003 10:22:09 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13826 for ; Thu, 9 Jan 2003 10:09:53 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24478; Thu, 9 Jan 2003 10:13:09 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15419; Thu, 9 Jan 2003 10:13:09 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Jan 2003 10:13:08 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CF0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'jh@lohi.eng.song.fi'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Thu, 9 Jan 2003 10:13:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Juha Not all gateways are equipped to do the mapping. In many cases, there is some element (a proxy server) that does the mapping. I am loath to make it a requirement that the mapping is done at the gateway. Also, tel URIs in Request-URIs are often rewritten by proxy servers to a form of sip:phonenumber@gateway;user=phone when the routing mechanisms that decide which gateway gets the call is not the next-to-last proxy. For example, one might have gateways at two sites in an enterprise. A local decision may be made on one site to forward a call to the gateway at the other site. To do this, it must rewrite the Request-URI so that subsequent proxy servers will correctly route the call. We have seen 3 or 4 different ways that gateways interpret fields to handle this case. P-A-I is interesting when asserting a phone number for a "normal" sip URI. This usage does not precisely follow the text of the RFC, but it's pretty close. Brian > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Thursday, January 09, 2003 2:49 AM > To: Rosen, Brian > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > brian, > > you can program your sip/ss7 gw whatever way you like to map phone > numbers and sip uris. there is no need to standardize > anything new now > that we already have asserted identity to place the phone > number in case > the user is using a from uri which is either anonymous or does not > contain callers phone number. the mappings themselves are a local > matter of your domain. > > -- juha > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:15:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14071 for ; Thu, 9 Jan 2003 10:15:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FR5630580 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:27:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FR5J30577 for ; Thu, 9 Jan 2003 10:27:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14033 for ; Thu, 9 Jan 2003 10:14:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FP4J30501; Thu, 9 Jan 2003 10:25:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FOYJ30405 for ; Thu, 9 Jan 2003 10:24:34 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13954 for ; Thu, 9 Jan 2003 10:12:17 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24707; Thu, 9 Jan 2003 10:15:34 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16150; Thu, 9 Jan 2003 10:15:34 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Jan 2003 10:15:34 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CF1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Christer Holmberg'" Cc: "'Cullen Jennings'" , "'Paul Kyzivat'" , sipping@ietf.org Subject: RE: [Sipping] URIs for Gateways Date: Thu, 9 Jan 2003 10:15:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Ugh. Legal though: SIP-URI = "sip:" [ userinfo "@" ] hostport uri-parameters [ headers ] userinfo = [ user / telephone-subscriber [ ":" password ]] user = *( unreserved / escaped / user-unreserved ) user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" I can deal with it, but it seems much more appropriate to have it be a uri-parameter Brian > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, January 09, 2003 10:11 AM > To: Rosen, Brian > Cc: 'Cullen Jennings'; 'Paul Kyzivat'; sipping@ietf.org > Subject: Re: [Sipping] URIs for Gateways > > > > Hi, > > > I don't think this works if I'm understanding you > > > > I have a tel uri like tel:+14125551212. I translate that > > to sip:14125551212@gateway.atlanta.com; user=phone > > Where does the port number go? > > Into the user part. The URI would look like: > > sip:14125551212;port=3@gateway.atlanta.com;user=phone > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > > Brian > > > > > -----Original Message----- > > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > Sent: Thursday, January 09, 2003 12:30 AM > > > To: 'Paul Kyzivat'; 'Rosen, Brian' > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > The port names a specific resource on the GW (similar to a > > > trunk group) > > > so if it is in a SIP URL, I think it should be in the user > > > portion. This > > > matches up perfectly with just defining it in the tel URL > then let the > > > normal tel to sip translation rules apply to how looks in > a SIP URL. > > > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > On Behalf Of Paul Kyzivat > > > > Sent: Wednesday, January 08, 2003 12:38 PM > > > > To: Rosen, Brian > > > > Cc: 'sipping@ietf.org' > > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > > > > Brian, > > > > > > > > A few initial comments. More later when I get time to think > > > about it. > > > > > > > > - I'm not sure of the advisability of adding caller name to > > > > the tel uri. > > > > If you do it, I don't like that way. Would prefer a tel: > > > > parameter, as in > > > > tel:+14125551212;caller-name="Alice Toklas" > > > > > > > > - I don't think the port should be a sip uri parameter. > It is very > > > > telephony oriented, so I think it is better as a tel: > uri parameter. > > > > > > > > Paul > > > > > > > > Rosen, Brian wrote: > > > > > After all of this, I propose the following: > > > > > > > > > > 1. We add the possibility of a callerId string to a tel uri: > > > > > telephone-uri = "tel:" [callerIdName LWS] subscriber > > > > > callerIdName = quoted-string > > > > > > > > > > 2. Gateways accept or send sip uris of the form: > > > > > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; > user=phone; > > > > > port=3 or tel uris of the form: > > > > > tel:"Alice Toklas" +14125551212; port=3 > > > > > or "ordinary" sip uri's with extra information in a > > > separate header > > > > > of the form: > > > > >
+14125551212; port=3 > > > > > > > > > > where
could be "P-Asserted-Identity", or it > > > could be a new > > > > > header we define for the purpose. > > > > > > > > > > Then, we have the following possibilities: > > > > > > > > > > SIP device to gateway (outgoing) call > > > > > To a phone number > > > > > use the phone number in the Request-URI & > To:, probably > > > > > in a tel URI, or maybe > phonenumber@localdomain; user=phone > > > > > > > > > > use normal sip URI in From: > > > > > > > > > > If a translator is available, it may assert the > > > phone number > > > > > for the identity in the From: using
> > > > > > > > > > proxy may rewrite the Request-URI in the form of > > > > > sip: phone@gateway;user=phone;port=portnum > > > > > > > > > > To a sip URI > > > > > use the sip uri in the Request-URI and To: > > > > > use normal sip URI in From: > > > > > > > > > > proxy rewrites Request-URI, due to forwarding > behavior, > > > > > ENUM lookup, etc, resulting in a tel URI or a > > > user=phone sip > > > > > uri. If necessary, a local incoming proxy can > > > rewrite it to > > > > > add the port parameter to the Request-URI based > > > on the From: > > > > > > > > > > If a translator is available, it may assert the > > > phone number > > > > > for the identity in the From: using the
> > > > > > > > > > Gateway to SIP device (incoming call) > > > > > With mapping > > > > > use the mapped uri in the Request-URI & To: > > > > > > > > > > (optionally) supply called number using
> > > > > This might be needed when multiple called numbers > > > > > map to the same uri. > > > > > > > > > > use sip:"callerId" phone@gateway; port=portnum or > > > > > a tel: uri in From: > > > > > > > > > > Without mapping > > > > > use a provisioned (per port) URI, a tel uri with > > > the called > > > > > number, or a sip uri with calledNumber@localdomain; > > > > user=phone > > > > > in the Request-URI & To:. Gateways should > support all 3, > > > > > choice should be made by provisioning. > > > > > > > > > > use sip:"callerId" phone@gateway; port=portnum or tel > > > > > uri in From: > > > > > > > > > > proxy will rewrite the Request-URI with the > > > correct sip URI > > > > > associated with the called number > > > > > > > > > > Brian > > > > > _______________________________________________ > > > > > Sipping mailing list > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP Use > > > > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > > > > sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on current > > > > sip Use sip@ietf.org for new developments of core SIP > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:30:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14625 for ; Thu, 9 Jan 2003 10:30:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Ffxo32228 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:41:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FfxJ32225 for ; Thu, 9 Jan 2003 10:41:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14555 for ; Thu, 9 Jan 2003 10:29:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fe6J31897; Thu, 9 Jan 2003 10:40:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FWiJ30849 for ; Thu, 9 Jan 2003 10:32:44 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14229 for ; Thu, 9 Jan 2003 10:20:27 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h09FNiAv010220; Thu, 9 Jan 2003 16:23:44 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNLT9NT; Thu, 9 Jan 2003 16:23:44 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h09FNiu4009823; Thu, 9 Jan 2003 17:23:44 +0200 (EET) Message-ID: <3E1D9406.92A57154@lmf.ericsson.se> Date: Thu, 09 Jan 2003 17:23:50 +0200 X-Sybari-Trust: 98ca81bf 1864f774 d5511081 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Cullen Jennings'" , "'Paul Kyzivat'" , sipping@ietf.org Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5CF1@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > Ugh. > > Legal though: > SIP-URI = "sip:" [ userinfo "@" ] hostport > uri-parameters [ headers ] > userinfo = [ user / telephone-subscriber [ ":" password ]] > user = *( unreserved / escaped / user-unreserved ) > user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" > > I can deal with it, but it seems much more appropriate to have it > be a uri-parameter I had issues with this too, a long time ago. You should have backed me up at that time ;) No idea to bring that up again, though... Also, chapter 19.1.6 describes how the tel-url, including the parameters, are mapped into sip-uri. Regards, Christer Holmberg Ericsson Finland > > > Brian > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Thursday, January 09, 2003 10:11 AM > > To: Rosen, Brian > > Cc: 'Cullen Jennings'; 'Paul Kyzivat'; sipping@ietf.org > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > Hi, > > > > > I don't think this works if I'm understanding you > > > > > > I have a tel uri like tel:+14125551212. I translate that > > > to sip:14125551212@gateway.atlanta.com; user=phone > > > Where does the port number go? > > > > Into the user part. The URI would look like: > > > > sip:14125551212;port=3@gateway.atlanta.com;user=phone > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > > Sent: Thursday, January 09, 2003 12:30 AM > > > > To: 'Paul Kyzivat'; 'Rosen, Brian' > > > > Cc: sipping@ietf.org > > > > Subject: RE: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > > The port names a specific resource on the GW (similar to a > > > > trunk group) > > > > so if it is in a SIP URL, I think it should be in the user > > > > portion. This > > > > matches up perfectly with just defining it in the tel URL > > then let the > > > > normal tel to sip translation rules apply to how looks in > > a SIP URL. > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > > On Behalf Of Paul Kyzivat > > > > > Sent: Wednesday, January 08, 2003 12:38 PM > > > > > To: Rosen, Brian > > > > > Cc: 'sipping@ietf.org' > > > > > Subject: Re: [Sipping] URIs for Gateways > > > > > > > > > > > > > > > Brian, > > > > > > > > > > A few initial comments. More later when I get time to think > > > > about it. > > > > > > > > > > - I'm not sure of the advisability of adding caller name to > > > > > the tel uri. > > > > > If you do it, I don't like that way. Would prefer a tel: > > > > > parameter, as in > > > > > tel:+14125551212;caller-name="Alice Toklas" > > > > > > > > > > - I don't think the port should be a sip uri parameter. > > It is very > > > > > telephony oriented, so I think it is better as a tel: > > uri parameter. > > > > > > > > > > Paul > > > > > > > > > > Rosen, Brian wrote: > > > > > > After all of this, I propose the following: > > > > > > > > > > > > 1. We add the possibility of a callerId string to a tel uri: > > > > > > telephone-uri = "tel:" [callerIdName LWS] subscriber > > > > > > callerIdName = quoted-string > > > > > > > > > > > > 2. Gateways accept or send sip uris of the form: > > > > > > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; > > user=phone; > > > > > > port=3 or tel uris of the form: > > > > > > tel:"Alice Toklas" +14125551212; port=3 > > > > > > or "ordinary" sip uri's with extra information in a > > > > separate header > > > > > > of the form: > > > > > >
+14125551212; port=3 > > > > > > > > > > > > where
could be "P-Asserted-Identity", or it > > > > could be a new > > > > > > header we define for the purpose. > > > > > > > > > > > > Then, we have the following possibilities: > > > > > > > > > > > > SIP device to gateway (outgoing) call > > > > > > To a phone number > > > > > > use the phone number in the Request-URI & > > To:, probably > > > > > > in a tel URI, or maybe > > phonenumber@localdomain; user=phone > > > > > > > > > > > > use normal sip URI in From: > > > > > > > > > > > > If a translator is available, it may assert the > > > > phone number > > > > > > for the identity in the From: using
> > > > > > > > > > > > proxy may rewrite the Request-URI in the form of > > > > > > sip: phone@gateway;user=phone;port=portnum > > > > > > > > > > > > To a sip URI > > > > > > use the sip uri in the Request-URI and To: > > > > > > use normal sip URI in From: > > > > > > > > > > > > proxy rewrites Request-URI, due to forwarding > > behavior, > > > > > > ENUM lookup, etc, resulting in a tel URI or a > > > > user=phone sip > > > > > > uri. If necessary, a local incoming proxy can > > > > rewrite it to > > > > > > add the port parameter to the Request-URI based > > > > on the From: > > > > > > > > > > > > If a translator is available, it may assert the > > > > phone number > > > > > > for the identity in the From: using the
> > > > > > > > > > > > Gateway to SIP device (incoming call) > > > > > > With mapping > > > > > > use the mapped uri in the Request-URI & To: > > > > > > > > > > > > (optionally) supply called number using
> > > > > > This might be needed when multiple called numbers > > > > > > map to the same uri. > > > > > > > > > > > > use sip:"callerId" phone@gateway; port=portnum or > > > > > > a tel: uri in From: > > > > > > > > > > > > Without mapping > > > > > > use a provisioned (per port) URI, a tel uri with > > > > the called > > > > > > number, or a sip uri with calledNumber@localdomain; > > > > > user=phone > > > > > > in the Request-URI & To:. Gateways should > > support all 3, > > > > > > choice should be made by provisioning. > > > > > > > > > > > > use sip:"callerId" phone@gateway; port=portnum or tel > > > > > > uri in From: > > > > > > > > > > > > proxy will rewrite the Request-URI with the > > > > correct sip URI > > > > > > associated with the called number > > > > > > > > > > > > Brian > > > > > > _______________________________________________ > > > > > > Sipping mailing list > > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > > This list is for NEW development of the application of SIP Use > > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > > > sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on current > > > > > sip Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:34:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14855 for ; Thu, 9 Jan 2003 10:34:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Fjt732558 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:45:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FjtJ32555 for ; Thu, 9 Jan 2003 10:45:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14781 for ; Thu, 9 Jan 2003 10:33:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fi4J32447; Thu, 9 Jan 2003 10:44:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FhqJ32423 for ; Thu, 9 Jan 2003 10:43:52 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14723 for ; Thu, 9 Jan 2003 10:31:35 -0500 (EST) Received: from cs.columbia.edu ([12.92.123.81]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030109153451.GNSH12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Thu, 9 Jan 2003 15:34:51 +0000 Message-ID: <3E1D9608.4080400@cs.columbia.edu> Date: Thu, 09 Jan 2003 10:32:24 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5CEF@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would find it instructive how non-SIP systems have solved similar problems. In web browsers and email, we have auto-completion functions and nick names, for examples. There's also the analogy with 'real names' (not the defunct company, the concept) which translates strings-nice-for-humans into URLs. See the CRN work, including the go: URL. (I'm not aware of implemenentations, but the concept may be relevant, in particular keeping the identifier and various 'nicknames' clearly distinct.) There are probably two sub-problems here: - Recognizing patterns so that one can keep the old "no-need-to-hit-dial" user interface. - Translating abbreviations such as extensions and local-area numbers to fully-expanded, globally unique identifiers. The former will always require downloading a pattern to an end system, the latter is a (local) translation service. The only question then becomes if the translation is done in one or two steps, i.e., before issuing a SIP request or as part of a SIP request. Aside: There are clearly examles of widely-deployed systems where the phone has a dial-plan, downloaded via tftp. Rosen, Brian wrote: > This comes up a lot. I think we should decide. > > Who translates a dial string into a tel uri? > > tel uris, as of now, explicitly don't handle dialing strings, > only dialed numbers. In essentially all existing systems, > phones don't have dialing plans in them; central elements > map dialing strings to dialed numbers. What's our story? > Does every UA that has a dial pad have to have a dialing plan > loaded in it that maps dialing strings to dialed numbers, > or does a proxy server do it? > > If it's the former, then how do we standardize the mapping? > If it's the latter, then how does a UA send a dialing string? > > Brian > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Thursday, January 09, 2003 9:53 AM >>To: 'sipping@ietf.org' >>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt >> >> >>I have a few comments about draft-schulzrinne-sipping-sos-04.txt. >>(I haven't been following this work very closely, so perhaps some of >>these pertain to things that were in earlier drafts.) >> >>I must say, these are really messy problems, so I am glad you are >>working on them. >> >>Section 3.2 says: >> >> ... a UAC MAY use a "tel" URI [3,4] without phone-context, such as >> >> tel:911 >> tel:112 >> >>The latest and greatest definition of the tel: uri that I can find is >>draft-antti-rfc2806bis-07.txt. According to that, the above tel: uris >>are syntactically incorrect. Either the number must be global >>or else it >>must contain a phone-context parameter. >> >>Are there plans to change the definition of the tel uri, or is this >>language going to change? >> >>In the case of a UAC that is using a local outbound proxy, is it >>required that the UAC specifically recognize these strings >>and deliver >>them to the proxy, or is it sufficient for it to deliver any and all >>dialed digit strings to the proxy as tel uris without attempting to >>recognize them itself? Is it sufficient to determine that the dialed >>number is complete by timeout on the input rather than by recognition? >> >>Section 5 specifies that the UAC should insert location >>information into >>emergency calls. However, presumably location information should in >>general not be placed in non-emergency calls, so it is important that >>the UAC realize it is making an emergency call. In the case of dialed >>digit strings, it may only be the outbound proxy that can >>determine if >>the call is an emergency call. One way to handle this would >>be for the >>local outbound proxy to redirect requests to tel: emergency >>numbers to >>the corresponding sip:sos number. Then the UAC would be able to >>positively determine this is an emergency call and include >>the location >>information. >> >>Section 9 says: >> >> We propose a new DHCP option that enumerates the valid local >> emergency identifiers, as a list of "tel", "sip" or "sips" URIs. >> >>This doesn't seem sufficient. Most phone-like devices have >>provision for >>entering primarily sequences of digits, not tel: uris. It is >>up to the >>phone to translate a digit sequence into a valid uri. In general this >>requires some sort of dial plan. Without the dial plan, the phone may >>well not be able to generate anything that matches one of the >>specified >>tel uris. >> >> Paul >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 10:45:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15101 for ; Thu, 9 Jan 2003 10:45:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Fv3a00628 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 10:57:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fv3J00625 for ; Thu, 9 Jan 2003 10:57:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15079 for ; Thu, 9 Jan 2003 10:43:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fq4J00386; Thu, 9 Jan 2003 10:52:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Fp6J00347 for ; Thu, 9 Jan 2003 10:51:06 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14976 for ; Thu, 9 Jan 2003 10:38:49 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26573; Thu, 9 Jan 2003 10:42:05 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21052; Thu, 9 Jan 2003 10:42:06 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Jan 2003 10:42:06 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CF4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 9 Jan 2003 10:42:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , The systems I'm aware of use regexps in one form or another to mangle a string into a dialed number. I don't have a problem making this a UA function, but if we do, I want to standardize the regexp and "Publish" it to the UA. A lot of enterprise gateways have dial string to dialed number mapping. Some sipphones do. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 09, 2003 10:32 AM > To: Rosen, Brian > Cc: 'Paul Kyzivat'; 'sipping@ietf.org' > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do > Proxies map? was > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > I would find it instructive how non-SIP systems have solved similar > problems. In web browsers and email, we have auto-completion > functions > and nick names, for examples. > > There's also the analogy with 'real names' (not the defunct > company, the > concept) which translates strings-nice-for-humans into URLs. > See the CRN > work, including the go: URL. (I'm not aware of implemenentations, but > the concept may be relevant, in particular keeping the identifier and > various 'nicknames' clearly distinct.) > > There are probably two sub-problems here: > > - Recognizing patterns so that one can keep the old > "no-need-to-hit-dial" user interface. > > - Translating abbreviations such as extensions and local-area > numbers to > fully-expanded, globally unique identifiers. > > The former will always require downloading a pattern to an > end system, > the latter is a (local) translation service. The only question then > becomes if the translation is done in one or two steps, i.e., before > issuing a SIP request or as part of a SIP request. > > Aside: There are clearly examles of widely-deployed systems where the > phone has a dial-plan, downloaded via tftp. > > Rosen, Brian wrote: > > This comes up a lot. I think we should decide. > > > > Who translates a dial string into a tel uri? > > > > tel uris, as of now, explicitly don't handle dialing strings, > > only dialed numbers. In essentially all existing systems, > > phones don't have dialing plans in them; central elements > > map dialing strings to dialed numbers. What's our story? > > Does every UA that has a dial pad have to have a dialing plan > > loaded in it that maps dialing strings to dialed numbers, > > or does a proxy server do it? > > > > If it's the former, then how do we standardize the mapping? > > If it's the latter, then how does a UA send a dialing string? > > > > Brian > > > > > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: Thursday, January 09, 2003 9:53 AM > >>To: 'sipping@ietf.org' > >>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > >> > >> > >>I have a few comments about draft-schulzrinne-sipping-sos-04.txt. > >>(I haven't been following this work very closely, so > perhaps some of > >>these pertain to things that were in earlier drafts.) > >> > >>I must say, these are really messy problems, so I am glad you are > >>working on them. > >> > >>Section 3.2 says: > >> > >> ... a UAC MAY use a "tel" URI [3,4] without > phone-context, such as > >> > >> tel:911 > >> tel:112 > >> > >>The latest and greatest definition of the tel: uri that I > can find is > >>draft-antti-rfc2806bis-07.txt. According to that, the above > tel: uris > >>are syntactically incorrect. Either the number must be global > >>or else it > >>must contain a phone-context parameter. > >> > >>Are there plans to change the definition of the tel uri, or is this > >>language going to change? > >> > >>In the case of a UAC that is using a local outbound proxy, is it > >>required that the UAC specifically recognize these strings > >>and deliver > >>them to the proxy, or is it sufficient for it to deliver > any and all > >>dialed digit strings to the proxy as tel uris without attempting to > >>recognize them itself? Is it sufficient to determine that > the dialed > >>number is complete by timeout on the input rather than by > recognition? > >> > >>Section 5 specifies that the UAC should insert location > >>information into > >>emergency calls. However, presumably location information should in > >>general not be placed in non-emergency calls, so it is > important that > >>the UAC realize it is making an emergency call. In the case > of dialed > >>digit strings, it may only be the outbound proxy that can > >>determine if > >>the call is an emergency call. One way to handle this would > >>be for the > >>local outbound proxy to redirect requests to tel: emergency > >>numbers to > >>the corresponding sip:sos number. Then the UAC would be able to > >>positively determine this is an emergency call and include > >>the location > >>information. > >> > >>Section 9 says: > >> > >> We propose a new DHCP option that enumerates the valid local > >> emergency identifiers, as a list of "tel", "sip" or "sips" URIs. > >> > >>This doesn't seem sufficient. Most phone-like devices have > >>provision for > >>entering primarily sequences of digits, not tel: uris. It is > >>up to the > >>phone to translate a digit sequence into a valid uri. In > general this > >>requires some sort of dial plan. Without the dial plan, the > phone may > >>well not be able to generate anything that matches one of the > >>specified > >>tel uris. > >> > >> Paul > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sip@ietf.org for new developments of core SIP > >> > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 11:25:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16716 for ; Thu, 9 Jan 2003 11:25:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09GbD104045 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 11:37:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GbDJ04037 for ; Thu, 9 Jan 2003 11:37:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16655 for ; Thu, 9 Jan 2003 11:24:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GZ7J03679; Thu, 9 Jan 2003 11:35:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GYpJ03653 for ; Thu, 9 Jan 2003 11:34:51 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16617 for ; Thu, 9 Jan 2003 11:22:34 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h09GOH53017880; Thu, 9 Jan 2003 11:24:17 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 10:25:42 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643F9@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , "Rosen, Brian" Cc: "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 9 Jan 2003 10:25:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > - Recognizing patterns so that one can keep the old > "no-need-to-hit-dial" user interface. AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! No! Cell phones have sufficiently trained the public that it's okay to hit something like "OK" or "YES" or "DIAL" or "ENTER" after a phone number. It makes life so much easier for user interface designers and users alike. For the love of all that is good, let's not encourage backsliding. /a _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 11:43:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17214 for ; Thu, 9 Jan 2003 11:43:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09GtP605422 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 11:55:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GtPJ05419 for ; Thu, 9 Jan 2003 11:55:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17177 for ; Thu, 9 Jan 2003 11:42:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GrZJ05354; Thu, 9 Jan 2003 11:53:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GqAJ05274 for ; Thu, 9 Jan 2003 11:52:10 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17133 for ; Thu, 9 Jan 2003 11:39:53 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09Gh7s02439 for ; Thu, 9 Jan 2003 11:43:07 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 16:43:06 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB8F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Tom-PT Taylor'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Comments on sos draft -0 Date: Thu, 9 Jan 2003 16:43:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Is the number 3333 on an internal network an emergency number in the terms of the sos draft? The way I read the defined sos url is that it only reachs public emergency service centres. therefore the scope of the document with regard to tel urls is to define the format of tel urls to reach those same centres. Have I misunderstood the scope? We possible need to extend Hennings proposed scope to make this clear. I do think we need to delve further into the subject of context, possible in association with additional clarifications in the rfc2806bis draft. I note that the text there has a special case dealing with 800 numbers, viz: "National freephone numbers do not need a context, even though they | are not necessarily reachable from outside a particular country code | or numbering plan. Recall that "tel" URIs are identifiers; it is | sufficient that a global number is unique, but it is not required | that it be reachable from everywhere." It therefore seems to me that we could say the same about emergency numbers that are globally unique. For those emergency numbers that are not globally unique (and we probably need to include 118 and 119 in this list), then looking at the existing RFC 2806 or at the bis, they probably do need a context. What worries me is that the user sticks in an inappropriate context, i.e. the one he uses for all his local calls, rather than one used for national calls. Such inappropriate usage would cause calls to fail. Would a special context used only for local service numbers be appropriate here? My thinking here is that if we give the user something real to code, then he will not be tempted to code something inappropriate. Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: 08 January 2003 14:54 > To: 'Drage, Keith (Keith)'; 'Henning Schulzrinne'; 'sipping@ietf.org' > Subject: RE: [Sipping] Comments on sos draft -0 > > > A comment on one point only. > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Monday, January 06, 2003 10:56 AM > > To: 'Henning Schulzrinne'; 'sipping@ietf.org' > > Subject: [Sipping] Comments on sos draft -0 > > > [snip] > > > > 6) section 3 (Emergency URI), 3rd paragraph: use of > > "phone-context". Is it appropriate to use phone context in > > any emergency call. In 3GPP, any use of one of the numbers > > from the list stored in the phone is an emergency call, no > > matter where it originates from. If my understanding of > > phone-context is correct, it SHOULD NOT be used, as it could > > result in failure to deliver an emergency call. > > > [PTT] My company has a scheme where "3333" on the internal > network reaches > an internal emergency response centre who then direct the > call externally if > required. This was introduced to ensure that emergency vehicles are > directed to the right building and building entrance. It might be > conceivable under such an arrangement to have a phone-context in the > original Request-URI. > > [snip] > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 12:54:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19008 for ; Thu, 9 Jan 2003 12:54:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09I6fj10102 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:06:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I6fJ10099 for ; Thu, 9 Jan 2003 13:06:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18893 for ; Thu, 9 Jan 2003 12:51:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I2HJ09937; Thu, 9 Jan 2003 13:02:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I1AJ09884 for ; Thu, 9 Jan 2003 13:01:10 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18840 for ; Thu, 9 Jan 2003 12:48:52 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09Hq7Y05188 for ; Thu, 9 Jan 2003 12:52:07 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 17:52:06 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB90@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henning Schulzrinne'" , "Drage, Keith (Keith)" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Comments on sos draft -03 (URI) Date: Thu, 9 Jan 2003 17:52:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , See below - I have snipped out the areas where I am happy with the response, or have replied elsewhere. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 06 January 2003 23:11 > To: Drage, Keith (Keith) > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] Comments on sos draft -03 (URI) > > > > 8) Section 4 (Request handling), text: "It is RECOMMENDED that user > > agents periodically automatically check for the availability....". I > > consider that the use of this may be unnecessary in all > cases. If the > > phone can be loaded with emergency numbers dynamically, and the > > update of those numbers is of reasonable frequency, then there is no > > need to regularly perform the OPTIONS request. For this reason, it > > would appear to be unnecessary for 3GPP phones. > > The problem is that I can't rely on a local friendly outbound > proxy that > knows how to handle either sip:sos or tel:XXX. You can > mandate this for > 3GPP providers, but not all VoIP systems will be run by > common carriers. > > I'm reluctant to encode 'I'm a 3GPP phone, so I don't need to > do this' > into the protocol. After all, this 3GPP phone may also use > your friendly > neighborhood 802.11 hotspot. > > > > Firstly I note that the requirement already was only a SHOULD rather than a MUST. In the case where SHOULD is used I usually prefer to specify some examples of where the SHOULD does not apply as guidance, and this appeared to be the appropriate one. From what you are saying, the flaw in the argument is that 3GPP controls the routeing to the emergency call centre as well as the downloading of numbers to the UA, and therefore can say that if a number is downloaded it will work, and therefore the the testing of the numbers is not needed. In a more general case the DHCP server or whatever may be providing information in the emergency numbers to the UE may not be provided by the same provider who does the routeing to the emergency call centre and therefore such numbers may fail, and as a result, should be tested. I am not convinced by the argument; that may be answered by what do we expect the UA to do if the OPTIONS request it sends to the tel url it has been given fails? If the user dials that tel url, does the UA continue to treat such a call as an emergency call, or does it flash a message on the users display saying "I don't know what to do with this"? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 13:20:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19806 for ; Thu, 9 Jan 2003 13:20:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09IW8612257 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:32:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IW8J12254 for ; Thu, 9 Jan 2003 13:32:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19736 for ; Thu, 9 Jan 2003 13:18:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ITlJ11912; Thu, 9 Jan 2003 13:29:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IMXJ11513 for ; Thu, 9 Jan 2003 13:22:33 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19503 for ; Thu, 9 Jan 2003 13:10:13 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09IE5qW026530; Thu, 9 Jan 2003 13:14:05 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX61833; Thu, 9 Jan 2003 13:18:22 -0500 (EST) Message-ID: <3E1DBBC0.6020704@cisco.com> Date: Thu, 09 Jan 2003 13:13:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5CF4@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Unless we are going to require users to enter full URIs into the phone (including "tel:"), the phone MUST have some sort of dial plan. We only need to discuss how complex it is. At one extreme it could simply be to prefix the entered digits with "tel:" and let a proxy do the rest. At the other extreme it could do all sorts of complex transformations to turn short sequences into global tel: uris, or even sip uris, possibly even chosing different gateways based on dialed number. As I mentioned in an earlier reply, simply slapping "tel:" on the entered digits doesn't create syntactically correct tel: uris according to the latest definition. To go that way, the tel: syntax needs to be altered. Also, the tel: definition currently says that a tel: address SHOULD always use global syntax unless there is no valid global address. Encoding dialed digits as a local tel: uri and defering conversion to a global address to a proxy would violate that rule. One possibility is to define the minimal dial plan for a phone as: prefix the dialed digits with "tel:" and suffix the dialed digits with ";phone-context=XXX", where XXX needs to be learned or provisioned somewhere. The XXX is then effectively a name for the dial plan to be used to expand the number. This gets around the syntax problem with using the tel: uri, though it still violates the semantic rule. Paul Rosen, Brian wrote: > The systems I'm aware of use regexps in one form or another > to mangle a string into a dialed number. I don't have > a problem making this a UA function, but if we do, I want > to standardize the regexp and "Publish" it to the UA. > > A lot of enterprise gateways have dial string to dialed number mapping. > Some sipphones do. > > Brian > > > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Thursday, January 09, 2003 10:32 AM >>To: Rosen, Brian >>Cc: 'Paul Kyzivat'; 'sipping@ietf.org' >>Subject: Re: [Sipping] Do Phones Have Dial Plans, or do >>Proxies map? was >>RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt >> >> >>I would find it instructive how non-SIP systems have solved similar >>problems. In web browsers and email, we have auto-completion >>functions >>and nick names, for examples. >> >>There's also the analogy with 'real names' (not the defunct >>company, the >>concept) which translates strings-nice-for-humans into URLs. >>See the CRN >>work, including the go: URL. (I'm not aware of implemenentations, but >>the concept may be relevant, in particular keeping the identifier and >>various 'nicknames' clearly distinct.) >> >>There are probably two sub-problems here: >> >>- Recognizing patterns so that one can keep the old >>"no-need-to-hit-dial" user interface. >> >>- Translating abbreviations such as extensions and local-area >>numbers to >>fully-expanded, globally unique identifiers. >> >>The former will always require downloading a pattern to an >>end system, >>the latter is a (local) translation service. The only question then >>becomes if the translation is done in one or two steps, i.e., before >>issuing a SIP request or as part of a SIP request. >> >>Aside: There are clearly examles of widely-deployed systems where the >>phone has a dial-plan, downloaded via tftp. >> >>Rosen, Brian wrote: >> >>>This comes up a lot. I think we should decide. >>> >>>Who translates a dial string into a tel uri? >>> >>>tel uris, as of now, explicitly don't handle dialing strings, >>>only dialed numbers. In essentially all existing systems, >>>phones don't have dialing plans in them; central elements >>>map dialing strings to dialed numbers. What's our story? >>>Does every UA that has a dial pad have to have a dialing plan >>>loaded in it that maps dialing strings to dialed numbers, >>>or does a proxy server do it? >>> >>>If it's the former, then how do we standardize the mapping? >>>If it's the latter, then how does a UA send a dialing string? >>> >>>Brian >>> >>> >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: Thursday, January 09, 2003 9:53 AM >>>>To: 'sipping@ietf.org' >>>>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt >>>> >>>> >>>>I have a few comments about draft-schulzrinne-sipping-sos-04.txt. >>>>(I haven't been following this work very closely, so >>> >>perhaps some of >> >>>>these pertain to things that were in earlier drafts.) >>>> >>>>I must say, these are really messy problems, so I am glad you are >>>>working on them. >>>> >>>>Section 3.2 says: >>>> >>>> ... a UAC MAY use a "tel" URI [3,4] without >>> >>phone-context, such as >> >>>> tel:911 >>>> tel:112 >>>> >>>>The latest and greatest definition of the tel: uri that I >>> >>can find is >> >>>>draft-antti-rfc2806bis-07.txt. According to that, the above >>> >>tel: uris >> >>>>are syntactically incorrect. Either the number must be global >>>>or else it >>>>must contain a phone-context parameter. >>>> >>>>Are there plans to change the definition of the tel uri, or is this >>>>language going to change? >>>> >>>>In the case of a UAC that is using a local outbound proxy, is it >>>>required that the UAC specifically recognize these strings >>>>and deliver >>>>them to the proxy, or is it sufficient for it to deliver >>> >>any and all >> >>>>dialed digit strings to the proxy as tel uris without attempting to >>>>recognize them itself? Is it sufficient to determine that >>> >>the dialed >> >>>>number is complete by timeout on the input rather than by >>> >>recognition? >> >>>>Section 5 specifies that the UAC should insert location >>>>information into >>>>emergency calls. However, presumably location information should in >>>>general not be placed in non-emergency calls, so it is >>> >>important that >> >>>>the UAC realize it is making an emergency call. In the case >>> >>of dialed >> >>>>digit strings, it may only be the outbound proxy that can >>>>determine if >>>>the call is an emergency call. One way to handle this would >>>>be for the >>>>local outbound proxy to redirect requests to tel: emergency >>>>numbers to >>>>the corresponding sip:sos number. Then the UAC would be able to >>>>positively determine this is an emergency call and include >>>>the location >>>>information. >>>> >>>>Section 9 says: >>>> >>>> We propose a new DHCP option that enumerates the valid local >>>> emergency identifiers, as a list of "tel", "sip" or "sips" URIs. >>>> >>>>This doesn't seem sufficient. Most phone-like devices have >>>>provision for >>>>entering primarily sequences of digits, not tel: uris. It is >>>>up to the >>>>phone to translate a digit sequence into a valid uri. In >>> >>general this >> >>>>requires some sort of dial plan. Without the dial plan, the >>> >>phone may >> >>>>well not be able to generate anything that matches one of the >>>>specified >>>>tel uris. >>>> >>>> Paul >>>> >>>>_______________________________________________ >>>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>>This list is for NEW development of the application of SIP >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sip@ietf.org for new developments of core SIP >>>> >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP >> > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 13:20:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19817 for ; Thu, 9 Jan 2003 13:20:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09IWAP12273 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:32:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IWAJ12270 for ; Thu, 9 Jan 2003 13:32:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19745 for ; Thu, 9 Jan 2003 13:19:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IU5J11980; Thu, 9 Jan 2003 13:30:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ITvJ11924 for ; Thu, 9 Jan 2003 13:29:57 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19667 for ; Thu, 9 Jan 2003 13:17:38 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h09I8nw03867; Thu, 9 Jan 2003 18:08:49 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 18:08:49 -0000 Message-ID: From: "Mark Watson" To: "'Adam Roach'" , "'Henning Schulzrinne'" , "Rosen, Brian" Cc: "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 9 Jan 2003 18:08:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B80A.272462F8" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B80A.272462F8 Content-Type: text/plain; charset="iso-8859-1" Adam wrote: > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! > > No! Is overlap dialling **really** that bad :-) (ok, ok, I know, it is) I'd agree you should really try and avoid UIs without an 'end of dialing' key whenever you can. You can't rely on any regexp to tell you when the end of dialling is - at least obtaining and maintaining such a regexp for the global E.164 dial-plan would be infeasible. Even for some national dialling plans it is infeasible. No 'end of dialling' key = overlap or inter-digit timers, end of story. ...Mark ------_=_NextPart_001_01C2B80A.272462F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was = RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt

Adam wrote:

> AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! = AAAAAUUUUGGGHHHHH!!!
>
> No!

Is overlap dialling **really** that bad :-) (ok, ok, = I know, it is)

I'd agree you should really try and avoid UIs without = an 'end of dialing' key whenever you can. You can't rely on any regexp = to tell you when the end of dialling is - at least obtaining and = maintaining such a regexp for the global E.164 dial-plan would be = infeasible. Even for some national dialling plans it is = infeasible.

No 'end of dialling' key =3D overlap or inter-digit = timers, end of story.

...Mark

 

------_=_NextPart_001_01C2B80A.272462F8-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 13:38:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20383 for ; Thu, 9 Jan 2003 13:38:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Io2l13829 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:50:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Io2J13826 for ; Thu, 9 Jan 2003 13:50:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20340 for ; Thu, 9 Jan 2003 13:37:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ImHJ13743; Thu, 9 Jan 2003 13:48:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IlpJ13700 for ; Thu, 9 Jan 2003 13:47:51 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20310 for ; Thu, 9 Jan 2003 13:35:31 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h09Iav53018766; Thu, 9 Jan 2003 13:37:00 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 12:38:22 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643FB@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , "Rosen, Brian" Cc: "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 9 Jan 2003 12:38:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > - Translating abbreviations such as extensions and local-area > numbers to > fully-expanded, globally unique identifiers. It's also interesting to note that many systems (e.g. PBXes) include extensions that don't have an external representation. For example, let's imaine a company that has a PBX with an assigned range of +1-713-555-8xxx. They use 4-digit internal dialling. Some extensions (e.g. 8123) can have an external mapping (+1 713 555 8123). Others, like 3123, can't be reached externally. They *can't* exist as fully-expanded, globally unique identifiers. So, how exactly do we address this? I see several options: 1) Allow "tel:" to include dialled digit strings, possibly with some parameter to indicate as much. 2) Create a new URI that is defined to carry dialled digits. Both of these have their own rather obvious problems. Can someone think of an alternate solution? /a _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 13:45:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20508 for ; Thu, 9 Jan 2003 13:45:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Iuma14046 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 13:56:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IumJ14043 for ; Thu, 9 Jan 2003 13:56:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20496 for ; Thu, 9 Jan 2003 13:44:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ItBJ13995; Thu, 9 Jan 2003 13:55:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IsRJ13951 for ; Thu, 9 Jan 2003 13:54:27 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20429 for ; Thu, 9 Jan 2003 13:42:07 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05945; Thu, 9 Jan 2003 13:45:22 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18461; Thu, 9 Jan 2003 13:45:23 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Jan 2003 13:45:23 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5CF9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 9 Jan 2003 13:45:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I think this response just restates the question. I think we either say that phones essentially always put out global numbers, or they put out dialing strings and a proxy expands it. We can probably agree on the tel uri prefix for either. If a proxy expands dialing strings to phone numbers, then we probably do need some kind of context, as you point out. First we should decide if we put the dialing plan in the phone. BTW, I currently favor NOT putting the dialing plan in the UA, but I don't feel strongly about it. I do feel strongly about standardizing this bit, because I surely want all sipphones to "play" in my system, and I don't want a boat-load of vendor specific code to make that work. Our sip based enterprise system has a classical enterprise dialing plan, although we interpret 7 or more digits as national or international numbers, rather than requiring the "9" prefix. That works because all internal numbers are less than 7 digits. Proxies do the expansion. There is vendor specific code in this proxy because no two gateways we support work the same. Hence this entire effort :) Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, January 09, 2003 1:13 PM > To: Rosen, Brian > Cc: 'Henning Schulzrinne'; 'sipping@ietf.org' > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do > Proxies map? was > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > Unless we are going to require users to enter full URIs into > the phone > (including "tel:"), the phone MUST have some sort of dial > plan. We only > need to discuss how complex it is. > > At one extreme it could simply be to prefix the entered digits with > "tel:" and let a proxy do the rest. > > At the other extreme it could do all sorts of complex > transformations to > turn short sequences into global tel: uris, or even sip uris, > possibly > even chosing different gateways based on dialed number. > > As I mentioned in an earlier reply, simply slapping "tel:" on the > entered digits doesn't create syntactically correct tel: uris > according > to the latest definition. To go that way, the tel: syntax needs to be > altered. Also, the tel: definition currently says that a tel: address > SHOULD always use global syntax unless there is no valid > global address. > Encoding dialed digits as a local tel: uri and defering > conversion to a > global address to a proxy would violate that rule. > > One possibility is to define the minimal dial plan for a phone as: > prefix the dialed digits with "tel:" and suffix the dialed > digits with > ";phone-context=XXX", where XXX needs to be learned or provisioned > somewhere. The XXX is then effectively a name for the dial plan to be > used to expand the number. This gets around the syntax problem with > using the tel: uri, though it still violates the semantic rule. > > Paul > > Rosen, Brian wrote: > > The systems I'm aware of use regexps in one form or another > > to mangle a string into a dialed number. I don't have > > a problem making this a UA function, but if we do, I want > > to standardize the regexp and "Publish" it to the UA. > > > > A lot of enterprise gateways have dial string to dialed > number mapping. > > Some sipphones do. > > > > Brian > > > > > > > > > >>-----Original Message----- > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>Sent: Thursday, January 09, 2003 10:32 AM > >>To: Rosen, Brian > >>Cc: 'Paul Kyzivat'; 'sipping@ietf.org' > >>Subject: Re: [Sipping] Do Phones Have Dial Plans, or do > >>Proxies map? was > >>RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > >> > >> > >>I would find it instructive how non-SIP systems have solved similar > >>problems. In web browsers and email, we have auto-completion > >>functions > >>and nick names, for examples. > >> > >>There's also the analogy with 'real names' (not the defunct > >>company, the > >>concept) which translates strings-nice-for-humans into URLs. > >>See the CRN > >>work, including the go: URL. (I'm not aware of > implemenentations, but > >>the concept may be relevant, in particular keeping the > identifier and > >>various 'nicknames' clearly distinct.) > >> > >>There are probably two sub-problems here: > >> > >>- Recognizing patterns so that one can keep the old > >>"no-need-to-hit-dial" user interface. > >> > >>- Translating abbreviations such as extensions and local-area > >>numbers to > >>fully-expanded, globally unique identifiers. > >> > >>The former will always require downloading a pattern to an > >>end system, > >>the latter is a (local) translation service. The only question then > >>becomes if the translation is done in one or two steps, > i.e., before > >>issuing a SIP request or as part of a SIP request. > >> > >>Aside: There are clearly examles of widely-deployed systems > where the > >>phone has a dial-plan, downloaded via tftp. > >> > >>Rosen, Brian wrote: > >> > >>>This comes up a lot. I think we should decide. > >>> > >>>Who translates a dial string into a tel uri? > >>> > >>>tel uris, as of now, explicitly don't handle dialing strings, > >>>only dialed numbers. In essentially all existing systems, > >>>phones don't have dialing plans in them; central elements > >>>map dialing strings to dialed numbers. What's our story? > >>>Does every UA that has a dial pad have to have a dialing plan > >>>loaded in it that maps dialing strings to dialed numbers, > >>>or does a proxy server do it? > >>> > >>>If it's the former, then how do we standardize the mapping? > >>>If it's the latter, then how does a UA send a dialing string? > >>> > >>>Brian > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>Sent: Thursday, January 09, 2003 9:53 AM > >>>>To: 'sipping@ietf.org' > >>>>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > >>>> > >>>> > >>>>I have a few comments about draft-schulzrinne-sipping-sos-04.txt. > >>>>(I haven't been following this work very closely, so > >>> > >>perhaps some of > >> > >>>>these pertain to things that were in earlier drafts.) > >>>> > >>>>I must say, these are really messy problems, so I am glad you are > >>>>working on them. > >>>> > >>>>Section 3.2 says: > >>>> > >>>> ... a UAC MAY use a "tel" URI [3,4] without > >>> > >>phone-context, such as > >> > >>>> tel:911 > >>>> tel:112 > >>>> > >>>>The latest and greatest definition of the tel: uri that I > >>> > >>can find is > >> > >>>>draft-antti-rfc2806bis-07.txt. According to that, the above > >>> > >>tel: uris > >> > >>>>are syntactically incorrect. Either the number must be global > >>>>or else it > >>>>must contain a phone-context parameter. > >>>> > >>>>Are there plans to change the definition of the tel uri, > or is this > >>>>language going to change? > >>>> > >>>>In the case of a UAC that is using a local outbound proxy, is it > >>>>required that the UAC specifically recognize these strings > >>>>and deliver > >>>>them to the proxy, or is it sufficient for it to deliver > >>> > >>any and all > >> > >>>>dialed digit strings to the proxy as tel uris without > attempting to > >>>>recognize them itself? Is it sufficient to determine that > >>> > >>the dialed > >> > >>>>number is complete by timeout on the input rather than by > >>> > >>recognition? > >> > >>>>Section 5 specifies that the UAC should insert location > >>>>information into > >>>>emergency calls. However, presumably location information > should in > >>>>general not be placed in non-emergency calls, so it is > >>> > >>important that > >> > >>>>the UAC realize it is making an emergency call. In the case > >>> > >>of dialed > >> > >>>>digit strings, it may only be the outbound proxy that can > >>>>determine if > >>>>the call is an emergency call. One way to handle this would > >>>>be for the > >>>>local outbound proxy to redirect requests to tel: emergency > >>>>numbers to > >>>>the corresponding sip:sos number. Then the UAC would be able to > >>>>positively determine this is an emergency call and include > >>>>the location > >>>>information. > >>>> > >>>>Section 9 says: > >>>> > >>>> We propose a new DHCP option that enumerates the valid local > >>>> emergency identifiers, as a list of "tel", "sip" or > "sips" URIs. > >>>> > >>>>This doesn't seem sufficient. Most phone-like devices have > >>>>provision for > >>>>entering primarily sequences of digits, not tel: uris. It is > >>>>up to the > >>>>phone to translate a digit sequence into a valid uri. In > >>> > >>general this > >> > >>>>requires some sort of dial plan. Without the dial plan, the > >>> > >>phone may > >> > >>>>well not be able to generate anything that matches one of the > >>>>specified > >>>>tel uris. > >>>> > >>>> Paul > >>>> > >>>>_______________________________________________ > >>>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>>This list is for NEW development of the application of SIP >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sip@ietf.org for new developments of core SIP >>>> >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP >> > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 14:02:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21986 for ; Thu, 9 Jan 2003 14:02:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09JE5D16199 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 14:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JE5J16196 for ; Thu, 9 Jan 2003 14:14:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21928 for ; Thu, 9 Jan 2003 14:01:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JAOJ15962; Thu, 9 Jan 2003 14:10:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09J9hJ15920 for ; Thu, 9 Jan 2003 14:09:43 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21436 for ; Thu, 9 Jan 2003 13:57:22 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09J14Yc005237; Thu, 9 Jan 2003 14:01:04 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX62371; Thu, 9 Jan 2003 14:05:22 -0500 (EST) Message-ID: <3E1DC6C5.1060606@cisco.com> Date: Thu, 09 Jan 2003 14:00:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Henning Schulzrinne'" , "Rosen, Brian" , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <9BF66EBF6BEFD942915B4D4D45C051F3A643FB@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I believe the current definition of tel: would want you to translate these numbers as follows: 8123 => tel:+17135558123 3123 => tel:3123;phone-context=+17135558 (Or use some other context, but this one should be legal for your case.) This is no problem as long as the phone is presumed to have a full and complete dial plan that can turn ever dialed number into the proper valid tel: uri. The problem comes if you want this task to be performed someplace else, like in a local outbound proxy. In that case, you need some way to convey the dialed digits to the proxy, where it can do its magic. See my earlier message for more on that. Paul Adam Roach wrote: >>- Translating abbreviations such as extensions and local-area >>numbers to >>fully-expanded, globally unique identifiers. > > > It's also interesting to note that many systems (e.g. PBXes) > include extensions that don't have an external representation. > > For example, let's imaine a company that has a PBX with an > assigned range of +1-713-555-8xxx. They use 4-digit internal > dialling. Some extensions (e.g. 8123) can have an external > mapping (+1 713 555 8123). Others, like 3123, can't be reached > externally. They *can't* exist as fully-expanded, globally unique > identifiers. > > So, how exactly do we address this? I see several options: > > 1) Allow "tel:" to include dialled digit strings, possibly > with some parameter to indicate as much. > > 2) Create a new URI that is defined to carry dialled digits. > > Both of these have their own rather obvious problems. > Can someone think of an alternate solution? > > /a > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 14:23:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23246 for ; Thu, 9 Jan 2003 14:23:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09JZQc17581 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 14:35:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JZQJ17578 for ; Thu, 9 Jan 2003 14:35:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23219 for ; Thu, 9 Jan 2003 14:23:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JYMJ17526; Thu, 9 Jan 2003 14:34:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JXeJ17432 for ; Thu, 9 Jan 2003 14:33:40 -0500 Received: from imo-r02.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23162 for ; Thu, 9 Jan 2003 14:21:19 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v34.13.) id 7.fe.21b2f31b (17079); Thu, 9 Jan 2003 14:24:08 -0500 (EST) Message-ID: Date: Thu, 9 Jan 2003 14:24:08 EST Subject: Re: [Sipping] Comments on sos draft -03 (URI) To: hgs@cs.columbia.edu CC: Brian.Rosen@marconi.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_fe.21b2f31b.2b4f2658_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_fe.21b2f31b.2b4f2658_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/8/2003 9:40:46 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > In other words, if a hotel in Europe > doesn't have room 911, it should allow this as an emergency number, to > accomodate the US or Canadian traveler. > No, this is not correct. I doubt that any European regulatory body would accept this. If 911 is not assigned in the local environment, the call must go to "intercept". Mike Pierce Artel --part1_fe.21b2f31b.2b4f2658_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/8/2003 9:40:46 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


In other words, if a hotel in Europe
doesn't have room 911, it should allow this as an emergency number, to
accomodate the US or Canadian traveler.



No, this is not correct. I doubt that any European regulatory body would accept this. If 911 is not assigned in the local environment, the call must go to "intercept".

Mike Pierce
Artel
--part1_fe.21b2f31b.2b4f2658_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 14:23:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23306 for ; Thu, 9 Jan 2003 14:23:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09JZjq17629 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 14:35:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JZjJ17626 for ; Thu, 9 Jan 2003 14:35:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23237 for ; Thu, 9 Jan 2003 14:23:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JYIJ17502; Thu, 9 Jan 2003 14:34:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JXRJ17420 for ; Thu, 9 Jan 2003 14:33:27 -0500 Received: from imo-r08.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23157 for ; Thu, 9 Jan 2003 14:21:07 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r08.mx.aol.com (mail_out_v34.13.) id 7.183.14efad93 (17079); Thu, 9 Jan 2003 14:24:11 -0500 (EST) Message-ID: <183.14efad93.2b4f265b@aol.com> Date: Thu, 9 Jan 2003 14:24:11 EST Subject: Re: [Sipping] New -sos- draft (04) To: hgs@cs.columbia.edu, Duncan.Mills@gb.vodafone.co.uk CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_183.14efad93.2b4f265b_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_183.14efad93.2b4f265b_boundary Content-Type: text/plain; charset="UTF-8" Content-Language: en Content-Transfer-Encoding: quoted-printable In a message dated 1/9/2003 8:35:40 AM Eastern Standard Time,=20 hgs@cs.columbia.edu writes: > Mills, Duncan, D, CND Tech Dev, VF UK wrote: > > Henning, > > > > A very very minor comment in case you revise the draft again: > > > > In section 3.2 you talk about 118 being an ambiguous number, i.e. a > > collision exists between a Japanese emergency number and a UK > > directory services number. I think it is actually Finland that uses > > 118 as a directory services number, not the UK. >=20 > Thanks for catching this. I had been confused by the new 118XXX numbers=20 > in the UK; see=20 > http://www.oftel.gov.uk/publications/consumer/2002/dq1202.htm. These=20 > 118XXX numbers would obviously not collide. >=20 > > > > Another well known collision exists for 192 which is currently one of > > the UK's directory services number and is also an emergency number in > > Brazil. >=20 > Apparently, according to the Oftel page above, this number is to be=20 > withdrawn. ("After the last weekend in August 2003 the existing DQ=20 > numbers such as 192 will no longer work =E2=80=93 only the 118 numbers wil= l be=20 > available.") Fortunately, 192 isn't on the list of 'default' emergency=20 > numbers. >=20 >=20 [MAP] What the above examples demonstrate conclusively, I hope, is that no=20 specific list of emergency numbers can be built into a phone device. No=20 matter what is done today, the set will likely change in some way in the nea= r=20 future, and all such phones would be obsolete. This leads back to the need t= o=20 determine if and how the phone is downloaded with the current local dial=20 plan. (See Brian Rosen's e-mail this morning.) Mike Pierce Artel --part1_183.14efad93.2b4f265b_boundary Content-Type: text/html; charset="UTF-8" Content-Language: en Content-Transfer-Encoding: quoted-printable In a message dated 1/9/20= 03 8:35:40 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


Mills, Duncan, D, CND Tech=20= Dev, VF UK wrote:
> Henning,
>
> A very very minor comment in case you revise the draft again:
>
> In section 3.2 you talk about 118 being an ambiguous number, i.e. a
> collision exists between a Japanese emergency number and a UK
> directory services number.  I think it is actually Finland tha= t uses
> 118 as a directory services number, not the UK.

Thanks for catching this. I had been confused by the new 118XXX numbers=20
in the UK; see=20
http://www.oftel.gov.uk/publications/consumer/2002/dq1202.htm. These=20
118XXX numbers would obviously not collide.

>
> Another well known collision exists for 192 which is currently one=20= of
> the UK's directory services number and is also an emergency number=20= in
> Brazil.

Apparently, according to the Oftel page above, this=20= number is to be
withdrawn. ("After the last weekend in August 2003 the e= xisting DQ
numbers such as 192 will no longer work =E2=80=93 only the 11= 8 numbers will be
available.") Fortunately, 192 isn't on the list of 'de= fault' emergency
numbers.

[MAP] What the above examples demonstrate conclusively, I hope, is that=20= no specific list of emergency numbers can be built into a phone device. No m= atter what is done today, the set will likely change in some way in the near= future, and all such phones would be obsolete. This leads back to the need=20= to determine if and how the phone is downloaded with the current local dial=20= plan. (See Brian Rosen's e-mail this morning.)

Mike Pierce
Artel
--part1_183.14efad93.2b4f265b_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 15:01:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24813 for ; Thu, 9 Jan 2003 15:01:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09KCpr21686 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 15:12:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KCpJ21682 for ; Thu, 9 Jan 2003 15:12:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24730 for ; Thu, 9 Jan 2003 15:00:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KBRJ21286; Thu, 9 Jan 2003 15:11:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09K9dJ20995 for ; Thu, 9 Jan 2003 15:09:39 -0500 Received: from imo-r04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24405 for ; Thu, 9 Jan 2003 14:57:17 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v34.13.) id e.e.2b13d0f0 (14374); Thu, 9 Jan 2003 14:59:58 -0500 (EST) Message-ID: Date: Thu, 9 Jan 2003 14:59:57 EST Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sippin... To: Brian.Rosen@marconi.com, pkyzivat@cisco.com CC: hgs@cs.columbia.edu, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_e.2b13d0f0.2b4f2ebd_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_e.2b13d0f0.2b4f2ebd_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/9/2003 2:08:43 PM Eastern Standard Time, Brian.Rosen@marconi.com writes: > First we should decide if we put the dialing plan in the phone. > [MAP] As I see it, there are only two possibilities to handle a SIP call (not just emergency calls): 1. The phone knows the dial plan for the area it is in 2. The outging proxy knows the dial plan (of the originating phone) WIth option 1, it is clearly unworkable for the dial plan (including knowledge of what the emergency number is) to be built into a phone. It would seem to be out of the question to expect an arbitrary proxy to know the dial plans for all areas of the world, so I must presume that the only workable scheme for option 2 is for the outgoing proxy to be "local" to the orginator. (There is, in effect, another case, such as the satellite service some have mentioned, in which the orginator has no "local" dial plan, that is, there is no expectation of being able to reach "local" things like emergency, repair, the local TV station by dialing #13, the highway patrol by dialing #77, etc. The only thing that can be dialed is an E.164 number, or specific "service" numbers that the satallite service provider themselves defines and uses.) So there are two possibilities (when there really is a "local" dial plan): 1. A phone is loaded with the dial plan when it "registers" for service, with the information coming from some "local" server. It can then know when dialing is complete without a "Send" key, and can send the appropriate tel:uri (E.164 number, SOS, etc.). 2. The phone knows nothing about the dial plan, depends on the user hitting a "Send" key (like cellualar) and the "local" outbound proxy does all interpretation of the dial digit string. The phone knows nothing about emergency calls. Certainly both of these should be allowed. (If you want an example of what could be required to send a dial plan to a phone, one can reference RFC 2705.) Mike Pierce Artel --part1_e.2b13d0f0.2b4f2ebd_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 1/9/2003 2:08:43 PM Eastern Standard Time, Brian.Rosen@marconi.com writes:


First we should decide if we put the dialing plan in the phone.

[MAP] As I see it, there are only two possibilities to handle a SIP call (not just emergency calls):

1. The phone knows the dial plan for the area it is in
2. The outging proxy knows the dial plan (of the originating phone)

WIth option 1, it is clearly unworkable for the dial plan (including knowledge of what the emergency number is) to be built into a phone.

It would seem to be out of the question to expect an arbitrary proxy to know the dial plans for all areas of the world, so I must presume that the only workable scheme for option 2 is for the outgoing proxy to be "local" to the orginator.

(There is, in effect, another case, such as the satellite service some have mentioned, in which the orginator has no "local" dial plan, that is, there is no expectation of being able to reach "local" things like emergency, repair, the local TV station by dialing #13, the highway patrol by dialing #77, etc. The only thing that can be dialed is an E.164 number, or specific "service" numbers that the satallite service provider themselves defines and uses.)

So there are two possibilities (when there really is a "local" dial plan):

1. A phone is loaded with the dial plan when it "registers" for service, with the information coming from some "local" server. It can then know when dialing is complete without a "Send" key, and can send the appropriate tel:uri (E.164 number, SOS, etc.).
2. The phone knows nothing about the dial plan, depends on the user hitting a "Send" key (like cellualar) and the "local" outbound proxy does all interpretation of the dial digit string. The phone knows nothing about emergency calls.

Certainly both of these should be allowed.

(If you want an example of what could be required to send a dial plan to a phone, one can reference RFC 2705.)

Mike Pierce
Artel
--part1_e.2b13d0f0.2b4f2ebd_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 18:01:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29291 for ; Thu, 9 Jan 2003 18:01:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09NDQY01459 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 18:13:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NDQJ01455 for ; Thu, 9 Jan 2003 18:13:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29286 for ; Thu, 9 Jan 2003 18:01:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NBwJ01373; Thu, 9 Jan 2003 18:11:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NAmJ01296 for ; Thu, 9 Jan 2003 18:10:48 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29133 for ; Thu, 9 Jan 2003 17:58:24 -0500 (EST) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09N1eQ25540 for ; Thu, 9 Jan 2003 18:01:40 -0500 (EST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 18:01:39 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D703F5AB11@oh0012itsa1.cb.lucent.com> From: "Deb, Sunandita (Sunandita)" To: "'sipping@ietf.org'" Date: Thu, 9 Jan 2003 18:01:30 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Mapping of ISDN PRI messages to SIP-T Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi, I'd like to get some information regarding the mapping of ISDN PRI messages to SIP-T messages. Has this work already been done? Is there any RFC avaailable for it? Is there any RFC or any spec describing a mapping of ISUP messages to SIP-T? If I can get the latter, I can make an attempt to extend it to the PRI to SIP-T mapping for my project. Thanks, Sunandita sudeb@lucent.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 18:58:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00859 for ; Thu, 9 Jan 2003 18:58:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A0AcU04692 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 19:10:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0AcJ04689 for ; Thu, 9 Jan 2003 19:10:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00837 for ; Thu, 9 Jan 2003 18:58:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A09PJ04614; Thu, 9 Jan 2003 19:09:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A08hJ04564 for ; Thu, 9 Jan 2003 19:08:43 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00815 for ; Thu, 9 Jan 2003 18:56:16 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h09NxH802953; Thu, 9 Jan 2003 23:59:17 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 19:01:40 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB511@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Rosen, Brian'" , "'Paul Kyzivat'" Cc: "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 9 Jan 2003 19:01:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I feel pretty strongly that phone numbers should be converted into fully-qualified E.164 numbers at the originating user agent. It is very problematic, outside of an architecture that is constrained in a way that we are unlikely to standardize, for a proxy server to figure out the context in which a set of arbitrary digits were dialed. Of course, if you're dialing a number that cannot be converted to E.164, then it needs to be sent as-is. This design decision has come up previously in the SIP-T work and in the tel URL work. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, January 09, 2003 10:45 AM > To: 'Paul Kyzivat' > Cc: 'Henning Schulzrinne'; 'sipping@ietf.org' > Subject: RE: [Sipping] Do Phones Have Dial Plans, or do > Proxies map? was > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > I think this response just restates the question. > I think we either say that phones essentially always put out > global numbers, or they put out dialing strings and a proxy > expands it. We can probably agree on the tel uri prefix for > either. If a proxy expands dialing strings to phone numbers, > then we probably do need some kind of context, as you point out. > > First we should decide if we put the dialing plan in the phone. > > BTW, I currently favor NOT putting the dialing plan in the UA, > but I don't feel strongly about it. I do feel strongly about > standardizing this bit, because I surely want all sipphones to > "play" in my system, and I don't want a boat-load of vendor specific > code to make that work. > > Our sip based enterprise system has a classical enterprise dialing > plan, although we interpret 7 or more digits as national or > international numbers, rather than requiring the "9" prefix. > That works because all internal numbers are less than 7 digits. > Proxies do the expansion. There is vendor specific code in this > proxy because no two gateways we support work the same. > Hence this entire effort :) > > Brian > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, January 09, 2003 1:13 PM > > To: Rosen, Brian > > Cc: 'Henning Schulzrinne'; 'sipping@ietf.org' > > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do > > Proxies map? was > > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > > > > Unless we are going to require users to enter full URIs into > > the phone > > (including "tel:"), the phone MUST have some sort of dial > > plan. We only > > need to discuss how complex it is. > > > > At one extreme it could simply be to prefix the entered digits with > > "tel:" and let a proxy do the rest. > > > > At the other extreme it could do all sorts of complex > > transformations to > > turn short sequences into global tel: uris, or even sip uris, > > possibly > > even chosing different gateways based on dialed number. > > > > As I mentioned in an earlier reply, simply slapping "tel:" on the > > entered digits doesn't create syntactically correct tel: uris > > according > > to the latest definition. To go that way, the tel: syntax > needs to be > > altered. Also, the tel: definition currently says that a > tel: address > > SHOULD always use global syntax unless there is no valid > > global address. > > Encoding dialed digits as a local tel: uri and defering > > conversion to a > > global address to a proxy would violate that rule. > > > > One possibility is to define the minimal dial plan for a phone as: > > prefix the dialed digits with "tel:" and suffix the dialed > > digits with > > ";phone-context=XXX", where XXX needs to be learned or provisioned > > somewhere. The XXX is then effectively a name for the dial > plan to be > > used to expand the number. This gets around the syntax problem with > > using the tel: uri, though it still violates the semantic rule. > > > > Paul > > > > Rosen, Brian wrote: > > > The systems I'm aware of use regexps in one form or another > > > to mangle a string into a dialed number. I don't have > > > a problem making this a UA function, but if we do, I want > > > to standardize the regexp and "Publish" it to the UA. > > > > > > A lot of enterprise gateways have dial string to dialed > > number mapping. > > > Some sipphones do. > > > > > > Brian > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > >>Sent: Thursday, January 09, 2003 10:32 AM > > >>To: Rosen, Brian > > >>Cc: 'Paul Kyzivat'; 'sipping@ietf.org' > > >>Subject: Re: [Sipping] Do Phones Have Dial Plans, or do > > >>Proxies map? was > > >>RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > >> > > >> > > >>I would find it instructive how non-SIP systems have > solved similar > > >>problems. In web browsers and email, we have auto-completion > > >>functions > > >>and nick names, for examples. > > >> > > >>There's also the analogy with 'real names' (not the defunct > > >>company, the > > >>concept) which translates strings-nice-for-humans into URLs. > > >>See the CRN > > >>work, including the go: URL. (I'm not aware of > > implemenentations, but > > >>the concept may be relevant, in particular keeping the > > identifier and > > >>various 'nicknames' clearly distinct.) > > >> > > >>There are probably two sub-problems here: > > >> > > >>- Recognizing patterns so that one can keep the old > > >>"no-need-to-hit-dial" user interface. > > >> > > >>- Translating abbreviations such as extensions and local-area > > >>numbers to > > >>fully-expanded, globally unique identifiers. > > >> > > >>The former will always require downloading a pattern to an > > >>end system, > > >>the latter is a (local) translation service. The only > question then > > >>becomes if the translation is done in one or two steps, > > i.e., before > > >>issuing a SIP request or as part of a SIP request. > > >> > > >>Aside: There are clearly examles of widely-deployed systems > > where the > > >>phone has a dial-plan, downloaded via tftp. > > >> > > >>Rosen, Brian wrote: > > >> > > >>>This comes up a lot. I think we should decide. > > >>> > > >>>Who translates a dial string into a tel uri? > > >>> > > >>>tel uris, as of now, explicitly don't handle dialing strings, > > >>>only dialed numbers. In essentially all existing systems, > > >>>phones don't have dialing plans in them; central elements > > >>>map dialing strings to dialed numbers. What's our story? > > >>>Does every UA that has a dial pad have to have a dialing plan > > >>>loaded in it that maps dialing strings to dialed numbers, > > >>>or does a proxy server do it? > > >>> > > >>>If it's the former, then how do we standardize the mapping? > > >>>If it's the latter, then how does a UA send a dialing string? > > >>> > > >>>Brian > > >>> > > >>> > > >>> > > >>>>-----Original Message----- > > >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>>>Sent: Thursday, January 09, 2003 9:53 AM > > >>>>To: 'sipping@ietf.org' > > >>>>Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > >>>> > > >>>> > > >>>>I have a few comments about > draft-schulzrinne-sipping-sos-04.txt. > > >>>>(I haven't been following this work very closely, so > > >>> > > >>perhaps some of > > >> > > >>>>these pertain to things that were in earlier drafts.) > > >>>> > > >>>>I must say, these are really messy problems, so I am > glad you are > > >>>>working on them. > > >>>> > > >>>>Section 3.2 says: > > >>>> > > >>>> ... a UAC MAY use a "tel" URI [3,4] without > > >>> > > >>phone-context, such as > > >> > > >>>> tel:911 > > >>>> tel:112 > > >>>> > > >>>>The latest and greatest definition of the tel: uri that I > > >>> > > >>can find is > > >> > > >>>>draft-antti-rfc2806bis-07.txt. According to that, the above > > >>> > > >>tel: uris > > >> > > >>>>are syntactically incorrect. Either the number must be global > > >>>>or else it > > >>>>must contain a phone-context parameter. > > >>>> > > >>>>Are there plans to change the definition of the tel uri, > > or is this > > >>>>language going to change? > > >>>> > > >>>>In the case of a UAC that is using a local outbound > proxy, is it > > >>>>required that the UAC specifically recognize these strings > > >>>>and deliver > > >>>>them to the proxy, or is it sufficient for it to deliver > > >>> > > >>any and all > > >> > > >>>>dialed digit strings to the proxy as tel uris without > > attempting to > > >>>>recognize them itself? Is it sufficient to determine that > > >>> > > >>the dialed > > >> > > >>>>number is complete by timeout on the input rather than by > > >>> > > >>recognition? > > >> > > >>>>Section 5 specifies that the UAC should insert location > > >>>>information into > > >>>>emergency calls. However, presumably location information > > should in > > >>>>general not be placed in non-emergency calls, so it is > > >>> > > >>important that > > >> > > >>>>the UAC realize it is making an emergency call. In the case > > >>> > > >>of dialed > > >> > > >>>>digit strings, it may only be the outbound proxy that can > > >>>>determine if > > >>>>the call is an emergency call. One way to handle this would > > >>>>be for the > > >>>>local outbound proxy to redirect requests to tel: emergency > > >>>>numbers to > > >>>>the corresponding sip:sos number. Then the UAC would be able to > > >>>>positively determine this is an emergency call and include > > >>>>the location > > >>>>information. > > >>>> > > >>>>Section 9 says: > > >>>> > > >>>> We propose a new DHCP option that enumerates the valid local > > >>>> emergency identifiers, as a list of "tel", "sip" or > > "sips" URIs. > > >>>> > > >>>>This doesn't seem sufficient. Most phone-like devices have > > >>>>provision for > > >>>>entering primarily sequences of digits, not tel: uris. It is > > >>>>up to the > > >>>>phone to translate a digit sequence into a valid uri. In > > >>> > > >>general this > > >> > > >>>>requires some sort of dial plan. Without the dial plan, the > > >>> > > >>phone may > > >> > > >>>>well not be able to generate anything that matches one of the > > >>>>specified > > >>>>tel uris. > > >>>> > > >>>> Paul > > >>>> > > >>>>_______________________________________________ > > >>>>Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >>>>This list is for NEW development of the application of SIP > >>>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>>Use sip@ietf.org for new developments of core SIP > >>>> > >>> > >>>_______________________________________________ > >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP >> > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 18:58:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00861 for ; Thu, 9 Jan 2003 18:58:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A0AcR04707 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 19:10:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0AcJ04704 for ; Thu, 9 Jan 2003 19:10:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00839 for ; Thu, 9 Jan 2003 18:58:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A09JJ04590; Thu, 9 Jan 2003 19:09:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A08GJ04540 for ; Thu, 9 Jan 2003 19:08:16 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00785 for ; Thu, 9 Jan 2003 18:55:50 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h09Nwt802941; Thu, 9 Jan 2003 23:58:55 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 19:01:18 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB510@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Rosen, Brian'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Thu, 9 Jan 2003 19:01:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I may have been a little thick up to this point - I now think that by 'gateway' you mean something that acts like a PBX (I was kind of thinking you meant a PSTN gateway, which has very different requirement for all of this). From the notes below, it sounds like in your case the PBX is a SIP UA that has a set of hardwired phone lines (your 'ports'), each of which goes to a single black phone. You want a proxy server to manage the mappings of identifiers (be they tel URLs or SIP URIs) to particular PBXs and PBX ports, because you want the PBXs themselves to be ignorant of the URIs that identify the phones that they manage. Is that right? Ordinarily, we say that in SIP architectures, features are pushed to the edges, not to the core of the network. Abstract out the PBX for a minute, and imagine coming forward with a SIP architecture in which you have a set of user agents that are so simple that they don't know their own identity, they can't learn it somehow from the network, and therefore cannot correctly populate the From header field of requests they generate. Instead, they'd like a proxy server to somehow populate this identity in requests as they are sent through the network. This would be essentially the same problem you brought to the list. My reaction would probably be that RFC3261 assumes that SIP UAs have the ability to populate a From header field. Even my 1G CDMA cell phone knows its own phone number. A PBX usually means something with a lot of features. Even if in your architecture you're trying to radically reduce the cost of the PBX component, a PBX can be expected to more be complex than, say, the sorts of simple SIP phones we see today (which are in my experience all capable of mananging one identity, if not several, for their users). Is it really that much harder for a PBX to look at the string 'port3' in the R-U of a SIP request and map that to a hardware resource than it is for a PBX to look at the string '+12025332600' in the R-U of a SIP request and map that to a hardware resource? PBXs that are compliant SIP implementations will have to perform a number of vastly more complicated operations. In other words, it's hard for me to understand why the PBX UA (the edge) isn't the right place to manage the mapping between an identifier (a phone number) and a port. Doing this in a proxy (the core) introduces a number of data synchronization questions as well as the protocol questions that have run through this thread. Is there some special reason why this PBX cannot be expected to do one of the simpler things that we ask of UAs? Is there a particularly large number of ports that you imagine such a PBX would manage (in the millions, maybe)? It would really help to have more background. The motivation for this is a little obscure to me. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, January 09, 2003 7:03 AM > To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Henning Schulzrinne' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] URIs for Gateways > > > Note below > > > What I suggested was that the From header hold the URI of the > > gateway - not > > the 'real' SIP URI of the user - for PSTN-to-SIP calls. The > > From address in > > this instance is not the address to which you should reply if > > you want to > > reach the initiator of the session later. The tel URL of that > > user is in > > fact the URI to which you should reply. I think this is a > > good place to put > > it for this case, and it doesn't warp the Reply-To header in > > any way that I > > can see. This is completely unrelated to where one would put > > the 'real' SIP > > URI of the user. > I see how it works in this case, but only if the UA knows > both identities. > In some cases it doesn't now, but I think we might reasonably ask > whether it should (ie the BCP I propose could state that gateways > should know the telephone number it is connected to, and fill in > From and Reply To as you suggest). We want to build systems where > a proxy knows this, and doesn't rely on the gateway. Basically, we > have ONE place that maintains the phone-number-to-user and > phone-number- > to-port-on-gateway information, and all tel URIs are routed through > that proxy. It adds mappings and decides on which gateway will get > the call. UAs don't know the mapping, gateways don't know > the mapping, > only the one proxy knows. We now have mechanisms that attempt to > keep gateway mapping systems accurate from the one database. > It takes > vendor specific code in the proxy that knows how to manipulate the > management port of each gateway in order to maintain the mappings. > That's not a good system design, even if it does work. > > > > > > It also has a serious problem that a proxy can't add it. > > > > I think you mean that you want the proxy to be able to add > a telephone > > number to a request for a SIP-to-PSTN call, or maybe to add > a SIP URI > > representing the originating user to a request for a > PSTN-to-SIP call > > (though this latter one is difficult - how would a user authenticate > > themselves to an auth service through a PSTN gateway?). I agree that > > Reply-To is not a good candidate for this usage - this is > > where it has been > > argued that P-Asserted-Identity is a good candidate. > Yes, you see what I mean. Yes P-A-I would work, although this use > does not meet the definition of P-A-I. I'm also bothered that we use > two different headers for what I think is the same thing (holding both > a sip URI and a tel URI in the sip message for the "From" identity). > > > > > There are some minor issues with this (such as how a proxy > > knows when and > > why to add identities, and how authentication for particular > > identifies is > > managed), but I think that if a proxy asserts an identity, it > > can and should > > use the identity mechanisms we've already defined, which > were designed > > specifically with proxies in mind. However, there are some > > reasons to ask > > whether or not proxies are always the best entities to decide > > when synonym > > identities should be added to a request. > I agree that authentication in this case is a little tricky, but > I don't think it's very hard. > > > > > > One of the requirements I have is that a proxy be able to > > > do the translation. Not every gateway can hold all the tables > > > required for this kind of translation, and I don't think > > > we want to force every gateway to have the tables. > > > > > > > The whole issue of who should do 'translation' by various > > entities is a > > little problematic, and ultimately this problem should be > > separable from the > > selection of the headers we might use to express the results > > of translation. > > Personally, I think ENUM is the right way to do telephone > > number to URI > > translations - however, it is not servicable for the reverse, > > for URI to > > telephone number translations. Having some kind of 'reverse > > ENUM' for this > > purpose has been the subject of much speculation in ENUM > > circles, but it > > currently is not well understood how it would work. > This is only true for Service Provider gateways. It is not true > for enterprise gateways. You would not want to use the currently > defined ENUM, because it would require that every enterprise > publish their internal mappings in the global ENUM DNS. That > is not acceptable, and there are no mechanisms to do that (it > implies that, for example, an enterprise tells it's SP what the > SIP URI associated with each extension is). > > > > > ENUM is best performed by the initiator of the session, > rather than an > > intermediary, for various reasons that are enumerated in > > sipping-e164-02. > > Therefore, for PSTN-to-SIP calls, I think the PSTN gateway is > > the right > > place to do an ENUM query. This does not require the gateway > > to have any > > tables, or what have you. Intermediaries can also query ENUM > > and apply the > > results to a message, even if it is sub-optimal for them to do so. > When ENUM is used, I agree, best at the gateway, less optimal in > an intermediary (proxy). > > > > > > I think your proposals on identity will not work unless > > > the signer can be a proxy which later in the routing > > > than my proxy that does the translation. > > > > Well, an authentication service, as I describe it, does the > > signing after a > > request has been generated, yes. If a later proxy wants to > shove some > > (authenticated) information into the request afterwards, that > > isn't possible > > unless is supplies a separate signed body. > It would be ugly, but possible, for an authentication to be performed > first on From/To/Reply-To and then subsequently on P-A-I. > The idea of authenticating cryptographically the P-A-I header > amuses me. > > > > > > If the gateway > > > does the translation, then in theory there would have to be > > > a trust relationship between the PSTN and the gateway. > > > > There is always, in effect, a trust relationship between the > > PSTN and a > > gateway. The gateway is a node on the PSTN (whether it is a > > privileged node, > > like an SS7 gateway, or a user node, like a CAS gateway), and > > nodes have a > > certain defined trust relationship with the PSTN. I think the > > gateway is one > > of the better candidates to do ENUM, and possibly to perform > > the reverse > > operation (however that would work). > Do SPs really trust CAS gateways? I didn't think it's true, > although I don't know what actually happens if the gateway > supplies a calling number that is not one of it's assigned DNs. > I'm pretty sure it's NOT true of PRI gateways, but don't really > know. I don't think that it matters for this discussion. > > See above for routing issues that argue against the gateway doing > the mapping, at least for an enterprise system. > > > > > > That won't work for an enterprise gateway, although I'm not > > > sure that's a practical problem, because if the gateway > > > translated, the PSTN is going to check that the number > > > the gateway asserted is one of the identities that loop > > > is allocated (PRIs have ranges). > > > > > > > Presumably, gateways shouldn't trust authentication services > > that might give > > them improper information. In fact, there are numerous restrictions > > surrounding what sorts of phone numbers should be sent over > > many sorts of > > ISUP trunks as well (as well as rules about when a CgPN must > > be present, as > > opposed to may be present). An proxy or user agent that > > supplies originating > > telephone numbers for SIP-to-PSTN calls should expect > > gateways to validate > > them, and there should be some way to accomodate cases in > > which the gateway > > cannot transmit these numbers to the PSTN, since it may be > > difficult for a > > proxy to determine what sort of gateway a request will > > ultimately land on > > (which is one of the reasons why proxies might not be the > > best place for > > synonym identities to be managed). > > > > > I don't see how ENUM is useful with identity assertion, > > > although it's clearly applicable to the proxy that > > > translates a SIP URI into a phone number or vice versa in > > > the Request URI. > > > > It doesn't assert identity itself, certainly. The one place > > in which it is > > conceivably useful for identity assertion is that ENUM could > > be queried for > > a URI associated with the calling party's number in a > > PSTN-to-SIP call. This > > could be useful for a number of reasons - that URI could be > stuck in a > > header to indicate a SIP URI for the end user that is more > explicit or > > recognizable than their telephone number. > Agree. This could be useful. What header? > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 20:13:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02865 for ; Thu, 9 Jan 2003 20:13:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A1P6E08822 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 20:25:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1P6J08819 for ; Thu, 9 Jan 2003 20:25:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02851 for ; Thu, 9 Jan 2003 20:12:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1NfJ08740; Thu, 9 Jan 2003 20:23:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1MNJ08687 for ; Thu, 9 Jan 2003 20:22:23 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02806 for ; Thu, 9 Jan 2003 20:09:51 -0500 (EST) Received: from w07087a (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8H00CD74MZ9B@mta0.huawei.com> for sipping@ietf.org; Fri, 10 Jan 2003 09:11:25 +0800 (CST) Date: Fri, 10 Jan 2003 09:14:10 +0800 From: wenkai To: sipping@ietf.org Message-id: <002801c2b845$94f91040$af064d0a@w07087a> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_6DNob1IWvEp7LlBW6Sbiww)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Sipping] a question about 3pcc Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_6DNob1IWvEp7LlBW6Sbiww) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi, The following is the "Mid-Call Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". After hanging up with the media server, the controller reconnects the Pre-Paid user to the called party. I think the media stream(stream 3) established between Pre-Paid user and the Called Party maybe is not the same as the original media stream(stream 1). In practice, maybe we want to have the same media codec as original one when we restore a call. Could you please give the call flow to reach this requirment? Best Regards Kevin Pre-Paid User Controller Called Party Media Server | | | | |..........stream 1.....................| | | |(1) INV SDP c=0 | | | |------------------>| | | |(2) 200 answer1 | | | |<------------------| | | |(3) ACK | | | |------------------>| | |(4) INV no SDP | | | |<------------------| | | |(5) 200 offer2 | | | |------------------>| | | | |(6) INV offer2 | | | |-------------------------------------->| | |(7) 200 answer2 | | | |<--------------------------------------| |(8) ACK answer2 | | | |<------------------| | | | |(9) ACK | | | |-------------------------------------->| |(10) RTP | | | |..........stream 2.........................................| | |(11) BYE | | | |-------------------------------------->| | |(12) 200 OK | | | |<--------------------------------------| | |(13) INV no SDP | | | |------------------>| | | |(14) 200 offer3 | | | |<------------------| | |(15) INV offer3' | | | |<------------------| | | |(16) 200 answer3' | | | |------------------>| | | | |(17) ACK answer3' | | | |------------------>| | |(18) ACK | | | |<------------------| | | |(19) RTP | | | |..........stream 3.....................| | --Boundary_(ID_6DNob1IWvEp7LlBW6Sbiww) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hi,
The following is the "Mid-Call Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt".
After hanging up with the media server, the controller reconnects the Pre-Paid user to the called party. I think the media stream(stream 3) established between Pre-Paid user and the Called Party maybe is not the same as the original media stream(stream 1).
In practice, maybe we want to have the same media codec as original one when we restore a call.
Could you please give the call flow to reach this requirment?
 
Best Regards
Kevin
 
 
     Pre-Paid User        Controller         Called Party        Media Server
          |                   |                   |                   |
          |..........stream 1.....................|                   |
          |                   |(1) INV SDP c=0    |                   |
          |                   |------------------>|                   |
          |                   |(2) 200 answer1    |                   |
          |                   |<------------------|                   |
          |                   |(3) ACK            |                   |
          |                   |------------------>|                   |
          |(4) INV no SDP     |                   |                   |
          |<------------------|                   |                   |
          |(5) 200 offer2     |                   |                   |
          |------------------>|                   |                   |
          |                   |(6) INV offer2     |                   |
          |                   |-------------------------------------->|
          |                   |(7) 200 answer2    |                   |
          |                   |<--------------------------------------|
          |(8) ACK answer2    |                   |                   |
          |<------------------|                   |                   |
          |                   |(9) ACK            |                   |
          |                   |-------------------------------------->|
          |(10) RTP           |                   |                   |
          |..........stream 2.........................................|
          |                   |(11) BYE           |                   |
          |                   |-------------------------------------->|
          |                   |(12) 200 OK        |                   |
          |                   |<--------------------------------------|
          |                   |(13) INV no SDP    |                   |
          |                   |------------------>|                   |
          |                   |(14) 200 offer3    |                   |
          |                   |<------------------|                   |
          |(15) INV offer3'   |                   |                   |
          |<------------------|                   |                   |
          |(16) 200 answer3'  |                   |                   |
          |------------------>|                   |                   |
          |                   |(17) ACK answer3'  |                   |
          |                   |------------------>|                   |
          |(18) ACK           |                   |                   |
          |<------------------|                   |                   |
          |(19) RTP           |                   |                   |
          |..........stream 3.....................|                   |
--Boundary_(ID_6DNob1IWvEp7LlBW6Sbiww)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 20:37:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03311 for ; Thu, 9 Jan 2003 20:37:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A1nPl10285 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 20:49:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1nPJ10282 for ; Thu, 9 Jan 2003 20:49:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03303 for ; Thu, 9 Jan 2003 20:36:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1mAJ10183; Thu, 9 Jan 2003 20:48:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1lgJ10154 for ; Thu, 9 Jan 2003 20:47:42 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03272 for ; Thu, 9 Jan 2003 20:35:12 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h0A1cTx4029914 for ; Thu, 9 Jan 2003 19:38:30 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032) id 3DF6BD4E00FD84FF; Thu, 9 Jan 2003 20:38:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B848.F8CF9A7F" Subject: RE: [Sipping] a question about 3pcc Date: Thu, 9 Jan 2003 20:38:27 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F9053B6613@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sipping] a question about 3pcc Thread-Index: AcK4Rd6PBhj/gZuNSGOjl0DKbLdBhgAAfusw From: "Roy, Radhika R, ALASO" To: "wenkai" , Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2B848.F8CF9A7F Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I think that Kevin is right. =20 A media server (e.g., placed in the service provider's network) may = support any number of standardized codecs that a user offers. So, = negotiations of codecs may not be needed. =20 For the callee, it may not be the case. As a result, negotiations of = codecs may needed. Call flows need to be extended to cover that = possibility. =20 Radhika R. Roy rrroy@att.com -----Original Message----- From: wenkai [mailto:wkai@huawei.com] Sent: Thursday, January 09, 2003 8:14 PM To: sipping@ietf.org Subject: [Sipping] a question about 3pcc Hi, The following is the "Mid-Call Announcement" call flow from = "draft-ietf-sipping-3pcc-02.txt".=20 After hanging up with the media server, the controller reconnects the = Pre-Paid user to the called party. I think the media stream(stream 3) = established between Pre-Paid user and the Called Party maybe is not the = same as the original media stream(stream 1). In practice, maybe we want to have the same media codec as original one = when we restore a call. Could you please give the call flow to reach this requirment? =20 Best Regards Kevin =20 =20 Pre-Paid User Controller Called Party Media = Server | | | | |..........stream 1.....................| | | |(1) INV SDP c=3D0 | = | | |------------------>| | | |(2) 200 answer1 | | | |<------------------| | | |(3) ACK | | | |------------------>| | |(4) INV no SDP | | | |<------------------| | | |(5) 200 offer2 | | | |------------------>| | | | |(6) INV offer2 | | | |-------------------------------------->| | |(7) 200 answer2 | | | |<--------------------------------------| |(8) ACK answer2 | | | |<------------------| | | | |(9) ACK | | | |-------------------------------------->| |(10) RTP | | | |..........stream 2.........................................| | |(11) BYE | | | |-------------------------------------->| | |(12) 200 OK | | | |<--------------------------------------| | |(13) INV no SDP | | | |------------------>| | | |(14) 200 offer3 | | | |<------------------| | |(15) INV offer3' | | | |<------------------| | | |(16) 200 answer3' | | | |------------------>| | | | |(17) ACK answer3' | | | |------------------>| | |(18) ACK | | | |<------------------| | | |(19) RTP | | | |..........stream 3.....................| | ------_=_NextPart_001_01C2B848.F8CF9A7F Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I=20 think that Kevin is right.
 
A=20 media server (e.g., placed in the service provider's network) may = support=20 any number of standardized codecs that a user offers. So, negotiations = of codecs=20 may not be needed.
 
For=20 the callee, it may not be the case. As a result, negotiations of codecs = may=20 needed. Call flows need to be extended to cover that=20 possibility.
 
Radhika R. Roy
rrroy@att.com
-----Original Message-----
From: wenkai=20 [mailto:wkai@huawei.com]
Sent: Thursday, January 09, 2003 = 8:14=20 PM
To: sipping@ietf.org
Subject: [Sipping] a = question=20 about 3pcc

Hi,
The following is the = "Mid-Call=20 Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". =
After hanging up with the = media server,=20 the controller reconnects the Pre-Paid user to the called = party. I=20 think the media stream(stream 3) established between Pre-Paid user and = the=20 Called Party maybe is not the same as the original media = stream(stream=20 1).
In practice, maybe we want to = have the=20 same media codec as original one when we restore a = call.
Could you please = give the call=20 flow to reach this requirment?
 
Best Regards
Kevin
 
 
     = Pre-Paid=20 User       =20 Controller         Called=20 Party        Media = Server
         =20 = |            =       =20 = |            =   =20    =20 = |            =       =20 |
         =20 |..........stream=20 = 1.....................|        &n= bsp;         =20 |
         =20 = |            =       =20 |(1) INV SDP c=3D0   =20 = |            =       =20 |
         =20 = |            =       =20 = |------------------>|        &= nbsp;         =20 |
         =20 = |            =       =20 |(2) 200 answer1   =20 = |            =       =20 |
         =20 = |            =       =20 = |<------------------|        &= nbsp;         =20 |
         =20 = |            =       =20 |(3) = ACK           =20 = |            =       =20 |
         =20 = |            =       =20 = |------------------>|        &= nbsp;         =20 |
          |(4) INV = no=20 SDP    =20 = |            =       =20 = |            =       =20 |
         =20 = |<------------------|        &= nbsp;         =20 = |            =       =20 |
          |(5) 200=20 offer2    =20 = |            =       =20 = |            =       =20 |
         =20 = |------------------>|        &= nbsp;         =20 = |            =       =20 |
         =20 = |            =       =20 |(6) INV offer2    =20 = |            =       =20 |
         =20 = |            =       =20 = |-------------------------------------->|
    &= nbsp;    =20 = |            =       =20 |(7) 200 answer2   =20 = |            =       =20 |
         =20 = |            =       =20 = |<--------------------------------------|
    &= nbsp;    =20 |(8) ACK answer2   =20 = |            =       =20 = |            =       =20 |
         =20 = |<------------------|        &= nbsp;         =20 = |            =       =20 |
         =20 = |            =       =20 |(9) = ACK           =20 = |            =       =20 |
         =20 = |            =       =20 = |-------------------------------------->|
    &= nbsp;    =20 |(10) RTP          =20 = |            =       =20 = |            =       =20 |
          = |..........stream=20 = 2.........................................|
    &n= bsp;    =20 = |            =       =20 |(11) BYE          =20 = |            =       =20 |
         =20 = |            =       =20 = |-------------------------------------->|
    &= nbsp;    =20 = |            =       =20 |(12) 200 OK       =20 = |            =       =20 |
         =20 = |            =       =20 = |<--------------------------------------|
    &= nbsp;    =20 = |            =       =20 |(13) INV no SDP   =20 = |            =       =20 |
         =20 = |            =       =20 = |------------------>|        &= nbsp;         =20 |
         =20 = |            =       =20 |(14) 200 offer3   =20 = |            =       =20 |
         =20 = |            =       =20 = |<------------------|        &= nbsp;         =20 |
          |(15) INV=20 offer3'  =20 = |            =       =20 = |            =       =20 |
         =20 = |<------------------|        &= nbsp;         =20 = |            =       =20 |
          |(16) 200=20 answer3' =20 = |            =       =20 = |            =       =20 |
         =20 = |------------------>|        &= nbsp;         =20 = |            =       =20 |
         =20 = |            =       =20 |(17) ACK answer3' =20 = |            =       =20 |
         =20 = |            =       =20 = |------------------>|        &= nbsp;         =20 |
          |(18)=20 ACK          =20 = |            =       =20 = |            =       =20 |
         =20 = |<------------------|        &= nbsp;         =20 = |            =       =20 |
          |(19)=20 RTP          =20 = |            =       =20 = |            =       =20 |
          = |..........stream=20 = 3.....................|        &n= bsp;         =20 |
------_=_NextPart_001_01C2B848.F8CF9A7F-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 21:08:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03777 for ; Thu, 9 Jan 2003 21:08:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A2K7E12136 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 21:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2K7J12133 for ; Thu, 9 Jan 2003 21:20:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03761 for ; Thu, 9 Jan 2003 21:07:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2J4J12083; Thu, 9 Jan 2003 21:19:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2ISJ12052 for ; Thu, 9 Jan 2003 21:18:28 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03738 for ; Thu, 9 Jan 2003 21:05:59 -0500 (EST) Received: from cs.columbia.edu ([12.92.113.231]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030110020916.YQDI12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Fri, 10 Jan 2003 02:09:16 +0000 Message-ID: <3E1E2AB8.9020204@cs.columbia.edu> Date: Thu, 09 Jan 2003 21:06:48 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "Rosen, Brian" , "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <9BF66EBF6BEFD942915B4D4D45C051F3A643F9@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In case there's doubt: I was not suggesting that we do this. I was trying to find out from Brian what he meant, since the two problem have very different solution sets. The 'abbreviated dialing' case requires nothing except a suitable URI scheme and the translation services of an outbound proxy. Adam Roach wrote: >>- Recognizing patterns so that one can keep the old >>"no-need-to-hit-dial" user interface. > > > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! > > No! > > Cell phones have sufficiently trained the public that it's > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER" > after a phone number. It makes life so much easier for user > interface designers and users alike. For the love of all that > is good, let's not encourage backsliding. > > /a _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 21:32:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04208 for ; Thu, 9 Jan 2003 21:32:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A2ioN13546 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 21:44:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2ioJ13543 for ; Thu, 9 Jan 2003 21:44:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04192 for ; Thu, 9 Jan 2003 21:32:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2hLJ13491; Thu, 9 Jan 2003 21:43:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2gLJ13445 for ; Thu, 9 Jan 2003 21:42:21 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04146 for ; Thu, 9 Jan 2003 21:29:52 -0500 (EST) Received: from cs.columbia.edu ([12.92.113.231]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030110023309.ZJGO12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Fri, 10 Jan 2003 02:33:09 +0000 Message-ID: <3E1E3052.1070207@cs.columbia.edu> Date: Thu, 09 Jan 2003 21:30:42 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: Brian.Rosen@marconi.com, sipping@ietf.org Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I gather you're claiming that 3GPP is violating European telecom rules, given that its SIM is recognizing 911 (and other non-local emergency numbers)? Mpierce1@aol.com wrote: >> In other words, if a hotel in Europe >> doesn't have room 911, it should allow this as an emergency number, to >> accomodate the US or Canadian traveler. > No, this is not correct. I doubt that any European regulatory body would > accept this. If 911 is not assigned in the local environment, the call > must go to "intercept". > > Mike Pierce > Artel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 21:34:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04360 for ; Thu, 9 Jan 2003 21:34:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A2kAm13636 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 21:46:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2kAJ13633 for ; Thu, 9 Jan 2003 21:46:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04300 for ; Thu, 9 Jan 2003 21:33:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2j4J13598; Thu, 9 Jan 2003 21:45:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2iXJ13530 for ; Thu, 9 Jan 2003 21:44:33 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04186 for ; Thu, 9 Jan 2003 21:32:04 -0500 (EST) Received: from cs.columbia.edu ([12.92.113.231]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030110023521.ZKZY12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Fri, 10 Jan 2003 02:35:21 +0000 Message-ID: <3E1E30D6.1060506@cs.columbia.edu> Date: Thu, 09 Jan 2003 21:32:54 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: Brian.Rosen@marconi.com, sipping@ietf.org Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > No, this is not correct. I doubt that any European regulatory body would > accept this. If 911 is not assigned in the local environment, the call > must go to "intercept". It doesn't. Logically speaking, this is nothing but a local (private) emergency number. As noted by others, lots of companies have local emergency numbers (911 and 3333 were mentioned). As far as I know, nobody complains if that local emergency number dials the police department. Please tell me which rule is being violated here? > > Mike Pierce > Artel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 22:47:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06153 for ; Thu, 9 Jan 2003 22:47:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A3xgK17198 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 22:59:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A3xfJ17195 for ; Thu, 9 Jan 2003 22:59:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06126 for ; Thu, 9 Jan 2003 22:47:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A3wPJ17148; Thu, 9 Jan 2003 22:58:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A3vHJ17107 for ; Thu, 9 Jan 2003 22:57:17 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06085 for ; Thu, 9 Jan 2003 22:44:46 -0500 (EST) Received: from cs.columbia.edu ([12.92.113.231]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030110034802.EDKU9286.mtiwmhc11.worldnet.att.net@cs.columbia.edu>; Fri, 10 Jan 2003 03:48:02 +0000 Message-ID: <3E1E41DF.6040403@cs.columbia.edu> Date: Thu, 09 Jan 2003 22:45:35 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Rosen, Brian'" , "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <15A2739B7DAA624D8091C65981D7DA815EB511@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are probably three slightly different dial-plan issues to deal with: (1) Extensions within a domain. The domain is likely defined by the outbound proxy server, so translating those into E.164 tel: URIs or SIP URIs (with E.164 user part) doesn't seem to cause undue problems. (2) General local numbers, as in 456-7890 in the US. Again, for a corporate network with an outbound proxy server in the same location as the person dialing, this is well-defined. (3) Service numbers, like 911 and 411. I'm not implying that (1) and (2) should use tel: URIs without phone-context. (3) was somewhat more open since the context is a bit iffier. If 3GPP, say, designates 911 as a universal emergency number, it can't really have a (national prefix) context. Even if you translate the digit string dialed to a tel: URI at the UA, you still need to get the regexp to the user, so that the UI can distinguish between things that should be come tel: URIs without phone-context and those that should get one or to add any of the missing digits. There are only three possible ways: - from the home domain, using the yet-to-be-finalized SIP configuration work; - via DHCP - via some kind of "ask the outbound proxy" mechanism. Since the outbound proxy needs to translate the tel: URIs, the third option seems like a good candidate. However, since the idea is to translate to global at the UA, even the home domain version would work, except that it would always have to generate a global tel: URI, not something with a phone-context. As a side note, one may want to support local SIP 'dialing strings' as well, so that I can type 'alice' instead of 'sip:alice@example.com'. One could return this, directly or via content-indirection, in an OPTIONS response addressed to sip:outbound.proxy.net. Peterson, Jon wrote: > I feel pretty strongly that phone numbers should be converted into > fully-qualified E.164 numbers at the originating user agent. It is very > problematic, outside of an architecture that is constrained in a way that we > are unlikely to standardize, for a proxy server to figure out the context in > which a set of arbitrary digits were dialed. Of course, if you're dialing a > number that cannot be converted to E.164, then it needs to be sent as-is. > > This design decision has come up previously in the SIP-T work and in the tel > URL work. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 9 23:27:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06917 for ; Thu, 9 Jan 2003 23:27:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A4det19995 for sipping-archive@odin.ietf.org; Thu, 9 Jan 2003 23:39:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4deJ19992 for ; Thu, 9 Jan 2003 23:39:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06912 for ; Thu, 9 Jan 2003 23:26:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4cGJ19966; Thu, 9 Jan 2003 23:38:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A4bBJ19583 for ; Thu, 9 Jan 2003 23:37:11 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06866 for ; Thu, 9 Jan 2003 23:24:38 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0A4Rd0E001295; Thu, 9 Jan 2003 20:27:39 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AAJ90618; Thu, 9 Jan 2003 20:27:38 -0800 (PST) From: "Cullen Jennings" To: "Adam Roach" , "'Henning Schulzrinne'" , "Rosen, Brian" Cc: "'Paul Kyzivat'" , Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 9 Jan 2003 20:32:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <9BF66EBF6BEFD942915B4D4D45C051F3A643F9@DYN-TX-EXCH-001.dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'd really love to agree with you but I suspect that several vendor's marketing departments will consider it a "feature" not to have to hit send. They will continue to use regular expressions of the MGCP digit map kind combined with timers to decide when to send the INVITE. When the phone sends and INVITE is an orthogonal issue from if the INVITE contains the dialed digits or an E.164 number. When designing systems it sure would be easier if every phone had a single globally unique number but this is simply not plausible because the PSTN address space has been constructed to be a scarce, and thus somewhat expense, resource. I still think it should be possible, and well worth while, to figure out some common normalized form that can represent E.164 number and phones without an E.164 number. It may be nothing more than a number with a + before it is an E.164 number and other numbers are a digit string that is interpreted purely in a context that is known to the proxy that controls the domain of the AOR of the UAC. Cullen > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of > Adam Roach > Sent: Thursday, January 09, 2003 8:26 AM > To: 'Henning Schulzrinne'; Rosen, Brian > Cc: 'Paul Kyzivat'; 'sipping@ietf.org' > Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > > - Recognizing patterns so that one can keep the old > > "no-need-to-hit-dial" user interface. > > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! > > No! > > Cell phones have sufficiently trained the public that it's > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER" > after a phone number. It makes life so much easier for user > interface designers and users alike. For the love of all that > is good, let's not encourage backsliding. > > /a > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 10 00:47:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08329 for ; Fri, 10 Jan 2003 00:47:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A5x2Y23581 for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 00:59:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A5x2J23577 for ; Fri, 10 Jan 2003 00:59:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08322 for ; Fri, 10 Jan 2003 00:46:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A5w5J23557; Fri, 10 Jan 2003 00:58:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A5vMJ23510 for ; Fri, 10 Jan 2003 00:57:22 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08296 for ; Fri, 10 Jan 2003 00:44:48 -0500 (EST) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h0A5Loa27574 for ; Fri, 10 Jan 2003 10:51:50 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CAA.001F6E54 ; Fri, 10 Jan 2003 11:13:18 +0530 X-Lotus-FromDomain: HSSBLR To: sipping@ietf.org Message-ID: <65256CAA.001F6D1D.00@sampark.hss.hns.com> Date: Fri, 10 Jan 2003 11:13:02 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi , I have a fundamental question on the the usage of SIP for transporting TCAP messages. If I understand correctly the figure 1 in the draft, is something like the following: SIP Element Signaling Gateway SS7 Node TCAP applications PSTN Services TCAP TCAP SIP---------------------IP--------------SIP||SS7--------------SS7---------- -----SS7 Here a TCAP peer will be running on the SIP Element and will use SIP to exchange TCAP messages with peers(i.e other TCAPs) in the PSTN network. However, SIGTRAN protocols defined also by the SIGTRAN Working group of the IETF have been especially designed for transporting Trunk/Access signaling over IP. So, could one not better(IMO) accomplish this by the following configuration using SIGTRAN? SIP Element Signaling Gateway PSTN Node TCAP applications PSTN Services TCAP TCAP SIGTRAN---------IP-------------SIGTRAN||SS7 ----------------SS7--------SS7 (SUA over SCTP) (SUA over SCTP) The difference of course is that in this case the SIP Element and the Signaling Gateway will have to (also) support SIGTRAN. They could continue to support SIP as well. Or am i missing something? thanks harsh This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 10 01:42:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08988 for ; Fri, 10 Jan 2003 01:42:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A6sD627139 for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 01:54:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A6sDJ27136 for ; Fri, 10 Jan 2003 01:54:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08982 for ; Fri, 10 Jan 2003 01:41:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A6rJJ27088; Fri, 10 Jan 2003 01:53:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A6qqJ27046 for ; Fri, 10 Jan 2003 01:52:52 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08970 for ; Fri, 10 Jan 2003 01:40:15 -0500 (EST) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h0A6HNa27962 for ; Fri, 10 Jan 2003 11:47:23 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CAA.002486C7 ; Fri, 10 Jan 2003 12:08:57 +0530 X-Lotus-FromDomain: HSSBLR To: sipping@ietf.org Message-ID: <65256CAA.0024865B.00@sampark.hss.hns.com> Date: Fri, 10 Jan 2003 12:08:55 +0530 Subject: Re: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , sorry,text corrected in the following mail. hbhondwe@hss.hns.com on 01/10/2003 11:13:02 AM To: sipping@ietf.org cc: (bcc: Harsh Bhondwe/HSSBLR) Subject: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt Hi , I have a fundamental question on the the usage of SIP for transporting TCAP messages. If I understand correctly the figure 1 in the draft, is something like the following: SIP Element Signaling Gateway SS7 Node TCAP applications PSTN Services TCAP TCAP SIP--------IP----------SIP||SS7--------SS7------SS7 Here a TCAP peer will be running on the SIP Element and will use SIP to exchange TCAP messages with peers(i.e other TCAPs) in the PSTN network. However, SIGTRAN protocols defined also by the SIGTRAN Working group of the IETF have been especially designed for transporting Trunk/Access signaling over IP. So, could one not better accomplish this by the following configuration using SIGTRAN? SIP Element Signaling Gateway PSTN Node TCAP applications PSTN Services TCAP TCAP SIGTRAN---------IP-------------SIGTRAN||SS7 ---SS7-----SS7 (SUA over SCTP) (SUA over SCTP) The difference of course is that in this case the SIP Element and the Signaling Gateway will have to (also) support SIGTRAN.They could continue to support SIP as well. Or am i missing something? thanks harsh _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 10 02:13:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19343 for ; Fri, 10 Jan 2003 02:13:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A7PkI05017 for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 02:25:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A7PjJ05014 for ; Fri, 10 Jan 2003 02:25:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19327 for ; Fri, 10 Jan 2003 02:12:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A7OWJ04923; Fri, 10 Jan 2003 02:24:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09BqdJ17026 for ; Thu, 9 Jan 2003 06:52:39 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07208 for ; Thu, 9 Jan 2003 06:40:26 -0500 (EST) Received: from w07087a (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8G00KUI362BL@mta0.huawei.com> for sipping@ietf.org; Thu, 09 Jan 2003 19:42:03 +0800 (CST) Date: Thu, 09 Jan 2003 19:44:48 +0800 From: wenkai To: sipping@ietf.org Message-id: <000c01c2b7d4$83a036a0$af064d0a@w07087a> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_RLquw50LCqUi3x3SciZZRw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Sipping] a question about 3pcc Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_RLquw50LCqUi3x3SciZZRw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi, The following is the "Mid-Call Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". After hanging up with the media server, the controller reconnects the Pre-Paid user to the called party. I think the media stream(stream 3) established between Pre-Paid user and the Called Party maybe is not the same as the original media stream(stream 1). In practice, maybe we want to have the same media codec as original one when we restore a call. Could you please give the call flow to reach this requirment? Best Regards Kevin Pre-Paid User Controller Called Party Media Server | | | | |..........stream 1.....................| | | |(1) INV SDP c=0 | | | |------------------>| | | |(2) 200 answer1 | | | |<------------------| | | |(3) ACK | | | |------------------>| | |(4) INV no SDP | | | |<------------------| | | |(5) 200 offer2 | | | |------------------>| | | | |(6) INV offer2 | | | |-------------------------------------->| | |(7) 200 answer2 | | | |<--------------------------------------| |(8) ACK answer2 | | | |<------------------| | | | |(9) ACK | | | |-------------------------------------->| |(10) RTP | | | |..........stream 2.........................................| | |(11) BYE | | | |-------------------------------------->| | |(12) 200 OK | | | |<--------------------------------------| | |(13) INV no SDP | | | |------------------>| | | |(14) 200 offer3 | | | |<------------------| | |(15) INV offer3' | | | |<------------------| | | |(16) 200 answer3' | | | |------------------>| | | | |(17) ACK answer3' | | | |------------------>| | |(18) ACK | | | |<------------------| | | |(19) RTP | | | |..........stream 3.....................| | --Boundary_(ID_RLquw50LCqUi3x3SciZZRw) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hi,
The following is the "Mid-Call Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt".
After hanging up with the media server, the controller reconnects the Pre-Paid user to the called party. I think the media stream(stream 3) established between Pre-Paid user and the Called Party maybe is not the same as the original media stream(stream 1).
In practice, maybe we want to have the same media codec as original one when we restore a call.
Could you please give the call flow to reach this requirment?
 
Best Regards
Kevin
 
 
     Pre-Paid User        Controller         Called Party        Media Server
          |                   |                   |                   |
          |..........stream 1.....................|                   |
          |                   |(1) INV SDP c=0    |                   |
          |                   |------------------>|                   |
          |                   |(2) 200 answer1    |                   |
          |                   |<------------------|                   |
          |                   |(3) ACK            |                   |
          |                   |------------------>|                   |
          |(4) INV no SDP     |                   |                   |
          |<------------------|                   |                   |
          |(5) 200 offer2     |                   |                   |
          |------------------>|                   |                   |
          |                   |(6) INV offer2     |                   |
          |                   |-------------------------------------->|
          |                   |(7) 200 answer2    |                   |
          |                   |<--------------------------------------|
          |(8) ACK answer2    |                   |                   |
          |<------------------|                   |                   |
          |                   |(9) ACK            |                   |
          |                   |-------------------------------------->|
          |(10) RTP           |                   |                   |
          |..........stream 2.........................................|
          |                   |(11) BYE           |                   |
          |                   |-------------------------------------->|
          |                   |(12) 200 OK        |                   |
          |                   |<--------------------------------------|
          |                   |(13) INV no SDP    |                   |
          |                   |------------------>|                   |
          |                   |(14) 200 offer3    |                   |
          |                   |<------------------|                   |
          |(15) INV offer3'   |                   |                   |
          |<------------------|                   |                   |
          |(16) 200 answer3'  |                   |                   |
          |------------------>|                   |                   |
          |                   |(17) ACK answer3'  |                   |
          |                   |------------------>|                   |
          |(18) ACK           |                   |                   |
          |<------------------|                   |                   |
          |(19) RTP           |                   |                   |
          |..........stream 3.....................|                   |
--Boundary_(ID_RLquw50LCqUi3x3SciZZRw)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 10 08:27:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27502 for ; Fri, 10 Jan 2003 08:27:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ADdRO31649 for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 08:39:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADdRJ31646 for ; Fri, 10 Jan 2003 08:39:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27458 for ; Fri, 10 Jan 2003 08:25:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADbWJ31531; Fri, 10 Jan 2003 08:37:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADapJ30803 for ; Fri, 10 Jan 2003 08:36:51 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27434 for ; Fri, 10 Jan 2003 08:24:08 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00061; Fri, 10 Jan 2003 08:27:24 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22774; Fri, 10 Jan 2003 08:27:22 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Jan 2003 08:27:21 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Adam Roach Cc: "Rosen, Brian" , "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Fri, 10 Jan 2003 08:27:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Actually, I'm happy with a "Dial" button. I'll note most existing SIP phones don't do this (or at least don't have a physical "Dial" button, I've seen some with softkeys). However, the issue remains. If I dial 6744 on my sip phone (and press dial), the sipphone on my admin's desk should ring. I should not have to dial +17247426744. The fact that I dialed a 4 digit number with a 6 as the starting digit tells my system that it is an internal extension. A dial plan is the thing that "knows" this. What do you want to have happen: 1) tel:6744; context=+1724742 2) tel:6744; context=marconi-pittsburgh-local-extension 3) tel:+17247426744 Note the last is problematic. As Mike Pierce points out, not all extensions have E.164s And, to amplify the thread that started this, how many identities does my admin's UA have to understand? Again, I'm not opposed to making dial string expansion be a requirement of the UA, as long as we standardize the form of the expansion, and the mechanism by which the UA learns it. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, January 09, 2003 9:07 PM > To: Adam Roach > Cc: Rosen, Brian; 'Paul Kyzivat'; 'sipping@ietf.org' > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do > Proxies map? was > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > In case there's doubt: I was not suggesting that we do this. I was > trying to find out from Brian what he meant, since the two > problem have > very different solution sets. The 'abbreviated dialing' case requires > nothing except a suitable URI scheme and the translation > services of an > outbound proxy. > > Adam Roach wrote: > >>- Recognizing patterns so that one can keep the old > >>"no-need-to-hit-dial" user interface. > > > > > > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! > > > > No! > > > > Cell phones have sufficiently trained the public that it's > > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER" > > after a phone number. It makes life so much easier for user > > interface designers and users alike. For the love of all that > > is good, let's not encourage backsliding. > > > > /a > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 10 08:29:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27579 for ; Fri, 10 Jan 2003 08:29:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ADfQk31767 for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 08:41:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADfQJ31764 for ; Fri, 10 Jan 2003 08:41:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27565 for ; Fri, 10 Jan 2003 08:28:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADbLJ31369; Fri, 10 Jan 2003 08:37:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ADa7J30759 for ; Fri, 10 Jan 2003 08:36:07 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27421 for ; Fri, 10 Jan 2003 08:23:24 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00025; Fri, 10 Jan 2003 08:26:40 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22512; Fri, 10 Jan 2003 08:26:41 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Jan 2003 08:26:40 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Fri, 10 Jan 2003 08:26:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Nope you have the wrong picture. See below > I may have been a little thick up to this point - I now think that by > 'gateway' you mean something that acts like a PBX (I was kind > of thinking > you meant a PSTN gateway, which has very different > requirement for all of > this). From the notes below, it sounds like in your case the > PBX is a SIP UA > that has a set of hardwired phone lines (your 'ports'), each > of which goes > to a single black phone. No we have a set of gateways, that are SIP UAs, that are connected to either a PSTN local loop (which may be an analog loop, DID trunk, a BRI, PRI or CAS trunk, or to a PBX station loop, which may be analog or digital, or in some cases a PRI connected to a PBX. These gateways provide the path for call. In the former case, the site has an all-VoIP phone system, and the gateways are the connection to the PSTN. In the latter case, there is a local PBX, but there is also a set of VoIP stations. The gateways provide the link between these systems. There are gateways that connect to phones, but this discussion is not about them. >You want a proxy server to manage > the mappings of > identifiers (be they tel URLs or SIP URIs) to particular PBXs > and PBX ports, > because you want the PBXs themselves to be ignorant of the URIs that > identify the phones that they manage. Is that right? No, we want the proxy server to manage the mappings because the sip identities in the sip phones are people with real sip URIs (like alice@atlanta.com) and not tel uris. However, each of the sip uris ALSO has a telephone number. If you call alice with either sip:alice@atlanta.com or tel:+14125551212, or +14125551212 on the PSTN, the call will go to Alice's sipphone. The problem is that alice has two uris (one is a tel uri), and we don't want to have all the UAs registering twice under both identities. Instead, we have a proxy server that understands the mapping. > > Ordinarily, we say that in SIP architectures, features are > pushed to the > edges, not to the core of the network. Abstract out the PBX > for a minute, > and imagine coming forward with a SIP architecture in which > you have a set > of user agents that are so simple that they don't know their > own identity, > they can't learn it somehow from the network, and therefore > cannot correctly > populate the From header field of requests they generate. > Instead, they'd > like a proxy server to somehow populate this identity in > requests as they > are sent through the network. This would be essentially the > same problem you > brought to the list. No the problem is that they have two identities, one of which they "know", and we want them to be able to be reached by any (there could be more than two) of these identities. The relationship between the identities is in a centralized (well, actually it's distributed, replicated) database. > > My reaction would probably be that RFC3261 assumes that SIP > UAs have the > ability to populate a From header field. Even my 1G CDMA cell > phone knows > its own phone number. A PBX usually means something with a > lot of features. > Even if in your architecture you're trying to radically > reduce the cost of > the PBX component, a PBX can be expected to more be complex > than, say, the > sorts of simple SIP phones we see today (which are in my > experience all > capable of mananging one identity, if not several, for their > users). Is it > really that much harder for a PBX to look at the string > 'port3' in the R-U > of a SIP request and map that to a hardware resource than it > is for a PBX to > look at the string '+12025332600' in the R-U of a SIP request > and map that > to a hardware resource? PBXs that are compliant SIP > implementations will > have to perform a number of vastly more complicated operations. Actually, I know of no sip UAs that handle multiple identities. I don't have direct experience with 3G phones, so they might. We have a half dozen sip phones, a half dozen soft phones, probably 10 different vendors of gateways and they all have the same characteristic that they only have one identity at a time. > > In other words, it's hard for me to understand why the PBX UA > (the edge) > isn't the right place to manage the mapping between an > identifier (a phone > number) and a port. Doing this in a proxy (the core) > introduces a number of > data synchronization questions as well as the protocol > questions that have > run through this thread. Is there some special reason why > this PBX cannot be > expected to do one of the simpler things that we ask of UAs? > Is there a > particularly large number of ports that you imagine such a > PBX would manage > (in the millions, maybe)? It would really help to have more > background. The > motivation for this is a little obscure to me. Small gateways are pretty simple. There are between 1 and maybe 24 ports, each of which is a one line/loop connection, like an analog loop. Big gateways in this context handle 1-8 PRIs. Each of the PRIs has blocks of directory numbers assigned to it. There are the usual issues with assigning numbers to "phones" (I used quotes, because it's actually users; we assign a number to a user, not to a phone) = multiple "phones" can be assigned to one number, multiple numbers can be assigned to one "phone". There are no gateways I know of that understand how to do this, although a SIP proxy servers could use the Single Line Extension and forking proxy mechanisms to simulate it. The point here is that it's the PROXY that does the work, not the UA. If we want to mandate that all sip UAs must handle multiple identities, and standardize a way that it learns all the identities associated with any one of them, then we probably can avoid dealing with my "translator". Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 10 16:46:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17362 for ; Fri, 10 Jan 2003 16:46:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ALxJP32213 for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 16:59:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALxJJ32210 for ; Fri, 10 Jan 2003 16:59:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17355 for ; Fri, 10 Jan 2003 16:46:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALwbJ32195; Fri, 10 Jan 2003 16:58:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALvdJ32162 for ; Fri, 10 Jan 2003 16:57:39 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17329 for ; Fri, 10 Jan 2003 16:44:46 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18X70T-00067r-00; Fri, 10 Jan 2003 23:48:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15903.16273.453205.50103@harjus.eng.song.fi> Date: Fri, 10 Jan 2003 23:48:01 +0200 To: "Rosen, Brian" Cc: "'Peterson, Jon'" , "'Drage, Keith (Keith)'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian writes: > Actually, I know of no sip UAs that handle multiple identities. on my desj i have cisco 7960 that understands lots of different identities. on my pc i have kphone that understand any number of identities. these can be phone numbers of email style sip uris. in addition, in my proxy a user can have any number of aliases for itself. thus i don't really see what the problem is. > We have a half dozen sip phones, a half dozen soft phones, > probably 10 different vendors of gateways and they all have the > same characteristic that they only have one identity at a time. looks you haven't got any good one. keep on shopping and junk the junk. the same for your proxy and pstn gw. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 10 17:52:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19100 for ; Fri, 10 Jan 2003 17:52:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AN4bY04192 for sipping-archive@odin.ietf.org; Fri, 10 Jan 2003 18:04:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AN4bJ04189 for ; Fri, 10 Jan 2003 18:04:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19091 for ; Fri, 10 Jan 2003 17:51:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AN3EJ04149; Fri, 10 Jan 2003 18:03:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AN2XJ04119 for ; Fri, 10 Jan 2003 18:02:33 -0500 Received: from mail.pingtel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19063 for ; Fri, 10 Jan 2003 17:49:38 -0500 (EST) Received: from pingtel.com (cdhcp144.pingtel.com [10.1.1.144]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h0AMqkR03511; Fri, 10 Jan 2003 17:52:46 -0500 Message-ID: <3E1F4E91.C2F22A30@pingtel.com> Date: Fri, 10 Jan 2003 17:52:01 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Henning Schulzrinne'" , Adam Roach , "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is actually a third reason to have dial plans on the UA. The first two have already been brought up: 1) To know when the user is done dialing 2) To know how to form a canonical URL (tel , sip or sips) 3) To know how to route the INVITE to the correct outbound proxy On the first one, knowing when the user is done dialing, I am afraid, as Cullen pointed out, the market (at least in North America) wants a phone that knows when the user is done dialing. There are too many people who still like the pre-cell phone metaphor. Sorry but the people on this list do not buy enough phones to decide this one ;-). The UA needs to know how it is going to form a cannonical URL from the mess of characters and digits the user entered. So as Brian pointed out you need some regexp to transform the entered characters into a URL. Well guess what, every proxy vendor wants this to be a little different. Some want short strings (AKA extensions) transformed differently than long strings (AKA E.164 numbers). So call it what you want you end up with the equivalent of a dial plan. The best we can do here is to come of with a standardized (or call it BCP) way to write the transforms. We can write a standard that says this is the one and only transform, but no phone vendor that has a dial plan mechanism will be able to drop their dial plan support because they have customers using it. However I am sure the market would be happy to push vendors to support a standardized dial plan description mechanism. The third use of dial plans is for routing purposes. I know! That is what the proxy is supposed to do. However there are several uses for doing some simple routing from the phone base upon the "dialed string": a) Functional routing: where based upon the purpose of the call the user wants the call routed differently. For example I have a phone at home from which I make personal calls via my favorite service provider and from which I make business calls via my enterprise IP PBX. I want my private/personal calls private and my business does not want to pay for my personal calls. A simple, familiar metaphor for this is to use a dialing prefix (e.g. dial 9 and number for business call, dial 8 and number for personal calls). The alternatives would be to sell home/office users two phones (I wish that would fly) or put a proxy in every home/office (I would not mind selling that many proxies if that would fly as well). b) Load balancing routing: based upon my dialed string I may want to use a different out bound proxy. Domestic US calls go to one proxy, international calls go to another, 911/emergency calls go directly to the local emergency gateway. Can this be done by the proxy? Sometimes, if I can get to it, but once you have a dial plan on the phone, this is just about free from both an implementation and compute cost perspective (e.g. loose routing with a Route header in the regexp/transform). I am happy to remove functionality from the UA and not support it, but I am afraid the dial plan is here to stay in the UA. I think our best path forward is with a standard way to specify the dial plan transforms. "Rosen, Brian" wrote: > Actually, I'm happy with a "Dial" button. > > I'll note most existing SIP phones don't do this (or at least don't > have a physical "Dial" button, I've seen some with softkeys). > > However, the issue remains. If I dial 6744 on my sip phone (and press > dial), the sipphone on my admin's desk should ring. I should not have > to dial +17247426744. The fact that I dialed a 4 digit number with > a 6 as the starting digit tells my system that it is an internal > extension. A dial plan is the thing that "knows" this. > > What do you want to have happen: > 1) tel:6744; context=+1724742 > 2) tel:6744; context=marconi-pittsburgh-local-extension > 3) tel:+17247426744 > > Note the last is problematic. As Mike Pierce points out, not all > extensions have E.164s > > And, to amplify the thread that started this, how many identities does > my admin's UA have to understand? > > Again, I'm not opposed to making dial string expansion be a requirement > of the UA, as long as we standardize the form of the expansion, and the > mechanism by which the UA learns it. > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, January 09, 2003 9:07 PM > > To: Adam Roach > > Cc: Rosen, Brian; 'Paul Kyzivat'; 'sipping@ietf.org' > > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do > > Proxies map? was > > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > > > > In case there's doubt: I was not suggesting that we do this. I was > > trying to find out from Brian what he meant, since the two > > problem have > > very different solution sets. The 'abbreviated dialing' case requires > > nothing except a suitable URI scheme and the translation > > services of an > > outbound proxy. > > > > Adam Roach wrote: > > >>- Recognizing patterns so that one can keep the old > > >>"no-need-to-hit-dial" user interface. > > > > > > > > > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! > > > > > > No! > > > > > > Cell phones have sufficiently trained the public that it's > > > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER" > > > after a phone number. It makes life so much easier for user > > > interface designers and users alike. For the love of all that > > > is good, let's not encourage backsliding. > > > > > > /a > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 11 10:39:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13428 for ; Sat, 11 Jan 2003 10:39:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BFqfi27968 for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 10:52:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFqeJ27965 for ; Sat, 11 Jan 2003 10:52:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13403 for ; Sat, 11 Jan 2003 10:39:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFppJ27924; Sat, 11 Jan 2003 10:51:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFoVJ27883 for ; Sat, 11 Jan 2003 10:50:31 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13374 for ; Sat, 11 Jan 2003 10:37:16 -0500 (EST) Received: from cs.columbia.edu (dclient13.netlab.uky.edu [204.198.76.127]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BFeYSY003162 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 11 Jan 2003 10:40:34 -0500 (EST) Message-ID: <3E1F2D76.3000500@cs.columbia.edu> Date: Fri, 10 Jan 2003 15:30:46 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Tom-PT Taylor'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Comments on sos draft -0 References: <475FF955A05DD411980D00508B6D5FB00439EB8F@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Is the number 3333 on an internal network an emergency number in the > terms of the sos draft? > > The way I read the defined sos url is that it only reachs public > emergency service centres. therefore the scope of the document with > regard to tel urls is to define the format of tel urls to reach those > same centres. Have I misunderstood the scope? We possible need to > extend Hennings proposed scope to make this clear. Interesting question. I think the boundaries are kind of fuzzy. For example, most US universities have a campus police department; some even have a campus ambulance and fire department (UMass Amherst did, for example). If they are a state university, they are even public institutions. In some cases, they have separate identifiers from the public 911 system (99 on the Columbia campus), but they are otherwise indistinguishable from an ECC. One solution might be to allow this as a qualification to 'sos', as in 'sos.internal' or 'sos.private'. > > I do think we need to delve further into the subject of context, > possible in association with additional clarifications in the > rfc2806bis draft. Agreed; in general, 'service numbers' are one of the major open issues for that draft. > It therefore seems to me that we could say the same about emergency > numbers that are globally unique. I assume, globally unique here means that they are not assigned for another purpose (extensions don't count). For 800#, we agreed after a long debate that the assignment system guarantees that the same number will not be assigned to two logically separate entities. It would be nice if we could get all national regulators to agree that assigning 911 to directory services would be a really dumb idea. I suspect that with 3GPP standardization, that this would be extremely unlikely. We know that none of the emergency numbers on the list could be assigned in the US since these are valid area codes, not N11 codes. > > For those emergency numbers that are not globally unique (and we > probably need to include 118 and 119 in this list), then looking at > the existing RFC 2806 or at the bis, they probably do need a context. > What worries me is that the user sticks in an inappropriate context, > i.e. the one he uses for all his local calls, rather than one used > for national calls. Such inappropriate usage would cause calls to > fail. Would a special context used only for local service numbers be > appropriate here? My thinking here is that if we give the user > something real to code, then he will not be tempted to code something > inappropriate. The problem is that 118 can mean two different things. I don't see how a 'use whatever local context applies here' would help with distinguishing 118 - I mean emergency service and 118 - I mean (Finnish) directory services If we effectively standardize dial strings, it seems unnecessary to have the UA propagate the original number as a tel URI. One possible algorithm: - If digits dialed = one of the emergency dial strings (preconfigured or locally learned) --> generate 'sos' request - Otherwise, make local dial-string translation translate this into one of: . tel:+something global string . tel:digits;phone-context=local-context where the translation would include something like 9### -> tel:number;phone-context=+1 for national service numbers. This could all be expressed through the same set of regexps, as in 911 -> sip:sos@example.com 112 -> sip:sos@example.com 3333 -> sip:sos.private@example.com (Being offline, I don't have my Megaco dial string reference handy.) Thus, maybe we can unify the local advertisement of dial strings with the local advertisement of emergency numbers. By virtue of the translation to 'sos', the UA can readily recognize that this is an emergency number. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 11 10:39:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13441 for ; Sat, 11 Jan 2003 10:39:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BFqgj27983 for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 10:52:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFqgJ27980 for ; Sat, 11 Jan 2003 10:52:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13407 for ; Sat, 11 Jan 2003 10:39:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFpwJ27948; Sat, 11 Jan 2003 10:51:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFoWJ27887 for ; Sat, 11 Jan 2003 10:50:32 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13377 for ; Sat, 11 Jan 2003 10:37:18 -0500 (EST) Received: from cs.columbia.edu (dclient13.netlab.uky.edu [204.198.76.127]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BFeaXZ005183 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 11 Jan 2003 10:40:36 -0500 (EST) Message-ID: <3E1F3CDC.2080706@cs.columbia.edu> Date: Fri, 10 Jan 2003 16:36:28 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Comments on sos draft -03 (URI) References: <475FF955A05DD411980D00508B6D5FB00439EB90@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Firstly I note that the requirement already was only a SHOULD rather > than a MUST. In the case where SHOULD is used I usually prefer to > specify some examples of where the SHOULD does not apply as guidance, > and this appeared to be the appropriate one. > I am not convinced by the argument; that may be answered by what do > we expect the UA to do if the OPTIONS request it sends to the tel url > it has been given fails? If the user dials that tel url, does the UA > continue to treat such a call as an emergency call, or does it flash > a message on the users display saying "I don't know what to do with > this"? There are only two choices: try again and hope that it works (maybe because somebody botched the OPTIONS implementation) or fail without trying. I suspect the robust solution is: - if OPTIONS doesn't work, warn the user that emergency calls for numbers X and Y may not work (but Z seems to). This will cause any failures to be discovered early, rather than at the time of emergency. One of the problems with the existing corporate emergency number systems is that I have no good way to "non-invasive" testing. The OPTIONS approach fixes this. 'Ping' has been a very useful network debugging tool - consider this the SIP equivalent. In the translation model I posited in my earlier note, all numbers would be translated to sos@. - if the user still tries to dial those numbers, I guess there's no harm in trying. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 11 11:01:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13805 for ; Sat, 11 Jan 2003 11:01:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BGE2N29165 for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 11:14:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGE2J29162 for ; Sat, 11 Jan 2003 11:14:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13793 for ; Sat, 11 Jan 2003 11:00:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGD9J29129; Sat, 11 Jan 2003 11:13:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGC4J29099 for ; Sat, 11 Jan 2003 11:12:04 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13767 for ; Sat, 11 Jan 2003 10:58:49 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BG26SY008672 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 11 Jan 2003 11:02:07 -0500 (EST) Message-ID: <3E204003.6060809@cs.columbia.edu> Date: Sat, 11 Jan 2003 11:02:11 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] URIs for Gateways References: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5CE2@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > 1. We add the possibility of a callerId string to a tel uri: > telephone-uri = "tel:" [callerIdName LWS] subscriber > callerIdName = quoted-string LWS and quoted strings are not exactly the right syntactic approach for tel URIs. Something like a tel URI parameter is much more likely to work (and be backwards compatible). > > 2. Gateways accept or send sip uris of the form: > sip:"Alice Toklas" 4125551212@gateway.atlanta.com; user=phone; port=3 > or tel uris of the form: > tel:"Alice Toklas" +14125551212; port=3 None of these are valid URIs... > or "ordinary" sip uri's with extra information in a separate header > of the form: >
+14125551212; port=3 > > where
could be "P-Asserted-Identity", or it could be a new > header we define for the purpose. > > Then, we have the following possibilities: > > SIP device to gateway (outgoing) call > To a phone number > use the phone number in the Request-URI & To:, probably > in a tel URI, or maybe phonenumber@localdomain; user=phone > > use normal sip URI in From: > > If a translator is available, it may assert the phone number > for the identity in the From: using
> > proxy may rewrite the Request-URI in the form of > sip: phone@gateway;user=phone;port=portnum > > To a sip URI > use the sip uri in the Request-URI and To: > use normal sip URI in From: > > proxy rewrites Request-URI, due to forwarding behavior, > ENUM lookup, etc, resulting in a tel URI or a user=phone sip > uri. If necessary, a local incoming proxy can rewrite it to > add the port parameter to the Request-URI based on the From: > > If a translator is available, it may assert the phone number > for the identity in the From: using the
> > Gateway to SIP device (incoming call) > With mapping > use the mapped uri in the Request-URI & To: > > (optionally) supply called number using
> This might be needed when multiple called numbers > map to the same uri. > > use sip:"callerId" phone@gateway; port=portnum or > a tel: uri in From: > > Without mapping > use a provisioned (per port) URI, a tel uri with the called > number, or a sip uri with calledNumber@localdomain; user=phone > in the Request-URI & To:. Gateways should support all 3, > choice should be made by provisioning. > > use sip:"callerId" phone@gateway; port=portnum or tel > uri in From: > > proxy will rewrite the Request-URI with the correct sip URI > associated with the called number > > Brian > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 11 11:36:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14155 for ; Sat, 11 Jan 2003 11:36:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BGmuA30658 for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 11:48:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGmuJ30655 for ; Sat, 11 Jan 2003 11:48:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14145 for ; Sat, 11 Jan 2003 11:35:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGmIJ30639; Sat, 11 Jan 2003 11:48:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGlLJ30599 for ; Sat, 11 Jan 2003 11:47:21 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14103 for ; Sat, 11 Jan 2003 11:34:05 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BGbNXZ019753 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 11 Jan 2003 11:37:24 -0500 (EST) Message-ID: <3E204849.8000308@cs.columbia.edu> Date: Sat, 11 Jan 2003 11:37:29 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel G. Petrie" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E1F4E91.C2F22A30@pingtel.com> In-Reply-To: <3E1F4E91.C2F22A30@pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Daniel G. Petrie wrote: > There is actually a third reason to have dial plans on the UA. The > first two have already been brought up: > > 1) To know when the user is done dialing 2) To know how to form a > canonical URL (tel , sip or sips) 3) To know how to route the INVITE > to the correct outbound proxy > I wrote up a five-minute skeleton of a proposal at http://www.cs.columbia.edu/sip/draft/dialplan/dialplan.txt so that we have something concrete to talk about, in the "provide text" spirit. Another syntactic rendition would follow the XML example of DML, as in draft-rosenberg-sipping-markup, as in xxxx sip:+1-859-555-\0@example.com DML itself doesn't quite seem to fit, given the need for substitution, but maybe it can be extended. > a) Functional routing: where based upon the purpose of the call the > user wants the call routed differently. For example I have a phone > at home from which I make personal calls via my favorite service > provider and from which I make business calls via my enterprise IP > PBX. I want my private/personal calls private and my business does > not want to pay for my personal calls. A simple, familiar metaphor > for this is to use a dialing prefix (e.g. dial 9 and number for > business call, dial 8 and number for personal calls). The > alternatives > > would be to sell home/office users two phones (I wish that would fly) > or put a proxy in every home/office (I would not mind selling that > many proxies if that would fly as well). This is roughly equivalent to the 'route' entries that we have for IPv4 routing on Unix and Windows machines. > > b) Load balancing routing: based upon my dialed string I may want to > use a different out bound proxy. Domestic US calls go to one proxy, > international calls go to another, 911/emergency calls go directly to > the local emergency gateway. Can this be done by the proxy? > Sometimes, if I can get to it, but once you have a dial plan on the > phone, this is just about free from both an implementation and > compute cost perspective (e.g. loose routing with a Route header in > the regexp/transform). > > I am happy to remove functionality from the UA and not support it, > but I am afraid the dial plan is here to stay in the UA. I think > our best path forward is with a standard way to specify the dial plan > transforms. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 11 11:38:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14205 for ; Sat, 11 Jan 2003 11:38:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BGpb330824 for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 11:51:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGpbJ30821 for ; Sat, 11 Jan 2003 11:51:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14197 for ; Sat, 11 Jan 2003 11:38:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGp6J30800; Sat, 11 Jan 2003 11:51:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BGoeJ30763 for ; Sat, 11 Jan 2003 11:50:40 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14179 for ; Sat, 11 Jan 2003 11:37:24 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BGegSY017581 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 11 Jan 2003 11:40:43 -0500 (EST) Message-ID: <3E204910.4090305@cs.columbia.edu> Date: Sat, 11 Jan 2003 11:40:48 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel G. Petrie" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E1F4E91.C2F22A30@pingtel.com> In-Reply-To: <3E1F4E91.C2F22A30@pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I should note that 'routing' functionality is implicit in the translation mechanism I proposed. I would prefer to call it a translation functionality, to avoid the notion that it has to be as rich as the proxy routing capabilities. I don't want to encode things like "Between 9 and 5, translate some-LD-number to @sprint.com, otherwise to @mci.com." Least-cost routing should not be part of the dialplan... (Obviously, nothing prevents a local admin from updating the dialplan accordingly.) > a) Functional routing: where based upon the purpose of the call the > user wants the call routed differently. For example I have a phone > at home from which I make personal calls via my favorite service > provider and from which I make business calls via my enterprise > IP PBX. I want my private/personal calls private and my business > does not want to pay for my personal calls. A simple, familiar > metaphor for this is to use a dialing prefix (e.g. dial 9 and number > for business call, dial 8 and number for personal calls). The alternatives > > would be to sell home/office users two phones (I wish that would fly) > or put a proxy in every home/office (I would not mind selling that > many proxies if that would fly as well). > > b) Load balancing routing: based upon my dialed string I may > want to use a different out bound proxy. Domestic US calls > go to one proxy, international calls go to another, 911/emergency > calls go directly to the local emergency gateway. Can this be > done by the proxy? Sometimes, if I can get to it, but once you > have a dial plan on the phone, this is just about free from > both an implementation and compute cost perspective (e.g. > loose routing with a Route header in the regexp/transform). > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 11 18:18:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20765 for ; Sat, 11 Jan 2003 18:18:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BNVOa18420 for sipping-archive@odin.ietf.org; Sat, 11 Jan 2003 18:31:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BNVNJ18417 for ; Sat, 11 Jan 2003 18:31:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20751 for ; Sat, 11 Jan 2003 18:17:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BNUYJ18389; Sat, 11 Jan 2003 18:30:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BNSHJ18347 for ; Sat, 11 Jan 2003 18:28:17 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20720 for ; Sat, 11 Jan 2003 18:14:52 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0BNHbjS005123; Sat, 11 Jan 2003 15:17:37 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AAK59354; Sat, 11 Jan 2003 15:18:11 -0800 (PST) From: "Cullen Jennings" To: "Rosen, Brian" Cc: Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Sat, 11 Jan 2003 15:22:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of > Rosen, Brian > > Again, I'm not opposed to making dial string expansion be a requirement > of the UA, as long as we standardize the form of the expansion, and the > mechanism by which the UA learns it. > I think this is a path worth exploring. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 13 03:30:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04290 for ; Mon, 13 Jan 2003 03:30:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D8iJw04520 for sipping-archive@odin.ietf.org; Mon, 13 Jan 2003 03:44:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8iJJ04517 for ; Mon, 13 Jan 2003 03:44:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04258 for ; Mon, 13 Jan 2003 03:30:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8hOJ04451; Mon, 13 Jan 2003 03:43:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8fCJ04369 for ; Mon, 13 Jan 2003 03:41:12 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04229 for ; Mon, 13 Jan 2003 03:27:09 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H8N00C018YDZR@siemenscomms.co.uk> for sipping@ietf.org; Mon, 13 Jan 2003 08:30:13 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H8N00BDB8YDYY@siemenscomms.co.uk>; Mon, 13 Jan 2003 08:30:13 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Jan 2003 08:30:26 +0000 Content-return: allowed Date: Mon, 13 Jan 2003 08:30:31 +0000 From: "Elwell, John" To: "'Mary Barnes'" , "'Mark Watson'" , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Mary and others, I don't want to open up the whole discussion we had a few weeks ago, but having read version 01 of the history requirements document I feel that we perhaps need to make an addition. Privacy requirements PRIV-req-1 and PRIV-req-2 both apply to information about the originator of the request (according to the preceding sentence). Privacy requirements of other users are not mentioned. I think they should be discussed in the document, even if the conclusion is that no additional requirements are placed on the solution. 1. Privacy requirements of the retargeted-to user. 1.1 This user may wish not to have his identity revealed to the originator. This, of course, can apply to any request, not just requests that have undergone retargeting. However, it is likely to be of greater relevance to a request that has been retargeted. A destination user can protect his privacy using RFC3323. It is important that the provisions of RFC3323 are not compromised as a result of retargeting. 2. Privacy requirements of the retargeting user. 2.1 This user may be unwilling to disclose to the originator the fact that retargeting has occurred 2.2 This user may be willing to disclose to the originator the fact that retargeting has occurred but unwilling to disclose to the originator the identity of the retargeted-to user. 2.3 This user may be unwilling to disclose to the retargeted-to user the fact that retargeting has occurred 2.4 This user may be willing to disclose to the retargeted-to user the fact that retargeting has occurred but unwilling to disclose to the retargeted-to user the identity of the previous target. NOTE. 2.3 and 2.4 are less convincing requirements, although I believe these requirements are supported in public ISDN. 2.5 The retargeting user can also be a retargeted-to user of a previous retarget. As such requirement 1.1 above can apply, i.e., the retargeting user (retargeted-to user of previous retarget) is unwilling to disclose his identity to the originating user. 2.6 The retargeting user has some of the characteristics of an originator if the request is retargeted again further downstream. As such PRIV-req-1 and PRIV-req-2 can apply to a retargeting user. Regards, John John Elwell e-mail: mailto:john.elwell@siemens.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 13 03:30:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04300 for ; Mon, 13 Jan 2003 03:30:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D8iK004536 for sipping-archive@odin.ietf.org; Mon, 13 Jan 2003 03:44:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8iJJ04533 for ; Mon, 13 Jan 2003 03:44:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04261 for ; Mon, 13 Jan 2003 03:30:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8hZJ04475; Mon, 13 Jan 2003 03:43:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D8fhJ04381 for ; Mon, 13 Jan 2003 03:41:43 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04238 for ; Mon, 13 Jan 2003 03:27:39 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H8N00D018Z805@siemenscomms.co.uk> for sipping@ietf.org; Mon, 13 Jan 2003 08:30:44 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H8N00BM38Z8M7@siemenscomms.co.uk>; Mon, 13 Jan 2003 08:30:44 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Jan 2003 08:30:57 +0000 Content-return: allowed Date: Mon, 13 Jan 2003 08:31:05 +0000 From: "Elwell, John" To: "'Mary Barnes'" , "'Mark Watson'" Cc: "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] History information in provisional responses Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Mary and others, In the solution draft, nothing is said about inclusion of history information in provisional responses. I am thinking in particular of 180. This might be of benefit to a human originator in particular. Although in many cases a proxy will retarget a request fairly quickly (e.g., if the target user has moved or is busy), it may be programmed to retarget only after alerting the target user for a certain time. If successful the retarget will result in a 180 response from the retargeted-to user and hopefully eventually a 200 response. This means the UAC could receive two (or more) 180 responses. If the second and subsequent 180 responses were to contain history information, this would give the originator an explanation of what is happening and may persuade the originator to allow the request to continue longer in order to give the retargeted-to user time to answer. Another possible advantage is that on seeing history information in a 180 the originator might decide not to establish a session with the retargeted-to user and might cancel the request immediately without waiting for answer. What are your thoughts on history information in provisional responses? Obviously it would need to be done in a way that does not compromise privacy requirements. Regards, John John Elwell e-mail: mailto:john.elwell@siemens.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 13 13:48:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19647 for ; Mon, 13 Jan 2003 13:48:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DJ2VV13870 for sipping-archive@odin.ietf.org; Mon, 13 Jan 2003 14:02:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ2VJ13867 for ; Mon, 13 Jan 2003 14:02:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19642 for ; Mon, 13 Jan 2003 13:48:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ1hJ13842; Mon, 13 Jan 2003 14:01:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ02J13775 for ; Mon, 13 Jan 2003 14:00:02 -0500 Received: from mail.pingtel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19597 for ; Mon, 13 Jan 2003 13:45:43 -0500 (EST) Received: from pingtel.com (cdhcp144.pingtel.com [10.1.1.144]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h0DImvR21890; Mon, 13 Jan 2003 13:48:58 -0500 Message-ID: <3E2309E6.D2F68E1E@pingtel.com> Date: Mon, 13 Jan 2003 13:48:07 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? wasRE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E1F4E91.C2F22A30@pingtel.com> <3E204849.8000308@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have a preference for the XML container for the digit maps, though either works for me. In either case I agree we should use the RFC 3015 style digit map representation as opposed to inventing another one. I would generalize the rfc 3015 syntax to handle non-DTMF characters as follows: "x" represents any single character (not just digits) "." represents any number of characters (not just digits) It also requires some sort of escaping mechanizm to be able to explicitly include "x", ".", "T", etc. in the digit map (e.g. \x, \., \T, etc.). Is the grouping by curly backet {} neccessary? There is implicitly a fixed and variable part of the dial plan. Why not just have a verbs that represents the entire or variable part of the dial plan? Any part of the fix part of the dial plan can easily be put back in the URL transform (e.g. 91xxxxxxxxxx tel:+\11 as opposed to 9{1xxxxxxxxxx} tel:+\1) Also just to be explicit I am assuming that the range (e.g. [1-6]) and or (e.g. 911|9911) constructs of the RFC 3015 are intended to be included, though not shown in your examples. I feel they at least SHOULD supported. Is there any reason to exclude other URL types in the transfrom that might result in non-SIP requests like HTTP? I am not sure this would make sense on all UAs, but it might on some. Henning Schulzrinne wrote: > Daniel G. Petrie wrote: > > There is actually a third reason to have dial plans on the UA. The > > first two have already been brought up: > > > > 1) To know when the user is done dialing 2) To know how to form a > > canonical URL (tel , sip or sips) 3) To know how to route the INVITE > > to the correct outbound proxy > > > > I wrote up a five-minute skeleton of a proposal at > http://www.cs.columbia.edu/sip/draft/dialplan/dialplan.txt so that we > have something concrete to talk about, in the "provide text" spirit. > > Another syntactic rendition would follow the XML example of DML, as in > draft-rosenberg-sipping-markup, as in > > > xxxx > sip:+1-859-555-\0@example.com > > > DML itself doesn't quite seem to fit, given the need for substitution, > but maybe it can be extended. > > > a) Functional routing: where based upon the purpose of the call the > > user wants the call routed differently. For example I have a phone > > at home from which I make personal calls via my favorite service > > provider and from which I make business calls via my enterprise IP > > PBX. I want my private/personal calls private and my business does > > not want to pay for my personal calls. A simple, familiar metaphor > > for this is to use a dialing prefix (e.g. dial 9 and number for > > business call, dial 8 and number for personal calls). The > > alternatives > > > > would be to sell home/office users two phones (I wish that would fly) > > or put a proxy in every home/office (I would not mind selling that > > many proxies if that would fly as well). > > This is roughly equivalent to the 'route' entries that we have for IPv4 > routing on Unix and Windows machines. > > > > > b) Load balancing routing: based upon my dialed string I may want to > > use a different out bound proxy. Domestic US calls go to one proxy, > > international calls go to another, 911/emergency calls go directly to > > the local emergency gateway. Can this be done by the proxy? > > Sometimes, if I can get to it, but once you have a dial plan on the > > phone, this is just about free from both an implementation and > > compute cost perspective (e.g. loose routing with a Route header in > > the regexp/transform). > > > > I am happy to remove functionality from the UA and not support it, > > but I am afraid the dial plan is here to stay in the UA. I think > > our best path forward is with a standard way to specify the dial plan > > transforms. > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 14 02:59:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18139 for ; Tue, 14 Jan 2003 02:59:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E8DnV08592 for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 03:13:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E8DmJ08589 for ; Tue, 14 Jan 2003 03:13:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18130 for ; Tue, 14 Jan 2003 02:59:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E8D1J08547; Tue, 14 Jan 2003 03:13:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E8BHJ08483 for ; Tue, 14 Jan 2003 03:11:17 -0500 Received: from alpha.jnpr.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18052 for ; Tue, 14 Jan 2003 02:56:43 -0500 (EST) Received: from muon.jnpr.net ([172.24.15.24]) by alpha.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 00:00:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sipping] expert review for draft-dcsgroup-sipping-proxy-proxy Date: Tue, 14 Jan 2003 00:00:04 -0800 Message-ID: <582ED0AECAB6E64B85FB508C956D597D048A2C@muon.jnpr.net> Thread-Topic: [Sipping] expert review for draft-dcsgroup-sipping-proxy-proxy Thread-Index: AcK7ovIdqfoJ6oWiTwOgP8gJyPPSgQ== From: "Burcak Beser" To: Cc: "Burcak Beser" X-OriginalArrivalTime: 14 Jan 2003 08:00:04.0528 (UTC) FILETIME=[F2602B00:01C2BBA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0E8BHJ08484 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Some issues/points: 1. The section '6 P-DCS-GATE' refers to PacketCable Dynamic Quality of Service which no longer specifies the Gate Coordination. The term DCS QoS mechanism should be used instead. 2. I know that because of the above issue the editor of the draft decided to use old versions of the specifications DQoS (PKT-SP-DQOS-I05-021127, the latest version is http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I07-021127.pdf) and Security (pkt-sp-sec-i05-020116, the latest version is http://www.packetcable.com/downloads/specs/pkt-sp-cmss-i02-021205.pdf). Since it is very hard, if not impossible to find older versions of CableLabs specifications; I do belive that referring an old version of specification would cause problems due to the fact that people will use the latest version that does not use the mechanism described. My suggestion is to remove the references to PacketCable. 3. Another alternative is to remove the section 6 completely which would result with dependency to DCS being removed as well. Since the remaining headers are used in the currently used in PacketCable specifications, the headers are not specific to DCS only. It is my expectation that this will cause the intrellectual property notice to be dropped as well. If necessary, I am planning to write an NCS architecture document which would point the PacketCable architecture that is currently being used, not as discussed long years ago for PacketCable. 4. I agree with Miguel about dropping the DCS portion from the headers. Even PacketCable will use these headers in a non-DCS enviroment. 5. In section 8, the definition of Financial Entity ID (FEID) should be as Financial-Entity-ID for consistency with other definitions. 6. The FEID is defined as 8 byte structure in text, where as the specification referenced defines it as 'variable length ASII character string, where first 8 bytes constitute MSO defined data, the rest contains MSO's domain name. 7. The reference to pkt-sp-em-i03-011221, should be updated due to above specified reasons. The correct reference is PKT-SP-EM-I05-021127. 8. I could not locate the definitions of Acct-Charge-URI, Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and Acct-Location-Routing-URI in the EM spec. 9. Why not use the same approach as RKS-Group-ID not refer to EM spec, for all these details. The parameters should be defined as more generalized which would make the definitions valid even if the specs change in the future. (By the way any reasons to keep RKS-Group-ID?) 10. Both P-DCS-LAES and P-DCS-Laes are being used in section 9. I suggest the use of P-DCS-LAES for consistency. 11. In section '10 Security Considerations' normative MUST is being used where I believe that should be non-normative must. 12. The acknowledgements section is divided into two and gives the impression that the DCS team and authors are a disjoint set, which is not the case. I would like to see that the real authors of the draft (at least Mike Mannette who wrote most of the initial text) should be properly acknowledged. 13. Is there a reason for two editors instead of one, as suggested in rfc-editor policies (http://www.rfc-editor.org/policy.html). Burcak Beser -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wednesday, December 11, 2002 2:06 PM To: 'sipping@ietf.org' Subject: [Sipping] expert review for draft-dcsgroup-sipping-proxy-proxy Hi, I'd like the SIPPING working group to provide expert review of: http://www.ietf.org/internet-drafts/draft-dcsgroup-sipping-proxy-proxy- 01.txt The authors have requested individual publication of the P-Headers defined therein. Expert Review will close on January 14, 2003 thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 14 15:08:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09981 for ; Tue, 14 Jan 2003 15:08:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKMqn28521 for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 15:22:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKMqJ28518 for ; Tue, 14 Jan 2003 15:22:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09969 for ; Tue, 14 Jan 2003 15:08:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKLYJ28415; Tue, 14 Jan 2003 15:21:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKKrJ28383 for ; Tue, 14 Jan 2003 15:20:53 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09892 for ; Tue, 14 Jan 2003 15:06:04 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (nas-cbv-6-62-147-149-122.dial.proxad.net [62.147.149.122]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h0EK9K316630 for ; Tue, 14 Jan 2003 21:09:20 +0100 Message-Id: <5.2.0.9.0.20030114183502.00b6bb38@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 14 Jan 2003 18:44:19 +0100 To: sipping@ietf.org From: Jiri Kuthan Subject: RE: [Sipping] URIs for Gateways In-Reply-To: <15903.16273.453205.50103@harjus.eng.song.fi> References: <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com> <313680C9A886D511A06000204840E1CF030B5D00@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This discussion became somehow multithreaded, so let me please make sure I'm catching up. One problem I see is ability of a PSTN gateway to propagate a calling number owned by a SIP caller down to PSTN. From: may or may not have the number in userpart (for example because a caller prefers to have "john" there). Perhaps some will agree that a gateway may not be necessarily the best place for mapping of From/username->PSTN number. Doing so in a proxy (a device which typically faetures lot of programmability) seems reasonable to me. Then the missing piece is how to propagate the PSTN number to the gateway. Using NAI as suggested here seems a very good hit to me. As for propagating the called number to PSTN -- I think that's about r-uri -- that is the resource which hit the gateway and which identifies the desired destination. Is there any additional functionality/problems folks would like to have? Is there any reason why NAI/r-uri should not be good enough for using in gateway's calling/caller-id PSTN signaling? Thanks, -Jiri _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 14 17:38:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14372 for ; Tue, 14 Jan 2003 17:38:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EMqgr08833 for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 17:52:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMqfJ08830 for ; Tue, 14 Jan 2003 17:52:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14331 for ; Tue, 14 Jan 2003 17:37:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMpsJ08756; Tue, 14 Jan 2003 17:51:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMoxJ08663 for ; Tue, 14 Jan 2003 17:50:59 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14254 for ; Tue, 14 Jan 2003 17:36:08 -0500 (EST) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0EMdRK28359 for ; Tue, 14 Jan 2003 17:39:27 -0500 (EST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 17:39:26 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D703F5AB54@oh0012itsa1.cb.lucent.com> From: "Deb, Sunandita (Sunandita)" To: "'sipping@ietf.org'" Date: Tue, 14 Jan 2003 17:39:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] difference between SIP and SIP-T Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi, Can you please let me know the basic difference between SIP and SIP-T? Is there any document describing the differences? My understanding is that SIP works in the pure IP world but SIP-T will be able to interwork between TDM and IP world and the SIP-T messages will have additional fields to include the specific telephony parameters like calling party number, called party number, originating line number etc. Thanks, Sunandita (614) 860-6471 (w) sudeb@lucent.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 14 19:02:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16605 for ; Tue, 14 Jan 2003 19:02:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F0HIn14473 for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 19:17:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0HIJ14470 for ; Tue, 14 Jan 2003 19:17:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16598 for ; Tue, 14 Jan 2003 19:02:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0GKJ14437; Tue, 14 Jan 2003 19:16:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0FsJ14399 for ; Tue, 14 Jan 2003 19:15:54 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16587 for ; Tue, 14 Jan 2003 19:01:02 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0F04FTI011023; Tue, 14 Jan 2003 18:04:17 -0600 From: "Dean Willis" To: "'Peterson, Jon'" , "'Rosen, Brian'" , "'Drage, Keith \(Keith\)'" , "'Henning Schulzrinne'" Cc: Subject: RE: [Sipping] URIs for Gateways Date: Tue, 14 Jan 2003 18:04:03 -0600 Message-ID: <005201c2bc29$9d797920$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <15A2739B7DAA624D8091C65981D7DA815EB4E6@stntexch2.va.neustar.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon said: > Technologies like ENUM (when/where available) could enable > gateways to convert originating telephone numbers into URIs. > Of course, a gateway wouldn't be able to assert that identity > to an intermediary unless it possessed credentials > appropriate to that URI, which is unlikely. I think the magic subtlety here is that the gateway would be asserting the PSTN number with its OWN credentials, meaning "I, Gateway, believe that I got this call from +1234567890, which I appear to be able to enum map to 1234567890@example.com". I think this should prove quite useful. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 14 19:03:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16619 for ; Tue, 14 Jan 2003 19:03:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F0HPk14489 for sipping-archive@odin.ietf.org; Tue, 14 Jan 2003 19:17:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0HPJ14486 for ; Tue, 14 Jan 2003 19:17:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16602 for ; Tue, 14 Jan 2003 19:02:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0GFJ14417; Tue, 14 Jan 2003 19:16:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0FlJ14395 for ; Tue, 14 Jan 2003 19:15:47 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16575 for ; Tue, 14 Jan 2003 19:00:55 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0F04FTF011023; Tue, 14 Jan 2003 18:04:15 -0600 From: "Dean Willis" To: "'Deb, Sunandita \(Sunandita\)'" , Subject: RE: [Sipping] difference between SIP and SIP-T Date: Tue, 14 Jan 2003 18:04:02 -0600 Message-ID: <004f01c2bc29$9ce21b20$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4C37CF2D8DF07E4CA6357BAD5EB9A5D703F5AB54@oh0012itsa1.cb.lucent.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0F0FlJ14396 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sunandita asked: > Can you please let me know the basic difference between SIP > and SIP-T? Is there any document describing the differences? > My understanding is that SIP works in the pure IP world but > SIP-T will be able to interwork between TDM and IP world and > the SIP-T messages will have additional fields to include the > specific telephony parameters like calling party number, > called party number, originating line number etc. In short, SIP-T is "HOW to do telephony interworking with SIP", and is NOT a separate protocol. The SIP-T work did not require any changes or extensions to the SIP protocol. Since I like analogies, imagine that useful tool "the standard slotted screwdriver". One may use it to drive screws. One may also use it to open paint cans. One may use it as a scraper, or a wood chisel, or a box-cutter, a hook-remover, a hasp-pin, a back scratcher, or any number of other things. SIP is, like a screwdriver, a versatile tool. SIP-T is instructions on how to use that tool for a particular task: interworking SS7 systems. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 15 03:22:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19717 for ; Wed, 15 Jan 2003 03:22:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F8avi21713 for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 03:36:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8auJ21710 for ; Wed, 15 Jan 2003 03:36:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19683 for ; Wed, 15 Jan 2003 03:21:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8YTJ21570; Wed, 15 Jan 2003 03:34:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8XiJ21544 for ; Wed, 15 Jan 2003 03:33:44 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19598 for ; Wed, 15 Jan 2003 03:18:40 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0F8LxAv013277; Wed, 15 Jan 2003 09:21:59 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GXDZA; Wed, 15 Jan 2003 09:21:59 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.92]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0F8Lxu4004279; Wed, 15 Jan 2003 10:21:59 +0200 (EET) Message-ID: <3E251A25.5F613C38@lmf.ericsson.se> Date: Wed, 15 Jan 2003 10:21:57 +0200 X-Sybari-Trust: 6f39a15d 1864f774 206fc897 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping , Alan Johnston , Robert Sparks CC: Miguel Angel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] From tag in CANCEL Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan, in the service example draft, http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-03.txt Some CANCELs have a tag in the From header field and some don't. For example, the CANCEL (F6) in page 73 does not have a tag, but the CANCEL (F9) in page 135 has it. Quoting from RFC 3261 (section 9.1): " The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags." Therefore, even if a CANCEL is generated by a proxy, it will have to have the From tag. The behavior regarding From tags for ACKs for non-2xx final responses generated by proxies is the same (Section 17.1.1.3). Regards, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 15 08:02:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24721 for ; Wed, 15 Jan 2003 08:02:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FDHJs08334 for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 08:17:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDHJJ08331 for ; Wed, 15 Jan 2003 08:17:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24711 for ; Wed, 15 Jan 2003 08:02:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDFQJ08141; Wed, 15 Jan 2003 08:15:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDDDJ08011 for ; Wed, 15 Jan 2003 08:13:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24301; Wed, 15 Jan 2003 07:58:04 -0500 (EST) Message-Id: <200301151258.HAA24301@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 15 Jan 2003 07:58:03 -0500 Subject: [Sipping] I-D ACTION:draft-willis-sip-infopackage-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Packaging and Negotiation of INFO Methods for the Session Initiation Protocol (SIP) Author(s) : D. Willis Filename : draft-willis-sip-infopackage-00.txt Pages : 11 Date : 2003-1-14 The SIP INFO method (RFC 2976) establishes a method by which applications may transfer application-specific information within a SIP dialog. However, RFC 2976 does not provide a mechanism for describing and documenting an application of INFO, nor does it provide a mechanism by which applications may negotiate such uses. This document provides a framework for documenting and naming specific uses of INFO (called INFO packages), for registering those package names with IANA, and for negotiating the support for various INFO packages between applications using SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-infopackage-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-willis-sip-infopackage-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-infopackage-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-14150945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-infopackage-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-infopackage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-14150945.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 15 15:27:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09178 for ; Wed, 15 Jan 2003 15:27:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FKg3807764 for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 15:42:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKg3J07761 for ; Wed, 15 Jan 2003 15:42:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09173 for ; Wed, 15 Jan 2003 15:26:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKelJ07695; Wed, 15 Jan 2003 15:40:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKd4J07610 for ; Wed, 15 Jan 2003 15:39:04 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09099 for ; Wed, 15 Jan 2003 15:23:46 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 5C4E74CEE4 for ; Wed, 15 Jan 2003 15:27:06 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA02339; Wed, 15 Jan 2003 15:27:03 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id PAA54736; Wed, 15 Jan 2003 15:27:03 -0500 (EST) Date: Wed, 15 Jan 2003 15:27:03 -0500 (EST) Message-Id: <200301152027.PAA54736@fish.research.att.com> To: sipping@ietf.org Subject: [Sipping] resolution of comments received during expert review of draft-dcsgroup-sipping-proxy-proxy-01 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Based on feedback during the "expert review period" for the indicated draft, the following changes have been incorporated in the recently submitted version. Until it appears in the archives, it may be found at ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sipping-proxy-proxy-02.txt and a MSWord version with changebars from the previous submission is ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sipping-proxy-proxy-02.doc Specific comments received, and the resolution of them, follows. Miguel Garcia wrote: > 1) I would recommend you to not use "addr-spec" in the syntax of any > header, and instead, use "name-addr". "name-addr" contains an "addr-spec" > within quotes, and optionally, a display name. It is therefore, richer > and easier to parse. Besides, there are a few SIP headers (Route, > Record-Route) that only allow "name-addr". One of the few changes we > did in the last version of the 3GPP P-headers draft was to fix all the > relevant headers to include "name-addr" instead of "addr-spec". > > So, for instance, the P-DCS-Trace-Party-ID syntax would become: > > P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr done. Miguel Garcia wrote: > 2) I miss in the document a table of new headers. Basically an > extension of Table 2 in RFC 3261. We have a similar one in section > 5.7 of the 3GPP P- headers. added, although I believe all the information in that table appears in the text already. Miguel Garcia wrote: > 3) With respect the name that you have chosen for the headers, I don't > understand why all of them are prepended by a "DCS" substring. I understand > that the headers were originally designed for the DCS architecture, but > once you publish the internet draft as an informational RFC, other > organizations (e.g., 3GPP) could "import" one or more headers in its > work. The fact that all the headers begin with "P-DCS-" will probably > give problems to some folks to use those headers outside their original > context. As an example, none of the 3GPP P- headers are named "P-3GPP-" > (I remember I fought this hard with some 3GPP folks). My recommendation > is to remove the "DCS" substring from the name of all these headers. Burcak Beser wrote: > 4. I agree with Miguel about dropping the DCS portion from the headers. > Even PacketCable will use these headers in a non-DCS enviroment. There is an issue of backward compatibility here, and changing the header names at the last minute, after years and years, seems extremely bad. But even more important is that removing "-DCS" from the names will leave such names as P-Billing-Info, P-Gate, P-LAES, etc. It would be very presumptuous of us to assume that all Billing information can be stored in the format we chose for P-Billing-Info, or that all other groups that needed to pass such information would choose a non-conflicting name for their header. While we can claim to be first, and take all that is available from IANA right now, that just doesn't seem fair to all. PacketCable is using them in a non-DCS environment, and the current released PacketCable spec (which was reviewed by all PacketCable vendors and approved) mandates them. With the "P-DCS-" prefix. Miguel Garcia wrote: > 4) Section 6.6. (Procedures at the proxy for P-DCS-Gate): "The > P-DCS-Gate header MUST NOT appear in any message other than the > initial INVITE request, or in the first reliable non-100 response > to that request". I have a question here: do you really mean in any > non-100 response to the request?? That will include, for instance, > 3xx and upper responses?? Perhaps do you mean "... any realiable 1xx > (except 100) or 2xx response ". Good point. This affects lots of other sections as well. Changed throughout. Miguel Garcia wrote: > 5) Section 7.4 (about the P-DCS-OSPS header): " ... it MUST reject the > request with a 409-Conflict error code.". Well, first I guess you refer > to the 409 response rather than error code. But what is more important: > the 409 response is not longer defined in RFC 3261, so you should change > it to any other suitable response. Changed to a 403 response. Miguel Garcia wrote: > 6) Section 7.6 (P-DCS-OSPS header): "If a proxy receives a P-DCS-OSPS > header in a request from an untrusted source, it MUST reject the request". > I find hard to understand why will you reject a request from an > untrusted source when it contains a header that you don't accept. I > consider it an easy denial of service attack to a proxy. I would think > that is logical to ignore and remove the header, and process the > request, if such request came from an untrusted source (similar > behaviour as for the P-Asserted-Identity). But if you have a very > good reason to reject requests in this case, I would say that you > should specify which response are you going to send back. Having the option to remove the header seems like a reasonable addition. Miguel Garcia wrote: > 7) Section 8.1 (Syntax for P-DCS-Billing-Info): According to the > comment I gave in my point 1 above, the syntax of Acct-Charge-URI, > Acct-Calling-URI- Acct-Called-URI, Acct-Routing-URI and > Acct-Loc-Routing-URI should be "name-addr" for all of them. The > word "URI" is not defined in this document nor in RFC 3261. The > same applies for the Called-ID and Redirector in the > P-DCS-Redirect in section 9.1. OK. Note that in current use, they will all reduce to tel: URLs, in order to be consistent with the PacketCable Event Messaging specification. But it is nice to generalize the syntax for the future. Miguel Garcia wrote: > 8) Section 8.6.1. In this section, you mention several times the > "18x-Ringing" response. I am not sure what kind of response is that. > Do you mean a 180 Ringing only or any 1xx response (including 181, > 182, 183)? What is meant is any 18x response, typically 180 or 183. Changed to "18x response". Burcak Beser wrote: > 1. The section '6 P-DCS-GATE' refers to PacketCable Dynamic Quality of > Service which no longer specifies the Gate Coordination. The term DCS > QoS mechanism should be used instead. A note is added stating the manner in which the PacketCable Dynamic Quality of Service specification currently uses Gate Coordination (see Section 5.1.5 of PKT-SP-DQOS-I05-021127). Burcak Beser wrote: > 2. I know that because of the above issue the editor of the draft > decided to use old versions of the specifications DQoS > (PKT-SP-DQOS-I05-021127, the latest version is > http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I07-021127.pdf) > and Security (pkt-sp-sec-i05-020116, the latest version is > http://www.packetcable.com/downloads/specs/pkt-sp-cmss-i02-021205.pdf). and > 7. The reference to pkt-sp-em-i03-011221, should be updated due to above > specified reasons. The correct reference is PKT-SP-EM-I05-021127. The "above issue" (your item #1) had nothing to do with it. The PacketCable specs have been updated several times and the references are outdated. All references in the draft have now been updated to the current versions of the PacketCable specs. However, we need to recognize that this problem will reappear. Burcak Beser wrote: > 5. In section 8, the definition of Financial Entity ID (FEID) should be > as Financial-Entity-ID for consistency with other definitions. done Burcak Beser wrote: > 6. The FEID is defined as 8 byte structure in text, where as the > specification referenced defines it as 'variable length ASII character > string, where first 8 bytes constitute MSO defined data, the rest > contains MSO's domain name. The Event Message spec (PKT-SP-EM-I05-021127) does state that the field is an ASCII string, but further states that the first 8 bytes, which are MSO-defined data, are zero filled. The "zero fill" may be either binary or ascii. The domain name (up to 239 bytes) is certainly ASCII, and is passed as such. The only way to guarantee passing the MSO-defined data transparently is to separate out the first 8 bytes from the last 239 bytes and treat them separately. Burcak Beser wrote: > 8. I could not locate the definitions of Acct-Charge-URI, > Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and > Acct-Location-Routing-URI in the EM spec. Perhaps it is not clear that Acct-Charge-URI corresponds to "Charge Number" (EM attribute ID 16), and that Acct-Calling-URI corresponds to "Calling Party Number" (EM attribute ID 4), etc. Although I think it is obvious to anyone looking at the SIG-START event, some text added to make this correspondance explicit. Burcak Beser wrote: > 9. Why not use the same approach as RKS-Group-ID not refer to EM spec, > for all these details. The parameters should be defined as more > generalized which would make the definitions valid even if the specs > change in the future. (By the way any reasons to keep RKS-Group-ID?) PKT-SP-CMSS-I02-021205 Section 8.4.1.2 makes extensive use of RKS-Group-ID. It is not defined in the EM spec. Burcak Beser wrote: > 10. Both P-DCS-LAES and P-DCS-Laes are being used in section 9. I > suggest the use of P-DCS-LAES for consistency. done Burcak Beser wrote: > 11. In section '10 Security Considerations' normative MUST is being used > where I believe that should be non-normative must. Note how in other documents, such as draft-ietf-sip-call-auth-06, the IESG demanded a normative MUST in the Security Considerations section. Similar situation and wording here. Burcak Beser wrote: > 12. The acknowledgements section is divided into two and gives the > impression that the DCS team and authors are a disjoint set, which is > not the case. I would like to see that the real authors of the draft (at > least Mike Mannette who wrote most of the initial text) should be > properly acknowledged. This was discussed in Spring 1999, nearly four years ago, and the agreed attribution of the co-authors has been maintained. Burcak Beser wrote: > 13. Is there a reason for two editors instead of one, as suggested in > rfc-editor policies (http://www.rfc-editor.org/policy.html). because there are two editors for this document. Further, there are other examples with multiple editors, e.g. RFC3312. Further, based on comments received from PacketCable MSOs, a new token value was added to the P-DCS-OSPS header in Section 7, value "RING", in order to signal a need to perform the Basic-911 operator ringback function in regulatory environments where it is mandated. Second, the use of MUSTs in Section 9 for including P-DCS-LAES information into SIP messages was changed to SHOULD, and an explanatory paragraph added at the beginning of the section explaining the conditions under which it is/isn't to be added. Bill Marshall wtm@research.att.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 15 16:06:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10013 for ; Wed, 15 Jan 2003 16:06:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FLL6M10005 for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 16:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLL5J10002 for ; Wed, 15 Jan 2003 16:21:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09989 for ; Wed, 15 Jan 2003 16:05:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLKLJ09935; Wed, 15 Jan 2003 16:20:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLJVJ09863 for ; Wed, 15 Jan 2003 16:19:31 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09959 for ; Wed, 15 Jan 2003 16:04:12 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H8R00A6VXC0R5@firewall.wcom.com> for sipping@ietf.org; Wed, 15 Jan 2003 21:07:12 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H8R00101XC0RI@pmismtp01.wcomnet.com>; Wed, 15 Jan 2003 21:07:12 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.34.75]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H8R001F0XBY4F@pmismtp01.wcomnet.com>; Wed, 15 Jan 2003 21:07:12 +0000 (GMT) Date: Wed, 15 Jan 2003 15:07:06 -0600 From: Alan Johnston Subject: Re: [Sipping] From tag in CANCEL In-reply-to: <3E251A25.5F613C38@lmf.ericsson.se> X-Sender: Alan.Johnston@pop.mcit.com To: Gonzalo Camarillo , sipping , Robert Sparks Cc: Miguel Angel Message-id: <5.1.1.6.0.20030115150430.03858f10@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Gonzalo, Thanks for the comments. Agreed - I will make the corrections on CANCEL tags. I also plan to go over the Call Flows I-Ds one last time to make sure that the tag usage is correct there. Thanks, Alan. At 10:21 AM 1/15/2003 +0200, Gonzalo Camarillo wrote: >Alan, > >in the service example draft, > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-03.txt > >Some CANCELs have a tag in the From header field and some don't. For >example, the CANCEL (F6) in page 73 does not have a tag, but the CANCEL >(F9) in page 135 has it. > >Quoting from RFC 3261 (section 9.1): >" The > Request-URI, Call-ID, To, the numeric part of CSeq, and From header > fields in the CANCEL request MUST be identical to those in the > request being cancelled, including tags." > >Therefore, even if a CANCEL is generated by a proxy, it will have to >have the From tag. > >The behavior regarding From tags for ACKs for non-2xx final responses >generated by proxies is the same (Section 17.1.1.3). > >Regards, > >Gonzalo >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 15 18:54:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15106 for ; Wed, 15 Jan 2003 18:54:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G08tm23582 for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 19:08:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G08tJ23578 for ; Wed, 15 Jan 2003 19:08:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15092 for ; Wed, 15 Jan 2003 18:53:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G08FJ23535; Wed, 15 Jan 2003 19:08:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G07VJ23427 for ; Wed, 15 Jan 2003 19:07:31 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15049 for ; Wed, 15 Jan 2003 18:52:09 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNtSQ11916; Wed, 15 Jan 2003 15:55:29 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNteN28463; Wed, 15 Jan 2003 17:55:40 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 17:55:27 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CC02@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Elwell, John'" , "Mark Watson" Cc: "'sipping@ietf.org'" Date: Wed, 15 Jan 2003 17:55:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCF1.90204790" Subject: [Sipping] RE: History information in provisional responses Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BCF1.90204790 Content-Type: text/plain; charset="ISO-8859-1" John, As long as the original request from the user had a Supported header with HistInfo, a UAS should be able to include History-Info in the appropriate provisional responses. I'll clearly state that when discussing responses in the sections of 2.3. Mary. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Monday, January 13, 2003 2:31 AM To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH] Cc: 'sipping@ietf.org' Subject: History information in provisional responses Mary and others, In the solution draft, nothing is said about inclusion of history information in provisional responses. I am thinking in particular of 180. This might be of benefit to a human originator in particular. Although in many cases a proxy will retarget a request fairly quickly (e.g., if the target user has moved or is busy), it may be programmed to retarget only after alerting the target user for a certain time. If successful the retarget will result in a 180 response from the retargeted-to user and hopefully eventually a 200 response. This means the UAC could receive two (or more) 180 responses. If the second and subsequent 180 responses were to contain history information, this would give the originator an explanation of what is happening and may persuade the originator to allow the request to continue longer in order to give the retargeted-to user time to answer. Another possible advantage is that on seeing history information in a 180 the originator might decide not to establish a session with the retargeted-to user and might cancel the request immediately without waiting for answer. What are your thoughts on history information in provisional responses? Obviously it would need to be done in a way that does not compromise privacy requirements. Regards, John John Elwell e-mail: mailto:john.elwell@siemens.com ------_=_NextPart_001_01C2BCF1.90204790 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: History information in provisional responses

John,

As long as the original request from the user had a = Supported header with HistInfo, a UAS should be able to include = History-Info in the appropriate provisional responses. I'll clearly = state that when discussing responses in the sections of 2.3.

Mary.

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Monday, January 13, 2003 2:31 AM
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark = [MOP:EP10:EXCH]
Cc: 'sipping@ietf.org'
Subject: History information in provisional = responses


Mary and others,

In the solution draft, nothing is said about = inclusion of history
information in provisional responses. I am thinking = in particular of 180.
This might be of benefit to a human originator in = particular.

Although in many cases a proxy will retarget a = request fairly quickly (e.g.,
if the target user has moved or is busy), it may be = programmed to retarget
only after alerting the target user for a certain = time. If successful the
retarget will result in a 180 response from the = retargeted-to user and
hopefully eventually a 200 response. This means the = UAC could receive two
(or more) 180 responses. If the second and = subsequent 180 responses were to
contain history information, this would give the = originator an explanation
of what is happening and may persuade the originator = to allow the request to
continue longer in order to give the retargeted-to = user time to answer.

Another possible advantage is that on seeing history = information in a 180
the originator might decide not to establish a = session with the
retargeted-to user and might cancel the request = immediately without waiting
for answer.

What are your thoughts on history information in = provisional responses?
Obviously it would need to be done in a way that = does not compromise privacy
requirements.

Regards,

John


John Elwell
e-mail: mailto:john.elwell@siemens.com

------_=_NextPart_001_01C2BCF1.90204790-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 15 18:54:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15120 for ; Wed, 15 Jan 2003 18:54:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G08xd23597 for sipping-archive@odin.ietf.org; Wed, 15 Jan 2003 19:08:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G08xJ23594 for ; Wed, 15 Jan 2003 19:08:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15096 for ; Wed, 15 Jan 2003 18:53:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G08CJ23514; Wed, 15 Jan 2003 19:08:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G07KJ23392 for ; Wed, 15 Jan 2003 19:07:20 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15042 for ; Wed, 15 Jan 2003 18:51:58 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNtBQ11880; Wed, 15 Jan 2003 15:55:11 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNtMN28427; Wed, 15 Jan 2003 17:55:22 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 17:55:09 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CC01@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Elwell, John'" , "Mark Watson" , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" , "'fluffy@cisco.com'" Date: Wed, 15 Jan 2003 17:55:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCF1.87F7CF20" Subject: [Sipping] RE: History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BCF1.87F7CF20 Content-Type: text/plain; charset="ISO-8859-1" John, The purpose of the requirements is to ensure that the protocol has the necessary elements to support any privacy requirements. The intent of PRIV-Req-1 was to ensure that user requested privacy is maintained as retargeting occurs and the intent of PRIV-Req-2 is to address the need for any entity (Proxy or UAS) receiving the information to maintain the privacy, with the implication that any privacy mechanism is based on RFC 3323. Now, perhaps the problem is that these requirements are currently too general and need to be more specific, although I think getting more specific involves getting more solution oriented. I could see the need to add a bit more background to section 5. You are correct that RFC3323 does briefly discuss the privacy requirements of the destination, but I think the clear recommendation is that you would have provided a URI that doesn't reveal any information that you wouldn't want disclosed. It clearly does not specify how you can maintain functionality if you apply privacy to things like Record Route and does clearly state that there's no way to privacy protect information needed to route a request, however, you can somehow "disguise" the URI so that it minimizes the privacy impact. (Jon, please do clarify if I've misinterpreted this here). As Mark pointed out in the conclusion to the previous thread, existing networks might appear to have this as a requirement, but it's not a general requirement for SIP. http://www.ietf.org/mail-archive/working-groups/sipping/current/msg03509.htm l I'm only personally familiar with how this works in the US with my understanding primarily based upon how my home service works, as specified by an insert provided by SWBell in 1995. It clearly states that even if one activates the feature to block the calling line ID, that this information is still sent to the network and may not be blocked on calls to 800/900 numbers. The blocking of the called party is typically not provided for a PSTN user (for the same reason it's not done for Request URIs - you can't reach the guy if you do so and is entirely application specific. There are examples where the actual DN of a destination isn't revealed, but that's all due to application specific logic and not the protocols (e.g call centers internally route calls without providing an externally dialable destination DN for the agents)). We can likely go on and on with anecdotal scenarios, but I really don't want to get into a rathole discussion on the nature of privacy (and calling line id blocking, etc.) but I am certainly open for further discussion if you point us to some regulatory specifications documenting the need for supporting something more. Regards, Mary. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Monday, January 13, 2003 2:31 AM To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 'Peterson, Jon' Cc: 'sipping@ietf.org' Subject: History information privacy requirements Mary and others, I don't want to open up the whole discussion we had a few weeks ago, but having read version 01 of the history requirements document I feel that we perhaps need to make an addition. Privacy requirements PRIV-req-1 and PRIV-req-2 both apply to information about the originator of the request (according to the preceding sentence). Privacy requirements of other users are not mentioned. I think they should be discussed in the document, even if the conclusion is that no additional requirements are placed on the solution. 1. Privacy requirements of the retargeted-to user. 1.1 This user may wish not to have his identity revealed to the originator. This, of course, can apply to any request, not just requests that have undergone retargeting. However, it is likely to be of greater relevance to a request that has been retargeted. A destination user can protect his privacy using RFC3323. It is important that the provisions of RFC3323 are not compromised as a result of retargeting. 2. Privacy requirements of the retargeting user. 2.1 This user may be unwilling to disclose to the originator the fact that retargeting has occurred 2.2 This user may be willing to disclose to the originator the fact that retargeting has occurred but unwilling to disclose to the originator the identity of the retargeted-to user. 2.3 This user may be unwilling to disclose to the retargeted-to user the fact that retargeting has occurred 2.4 This user may be willing to disclose to the retargeted-to user the fact that retargeting has occurred but unwilling to disclose to the retargeted-to user the identity of the previous target. NOTE. 2.3 and 2.4 are less convincing requirements, although I believe these requirements are supported in public ISDN. 2.5 The retargeting user can also be a retargeted-to user of a previous retarget. As such requirement 1.1 above can apply, i.e., the retargeting user (retargeted-to user of previous retarget) is unwilling to disclose his identity to the originating user. 2.6 The retargeting user has some of the characteristics of an originator if the request is retargeted again further downstream. As such PRIV-req-1 and PRIV-req-2 can apply to a retargeting user. Regards, John John Elwell e-mail: mailto:john.elwell@siemens.com ------_=_NextPart_001_01C2BCF1.87F7CF20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: History information privacy requirements

John,

The purpose of the requirements is to ensure that the = protocol has the necessary elements to support any privacy = requirements.  The intent of PRIV-Req-1 was to ensure that user = requested privacy is maintained as retargeting occurs and the intent of = PRIV-Req-2 is to address the need for any entity (Proxy or UAS) = receiving the information to maintain the privacy, with the implication = that any privacy mechanism is based on RFC 3323. Now, perhaps the = problem is that these requirements are currently too general and need = to be more specific, although I think getting more specific involves = getting more solution oriented. I could see the need to add a bit more = background to section 5.

You are correct that RFC3323 does briefly discuss the = privacy requirements of the destination, but I think the clear = recommendation is that you would have provided a URI that doesn't = reveal any information that you wouldn't want disclosed. It clearly = does not specify how you can maintain functionality if you apply = privacy to things like Record Route and does clearly state that there's = no way to privacy protect information needed to route a request, = however, you can somehow "disguise" the URI so that it = minimizes the privacy impact. (Jon, please do clarify if I've = misinterpreted this here).

As Mark pointed out in the conclusion to the previous = thread, existing networks might appear to have this as a requirement, = but it's not a general requirement for SIP.

http://www.ietf.org/mail-archive/working-groups/sippin= g/current/msg03509.html
I'm only personally familiar with how this works in = the US with my understanding primarily based upon how my home service = works, as specified by an insert provided by SWBell in 1995.  It = clearly states that even if one activates the feature to block the = calling line ID, that this information is still sent to the network and = may not be blocked on calls to 800/900 numbers.  The blocking of = the called party is typically not provided for a PSTN user (for the = same reason it's not done for Request URIs - you can't reach the guy if = you do so and is entirely application specific.  There are = examples where the actual DN of a destination isn't revealed, but = that's all due to application specific logic and not the protocols (e.g = call centers internally route calls without providing an externally = dialable destination DN for the agents)). 

We can likely go on and on with anecdotal scenarios, = but I really don't want to get into a rathole discussion on the nature = of privacy (and calling line id blocking, etc.)  but I am = certainly open for further discussion if you point us to some = regulatory specifications documenting the need for supporting something = more.

Regards,
Mary.

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Monday, January 13, 2003 2:31 AM
To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark = [MOP:EP10:EXCH];
'Peterson, Jon'
Cc: 'sipping@ietf.org'
Subject: History information privacy = requirements


Mary and others,
 
I don't want to open up the whole discussion we had = a few weeks ago, but
having read version 01 of the history requirements = document I feel that we
perhaps need to make an addition.
 
Privacy requirements PRIV-req-1 and PRIV-req-2 both = apply to information
about the originator of the request (according to = the preceding sentence).
Privacy requirements of other users are not = mentioned. I think they should
be discussed in the document, even if the conclusion = is that no additional
requirements are placed on the solution.
 
1. Privacy requirements of the retargeted-to = user.
 
1.1 This user may wish not to have his identity = revealed to the originator.
This, of course, can apply to any request, not just = requests that have
undergone retargeting. However, it is likely to be = of greater relevance to a
request that has been retargeted. A destination user = can protect his privacy
using RFC3323. It is important that the provisions = of RFC3323 are not
compromised as a result of retargeting.
 
2. Privacy requirements of the retargeting = user.
 
2.1 This user may be unwilling to disclose to the = originator the fact that
retargeting has occurred
 
2.2 This user may be willing to disclose to the = originator the fact that
retargeting has occurred but unwilling to disclose = to the originator the
identity of the retargeted-to user.
 
2.3 This user may be unwilling to disclose to the = retargeted-to user the
fact that retargeting has occurred
 
2.4 This user may be willing to disclose to the = retargeted-to user the fact
that retargeting has occurred but unwilling to = disclose to the retargeted-to
user the identity of the previous target.
 
NOTE. 2.3 and 2.4 are less convincing requirements, = although I believe these
requirements are supported in public ISDN.
 
2.5 The retargeting user can also be a retargeted-to = user of a previous
retarget. As such requirement 1.1 above can apply, = i.e., the retargeting
user (retargeted-to user of previous retarget) is = unwilling to disclose his
identity to the originating user.
 
2.6 The retargeting user has some of the = characteristics of an originator if
the request is retargeted again further downstream. = As such PRIV-req-1 and
PRIV-req-2 can apply to a retargeting user.
 
Regards,
 
John
 
John Elwell
e-mail: mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com> 

------_=_NextPart_001_01C2BCF1.87F7CF20-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 08:12:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09332 for ; Thu, 16 Jan 2003 08:12:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GDRa220591 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 08:27:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDRZJ20588 for ; Thu, 16 Jan 2003 08:27:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09311 for ; Thu, 16 Jan 2003 08:11:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDNHJ20158; Thu, 16 Jan 2003 08:23:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDM6J20076 for ; Thu, 16 Jan 2003 08:22:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08897; Thu, 16 Jan 2003 08:06:29 -0500 (EST) Message-Id: <200301161306.IAA08897@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 16 Jan 2003 08:06:29 -0500 Subject: [Sipping] I-D ACTION:draft-wu-sipping-floor-control-03.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of Session Initiation Protocol (SIP) and Simple Object Access Protocol (SOAP) for Conference Floor Control Author(s) : X. Wu et al. Filename : draft-wu-sipping-floor-control-03.txt Pages : 33 Date : 2003-1-15 During a conference, floor control coordinates simultaneous access to shared resource in multimedia conferences. Floor control allows applications and users to gain safe and mutually exclusive or non- exclusive access to the shared resources. This document defines an approach of using Session Initiation Protocol (SIP) event notification mechanism and Simple Object Access Protocol (SOAP) to perform floor control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wu-sipping-floor-control-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wu-sipping-floor-control-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-wu-sipping-floor-control-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-15125659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wu-sipping-floor-control-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-wu-sipping-floor-control-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-15125659.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 08:56:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10920 for ; Thu, 16 Jan 2003 08:56:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEBNA24348 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 09:11:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEBMJ24345 for ; Thu, 16 Jan 2003 09:11:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10900 for ; Thu, 16 Jan 2003 08:55:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE7KJ23922; Thu, 16 Jan 2003 09:07:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GE5XJ23341 for ; Thu, 16 Jan 2003 09:05:33 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10808 for ; Thu, 16 Jan 2003 08:49:52 -0500 (EST) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h0GDQHa04305; Thu, 16 Jan 2003 18:56:17 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CB0.004BDA0B ; Thu, 16 Jan 2003 19:18:30 +0530 X-Lotus-FromDomain: HSSBLR To: sipping@ietf.org cc: fmiller@sentito.com Message-ID: <65256CB0.004BD998.00@sampark.hss.hns.com> Date: Thu, 16 Jan 2003 19:18:28 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Reposting this mail as it did not receive a response on the list the first time. hbhondwe@hss.hns.com on 01/10/2003 11:13:02 AM To: sipping@ietf.org cc: (bcc: Harsh Bhondwe/HSSBLR) Subject: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt Hi , I have a fundamental question on the the usage of SIP for transporting TCAP messages. If I understand correctly the figure 1 in the draft, is something like the following: SIP Element Signaling Gateway SS7 Node TCAP applications PSTN Services TCAP TCAP SIP--------IP----------SIP||SS7--------SS7------SS7 Here a TCAP peer will be running on the SIP Element and will use SIP to exchange TCAP messages with peers(i.e other TCAPs) in the PSTN network. However, SIGTRAN protocols defined also by the SIGTRAN Working group of the IETF have been especially designed for transporting Trunk/Access signaling over IP. So, could one not better accomplish this by the following configuration using SIGTRAN? SIP Element Signaling Gateway PSTN Node TCAP applications PSTN Services TCAP TCAP SIGTRAN---------IP-------------SIGTRAN||SS7 ---SS7-----SS7 (SUA over SCTP) (SUA over SCTP) The difference of course is that in this case the SIP Element and the Signaling Gateway will have to (also) support SIGTRAN.They could continue to support SIP as well. Or am i missing something? thanks harsh _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 09:29:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12023 for ; Thu, 16 Jan 2003 09:29:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEik726745 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 09:44:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEikJ26741 for ; Thu, 16 Jan 2003 09:44:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11998 for ; Thu, 16 Jan 2003 09:29:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEegJ26509; Thu, 16 Jan 2003 09:40:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GADKJ07698 for ; Thu, 16 Jan 2003 05:13:20 -0500 Received: from bramg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05872 for ; Thu, 16 Jan 2003 04:57:45 -0500 (EST) Received: from loire.grenoble.hp.com (loire.grenoble.hp.com [15.128.14.199]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 7EF8D85B for ; Thu, 16 Jan 2003 11:01:07 +0100 (MET) Received: by loire.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 16 Jan 2003 11:01:07 +0100 Message-ID: <1FA8FB96ED5BD411911D00D0B77FC68E07FEE7C7@galilei.italy.hp.com> From: "PRATI,LUCA (HP-Italy,ex1)" To: "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 16 Jan 2003 11:01:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi Folks, how would you compare SIP/SIMPLE with XMPP from an Instant Messaging/Presence Management perspective if this is a subject you've tackled already? No reference to XMPP in the huge (269 pages) RFC 3261 on SIP... ... and it looks that no reference to SIP in the XMPP drafts. Thanks and kind regards Luca _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 09:29:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12036 for ; Thu, 16 Jan 2003 09:29:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEipJ26760 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 09:44:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEipJ26757 for ; Thu, 16 Jan 2003 09:44:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12007 for ; Thu, 16 Jan 2003 09:29:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEejJ26535; Thu, 16 Jan 2003 09:40:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAQ2J08146 for ; Thu, 16 Jan 2003 05:26:02 -0500 Received: from gremg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06016 for ; Thu, 16 Jan 2003 05:10:27 -0500 (EST) Received: from loire.grenoble.hp.com (loire.grenoble.hp.com [15.128.14.199]) by gremg1.net.external.hp.com (Postfix) with ESMTP id 29163195 for ; Thu, 16 Jan 2003 11:13:49 +0100 (MET) Received: by loire.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 16 Jan 2003 11:13:48 +0100 Message-ID: <1FA8FB96ED5BD411911D00D0B77FC68E07FEE7DD@galilei.italy.hp.com> From: "PRATI,LUCA (HP-Italy,ex1)" To: sipping@ietf.org Date: Thu, 16 Jan 2003 11:13:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] SIP <-> XMPP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi Folks, how would you compare SIP/SIMPLE with XMPP from an Instant Messaging/Presence Management perspective if this is a subject you've tackled already? No reference to XMPP in the huge (269 pages) RFC 3261 on SIP... and it looks that no reference to SIP in the XMPP drafts. Thanks and kind regards, Luca _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 09:59:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13019 for ; Thu, 16 Jan 2003 09:59:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFEmk28976 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 10:14:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFEmJ28973 for ; Thu, 16 Jan 2003 10:14:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13015 for ; Thu, 16 Jan 2003 09:59:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFAcJ28745; Thu, 16 Jan 2003 10:10:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF9vJ28656 for ; Thu, 16 Jan 2003 10:09:57 -0500 Received: from fmis401r.omnitel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12838 for ; Thu, 16 Jan 2003 09:54:16 -0500 (EST) From: loretosa@vizzavi.it Received: from fmis439.omnitel.it by fmis401r.omnitel.it via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 16 Jan 2003 14:57:39 UT Received: (private information removed) Received: (private information removed) Content-Class: urn:content-classes:message To: Date: Thu, 16 Jan 2003 15:53:36 +0100 Message-ID: <676001c2bd6f$0c349f70$5dde010a@omnitel.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcK9bww0YkduIi2yTTGs1Xj8ryMsyg== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GF9vJ28657 Subject: [Sipping] state of the art Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, please can someone help me to do a summary about the state of the art of SIP, SIPPING, and SIMPLE: what are the open issues ? what are the problems and priorities about this standard in 3GPP ? what are the outlooks about the use of this protocol ? Sal _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 11:42:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15744 for ; Thu, 16 Jan 2003 11:42:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GGw7T04144 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 11:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGw7J04139 for ; Thu, 16 Jan 2003 11:58:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15724 for ; Thu, 16 Jan 2003 11:42:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGsCJ03891; Thu, 16 Jan 2003 11:54:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGlFJ03568 for ; Thu, 16 Jan 2003 11:47:15 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15470 for ; Thu, 16 Jan 2003 11:31:31 -0500 (EST) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0GGYMTF027448; Thu, 16 Jan 2003 10:34:22 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.5/8.12.5/Submit) id h0GGYM3w027446; Thu, 16 Jan 2003 10:34:22 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Sipping] SIP <-> XMPP From: Dean Willis To: "PRATI,LUCA ""(HP-Italy,ex1)" Cc: sipping@ietf.org In-Reply-To: <1FA8FB96ED5BD411911D00D0B77FC68E07FEE7DD@galilei.italy.hp.com> References: <1FA8FB96ED5BD411911D00D0B77FC68E07FEE7DD@galilei.italy.hp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1042734861.27238.18.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 16 Jan 2003 10:34:22 -0600 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-01-16 at 04:13, PRATI,LUCA (HP-Italy,ex1) wrote: > Hi Folks, > how would you compare SIP/SIMPLE with XMPP from an Instant > Messaging/Presence Management perspective if this is a subject you've > tackled already? > No reference to XMPP in the huge (269 pages) RFC 3261 on SIP... and it looks > that no reference to SIP in the XMPP drafts. > Thanks and kind regards, > Luca SCOPE ALERT: This probably belongs in the SIMPLE or XMPP working groups. Historically speaking, XMPP was not on the radar screen of the IETF when 3261 was published. I believe there is a SIMPLE draft dealing with using SIP to set up an XMPP session for messaging. -- Dean Willis _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 12:51:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17832 for ; Thu, 16 Jan 2003 12:51:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GI6aT09327 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 13:06:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI6aJ09324 for ; Thu, 16 Jan 2003 13:06:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17804 for ; Thu, 16 Jan 2003 12:50:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI2UJ09052; Thu, 16 Jan 2003 13:02:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI0EJ08841 for ; Thu, 16 Jan 2003 13:00:14 -0500 Received: from lor.jeremie.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17524 for ; Thu, 16 Jan 2003 12:44:31 -0500 (EST) Received: from localhost (stpeter@localhost) by lor.jeremie.com (8.9.3/8.9.3) with ESMTP id LAA18778; Thu, 16 Jan 2003 11:47:38 -0600 Date: Thu, 16 Jan 2003 11:47:38 -0600 (CST) From: Peter Saint-Andre X-Sender: stpeter@lor.jeremie.com To: Dean Willis cc: "PRATI,LUCA (HP-Italy,ex1)" , sipping@ietf.org Subject: Re: [Sipping] SIP <-> XMPP In-Reply-To: <1042734861.27238.18.camel@bdsl.greycouncil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , On 16 Jan 2003, Dean Willis wrote: > Historically speaking, XMPP was not on the radar screen of the IETF when > 3261 was published. True, so we would not expect mention of XMPP in 3261. > I believe there is a SIMPLE draft dealing with using SIP to set up an > XMPP session for messaging. http://www.ietf.org/internet-drafts/draft-sparks-simple-jabber-sessions-00.txt Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 13:13:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18725 for ; Thu, 16 Jan 2003 13:13:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GISSI11473 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 13:28:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GISSJ11470 for ; Thu, 16 Jan 2003 13:28:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18713 for ; Thu, 16 Jan 2003 13:12:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIRDJ11386; Thu, 16 Jan 2003 13:27:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIOhJ11306 for ; Thu, 16 Jan 2003 13:24:43 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18599 for ; Thu, 16 Jan 2003 13:08:59 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H8T00601JW55J@siemenscomms.co.uk> for sipping@ietf.org; Thu, 16 Jan 2003 18:12:05 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H8T005JEJW53F@siemenscomms.co.uk>; Thu, 16 Jan 2003 18:12:05 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Jan 2003 18:12:19 +0000 Content-return: allowed Date: Thu, 16 Jan 2003 18:12:30 +0000 From: "Elwell, John" To: Mary Barnes , Mark Watson , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" , "'fluffy@cisco.com'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Mary, To pick up on a particular point, you wrote: ".... There are examples where the actual DN of a destination isn't revealed, but that's all due to application specific logic and not the protocols (e.g call centers internally route calls without providing an externally dialable destination DN for the agents)...." Applying this same principle to SIP, application logic at the proxy could determine the retargeted to URI. There may be reasons for not disclosing this URI to the caller. Obviously one way to achieve this is to omit history information altogether. Then the caller will never discover the retargeted-to URI unless the UAS sends it back, but RFC 3323 provides the UAS with a way of preventing that. However, there may be good reason why the proxy will wish to place history information in the request before sending it on downstream, e.g., to prevent retrying targets that have already been tried, to advise the callee where the call has come from. So there may be a requirement to send history information downstream but prevent it going upstream back to the caller. Either there has to be a protocol solution to indicate this privacy requirement to downstream proxies and the UAS, or the retargeting proxy has to be responsible for removing any history information that might compromise the privacy requirement. Unfortunately the latter works only for a proxy, not a redirect, but perhaps redirection is inappropriate in this situation (since the redirection request could reach the UAC). So even if we say that we don't need protocol enhancements as such, the section of the solution document that describes proxy behaviour should point out the possible need to remove upstream history information. I guess most of the additional privacy requirements I mentioned can be solved by appropriate proxy behaviour without requiring any additional protocol elements. But I had expected these requirements to be laid down in the requirements document and text in the solutions document indicating what action needs to be taken to fulfil these requirements. Concerning regulatory requirements, these are not my primary concern. Even if there is no regulatory requirement governing a certain aspect of privacy, there may be business requirements, as in the example above where there is a requirement not to reveal the identity of a call centre agent. Regards, John John Elwell e-mail: mailto:john.elwell@siemens.com -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] Sent: 15 January 2003 23:55 PM To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' Subject: RE: History information privacy requirements John, The purpose of the requirements is to ensure that the protocol has the necessary elements to support any privacy requirements. The intent of PRIV-Req-1 was to ensure that user requested privacy is maintained as retargeting occurs and the intent of PRIV-Req-2 is to address the need for any entity (Proxy or UAS) receiving the information to maintain the privacy, with the implication that any privacy mechanism is based on RFC 3323. Now, perhaps the problem is that these requirements are currently too general and need to be more specific, although I think getting more specific involves getting more solution oriented. I could see the need to add a bit more background to section 5. You are correct that RFC3323 does briefly discuss the privacy requirements of the destination, but I think the clear recommendation is that you would have provided a URI that doesn't reveal any information that you wouldn't want disclosed. It clearly does not specify how you can maintain functionality if you apply privacy to things like Record Route and does clearly state that there's no way to privacy protect information needed to route a request, however, you can somehow "disguise" the URI so that it minimizes the privacy impact. (Jon, please do clarify if I've misinterpreted this here). As Mark pointed out in the conclusion to the previous thread, existing networks might appear to have this as a requirement, but it's not a general requirement for SIP. http://www.ietf.org/mail-archive/working-groups/sipping/current/msg03509.htm l I'm only personally familiar with how this works in the US with my understanding primarily based upon how my home service works, as specified by an insert provided by SWBell in 1995. It clearly states that even if one activates the feature to block the calling line ID, that this information is still sent to the network and may not be blocked on calls to 800/900 numbers. The blocking of the called party is typically not provided for a PSTN user (for the same reason it's not done for Request URIs - you can't reach the guy if you do so and is entirely application specific. There are examples where the actual DN of a destination isn't revealed, but that's all due to application specific logic and not the protocols (e.g call centers internally route calls without providing an externally dialable destination DN for the agents)). We can likely go on and on with anecdotal scenarios, but I really don't want to get into a rathole discussion on the nature of privacy (and calling line id blocking, etc.) but I am certainly open for further discussion if you point us to some regulatory specifications documenting the need for supporting something more. Regards, Mary. -----Original Message----- From: Elwell, John [ mailto:john.elwell@siemens.com ] Sent: Monday, January 13, 2003 2:31 AM To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 'Peterson, Jon' Cc: 'sipping@ietf.org' Subject: History information privacy requirements Mary and others, I don't want to open up the whole discussion we had a few weeks ago, but having read version 01 of the history requirements document I feel that we perhaps need to make an addition. Privacy requirements PRIV-req-1 and PRIV-req-2 both apply to information about the originator of the request (according to the preceding sentence). Privacy requirements of other users are not mentioned. I think they should be discussed in the document, even if the conclusion is that no additional requirements are placed on the solution. 1. Privacy requirements of the retargeted-to user. 1.1 This user may wish not to have his identity revealed to the originator. This, of course, can apply to any request, not just requests that have undergone retargeting. However, it is likely to be of greater relevance to a request that has been retargeted. A destination user can protect his privacy using RFC3323. It is important that the provisions of RFC3323 are not compromised as a result of retargeting. 2. Privacy requirements of the retargeting user. 2.1 This user may be unwilling to disclose to the originator the fact that retargeting has occurred 2.2 This user may be willing to disclose to the originator the fact that retargeting has occurred but unwilling to disclose to the originator the identity of the retargeted-to user. 2.3 This user may be unwilling to disclose to the retargeted-to user the fact that retargeting has occurred 2.4 This user may be willing to disclose to the retargeted-to user the fact that retargeting has occurred but unwilling to disclose to the retargeted-to user the identity of the previous target. NOTE. 2.3 and 2.4 are less convincing requirements, although I believe these requirements are supported in public ISDN. 2.5 The retargeting user can also be a retargeted-to user of a previous retarget. As such requirement 1.1 above can apply, i.e., the retargeting user (retargeted-to user of previous retarget) is unwilling to disclose his identity to the originating user. 2.6 The retargeting user has some of the characteristics of an originator if the request is retargeted again further downstream. As such PRIV-req-1 and PRIV-req-2 can apply to a retargeting user. Regards, John John Elwell e-mail: mailto:john.elwell@siemens.com < mailto:john.elwell@siemens.com > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 15:40:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23340 for ; Thu, 16 Jan 2003 15:40:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GKu1C22362 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 15:56:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKu1J22359 for ; Thu, 16 Jan 2003 15:56:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23330 for ; Thu, 16 Jan 2003 15:40:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKsmJ22266; Thu, 16 Jan 2003 15:54:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKr2J22175 for ; Thu, 16 Jan 2003 15:53:02 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23264 for ; Thu, 16 Jan 2003 15:37:15 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GKeRw27675; Thu, 16 Jan 2003 12:40:27 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GKebH26898; Thu, 16 Jan 2003 14:40:37 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 14:40:24 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CC0D@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Elwell, John'" , "Mark Watson" , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" , "'fluffy@cisco.com'" Date: Thu, 16 Jan 2003 14:40:23 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sipping] RE: History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi John, I do understand your concerns and I think we agree that this is an application issue. I think what we need to do is to add some text in section 5 (and actually I think this text should replace what's currently the last paragraph of that section) highlighting that there may also be application specific reasons for not including the Request History Information in responses, but that the these reasons don't impose any additional requirements on the protocol. I think there is alot of overlap with the concerns you have raised and the general optionality aspects that are primarily controlled by the application and local policy as to whether the information is captured, and if it is captured whether it is included in requests beyond that domain or in responses, etc. As with the optionality, I think we've previously agreed (and documented in the requirements) that the solution does need to provide some guidelines as to the aspects which must be addressed by applications making use of this capability. I can add similar wording to section 5. As to what's needed in the solution draft to address this, section 2.3.3 does describe that whether the information is included in the response is also based upon local policy, which should thus encompass these privacy aspects. Mary. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Thursday, January 16, 2003 12:12 PM To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; 'Peterson, Jon' Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' Subject: RE: History information privacy requirements Mary, To pick up on a particular point, you wrote: ".... There are examples where the actual DN of a destination isn't revealed, but that's all due to application specific logic and not the protocols (e.g call centers internally route calls without providing an externally dialable destination DN for the agents)...." Applying this same principle to SIP, application logic at the proxy could determine the retargeted to URI. There may be reasons for not disclosing this URI to the caller. Obviously one way to achieve this is to omit history information altogether. Then the caller will never discover the retargeted-to URI unless the UAS sends it back, but RFC 3323 provides the UAS with a way of preventing that. However, there may be good reason why the proxy will wish to place history information in the request before sending it on downstream, e.g., to prevent retrying targets that have already been tried, to advise the callee where the call has come from. So there may be a requirement to send history information downstream but prevent it going upstream back to the caller. Either there has to be a protocol solution to indicate this privacy requirement to downstream proxies and the UAS, or the retargeting proxy has to be responsible for removing any history information that might compromise the privacy requirement. Unfortunately the latter works only for a proxy, not a redirect, but perhaps redirection is inappropriate in this situation (since the redirection request could reach the UAC). So even if we say that we don't need protocol enhancements as such, the section of the solution document that describes proxy behaviour should point out the possible need to remove upstream history information. I guess most of the additional privacy requirements I mentioned can be solved by appropriate proxy behaviour without requiring any additional protocol elements. But I had expected these requirements to be laid down in the requirements document and text in the solutions document indicating what action needs to be taken to fulfil these requirements. Concerning regulatory requirements, these are not my primary concern. Even if there is no regulatory requirement governing a certain aspect of privacy, there may be business requirements, as in the example above where there is a requirement not to reveal the identity of a call centre agent. Regards, John John Elwell e-mail: mailto:john.elwell@siemens.com ----remainder of thread deleted------ _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 16 17:43:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25820 for ; Thu, 16 Jan 2003 17:43:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GMwuo30393 for sipping-archive@odin.ietf.org; Thu, 16 Jan 2003 17:58:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMwuJ30390 for ; Thu, 16 Jan 2003 17:58:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25816 for ; Thu, 16 Jan 2003 17:43:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMvjJ30333; Thu, 16 Jan 2003 17:57:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMu7J30281 for ; Thu, 16 Jan 2003 17:56:07 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25796 for ; Thu, 16 Jan 2003 17:40:15 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GMhYw24368; Thu, 16 Jan 2003 14:43:35 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GMhjH00670; Thu, 16 Jan 2003 16:43:46 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 16:43:32 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E076E29A0@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Daniel G. Petrie" , "Rosen, Brian" Cc: "'Henning Schulzrinne'" , Adam Roach , "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 16 Jan 2003 16:43:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BDB0.AFC062F0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BDB0.AFC062F0 Content-Type: text/plain; charset="ISO-8859-1" A few observations from left field... We can "know" when a user is done dialing, if you don't want to click to dial through other means: - The user picks up the handset after dialing (ala PBX phones). - A timer pops in the digit collection routine on the UA (ala PSTN digit collectors). - The user hits an extra button to tell the device their done, so it doesn't have to read their mind as to when they may be finished (ala cell phones, and PBX phones). Really, no matter what, you're going to have to have a timer or an explicit form of "punctuation" (ie a TALK/SEND/CALL/DIAL button) involved in the digit collection algorithm. Otherwise, how do you know when a user is continuing to enter digits, or has simply entered an invalid number? To use Henning's example of dialing 6744 to ring his admin, what do you expect the UA to do when he dials 674? Sit there forever and wait for the other four to drop? You can still offer an auto-completed set of dialed digits for the user, without having to understand what it is that they're dialing. As for knowing how to form a canonical URL, other than some sort of very bland BCP, such as, use a tel url with a particular, one-size-fits-all, phone context setting, I doubt you'll be able to satisfy all of the demands that each vendor/customer may have in being able to route calls in a predictable manner. As for the routing to the correct outbound proxy, it seems very artificial to say that a reason for having a dialplan in the UA is so that you can select an outbound proxy by making the election as part of the dialed digits. I could argue that the functionality you describe can also be reasonably handled by representing each outbound proxy as a "virtual line". People are used to the idea, that to use your example, personal calls should not go through their business's PBX, and vice-versa, that they have, at a minimum, two-lines (and possibly two phones). One is hooked up to the business PBX, the other through another carrier for private calls. Reducing this down to virtual lines on the UA seems reasonably logical to me. You select the "private" line (which is configured to your private service provider), and then dial to make a personal call. Likewise, you select the "business" line (which is configured to your IP PBX), to make business calls. To me, there's a big difference in the UA being able to correctly format it's request to the outbound proxy, and the UA having to actually *understand* what is sent to the local outbound proxy. A dialplan, to me, infers that the UA has to actually understand to some degree, and interpret the digits prior to translations at the proxy. This means that some degree of translations are possible at two points in the network, and now I have to go about keeping them in-sync with one another to get predictable results. Seems like a dangerous mess, and one that the phone system has done without for a very long time. If a dialplan is simply something that we use to format the digit stream into a standard, no matter what they dialed, layout so that the proxy can expect a predictable format that it will receive the digit stream in, that seems much more feasible and reasonable. If this is the case, SIP itself can be considered a dialplan, as the digits must be transported in a legally formatted SIP request. Regards, Brian -----Original Message----- From: Daniel G. Petrie [mailto:dpetrie@pingtel.com] Sent: Friday, January 10, 2003 4:52 PM To: Rosen, Brian Cc: 'Henning Schulzrinne'; Adam Roach; 'Paul Kyzivat'; 'sipping@ietf.org' Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt There is actually a third reason to have dial plans on the UA. The first two have already been brought up: 1) To know when the user is done dialing 2) To know how to form a canonical URL (tel , sip or sips) 3) To know how to route the INVITE to the correct outbound proxy On the first one, knowing when the user is done dialing, I am afraid, as Cullen pointed out, the market (at least in North America) wants a phone that knows when the user is done dialing. There are too many people who still like the pre-cell phone metaphor. Sorry but the people on this list do not buy enough phones to decide this one ;-). The UA needs to know how it is going to form a cannonical URL from the mess of characters and digits the user entered. So as Brian pointed out you need some regexp to transform the entered characters into a URL. Well guess what, every proxy vendor wants this to be a little different. Some want short strings (AKA extensions) transformed differently than long strings (AKA E.164 numbers). So call it what you want you end up with the equivalent of a dial plan. The best we can do here is to come of with a standardized (or call it BCP) way to write the transforms. We can write a standard that says this is the one and only transform, but no phone vendor that has a dial plan mechanism will be able to drop their dial plan support because they have customers using it. However I am sure the market would be happy to push vendors to support a standardized dial plan description mechanism. The third use of dial plans is for routing purposes. I know! That is what the proxy is supposed to do. However there are several uses for doing some simple routing from the phone base upon the "dialed string": a) Functional routing: where based upon the purpose of the call the user wants the call routed differently. For example I have a phone at home from which I make personal calls via my favorite service provider and from which I make business calls via my enterprise IP PBX. I want my private/personal calls private and my business does not want to pay for my personal calls. A simple, familiar metaphor for this is to use a dialing prefix (e.g. dial 9 and number for business call, dial 8 and number for personal calls). The alternatives would be to sell home/office users two phones (I wish that would fly) or put a proxy in every home/office (I would not mind selling that many proxies if that would fly as well). b) Load balancing routing: based upon my dialed string I may want to use a different out bound proxy. Domestic US calls go to one proxy, international calls go to another, 911/emergency calls go directly to the local emergency gateway. Can this be done by the proxy? Sometimes, if I can get to it, but once you have a dial plan on the phone, this is just about free from both an implementation and compute cost perspective (e.g. loose routing with a Route header in the regexp/transform). I am happy to remove functionality from the UA and not support it, but I am afraid the dial plan is here to stay in the UA. I think our best path forward is with a standard way to specify the dial plan transforms. "Rosen, Brian" wrote: > Actually, I'm happy with a "Dial" button. > > I'll note most existing SIP phones don't do this (or at least don't > have a physical "Dial" button, I've seen some with softkeys). > > However, the issue remains. If I dial 6744 on my sip phone (and press > dial), the sipphone on my admin's desk should ring. I should not have > to dial +17247426744. The fact that I dialed a 4 digit number with > a 6 as the starting digit tells my system that it is an internal > extension. A dial plan is the thing that "knows" this. > > What do you want to have happen: > 1) tel:6744; context=+1724742 > 2) tel:6744; context=marconi-pittsburgh-local-extension > 3) tel:+17247426744 > > Note the last is problematic. As Mike Pierce points out, not all > extensions have E.164s > > And, to amplify the thread that started this, how many identities does > my admin's UA have to understand? > > Again, I'm not opposed to making dial string expansion be a requirement > of the UA, as long as we standardize the form of the expansion, and the > mechanism by which the UA learns it. > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, January 09, 2003 9:07 PM > > To: Adam Roach > > Cc: Rosen, Brian; 'Paul Kyzivat'; 'sipping@ietf.org' > > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do > > Proxies map? was > > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > > > > In case there's doubt: I was not suggesting that we do this. I was > > trying to find out from Brian what he meant, since the two > > problem have > > very different solution sets. The 'abbreviated dialing' case requires > > nothing except a suitable URI scheme and the translation > > services of an > > outbound proxy. > > > > Adam Roach wrote: > > >>- Recognizing patterns so that one can keep the old > > >>"no-need-to-hit-dial" user interface. > > > > > > > > > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! > > > > > > No! > > > > > > Cell phones have sufficiently trained the public that it's > > > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER" > > > after a phone number. It makes life so much easier for user > > > interface designers and users alike. For the love of all that > > > is good, let's not encourage backsliding. > > > > > > /a > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C2BDB0.AFC062F0 Content-Type: text/html; charset="ISO-8859-1" RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt

A few observations from left field...

We can "know" when a user is done dialing, if you don't want to click to dial through other
means:

- The user picks up the handset after dialing (ala PBX phones).
- A timer pops in the digit collection routine on the UA (ala PSTN digit collectors).
- The user hits an extra button to tell the device their done, so it doesn't have
to read their mind as to when they may be finished (ala cell phones, and PBX phones).

Really, no matter what, you're going to have to have a timer or an explicit form of
"punctuation" (ie a TALK/SEND/CALL/DIAL button) involved in the digit collection
algorithm. Otherwise, how do you know when a user is continuing to enter digits, or
has simply entered an invalid number? To use Henning's example of dialing 6744 to
ring his admin, what do you expect the UA to do when he dials 674? Sit there forever
and wait for the other four to drop?

You can still offer an auto-completed set of dialed digits for the user, without
having to understand what it is that they're dialing.

As for knowing how to form a canonical URL, other than some sort of very bland BCP,
such as, use a tel url with a particular, one-size-fits-all, phone context setting,
I doubt you'll be able to satisfy all of the demands that each vendor/customer may
have in being able to route calls in a predictable manner.

As for the routing to the correct outbound proxy, it seems very artificial to say that
a reason for having a dialplan in the UA is so that you can select an outbound proxy
by making the election as part of the dialed digits.

I could argue that the functionality you describe can also be reasonably handled by
representing each outbound proxy as a "virtual line". People are used to the idea,
that to use your example, personal calls should not go through their business's PBX,
and vice-versa, that they have, at a minimum, two-lines (and possibly two phones).
One is hooked up to the business PBX, the other through another carrier for private
calls. Reducing this down to virtual lines on the UA seems reasonably logical to me.
You select the "private" line (which is configured to your private service provider),
and then dial to make a personal call. Likewise, you select the "business" line (which
is configured to your IP PBX), to make business calls.

To me, there's a big difference in the UA being able to correctly format it's request
to the outbound proxy, and the UA having to actually *understand* what is sent to the
local outbound proxy. A dialplan, to me, infers that the UA has to actually understand
to some degree, and interpret the digits prior to translations at the proxy. This means
that some degree of translations are possible at two points in the network, and now I
have to go about keeping them in-sync with one another to get predictable results. Seems
like a dangerous mess, and one that the phone system has done without for a very long
time.

If a dialplan is simply something that we use to format the digit stream into a standard,
no matter what they dialed, layout so that the proxy can expect a predictable format that
it will receive the digit stream in, that seems much more feasible and reasonable. If this
is the case, SIP itself can be considered a dialplan, as the digits must be transported in
a legally formatted SIP request.

Regards,

Brian



-----Original Message-----
From: Daniel G. Petrie [mailto:dpetrie@pingtel.com]
Sent: Friday, January 10, 2003 4:52 PM
To: Rosen, Brian
Cc: 'Henning Schulzrinne'; Adam Roach; 'Paul Kyzivat';
'sipping@ietf.org'
Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was
RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt


There is actually a third reason to have dial plans on the UA.  The
first two have already been brought up:

1) To know when the user is done dialing
2) To know how to form a canonical URL (tel , sip or sips)
3) To know how to route the INVITE to the correct outbound proxy

On the first one, knowing when the user is done dialing,  I am afraid, as
Cullen pointed out, the market (at least in North America) wants a phone
that knows when the user is done dialing.  There are too many people
who still like the pre-cell phone metaphor. Sorry but the people on this
list do not buy enough phones to decide this one ;-).

The UA needs to know how it is going to form a cannonical URL from
the mess of characters and digits the user entered.  So as Brian pointed
out you need some regexp to transform the entered characters into a
URL.   Well guess what, every proxy vendor wants this to be a little
different.   Some want short strings (AKA extensions) transformed
differently
than long strings (AKA E.164 numbers).  So call it what you want you
end up with the equivalent of a dial plan.  The best we can do here is
to come of with a standardized (or call it BCP) way to write the
transforms.  We can write a standard that says this is the one and
only transform, but no phone vendor that has a dial plan mechanism
will be able to drop their dial plan support because they have customers
using it.  However I am sure the market would be happy to push
vendors to support a standardized dial plan description mechanism.

The third use of dial plans is for routing purposes.  I know!  That is
what the proxy is supposed to do.  However there are several uses
for doing some simple routing from the phone base upon the "dialed
string":

a) Functional routing: where based upon the purpose of the call the
user wants the call routed differently.  For example I have a phone
at home from which I make personal calls via my favorite service
provider and from which I make business calls via my enterprise
IP PBX.  I want my private/personal calls private and my business
does not want to pay for my personal calls.   A simple, familiar
metaphor for this is to use a dialing prefix (e.g. dial 9 and number
for business call, dial 8 and number for personal calls).  The alternatives

would be to sell home/office users two phones (I wish that would fly)
or put a proxy in every home/office (I would not mind selling that
many proxies if that would fly as well).

b) Load balancing routing:  based upon my dialed string I may
want to use a different out bound proxy.   Domestic US calls
go to one proxy, international calls go to another, 911/emergency
calls go directly to the local emergency gateway.  Can this be
done by the proxy? Sometimes, if I can get to it, but once you
have a dial plan on the phone, this is just about free from
both an implementation and compute cost perspective (e.g.
loose routing with a Route header in the regexp/transform).

I am happy to remove functionality from the UA and not support
it, but I am afraid the dial plan is here to stay in the UA.  I  think
our best path forward is with a standard way to specify the dial plan
transforms.



"Rosen, Brian" wrote:

> Actually, I'm happy with a "Dial" button.
>
> I'll note most existing SIP phones don't do this (or at least don't
> have a physical "Dial" button, I've seen some with softkeys).
>
> However, the issue remains.  If I dial 6744 on my sip phone (and press
> dial), the sipphone on my admin's desk should ring.  I should not have
> to dial +17247426744.  The fact that I dialed a 4 digit number with
> a 6 as the starting digit tells my system that it is an internal
> extension.  A dial plan is the thing that "knows" this.
>
> What do you want to have happen:
> 1) tel:6744; context=+1724742
> 2) tel:6744; context=marconi-pittsburgh-local-extension
> 3) tel:+17247426744
>
> Note the last is problematic.  As Mike Pierce points out, not all
> extensions have E.164s
>
> And, to amplify the thread that started this, how many identities does
> my admin's UA have to understand?
>
> Again, I'm not opposed to making dial string expansion be a requirement
> of the UA, as long as we standardize the form of the expansion, and the
> mechanism by which the UA learns it.
>
> Brian
>
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Thursday, January 09, 2003 9:07 PM
> > To: Adam Roach
> > Cc: Rosen, Brian; 'Paul Kyzivat'; 'sipping@ietf.org'
> > Subject: Re: [Sipping] Do Phones Have Dial Plans, or do
> > Proxies map? was
> > RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> >
> >
> > In case there's doubt: I was not suggesting that we do this. I was
> > trying to find out from Brian what he meant, since the two
> > problem have
> > very different solution sets. The 'abbreviated dialing' case requires
> > nothing except a suitable URI scheme and the translation
> > services of an
> > outbound proxy.
> >
> > Adam Roach wrote:
> > >>- Recognizing patterns so that one can keep the old
> > >>"no-need-to-hit-dial" user interface.
> > >
> > >
> > > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!
> > >
> > > No!
> > >
> > > Cell phones have sufficiently trained the public that it's
> > > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER"
> > > after a phone number. It makes life so much easier for user
> > > interface designers and users alike. For the love of all that
> > > is good, let's not encourage backsliding.
> > >
> > > /a
> >
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

------_=_NextPart_001_01C2BDB0.AFC062F0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 17 05:26:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17510 for ; Fri, 17 Jan 2003 05:26:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HAfhk19261 for sipping-archive@odin.ietf.org; Fri, 17 Jan 2003 05:41:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HAfgJ19258 for ; Fri, 17 Jan 2003 05:41:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17504 for ; Fri, 17 Jan 2003 05:25:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HAf0J19229; Fri, 17 Jan 2003 05:41:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HAdgJ19126 for ; Fri, 17 Jan 2003 05:39:42 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17455 for ; Fri, 17 Jan 2003 05:23:37 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H8U00H01SZR08@siemenscomms.co.uk> for sipping@ietf.org; Fri, 17 Jan 2003 10:26:21 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H8U00G2ASXUZ9@siemenscomms.co.uk>; Fri, 17 Jan 2003 10:25:06 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Jan 2003 10:25:19 +0000 Content-return: allowed Date: Fri, 17 Jan 2003 10:25:31 +0000 From: "Elwell, John" To: "'Mary Barnes'" , Mark Watson , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" , "'fluffy@cisco.com'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Mary, In-line. Regards, John > -----Original Message----- > From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] > Sent: 16 January 2003 20:40 > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > Subject: RE: History information privacy requirements > > > Hi John, > > I do understand your concerns and I think we agree that this is an > application issue. > I think what we need to do is to add some text in section 5 > (and actually I > think this text should replace what's currently the last > paragraph of that > section) highlighting that there may also be application > specific reasons > for not including the Request History Information in > responses, but that the > these reasons don't impose any additional requirements on the > protocol. I > think there is alot of overlap with the concerns you have > raised and the > general optionality aspects that are primarily controlled by > the application > and local policy as to whether the information is captured, > and if it is > captured whether it is included in requests beyond that domain or in > responses, etc. As with the optionality, I think we've > previously agreed > (and documented in the requirements) that the solution does > need to provide > some guidelines as to the aspects which must be addressed by > applications > making use of this capability. I can add similar wording to > section 5. [JRE] Good. I look forward to that in the next draft. > > As to what's needed in the solution draft to address this, > section 2.3.3 > does describe that whether the information is included in the > response is > also based upon local policy, which should thus encompass > these privacy > aspects. [JRE] Yes, but there may also be cases where the proxy wishes to include information in the request sent downstream but not in the response sent upstream. It is not clear from the existing text that local policy could say different things for the two directions. Also this may mean intercepting History-info headers received in responses from downstream entities and stripping out those that this proxy originally inserted if policy dictates that they not be sent upstream. > > Mary. > > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Thursday, January 16, 2003 12:12 PM > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > 'Peterson, Jon' > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > Subject: RE: History information privacy requirements > > > Mary, > > To pick up on a particular point, you wrote: > > ".... There are examples where the actual DN of a destination isn't > revealed, but that's all due to application specific logic and not the > protocols (e.g call centers internally route calls without > providing an > externally dialable destination DN for the agents)...." > > Applying this same principle to SIP, application logic at the > proxy could > determine the retargeted to URI. There may be reasons for not > disclosing > this URI to the caller. Obviously one way to achieve this is > to omit history > information altogether. Then the caller will never discover the > retargeted-to URI unless the UAS sends it back, but RFC 3323 > provides the > UAS with a way of preventing that. However, there may be good > reason why the > proxy will wish to place history information in the request > before sending > it on downstream, e.g., to prevent retrying targets that have > already been > tried, to advise the callee where the call has come from. So > there may be a > requirement to send history information downstream but > prevent it going > upstream back to the caller. Either there has to be a > protocol solution to > indicate this privacy requirement to downstream proxies and > the UAS, or the > retargeting proxy has to be responsible for removing any > history information > that might compromise the privacy requirement. Unfortunately > the latter > works only for a proxy, not a redirect, but perhaps redirection is > inappropriate in this situation (since the redirection > request could reach > the UAC). > > So even if we say that we don't need protocol enhancements as > such, the > section of the solution document that describes proxy > behaviour should point > out the possible need to remove upstream history information. > > I guess most of the additional privacy requirements I mentioned can be > solved by appropriate proxy behaviour without requiring any additional > protocol elements. But I had expected these requirements to > be laid down in > the requirements document and text in the solutions document > indicating what > action needs to be taken to fulfil these requirements. > > Concerning regulatory requirements, these are not my primary > concern. Even > if there is no regulatory requirement governing a certain > aspect of privacy, > there may be business requirements, as in the example above > where there is a > requirement not to reveal the identity of a call centre agent. > > Regards, > > John > > John Elwell > e-mail: mailto:john.elwell@siemens.com > > > ----remainder of thread deleted------ > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 17 07:07:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18962 for ; Fri, 17 Jan 2003 07:07:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HCN2t25254 for sipping-archive@odin.ietf.org; Fri, 17 Jan 2003 07:23:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HCN1J25251 for ; Fri, 17 Jan 2003 07:23:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18892 for ; Fri, 17 Jan 2003 07:06:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HCLHJ25192; Fri, 17 Jan 2003 07:21:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HCKvJ25169 for ; Fri, 17 Jan 2003 07:20:57 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18848 for ; Fri, 17 Jan 2003 07:04:50 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0HC7qK27990; Fri, 17 Jan 2003 12:07:52 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 12:07:52 -0000 Message-ID: From: "Mark Watson" To: "'Elwell, John'" , "Mary Barnes" , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" , "'fluffy@cisco.com'" Date: Fri, 17 Jan 2003 12:07:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE21.0EE327A2" Subject: [Sipping] RE: History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BE21.0EE327A2 Content-Type: text/plain; charset="iso-8859-1" John, All, John suggests there may be a requirement for a proxy to 'strip out' History-Info from a response as that response goes past. I think we should be clear that this happens as a result of local policy (related to privacy) *at the proxy doing the stripping*, and not policy somehow communicated from elsewhere. What we need to avoid is cases where a proxy knows there is some privacy restriction associated with a piece of information, but it includes it in the message anyway, and 'trusts' a later proxy to remove it. At least this work should not assume such trust relationships. I think it would be sufficient for the Request History work to require that information which is known to be subject to a privacy requirement is just not sent - and by 'sending' I include passing on received information when you forward a request/response. Other work (the generic privacy solution) can provide generic mechanisms for sending information subject to privacy requirements around the network. Only two ways to do this: 1) Encrypt it with a key known only to entities 'trusted' to have the information 2) Send the message (securly) to an entity known to be able to provide the required privacy protection (i.e. privacy service). So, as far as Request History goes, do we need to say any more than 'local policy at a proxy may identify privacy requirements associated with Request History information. Request History information subject to privacy requirements shall not be included in outgoing messages unless it is protected as described in .' ...Mark > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 17 January 2003 10:26 > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > 'Peterson, Jon' > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > Subject: RE: History information privacy requirements > > > Mary, > > In-line. > > Regards, > > John > > -----Original Message----- > > From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] > > Sent: 16 January 2003 20:40 > > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > Subject: RE: History information privacy requirements > > > > > > Hi John, > > > > I do understand your concerns and I think we agree that this is an > > application issue. > > I think what we need to do is to add some text in section 5 > > (and actually I > > think this text should replace what's currently the last > > paragraph of that > > section) highlighting that there may also be application > > specific reasons > > for not including the Request History Information in > > responses, but that the > > these reasons don't impose any additional requirements on the > > protocol. I > > think there is alot of overlap with the concerns you have > > raised and the > > general optionality aspects that are primarily controlled by > > the application > > and local policy as to whether the information is captured, > > and if it is > > captured whether it is included in requests beyond that domain or in > > responses, etc. As with the optionality, I think we've > > previously agreed > > (and documented in the requirements) that the solution does > > need to provide > > some guidelines as to the aspects which must be addressed by > > applications > > making use of this capability. I can add similar wording to > > section 5. > > [JRE] Good. I look forward to that in the next draft. > > > > > As to what's needed in the solution draft to address this, > > section 2.3.3 > > does describe that whether the information is included in the > > response is > > also based upon local policy, which should thus encompass > > these privacy > > aspects. > > [JRE] Yes, but there may also be cases where the proxy wishes > to include > information in the request sent downstream but not in the > response sent > upstream. It is not clear from the existing text that local > policy could say > different things for the two directions. Also this may mean > intercepting > History-info headers received in responses from downstream > entities and > stripping out those that this proxy originally inserted if > policy dictates > that they not be sent upstream. > > > > > Mary. > > > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Thursday, January 16, 2003 12:12 PM > > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > > 'Peterson, Jon' > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > Subject: RE: History information privacy requirements > > > > > > Mary, > > > > To pick up on a particular point, you wrote: > > > > ".... There are examples where the actual DN of a destination isn't > > revealed, but that's all due to application specific logic > and not the > > protocols (e.g call centers internally route calls without > > providing an > > externally dialable destination DN for the agents)...." > > > > Applying this same principle to SIP, application logic at the > > proxy could > > determine the retargeted to URI. There may be reasons for not > > disclosing > > this URI to the caller. Obviously one way to achieve this is > > to omit history > > information altogether. Then the caller will never discover the > > retargeted-to URI unless the UAS sends it back, but RFC 3323 > > provides the > > UAS with a way of preventing that. However, there may be good > > reason why the > > proxy will wish to place history information in the request > > before sending > > it on downstream, e.g., to prevent retrying targets that have > > already been > > tried, to advise the callee where the call has come from. So > > there may be a > > requirement to send history information downstream but > > prevent it going > > upstream back to the caller. Either there has to be a > > protocol solution to > > indicate this privacy requirement to downstream proxies and > > the UAS, or the > > retargeting proxy has to be responsible for removing any > > history information > > that might compromise the privacy requirement. Unfortunately > > the latter > > works only for a proxy, not a redirect, but perhaps redirection is > > inappropriate in this situation (since the redirection > > request could reach > > the UAC). > > > > So even if we say that we don't need protocol enhancements as > > such, the > > section of the solution document that describes proxy > > behaviour should point > > out the possible need to remove upstream history information. > > > > I guess most of the additional privacy requirements I > mentioned can be > > solved by appropriate proxy behaviour without requiring any > additional > > protocol elements. But I had expected these requirements to > > be laid down in > > the requirements document and text in the solutions document > > indicating what > > action needs to be taken to fulfil these requirements. > > > > Concerning regulatory requirements, these are not my primary > > concern. Even > > if there is no regulatory requirement governing a certain > > aspect of privacy, > > there may be business requirements, as in the example above > > where there is a > > requirement not to reveal the identity of a call centre agent. > > > > Regards, > > > > John > > > > John Elwell > > e-mail: mailto:john.elwell@siemens.com > > > > > > ----remainder of thread deleted------ > > > ------_=_NextPart_001_01C2BE21.0EE327A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: History information privacy requirements

John, All,

John suggests there may be a requirement for a proxy = to 'strip out' History-Info from a response as that response goes past. = I think we should be clear that this happens as a result of local = policy (related to privacy) *at the proxy doing the stripping*, and not = policy somehow communicated from elsewhere.

What we need to avoid is cases where a proxy knows = there is some privacy restriction associated with a piece of = information, but it includes it in the message anyway, and 'trusts' a = later proxy to remove it. At least this work should not assume such = trust relationships.

I think it would be sufficient for the Request = History work to require that information which is known to be subject = to a privacy requirement is just not sent - and by 'sending' I include = passing on received information when you forward a = request/response.

Other work (the generic privacy solution) can provide = generic mechanisms for sending information subject to privacy = requirements around the network. Only two ways to do this:

1) Encrypt it with a key known only to entities = 'trusted' to have the information
2) Send the message (securly) to an entity known to = be able to provide the required privacy protection (i.e. privacy = service).

So, as far as Request History goes, do we need to say = any more than 'local policy at a proxy may identify privacy = requirements associated with Request History information. Request = History information subject to privacy requirements shall not be = included in outgoing messages unless it is protected as described in = <general privacy mechanism>.'

...Mark

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: 17 January 2003 10:26
> To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark = [MOP:EP10:EXCH];
> 'Peterson, Jon'
> Cc: 'sipping@ietf.org'; = 'fluffy@cisco.com'
> Subject: RE: History information privacy = requirements
>
>
> Mary,
>
> In-line.
>
> Regards,
>
> John
> > -----Original Message-----
> > From: Mary Barnes [mailto:mbarnes@nortelnetworks= .com]
> > Sent: 16 January 2003 20:40
> > To: 'Elwell, John'; Mark Watson; = 'Peterson, Jon'
> > Cc: 'sipping@ietf.org'; = 'fluffy@cisco.com'
> > Subject: RE: History information privacy = requirements
> >
> >
> > Hi John,
> >
> > I do understand your concerns and I think = we agree that this is an
> > application issue.
> > I think what we need to do is to add some = text in section 5
> > (and actually I
> > think this text should replace what's = currently the last
> > paragraph of that
> > section) highlighting that there may also = be application
> > specific reasons
> > for not including the Request History = Information in
> > responses, but that the
> > these reasons don't impose any additional = requirements on the
> > protocol.  I
> > think there is alot of overlap with the = concerns you have
> > raised and the
> > general optionality aspects that are = primarily controlled by
> > the application
> > and local policy as to whether the = information is captured,
> > and if it is
> > captured whether it is included in = requests beyond that domain or in
> > responses, etc. As with the optionality, I = think we've
> > previously agreed
> > (and documented in the requirements) that = the solution does
> > need to provide
> > some guidelines as to the aspects which = must be addressed by
> > applications
> > making use of this capability.  I can = add similar wording to
> > section 5.
>
> [JRE] Good. I look forward to that in the next = draft.
>
> >
> > As to what's needed in the solution draft = to address this,
> > section 2.3.3
> > does describe that whether the information = is included in the
> > response is
> > also based upon local policy, which should = thus encompass
> > these privacy
> > aspects.
>
> [JRE] Yes, but there may also be cases where = the proxy wishes
> to include
> information in the request sent downstream but = not in the
> response sent
> upstream. It is not clear from the existing = text that local
> policy could say
> different things for the two directions. Also = this may mean
> intercepting
> History-info headers received in responses from = downstream
> entities and
> stripping out those that this proxy originally = inserted if
> policy dictates
> that they not be sent upstream.
>
> >
> > Mary.
> >
> >
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens.com]
> > Sent: Thursday, January 16, 2003 12:12 = PM
> > To: Barnes, Mary [NGC:B602:EXCH]; Watson, = Mark [MOP:EP10:EXCH];
> > 'Peterson, Jon'
> > Cc: 'sipping@ietf.org'; = 'fluffy@cisco.com'
> > Subject: RE: History information privacy = requirements
> >
> >
> > Mary,
> > 
> > To pick up on a particular point, you = wrote:
> > 
> > ".... There are examples where the = actual DN of a destination isn't
> > revealed, but that's all due to = application specific logic
> and not the
> > protocols (e.g call centers internally = route calls without
> > providing an
> > externally dialable destination DN for the = agents)...."
> > 
> > Applying this same principle to SIP, = application logic at the
> > proxy could
> > determine the retargeted to URI. There may = be reasons for not
> > disclosing
> > this URI to the caller. Obviously one way = to achieve this is
> > to omit history
> > information altogether. Then the caller = will never discover the
> > retargeted-to URI unless the UAS sends it = back, but RFC 3323
> > provides the
> > UAS with a way of preventing that. = However, there may be good
> > reason why the
> > proxy will wish to place history = information in the request
> > before sending
> > it on downstream, e.g., to prevent = retrying targets that have
> > already been
> > tried, to advise the callee where the call = has come from. So
> > there may be a
> > requirement to send history information = downstream but
> > prevent it going
> > upstream back to the caller. Either there = has to be a
> > protocol solution to
> > indicate this privacy requirement to = downstream proxies and
> > the UAS, or the
> > retargeting proxy has to be responsible = for removing any
> > history information
> > that might compromise the privacy = requirement. Unfortunately
> > the latter
> > works only for a proxy, not a redirect, = but perhaps redirection is
> > inappropriate in this situation (since the = redirection
> > request could reach
> > the UAC).
> > 
> > So even if we say that we don't need = protocol enhancements as
> > such, the
> > section of the solution document that = describes proxy
> > behaviour should point
> > out the possible need to remove upstream = history information.
> > 
> > I guess most of the additional privacy = requirements I
> mentioned can be
> > solved by appropriate proxy behaviour = without requiring any
> additional
> > protocol elements. But I had expected = these requirements to
> > be laid down in
> > the requirements document and text in the = solutions document
> > indicating what
> > action needs to be taken to fulfil these = requirements.
> > 
> > Concerning regulatory requirements, these = are not my primary
> > concern. Even
> > if there is no regulatory requirement = governing a certain
> > aspect of privacy,
> > there may be business requirements, as in = the example above
> > where there is a
> > requirement not to reveal the identity of = a call centre agent.
> > 
> > Regards,
> > 
> > John
> >
> > John Elwell
> > e-mail: mailto:john.elwell@siemens.com
> > <mailto:john.elwell@siemens.com> 
> > 
> > ----remainder of thread = deleted------
> >
>

------_=_NextPart_001_01C2BE21.0EE327A2-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 17 12:37:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29451 for ; Fri, 17 Jan 2003 12:37:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HHqi217445 for sipping-archive@odin.ietf.org; Fri, 17 Jan 2003 12:52:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHqiJ17442 for ; Fri, 17 Jan 2003 12:52:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29423 for ; Fri, 17 Jan 2003 12:36:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHpiJ17395; Fri, 17 Jan 2003 12:51:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHncJ17279 for ; Fri, 17 Jan 2003 12:49:38 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29349 for ; Fri, 17 Jan 2003 12:33:24 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H8V00601CWXD0@siemenscomms.co.uk> for sipping@ietf.org; Fri, 17 Jan 2003 17:36:33 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H8V005LTCWW23@siemenscomms.co.uk>; Fri, 17 Jan 2003 17:36:32 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Jan 2003 17:36:46 +0000 Content-return: allowed Date: Fri, 17 Jan 2003 17:36:52 +0000 From: "Elwell, John" To: "'Mark Watson'" , Mary Barnes , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" , "'fluffy@cisco.com'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Mark, Although I think we have agreement on the general principles, I am still concerned that the text you propose does not explicitly mention removing information from responses. Regards, John -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 17 January 2003 12:08 To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon' Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' Subject: RE: History information privacy requirements John, All, John suggests there may be a requirement for a proxy to 'strip out' History-Info from a response as that response goes past. I think we should be clear that this happens as a result of local policy (related to privacy) *at the proxy doing the stripping*, and not policy somehow communicated from elsewhere. What we need to avoid is cases where a proxy knows there is some privacy restriction associated with a piece of information, but it includes it in the message anyway, and 'trusts' a later proxy to remove it. At least this work should not assume such trust relationships. I think it would be sufficient for the Request History work to require that information which is known to be subject to a privacy requirement is just not sent - and by 'sending' I include passing on received information when you forward a request/response. Other work (the generic privacy solution) can provide generic mechanisms for sending information subject to privacy requirements around the network. Only two ways to do this: 1) Encrypt it with a key known only to entities 'trusted' to have the information 2) Send the message (securly) to an entity known to be able to provide the required privacy protection (i.e. privacy service). So, as far as Request History goes, do we need to say any more than 'local policy at a proxy may identify privacy requirements associated with Request History information. Request History information subject to privacy requirements shall not be included in outgoing messages unless it is protected as described in .' ...Mark > -----Original Message----- > From: Elwell, John [ mailto:john.elwell@siemens.com ] > Sent: 17 January 2003 10:26 > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > 'Peterson, Jon' > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > Subject: RE: History information privacy requirements > > > Mary, > > In-line. > > Regards, > > John > > -----Original Message----- > > From: Mary Barnes [ mailto:mbarnes@nortelnetworks.com ] > > Sent: 16 January 2003 20:40 > > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > Subject: RE: History information privacy requirements > > > > > > Hi John, > > > > I do understand your concerns and I think we agree that this is an > > application issue. > > I think what we need to do is to add some text in section 5 > > (and actually I > > think this text should replace what's currently the last > > paragraph of that > > section) highlighting that there may also be application > > specific reasons > > for not including the Request History Information in > > responses, but that the > > these reasons don't impose any additional requirements on the > > protocol. I > > think there is alot of overlap with the concerns you have > > raised and the > > general optionality aspects that are primarily controlled by > > the application > > and local policy as to whether the information is captured, > > and if it is > > captured whether it is included in requests beyond that domain or in > > responses, etc. As with the optionality, I think we've > > previously agreed > > (and documented in the requirements) that the solution does > > need to provide > > some guidelines as to the aspects which must be addressed by > > applications > > making use of this capability. I can add similar wording to > > section 5. > > [JRE] Good. I look forward to that in the next draft. > > > > > As to what's needed in the solution draft to address this, > > section 2.3.3 > > does describe that whether the information is included in the > > response is > > also based upon local policy, which should thus encompass > > these privacy > > aspects. > > [JRE] Yes, but there may also be cases where the proxy wishes > to include > information in the request sent downstream but not in the > response sent > upstream. It is not clear from the existing text that local > policy could say > different things for the two directions. Also this may mean > intercepting > History-info headers received in responses from downstream > entities and > stripping out those that this proxy originally inserted if > policy dictates > that they not be sent upstream. > > > > > Mary. > > > > > > -----Original Message----- > > From: Elwell, John [ mailto:john.elwell@siemens.com ] > > Sent: Thursday, January 16, 2003 12:12 PM > > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > > 'Peterson, Jon' > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > Subject: RE: History information privacy requirements > > > > > > Mary, > > > > To pick up on a particular point, you wrote: > > > > ".... There are examples where the actual DN of a destination isn't > > revealed, but that's all due to application specific logic > and not the > > protocols (e.g call centers internally route calls without > > providing an > > externally dialable destination DN for the agents)...." > > > > Applying this same principle to SIP, application logic at the > > proxy could > > determine the retargeted to URI. There may be reasons for not > > disclosing > > this URI to the caller. Obviously one way to achieve this is > > to omit history > > information altogether. Then the caller will never discover the > > retargeted-to URI unless the UAS sends it back, but RFC 3323 > > provides the > > UAS with a way of preventing that. However, there may be good > > reason why the > > proxy will wish to place history information in the request > > before sending > > it on downstream, e.g., to prevent retrying targets that have > > already been > > tried, to advise the callee where the call has come from. So > > there may be a > > requirement to send history information downstream but > > prevent it going > > upstream back to the caller. Either there has to be a > > protocol solution to > > indicate this privacy requirement to downstream proxies and > > the UAS, or the > > retargeting proxy has to be responsible for removing any > > history information > > that might compromise the privacy requirement. Unfortunately > > the latter > > works only for a proxy, not a redirect, but perhaps redirection is > > inappropriate in this situation (since the redirection > > request could reach > > the UAC). > > > > So even if we say that we don't need protocol enhancements as > > such, the > > section of the solution document that describes proxy > > behaviour should point > > out the possible need to remove upstream history information. > > > > I guess most of the additional privacy requirements I > mentioned can be > > solved by appropriate proxy behaviour without requiring any > additional > > protocol elements. But I had expected these requirements to > > be laid down in > > the requirements document and text in the solutions document > > indicating what > > action needs to be taken to fulfil these requirements. > > > > Concerning regulatory requirements, these are not my primary > > concern. Even > > if there is no regulatory requirement governing a certain > > aspect of privacy, > > there may be business requirements, as in the example above > > where there is a > > requirement not to reveal the identity of a call centre agent. > > > > Regards, > > > > John > > > > John Elwell > > e-mail: mailto:john.elwell@siemens.com > > < mailto:john.elwell@siemens.com > > > > > ----remainder of thread deleted------ > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 17 12:42:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29551 for ; Fri, 17 Jan 2003 12:42:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HHwN217782 for sipping-archive@odin.ietf.org; Fri, 17 Jan 2003 12:58:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHwMJ17779 for ; Fri, 17 Jan 2003 12:58:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29544 for ; Fri, 17 Jan 2003 12:42:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHv6J17689; Fri, 17 Jan 2003 12:57:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHuDJ17598 for ; Fri, 17 Jan 2003 12:56:13 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29513 for ; Fri, 17 Jan 2003 12:39:59 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0HHhCK00113; Fri, 17 Jan 2003 17:43:12 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 17:43:12 -0000 Message-ID: From: "Mark Watson" To: "'Elwell, John'" , "Mary Barnes" , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" , "'fluffy@cisco.com'" Date: Fri, 17 Jan 2003 17:43:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE4F.AB8D0A9A" Subject: [Sipping] RE: History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BE4F.AB8D0A9A Content-Type: text/plain; charset="iso-8859-1" Well, a response is an 'outgoing message' from the UAS and every proxy it passes through. So the text below certainly includes removing information from a response. This would occur if a proxy was aware of some privacy requirement for the information that the original sender & other proxies in the path was not aware of. ...Mark > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 17 January 2003 17:37 > To: Watson, Mark [MOP:EP10:EXCH]; Barnes, Mary [NGC:B602:EXCH]; > 'Peterson, Jon' > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > Subject: RE: History information privacy requirements > > > Mark, > > Although I think we have agreement on the general principles, > I am still > concerned that the text you propose does not explicitly > mention removing > information from responses. > > Regards, > > John > > -----Original Message----- > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: 17 January 2003 12:08 > To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon' > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > Subject: RE: History information privacy requirements > > > > John, All, > > John suggests there may be a requirement for a proxy to 'strip out' > History-Info from a response as that response goes past. I > think we should > be clear that this happens as a result of local policy > (related to privacy) > *at the proxy doing the stripping*, and not policy somehow > communicated from > elsewhere. > > What we need to avoid is cases where a proxy knows there is > some privacy > restriction associated with a piece of information, but it > includes it in > the message anyway, and 'trusts' a later proxy to remove it. > At least this > work should not assume such trust relationships. > > I think it would be sufficient for the Request History work > to require that > information which is known to be subject to a privacy > requirement is just > not sent - and by 'sending' I include passing on received > information when > you forward a request/response. > > Other work (the generic privacy solution) can provide generic > mechanisms for > sending information subject to privacy requirements around > the network. Only > two ways to do this: > > 1) Encrypt it with a key known only to entities 'trusted' to have the > information > 2) Send the message (securly) to an entity known to be able > to provide the > required privacy protection (i.e. privacy service). > > So, as far as Request History goes, do we need to say any > more than 'local > policy at a proxy may identify privacy requirements > associated with Request > History information. Request History information subject to privacy > requirements shall not be included in outgoing messages unless it is > protected as described in .' > > ...Mark > > > -----Original Message----- > > From: Elwell, John [ mailto:john.elwell@siemens.com > ] > > Sent: 17 January 2003 10:26 > > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > > 'Peterson, Jon' > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > Subject: RE: History information privacy requirements > > > > > > Mary, > > > > In-line. > > > > Regards, > > > > John > > > -----Original Message----- > > > From: Mary Barnes [ mailto:mbarnes@nortelnetworks.com > ] > > > Sent: 16 January 2003 20:40 > > > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' > > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > > Subject: RE: History information privacy requirements > > > > > > > > > Hi John, > > > > > > I do understand your concerns and I think we agree that > this is an > > > application issue. > > > I think what we need to do is to add some text in section 5 > > > (and actually I > > > think this text should replace what's currently the last > > > paragraph of that > > > section) highlighting that there may also be application > > > specific reasons > > > for not including the Request History Information in > > > responses, but that the > > > these reasons don't impose any additional requirements on the > > > protocol. I > > > think there is alot of overlap with the concerns you have > > > raised and the > > > general optionality aspects that are primarily controlled by > > > the application > > > and local policy as to whether the information is captured, > > > and if it is > > > captured whether it is included in requests beyond that > domain or in > > > responses, etc. As with the optionality, I think we've > > > previously agreed > > > (and documented in the requirements) that the solution does > > > need to provide > > > some guidelines as to the aspects which must be addressed by > > > applications > > > making use of this capability. I can add similar wording to > > > section 5. > > > > [JRE] Good. I look forward to that in the next draft. > > > > > > > > As to what's needed in the solution draft to address this, > > > section 2.3.3 > > > does describe that whether the information is included in the > > > response is > > > also based upon local policy, which should thus encompass > > > these privacy > > > aspects. > > > > [JRE] Yes, but there may also be cases where the proxy wishes > > to include > > information in the request sent downstream but not in the > > response sent > > upstream. It is not clear from the existing text that local > > policy could say > > different things for the two directions. Also this may mean > > intercepting > > History-info headers received in responses from downstream > > entities and > > stripping out those that this proxy originally inserted if > > policy dictates > > that they not be sent upstream. > > > > > > > > Mary. > > > > > > > > > -----Original Message----- > > > From: Elwell, John [ mailto:john.elwell@siemens.com > ] > > > Sent: Thursday, January 16, 2003 12:12 PM > > > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > > > 'Peterson, Jon' > > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > > Subject: RE: History information privacy requirements > > > > > > > > > Mary, > > > > > > To pick up on a particular point, you wrote: > > > > > > ".... There are examples where the actual DN of a > destination isn't > > > revealed, but that's all due to application specific logic > > and not the > > > protocols (e.g call centers internally route calls without > > > providing an > > > externally dialable destination DN for the agents)...." > > > > > > Applying this same principle to SIP, application logic at the > > > proxy could > > > determine the retargeted to URI. There may be reasons for not > > > disclosing > > > this URI to the caller. Obviously one way to achieve this is > > > to omit history > > > information altogether. Then the caller will never discover the > > > retargeted-to URI unless the UAS sends it back, but RFC 3323 > > > provides the > > > UAS with a way of preventing that. However, there may be good > > > reason why the > > > proxy will wish to place history information in the request > > > before sending > > > it on downstream, e.g., to prevent retrying targets that have > > > already been > > > tried, to advise the callee where the call has come from. So > > > there may be a > > > requirement to send history information downstream but > > > prevent it going > > > upstream back to the caller. Either there has to be a > > > protocol solution to > > > indicate this privacy requirement to downstream proxies and > > > the UAS, or the > > > retargeting proxy has to be responsible for removing any > > > history information > > > that might compromise the privacy requirement. Unfortunately > > > the latter > > > works only for a proxy, not a redirect, but perhaps > redirection is > > > inappropriate in this situation (since the redirection > > > request could reach > > > the UAC). > > > > > > So even if we say that we don't need protocol enhancements as > > > such, the > > > section of the solution document that describes proxy > > > behaviour should point > > > out the possible need to remove upstream history information. > > > > > > I guess most of the additional privacy requirements I > > mentioned can be > > > solved by appropriate proxy behaviour without requiring any > > additional > > > protocol elements. But I had expected these requirements to > > > be laid down in > > > the requirements document and text in the solutions document > > > indicating what > > > action needs to be taken to fulfil these requirements. > > > > > > Concerning regulatory requirements, these are not my primary > > > concern. Even > > > if there is no regulatory requirement governing a certain > > > aspect of privacy, > > > there may be business requirements, as in the example above > > > where there is a > > > requirement not to reveal the identity of a call centre agent. > > > > > > Regards, > > > > > > John > > > > > > John Elwell > > > e-mail: mailto:john.elwell@siemens.com > > > > > < mailto:john.elwell@siemens.com > > > > > > > > ----remainder of thread deleted------ > > > > > > > ------_=_NextPart_001_01C2BE4F.AB8D0A9A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: History information privacy requirements

Well, a response is an 'outgoing message' from the = UAS and every proxy it passes through. So the text below certainly = includes removing information from a response. This would occur if a = proxy was aware of some privacy requirement for the information that = the original sender & other proxies in the path was not aware = of.

...Mark

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: 17 January 2003 17:37
> To: Watson, Mark [MOP:EP10:EXCH]; Barnes, Mary = [NGC:B602:EXCH];
> 'Peterson, Jon'
> Cc: 'sipping@ietf.org'; = 'fluffy@cisco.com'
> Subject: RE: History information privacy = requirements
>
>
> Mark,
> 
> Although I think we have agreement on the = general principles,
> I am still
> concerned that the text you propose does not = explicitly
> mention removing
> information from responses.
> 
> Regards,
> 
> John
>
> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks= .com]
> Sent: 17 January 2003 12:08
> To: 'Elwell, John'; Mary Barnes; 'Peterson, = Jon'
> Cc: 'sipping@ietf.org'; = 'fluffy@cisco.com'
> Subject: RE: History information privacy = requirements
>
>
>
> John, All,
>
> John suggests there may be a requirement for a = proxy to 'strip out'
> History-Info from a response as that response = goes past. I
> think we should
> be clear that this happens as a result of local = policy
> (related to privacy)
> *at the proxy doing the stripping*, and not = policy somehow
> communicated from
> elsewhere.
>
> What we need to avoid is cases where a proxy = knows there is
> some privacy
> restriction associated with a piece of = information, but it
> includes it in
> the message anyway, and 'trusts' a later proxy = to remove it.
> At least this
> work should not assume such trust = relationships.
>
> I think it would be sufficient for the Request = History work
> to require that
> information which is known to be subject to a = privacy
> requirement is just
> not sent - and by 'sending' I include passing = on received
> information when
> you forward a request/response.
>
> Other work (the generic privacy solution) can = provide generic
> mechanisms for
> sending information subject to privacy = requirements around
> the network. Only
> two ways to do this:
>
> 1) Encrypt it with a key known only to entities = 'trusted' to have the
> information
> 2) Send the message (securly) to an entity = known to be able
> to provide the
> required privacy protection (i.e. privacy = service).
>
> So, as far as Request History goes, do we need = to say any
> more than 'local
> policy at a proxy may identify privacy = requirements
> associated with Request
> History information. Request History = information subject to privacy
> requirements shall not be included in outgoing = messages unless it is
> protected as described in <general privacy = mechanism>.'
>
> ...Mark
>
> > -----Original Message-----
> > From: Elwell, John [ mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com> ]
> > Sent: 17 January 2003 10:26
> > To: Barnes, Mary [NGC:B602:EXCH]; Watson, = Mark [MOP:EP10:EXCH];
> > 'Peterson, Jon'
> > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' =
> > Subject: RE: History information privacy = requirements
> >
> >
> > Mary,
> >
> > In-line.
> >
> > Regards,
> >
> > John
> > > -----Original Message-----
> > > From: Mary Barnes [ mailto:mbarnes@nortelnetworks= .com
> <mailto:mbarnes@nortelnetworks= .com> ]
> > > Sent: 16 January 2003 20:40
> > > To: 'Elwell, John'; Mark Watson; = 'Peterson, Jon'
> > > Cc: 'sipping@ietf.org'; = 'fluffy@cisco.com'
> > > Subject: RE: History information = privacy requirements
> > >
> > >
> > > Hi John,
> > >
> > > I do understand your concerns and I = think we agree that
> this is an
> > > application issue.
> > > I think what we need to do is to add = some text in section 5
> > > (and actually I
> > > think this text should replace what's = currently the last
> > > paragraph of that
> > > section) highlighting that there may = also be application
> > > specific reasons
> > > for not including the Request History = Information in
> > > responses, but that the
> > > these reasons don't impose any = additional requirements on the
> > > protocol.  I
> > > think there is alot of overlap with = the concerns you have
> > > raised and the
> > > general optionality aspects that are = primarily controlled by
> > > the application
> > > and local policy as to whether the = information is captured,
> > > and if it is
> > > captured whether it is included in = requests beyond that
> domain or in
> > > responses, etc. As with the = optionality, I think we've
> > > previously agreed
> > > (and documented in the requirements) = that the solution does
> > > need to provide
> > > some guidelines as to the aspects = which must be addressed by
> > > applications
> > > making use of this capability.  = I can add similar wording to
> > > section 5.
> >
> > [JRE] Good. I look forward to that in the = next draft.
> >
> > >
> > > As to what's needed in the solution = draft to address this,
> > > section 2.3.3
> > > does describe that whether the = information is included in the
> > > response is
> > > also based upon local policy, which = should thus encompass
> > > these privacy
> > > aspects.
> >
> > [JRE] Yes, but there may also be cases = where the proxy wishes
> > to include
> > information in the request sent downstream = but not in the
> > response sent
> > upstream. It is not clear from the = existing text that local
> > policy could say
> > different things for the two directions. = Also this may mean
> > intercepting
> > History-info headers received in responses = from downstream
> > entities and
> > stripping out those that this proxy = originally inserted if
> > policy dictates
> > that they not be sent upstream.
> >
> > >
> > > Mary.
> > >
> > >
> > > -----Original Message-----
> > > From: Elwell, John [ mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com> ]
> > > Sent: Thursday, January 16, 2003 = 12:12 PM
> > > To: Barnes, Mary [NGC:B602:EXCH]; = Watson, Mark [MOP:EP10:EXCH];
> > > 'Peterson, Jon'
> > > Cc: 'sipping@ietf.org'; = 'fluffy@cisco.com'
> > > Subject: RE: History information = privacy requirements
> > >
> > >
> > > Mary,
> > > 
> > > To pick up on a particular point, you = wrote:
> > > 
> > > ".... There are examples where = the actual DN of a
> destination isn't
> > > revealed, but that's all due to = application specific logic
> > and not the
> > > protocols (e.g call centers = internally route calls without
> > > providing an
> > > externally dialable destination DN = for the agents)...."
> > > 
> > > Applying this same principle to SIP, = application logic at the
> > > proxy could
> > > determine the retargeted to URI. = There may be reasons for not
> > > disclosing
> > > this URI to the caller. Obviously one = way to achieve this is
> > > to omit history
> > > information altogether. Then the = caller will never discover the
> > > retargeted-to URI unless the UAS = sends it back, but RFC 3323
> > > provides the
> > > UAS with a way of preventing that. = However, there may be good
> > > reason why the
> > > proxy will wish to place history = information in the request
> > > before sending
> > > it on downstream, e.g., to prevent = retrying targets that have
> > > already been
> > > tried, to advise the callee where the = call has come from. So
> > > there may be a
> > > requirement to send history = information downstream but
> > > prevent it going
> > > upstream back to the caller. Either = there has to be a
> > > protocol solution to
> > > indicate this privacy requirement to = downstream proxies and
> > > the UAS, or the
> > > retargeting proxy has to be = responsible for removing any
> > > history information
> > > that might compromise the privacy = requirement. Unfortunately
> > > the latter
> > > works only for a proxy, not a = redirect, but perhaps
> redirection is
> > > inappropriate in this situation = (since the redirection
> > > request could reach
> > > the UAC).
> > > 
> > > So even if we say that we don't need = protocol enhancements as
> > > such, the
> > > section of the solution document that = describes proxy
> > > behaviour should point
> > > out the possible need to remove = upstream history information.
> > > 
> > > I guess most of the additional = privacy requirements I
> > mentioned can be
> > > solved by appropriate proxy behaviour = without requiring any
> > additional
> > > protocol elements. But I had expected = these requirements to
> > > be laid down in
> > > the requirements document and text in = the solutions document
> > > indicating what
> > > action needs to be taken to fulfil = these requirements.
> > > 
> > > Concerning regulatory requirements, = these are not my primary
> > > concern. Even
> > > if there is no regulatory requirement = governing a certain
> > > aspect of privacy,
> > > there may be business requirements, = as in the example above
> > > where there is a
> > > requirement not to reveal the = identity of a call centre agent.
> > > 
> > > Regards,
> > > 
> > > John
> > >
> > > John Elwell
> > > e-mail: mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com>
>
> > > < mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com> > 
> > > 
> > > ----remainder of thread deleted------ =
> > >
> >
>
>

------_=_NextPart_001_01C2BE4F.AB8D0A9A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 20 03:47:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14221 for ; Mon, 20 Jan 2003 03:47:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0K94Dc02448 for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 04:04:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K94CJ02445 for ; Mon, 20 Jan 2003 04:04:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14208 for ; Mon, 20 Jan 2003 03:46:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K92fJ02372; Mon, 20 Jan 2003 04:02:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8oWJ01592 for ; Mon, 20 Jan 2003 03:50:32 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13972 for ; Mon, 20 Jan 2003 03:33:03 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H90004017WAQO@siemenscomms.co.uk> for sipping@ietf.org; Mon, 20 Jan 2003 08:36:10 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H90003FI7W978@siemenscomms.co.uk>; Mon, 20 Jan 2003 08:36:10 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Jan 2003 08:36:26 +0000 Content-return: allowed Date: Mon, 20 Jan 2003 08:36:33 +0000 From: "Elwell, John" To: "'Mark Watson'" , Mary Barnes , "'Peterson, Jon'" Cc: "'sipping@ietf.org'" , "'fluffy@cisco.com'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: History information privacy requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Mark, I understand that "outgoing messages" includes responses, but the text talks only about "include" in outgoing messages, which might be interpreted as insertion into the response as opposed to passing information on in the response. Furthermore, we have to be careful when discussing passing information on in the response, since the condition "unless it is protected as described in " applies only to information provided by the proxy concerned (i.e., sent downstream in the request and received back again in the response). For this information, passing the information on in the response towards the upstream entity should indeed be subject to privacy protection and if not the information should be removed from the response. Of course, the proxy concerned cannot be responsible for privacy information inserted by other downstream entities and therefore such information can be passed on unconditionally. I think the words you propose, whilst "correct", do not adequately point out the implications. Therefore perhaps the words could be extended as follows: 'Local policy at a proxy may identify privacy requirements associated with Request History information. Request History information subject to privacy requirements shall not be included in outgoing messages unless it is protected as described in . Local policy can apply different rules to the inclusion of Request History information in the request and the inclusion of Request History information in the response. If Request History information is subject to privacy requirements in the response but not in the request, the proxy is responsible for removing from any received response any Request History information that this proxy inserted into the request.' Regards, John -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 17 January 2003 17:43 To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon' Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' Subject: RE: History information privacy requirements Well, a response is an 'outgoing message' from the UAS and every proxy it passes through. So the text below certainly includes removing information from a response. This would occur if a proxy was aware of some privacy requirement for the information that the original sender & other proxies in the path was not aware of. ...Mark > -----Original Message----- > From: Elwell, John [ mailto:john.elwell@siemens.com ] > Sent: 17 January 2003 17:37 > To: Watson, Mark [MOP:EP10:EXCH]; Barnes, Mary [NGC:B602:EXCH]; > 'Peterson, Jon' > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > Subject: RE: History information privacy requirements > > > Mark, > > Although I think we have agreement on the general principles, > I am still > concerned that the text you propose does not explicitly > mention removing > information from responses. > > Regards, > > John > > -----Original Message----- > From: Mark Watson [ mailto:mwatson@nortelnetworks.com ] > Sent: 17 January 2003 12:08 > To: 'Elwell, John'; Mary Barnes; 'Peterson, Jon' > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > Subject: RE: History information privacy requirements > > > > John, All, > > John suggests there may be a requirement for a proxy to 'strip out' > History-Info from a response as that response goes past. I > think we should > be clear that this happens as a result of local policy > (related to privacy) > *at the proxy doing the stripping*, and not policy somehow > communicated from > elsewhere. > > What we need to avoid is cases where a proxy knows there is > some privacy > restriction associated with a piece of information, but it > includes it in > the message anyway, and 'trusts' a later proxy to remove it. > At least this > work should not assume such trust relationships. > > I think it would be sufficient for the Request History work > to require that > information which is known to be subject to a privacy > requirement is just > not sent - and by 'sending' I include passing on received > information when > you forward a request/response. > > Other work (the generic privacy solution) can provide generic > mechanisms for > sending information subject to privacy requirements around > the network. Only > two ways to do this: > > 1) Encrypt it with a key known only to entities 'trusted' to have the > information > 2) Send the message (securly) to an entity known to be able > to provide the > required privacy protection (i.e. privacy service). > > So, as far as Request History goes, do we need to say any > more than 'local > policy at a proxy may identify privacy requirements > associated with Request > History information. Request History information subject to privacy > requirements shall not be included in outgoing messages unless it is > protected as described in .' > > ...Mark > > > -----Original Message----- > > From: Elwell, John [ mailto:john.elwell@siemens.com > < mailto:john.elwell@siemens.com > ] > > Sent: 17 January 2003 10:26 > > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > > 'Peterson, Jon' > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > Subject: RE: History information privacy requirements > > > > > > Mary, > > > > In-line. > > > > Regards, > > > > John > > > -----Original Message----- > > > From: Mary Barnes [ mailto:mbarnes@nortelnetworks.com > < mailto:mbarnes@nortelnetworks.com > ] > > > Sent: 16 January 2003 20:40 > > > To: 'Elwell, John'; Mark Watson; 'Peterson, Jon' > > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > > Subject: RE: History information privacy requirements > > > > > > > > > Hi John, > > > > > > I do understand your concerns and I think we agree that > this is an > > > application issue. > > > I think what we need to do is to add some text in section 5 > > > (and actually I > > > think this text should replace what's currently the last > > > paragraph of that > > > section) highlighting that there may also be application > > > specific reasons > > > for not including the Request History Information in > > > responses, but that the > > > these reasons don't impose any additional requirements on the > > > protocol. I > > > think there is alot of overlap with the concerns you have > > > raised and the > > > general optionality aspects that are primarily controlled by > > > the application > > > and local policy as to whether the information is captured, > > > and if it is > > > captured whether it is included in requests beyond that > domain or in > > > responses, etc. As with the optionality, I think we've > > > previously agreed > > > (and documented in the requirements) that the solution does > > > need to provide > > > some guidelines as to the aspects which must be addressed by > > > applications > > > making use of this capability. I can add similar wording to > > > section 5. > > > > [JRE] Good. I look forward to that in the next draft. > > > > > > > > As to what's needed in the solution draft to address this, > > > section 2.3.3 > > > does describe that whether the information is included in the > > > response is > > > also based upon local policy, which should thus encompass > > > these privacy > > > aspects. > > > > [JRE] Yes, but there may also be cases where the proxy wishes > > to include > > information in the request sent downstream but not in the > > response sent > > upstream. It is not clear from the existing text that local > > policy could say > > different things for the two directions. Also this may mean > > intercepting > > History-info headers received in responses from downstream > > entities and > > stripping out those that this proxy originally inserted if > > policy dictates > > that they not be sent upstream. > > > > > > > > Mary. > > > > > > > > > -----Original Message----- > > > From: Elwell, John [ mailto:john.elwell@siemens.com > < mailto:john.elwell@siemens.com > ] > > > Sent: Thursday, January 16, 2003 12:12 PM > > > To: Barnes, Mary [NGC:B602:EXCH]; Watson, Mark [MOP:EP10:EXCH]; > > > 'Peterson, Jon' > > > Cc: 'sipping@ietf.org'; 'fluffy@cisco.com' > > > Subject: RE: History information privacy requirements > > > > > > > > > Mary, > > > > > > To pick up on a particular point, you wrote: > > > > > > ".... There are examples where the actual DN of a > destination isn't > > > revealed, but that's all due to application specific logic > > and not the > > > protocols (e.g call centers internally route calls without > > > providing an > > > externally dialable destination DN for the agents)...." > > > > > > Applying this same principle to SIP, application logic at the > > > proxy could > > > determine the retargeted to URI. There may be reasons for not > > > disclosing > > > this URI to the caller. Obviously one way to achieve this is > > > to omit history > > > information altogether. Then the caller will never discover the > > > retargeted-to URI unless the UAS sends it back, but RFC 3323 > > > provides the > > > UAS with a way of preventing that. However, there may be good > > > reason why the > > > proxy will wish to place history information in the request > > > before sending > > > it on downstream, e.g., to prevent retrying targets that have > > > already been > > > tried, to advise the callee where the call has come from. So > > > there may be a > > > requirement to send history information downstream but > > > prevent it going > > > upstream back to the caller. Either there has to be a > > > protocol solution to > > > indicate this privacy requirement to downstream proxies and > > > the UAS, or the > > > retargeting proxy has to be responsible for removing any > > > history information > > > that might compromise the privacy requirement. Unfortunately > > > the latter > > > works only for a proxy, not a redirect, but perhaps > redirection is > > > inappropriate in this situation (since the redirection > > > request could reach > > > the UAC). > > > > > > So even if we say that we don't need protocol enhancements as > > > such, the > > > section of the solution document that describes proxy > > > behaviour should point > > > out the possible need to remove upstream history information. > > > > > > I guess most of the additional privacy requirements I > > mentioned can be > > > solved by appropriate proxy behaviour without requiring any > > additional > > > protocol elements. But I had expected these requirements to > > > be laid down in > > > the requirements document and text in the solutions document > > > indicating what > > > action needs to be taken to fulfil these requirements. > > > > > > Concerning regulatory requirements, these are not my primary > > > concern. Even > > > if there is no regulatory requirement governing a certain > > > aspect of privacy, > > > there may be business requirements, as in the example above > > > where there is a > > > requirement not to reveal the identity of a call centre agent. > > > > > > Regards, > > > > > > John > > > > > > John Elwell > > > e-mail: mailto:john.elwell@siemens.com > < mailto:john.elwell@siemens.com > > > > > < mailto:john.elwell@siemens.com > < mailto:john.elwell@siemens.com > > > > > > > > ----remainder of thread deleted------ > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 20 06:31:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16691 for ; Mon, 20 Jan 2003 06:31:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KBmYx12852 for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 06:48:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBmYJ12849 for ; Mon, 20 Jan 2003 06:48:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16613 for ; Mon, 20 Jan 2003 06:31:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBlkJ12805; Mon, 20 Jan 2003 06:47:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KBknJ12726 for ; Mon, 20 Jan 2003 06:46:49 -0500 Received: from mip.miptel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16424 for ; Mon, 20 Jan 2003 06:29:14 -0500 (EST) Received: from khlee ([61.250.222.86]) by mip.miptel.com (8.11.3/8.11.3) with ESMTP id h0KBhbF05464 for ; Mon, 20 Jan 2003 20:43:37 +0900 From: "Lee Kyung Hee" To: Date: Mon, 20 Jan 2003 20:31:12 +0900 Message-ID: <000001c2c077$6fa41260$56defa3d@khlee> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C2C0C2.DF8D4100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sipping] rfc3323 - privacy include TLS, S/MIME? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2C0C2.DF8D4100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Privacy include TLS, S/MIME? We want implement rfc2833. So then, Do we must implement TLS, S/MIME?? Best regards. Lee Kyung Hee. ------=_NextPart_000_0001_01C2C0C2.DF8D4100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Privacy include TLS, S/MIME?

We want implement = rfc2833.

So then, Do = we must implement TLS, S/MIME??

 

Best = regards.

Lee Kyung Hee.

------=_NextPart_000_0001_01C2C0C2.DF8D4100-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 20 09:28:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20937 for ; Mon, 20 Jan 2003 09:28:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KEjGx23549 for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 09:45:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEjGJ23546 for ; Mon, 20 Jan 2003 09:45:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20924 for ; Mon, 20 Jan 2003 09:27:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEiLJ23486; Mon, 20 Jan 2003 09:44:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JItNJ15476 for ; Sun, 19 Jan 2003 13:55:23 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23672 for ; Sun, 19 Jan 2003 13:38:11 -0500 (EST) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h0JIfah6014553 for ; Sun, 19 Jan 2003 12:41:36 -0600 (CST) Received: from fisherlatitude ([135.210.86.178]) by maillennium.att.com (mailgw1) with SMTP id <20030119184105gw100kschue>; Sun, 19 Jan 2003 18:41:05 +0000 From: "Steve Fisher" To: "'Eric Burger'" Cc: Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Sun, 19 Jan 2003 13:41:26 -0500 Message-ID: <000001c2bfea$6021de40$b256d287@fisherlatitude> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D2DF65E@zoe.office.snowshore.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, I've been meeting with several colleagues over the past few weeks discussing KPML and we had some comments and questions that we thought we'd pass on: 1) We very much prefer the use of SIP NOTIFY, instead of HTTP, to notify application servers when a UA has detected the specified key presses. Given that all entities, and the network infrastructure that connects them, are already SIP-capable, it would be much simpler to have the notification also be over SIP. Further, it seems to us that this would be an appropriate use of the NOTIFY method, and thus would not be abusing SIP simply for convenience. 2) It seems to us that the "subscription" could be established as part of the session setup process (and not via a SUBSCRIBE, for the reasons you indicated). This also seems to us to be a reasonable use of SIP, since detecting key presses is one aspect of the session. We envisioned that this would occur along the lines of what's described in draft-jennings-sip-app-info-00, although the KPML would be "inlined", rather than fetched via HTTP. 3) The other area of debate that we had concerned the appropriate place to put the logic for managing the "digit maps". In the KPML draft, you wrote: An interested application could request notifications of every key press. However, many of the use cases for such signaling has the application interested in only one or a few keystrokes. Thus we need a mechanism for specifying to the user device what stimulus the application would like notification of. Our concern is that the specific mechanism defined in KPML will impose significant requirements on the KPML interpreters, which will frequently be either inexpensive devices, or will be PSTN gateways that are optimized for media processing at scale, and not for the type of processing required by KPML. We were wondering if you are open to an alternative approach, in which the application servers indicate to the device which key presses they're interested in, but not the ordering of those digits, leaving it to the application servers to manage the sequencing of the key presses (checking intervals, etc.). Thus, this mechanism would not be as simple as "signal for all key presses", but would not require that the devices maintain any state other than the list of key presses and the name of the Application Server to NOTIFY (i.e. no state machines, regular expression interpreters, etc.). What do you think? Steve Fisher Division Manager AT&T Labs _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 20 18:11:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03874 for ; Mon, 20 Jan 2003 18:11:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KNSVB23098 for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 18:28:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNSVJ23095 for ; Mon, 20 Jan 2003 18:28:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03861 for ; Mon, 20 Jan 2003 18:10:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNRvJ23074; Mon, 20 Jan 2003 18:27:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNOeJ22905 for ; Mon, 20 Jan 2003 18:24:40 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03794 for ; Mon, 20 Jan 2003 18:06:53 -0500 (EST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0KNAH725092 for ; Mon, 20 Jan 2003 18:10:18 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Jan 2003 18:10:17 -0500 Message-ID: From: "Jain, Rajnish (Rajnish)" To: "'Steve Fisher'" , "'Eric Burger'" Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs a nd apps? Date: Mon, 20 Jan 2003 18:10:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Steve, Eric, I just wanted to add that, I second Steve's proposal wrt using SIP NOTIFY (w/ KPML inline) instead of HTTP POST for DTMF digit reporting. Rajnish -----Original Message----- From: Steve Fisher [mailto:sfisher1@att.com] Sent: Sunday, January 19, 2003 1:41 PM To: 'Eric Burger' Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Eric, I've been meeting with several colleagues over the past few weeks discussing KPML and we had some comments and questions that we thought we'd pass on: 1) We very much prefer the use of SIP NOTIFY, instead of HTTP, to notify application servers when a UA has detected the specified key presses. Given that all entities, and the network infrastructure that connects them, are already SIP-capable, it would be much simpler to have the notification also be over SIP. Further, it seems to us that this would be an appropriate use of the NOTIFY method, and thus would not be abusing SIP simply for convenience. 2) It seems to us that the "subscription" could be established as part of the session setup process (and not via a SUBSCRIBE, for the reasons you indicated). This also seems to us to be a reasonable use of SIP, since detecting key presses is one aspect of the session. We envisioned that this would occur along the lines of what's described in draft-jennings-sip-app-info-00, although the KPML would be "inlined", rather than fetched via HTTP. 3) The other area of debate that we had concerned the appropriate place to put the logic for managing the "digit maps". In the KPML draft, you wrote: An interested application could request notifications of every key press. However, many of the use cases for such signaling has the application interested in only one or a few keystrokes. Thus we need a mechanism for specifying to the user device what stimulus the application would like notification of. Our concern is that the specific mechanism defined in KPML will impose significant requirements on the KPML interpreters, which will frequently be either inexpensive devices, or will be PSTN gateways that are optimized for media processing at scale, and not for the type of processing required by KPML. We were wondering if you are open to an alternative approach, in which the application servers indicate to the device which key presses they're interested in, but not the ordering of those digits, leaving it to the application servers to manage the sequencing of the key presses (checking intervals, etc.). Thus, this mechanism would not be as simple as "signal for all key presses", but would not require that the devices maintain any state other than the list of key presses and the name of the Application Server to NOTIFY (i.e. no state machines, regular expression interpreters, etc.). What do you think? Steve Fisher Division Manager AT&T Labs _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 20 22:08:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07915 for ; Mon, 20 Jan 2003 22:08:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L3QFt03593 for sipping-archive@odin.ietf.org; Mon, 20 Jan 2003 22:26:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3QFJ03590 for ; Mon, 20 Jan 2003 22:26:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07909 for ; Mon, 20 Jan 2003 22:08:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3PcJ03543; Mon, 20 Jan 2003 22:25:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3OJJ03486 for ; Mon, 20 Jan 2003 22:24:19 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07859 for ; Mon, 20 Jan 2003 22:06:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Mon, 20 Jan 2003 22:09:53 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248669@zoe.office.snowshore.com> Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Thread-Index: AcLAkrzoIQKTCOLwTMuZkvJz9kq4UwAKUiIg From: "Eric Burger" To: "Steve Fisher" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0L3OJJ03487 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I fully agree on items 1 & 2 in your message, as it is the direction MSCML is going (NOTIFY for INFO). On item 3, I'm personally not that fond of the idea of an application doing per-digit collection. This is more especially so if the application server is doing timing related activities. Remember, SIP does not have timely delivery. For that matter, in a wireless network, you are virtually guaranteed to have SLOW signaling (as you will be traversing at least two proxies, probably more in reality). I would offer three possible directions to go: A. Use H.248: If you really want to manage digit detectors and get per-digit notifications, treat the gateway as a device. My guess is that you will find (1) you will use digit maps and (2) you can't do it, because two devices cannot control the same resources in H.248. B. Send RFC2833 events to the application: If the application wants digit events with timing, then it should get an RFC2833 stream. That may be easier for a cheap device to do than for it to have a KPML interpreter. This does constitute a "send everything" policy, however. On the other hand, once one goes down the road of sending digit masks (or maps), you might as well go all the way (see C, below). C. Use markup: There is an area of "It is, or it isn't." Either a device will be able to interpret KPML (which doesn't even really need DOM or SAX) or it won't. At some point one has to say that the device is "too stupid." That is, it isn't worth trying to run stuff on it. > -----Original Message----- > From: Steve Fisher [mailto:sfisher1@att.com] > Sent: Sunday, January 19, 2003 1:41 PM > To: Eric Burger > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Eric, > > I've been meeting with several colleagues over the past few weeks > discussing KPML and we had some comments and questions that we thought > we'd pass on: > > 1) We very much prefer the use of SIP NOTIFY, instead of > HTTP, to notify > application servers when a UA has detected the specified key presses. > Given that all entities, and the network infrastructure that connects > them, are already SIP-capable, it would be much simpler to have the > notification also be over SIP. Further, it seems to us that this would > be an appropriate use of the NOTIFY method, and thus would not be > abusing SIP simply for convenience. > > 2) It seems to us that the "subscription" could be established as part > of the session setup process (and not via a SUBSCRIBE, for the reasons > you indicated). This also seems to us to be a reasonable use of SIP, > since detecting key presses is one aspect of the session. We > envisioned > that this would occur along the lines of what's described in > draft-jennings-sip-app-info-00, although the KPML would be "inlined", > rather than fetched via HTTP. > > 3) The other area of debate that we had concerned the > appropriate place > to put the logic for managing the "digit maps". In the KPML draft, you > wrote: > > An interested application could request notifications of every > key > press. However, many of the use cases for such signaling has > the > application interested in only one or a few keystrokes. Thus we > > need a mechanism for specifying to the user device what stimulus > the > application would like notification of. > > Our concern is that the specific mechanism defined in KPML will impose > significant requirements on the KPML interpreters, which will > frequently > be either inexpensive devices, or will be PSTN gateways that are > optimized for media processing at scale, and not for the type of > processing required by KPML. We were wondering if you are open to an > alternative approach, in which the application servers indicate to the > device which key presses they're interested in, but not the > ordering of > those digits, leaving it to the application servers to manage the > sequencing of the key presses (checking intervals, etc.). Thus, this > mechanism would not be as simple as "signal for all key presses", but > would not require that the devices maintain any state other than the > list of key presses and the name of the Application Server to NOTIFY > (i.e. no state machines, regular expression interpreters, etc.). > > What do you think? > > Steve Fisher > Division Manager > AT&T Labs > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 21 12:25:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05951 for ; Tue, 21 Jan 2003 12:25:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LHhZb02382 for sipping-archive@odin.ietf.org; Tue, 21 Jan 2003 12:43:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHhZJ02379 for ; Tue, 21 Jan 2003 12:43:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05929 for ; Tue, 21 Jan 2003 12:25:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHgtJ02275; Tue, 21 Jan 2003 12:42:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHcNJ02006 for ; Tue, 21 Jan 2003 12:38:23 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05746 for ; Tue, 21 Jan 2003 12:20:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Tue, 21 Jan 2003 12:23:40 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097BE0@zoe.office.snowshore.com> Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Thread-Index: AcLA2R1RTPUJn9r/Ssq80ZoFb6yOXAAmJmog From: "Eric Burger" To: "Jain, Rajnish (Rajnish)" , "Steve Fisher" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h0LHcNJ02007 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit As far as delivering the script is concerned, draft-jennings-sipping-app-info addresses in-line delivery with the cid: type. I third the motion for SIP NOTIFY for reporting :-) The new draft should be out within 2 weeks. -----Original Message----- From: Jain, Rajnish (Rajnish) [mailto:rajnishjain@lucent.com] Sent: Mon 1/20/2003 6:10 PM To: 'Steve Fisher'; Eric Burger Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Steve, Eric, I just wanted to add that, I second Steve's proposal wrt using SIP NOTIFY (w/ KPML inline) instead of HTTP POST for DTMF digit reporting. Rajnish -----Original Message----- From: Steve Fisher [mailto:sfisher1@att.com] Sent: Sunday, January 19, 2003 1:41 PM To: 'Eric Burger' Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Eric, I've been meeting with several colleagues over the past few weeks discussing KPML and we had some comments and questions that we thought we'd pass on: 1) We very much prefer the use of SIP NOTIFY, instead of HTTP, to notify application servers when a UA has detected the specified key presses. Given that all entities, and the network infrastructure that connects them, are already SIP-capable, it would be much simpler to have the notification also be over SIP. Further, it seems to us that this would be an appropriate use of the NOTIFY method, and thus would not be abusing SIP simply for convenience. 2) It seems to us that the "subscription" could be established as part of the session setup process (and not via a SUBSCRIBE, for the reasons you indicated). This also seems to us to be a reasonable use of SIP, since detecting key presses is one aspect of the session. We envisioned that this would occur along the lines of what's described in draft-jennings-sip-app-info-00, although the KPML would be "inlined", rather than fetched via HTTP. 3) The other area of debate that we had concerned the appropriate place to put the logic for managing the "digit maps". In the KPML draft, you wrote: An interested application could request notifications of every key press. However, many of the use cases for such signaling has the application interested in only one or a few keystrokes. Thus we need a mechanism for specifying to the user device what stimulus the application would like notification of. Our concern is that the specific mechanism defined in KPML will impose significant requirements on the KPML interpreters, which will frequently be either inexpensive devices, or will be PSTN gateways that are optimized for media processing at scale, and not for the type of processing required by KPML. We were wondering if you are open to an alternative approach, in which the application servers indicate to the device which key presses they're interested in, but not the ordering of those digits, leaving it to the application servers to manage the sequencing of the key presses (checking intervals, etc.). Thus, this mechanism would not be as simple as "signal for all key presses", but would not require that the devices maintain any state other than the list of key presses and the name of the Application Server to NOTIFY (i.e. no state machines, regular expression interpreters, etc.). What do you think? Steve Fisher Division Manager AT&T Labs _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 21 12:34:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06228 for ; Tue, 21 Jan 2003 12:34:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LHqHS02849 for sipping-archive@odin.ietf.org; Tue, 21 Jan 2003 12:52:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHqHJ02846 for ; Tue, 21 Jan 2003 12:52:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06220 for ; Tue, 21 Jan 2003 12:34:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHpEJ02750; Tue, 21 Jan 2003 12:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LHogJ02715 for ; Tue, 21 Jan 2003 12:50:42 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06184 for ; Tue, 21 Jan 2003 12:32:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Tue, 21 Jan 2003 12:35:58 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097BE7@zoe.office.snowshore.com> Thread-Topic: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Thread-Index: AcLBUBKmAcj30MmOSb+CFfONFr6OlAAI1l3P From: "Eric Burger" To: "Steve Fisher" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h0LHogJ02716 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit KPML and MSCML will be revved within 2 weeks. In-line delivery of KPML is already covered in draft-jennings-sipping-app-info (the cid: scheme). In-line delivery of MSCML is already covered in draft-vandyke-mscml. -----Original Message----- From: Steve Fisher [mailto:sfisher1@att.com] Sent: Tue 1/21/2003 8:21 AM To: Eric Burger Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Eric, Thanks for the quick reply. Does the design team intend to create new versions of draft-burger-sipping-kpml-00 and draft-jennings-sip-app-info-00 to reflect "inline" KPML and the use of NOTIFY instead of HTTP? Also, do you plan on issuing a new version of the MSCML draft? Thanks! Steve -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Eric Burger Sent: Monday, January 20, 2003 10:10 PM To: Steve Fisher Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? I fully agree on items 1 & 2 in your message, as it is the direction MSCML is going (NOTIFY for INFO). On item 3, I'm personally not that fond of the idea of an application doing per-digit collection. This is more especially so if the application server is doing timing related activities. Remember, SIP does not have timely delivery. For that matter, in a wireless network, you are virtually guaranteed to have SLOW signaling (as you will be traversing at least two proxies, probably more in reality). I would offer three possible directions to go: A. Use H.248: If you really want to manage digit detectors and get per-digit notifications, treat the gateway as a device. My guess is that you will find (1) you will use digit maps and (2) you can't do it, because two devices cannot control the same resources in H.248. B. Send RFC2833 events to the application: If the application wants digit events with timing, then it should get an RFC2833 stream. That may be easier for a cheap device to do than for it to have a KPML interpreter. This does constitute a "send everything" policy, however. On the other hand, once one goes down the road of sending digit masks (or maps), you might as well go all the way (see C, below). C. Use markup: There is an area of "It is, or it isn't." Either a device will be able to interpret KPML (which doesn't even really need DOM or SAX) or it won't. At some point one has to say that the device is "too stupid." That is, it isn't worth trying to run stuff on it. > -----Original Message----- > From: Steve Fisher [mailto:sfisher1@att.com] > Sent: Sunday, January 19, 2003 1:41 PM > To: Eric Burger > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Eric, > > I've been meeting with several colleagues over the past few weeks > discussing KPML and we had some comments and questions that we thought > we'd pass on: > > 1) We very much prefer the use of SIP NOTIFY, instead of > HTTP, to notify > application servers when a UA has detected the specified key presses. > Given that all entities, and the network infrastructure that connects > them, are already SIP-capable, it would be much simpler to have the > notification also be over SIP. Further, it seems to us that this would > be an appropriate use of the NOTIFY method, and thus would not be > abusing SIP simply for convenience. > > 2) It seems to us that the "subscription" could be established as part > of the session setup process (and not via a SUBSCRIBE, for the reasons > you indicated). This also seems to us to be a reasonable use of SIP, > since detecting key presses is one aspect of the session. We > envisioned that this would occur along the lines of what's described > in draft-jennings-sip-app-info-00, although the KPML would be > "inlined", rather than fetched via HTTP. > > 3) The other area of debate that we had concerned the > appropriate place > to put the logic for managing the "digit maps". In the KPML draft, you > wrote: > > An interested application could request notifications of every key > press. However, many of the use cases for such signaling has > the > application interested in only one or a few keystrokes. Thus we > > need a mechanism for specifying to the user device what stimulus the > application would like notification of. > > Our concern is that the specific mechanism defined in KPML will impose > significant requirements on the KPML interpreters, which will > frequently be either inexpensive devices, or will be PSTN gateways > that are optimized for media processing at scale, and not for the type > of processing required by KPML. We were wondering if you are open to > an alternative approach, in which the application servers indicate to > the device which key presses they're interested in, but not the > ordering of > those digits, leaving it to the application servers to manage the > sequencing of the key presses (checking intervals, etc.). Thus, this > mechanism would not be as simple as "signal for all key presses", but > would not require that the devices maintain any state other than the > list of key presses and the name of the Application Server to NOTIFY > (i.e. no state machines, regular expression interpreters, etc.). > > What do you think? > > Steve Fisher > Division Manager > AT&T Labs > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 22 03:03:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18537 for ; Wed, 22 Jan 2003 03:03:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M8Lc501601 for sipping-archive@odin.ietf.org; Wed, 22 Jan 2003 03:21:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8LcJ01598 for ; Wed, 22 Jan 2003 03:21:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18529 for ; Wed, 22 Jan 2003 03:03:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8JWJ01478; Wed, 22 Jan 2003 03:19:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8ILJ01422 for ; Wed, 22 Jan 2003 03:18:21 -0500 Received: from wire.cs.nthu.edu.tw (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18426; Wed, 22 Jan 2003 02:59:53 -0500 (EST) From: shunchao@wire.cs.nthu.edu.tw Received: (from shunchao@localhost) by wire.cs.nthu.edu.tw (8.11.6/8.11.6) id h0M83SK20521; Wed, 22 Jan 2003 16:03:28 +0800 Date: Wed, 22 Jan 2003 16:03:28 +0800 To: sip@ietf.org, sipping@ietf.org Message-ID: <20030122160328.A20304@wire.cs.nthu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [Sipping] IEEE JSAC - All-IP WIRELESS NETWORKS , CALL FOR PAPERS Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , CALL FOR PAPERS IEEE Journal on Selected Areas in Communications ALL-IP WIRELESS NETWORKS IP (Internet Protocol), which is already a universal network-layer protocol for wireline packet networks, is becoming a promising universal network-layer protocol over all wireless systems. IP provides a globally successful open infrastructure for creating and providing services and applications. An all-IP wireless and wireline network could make wireless networks more robust, scalable, and cost effective. It will also enable the abundant applications and software technologies developed for IP networks to be used over wireless networks. Today's many different wireless systems, ranging from PANs (Personal Area Networks), wireless LANs (Local Area Networks) to wide-area cellular systems, are often not compatible with each other which makes it difficult for a user to roam from one radio system to another. No wireless technology has emerged as a common and long-term universal solution. With IP as the common network layer protocol, an IP-based mobile device (with multiple radio interfaces or software defined radio) could roam between different wireless systems. The papers in this issue will focus on state-of-the-art research in all-IP wireless networks. Submission for Beyond 3G (B3G) systems will be included. We solicit papers covering a variety of topics including, but not limited to, the following topics: o Systems and Architecture o Access Protocols o Transport Protocols o Signaling Protocols o Resource Management o Power Control and Management o QoS Provisioning o Security o Mobile VoIP o Video over Wireless Internet o Network Performance Analysis o Internetworking o System Integration Only original and unpublished research papers will be considered. Authors should follow the IEEE J-SAC manuscript format described in the Information for Authors on the inside back cover of any issue of J-SAC. There will be one round of reviews and acceptance will be limited to papers needing only moderate revisions. Prospective authors should submit a pdf version of their complete manuscript (which should be compressed if the file size exceeds 1 Mbyte) online via http://wire.cs.nthu.edu.tw/~jsac according to the following timetable: Manuscript Submission: FEBRUARY 1, 2003 Acceptance Notification: June 1, 2003 Final Manuscript Due: September 1, 2003 Publication: 1st Quarter 2004 Prathima Agrawal Telcordia Technologies Room 1J244B 445 South St Morristown, NJ 07960 USA Tao Zhang Telcordia Technologies Room 1J214B 445 South St Morristown, NJ 07960 USA Cormac J. Sreenan Dept of Computer Science University College Cork Cork, Ireland Jyh-Cheng Chen Dept of Computer Science and Inst of Communications Engineering National Tsing Hua Univ Hsinchu, Taiwan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jan 22 23:10:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16586 for ; Wed, 22 Jan 2003 23:10:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N4Sut12905 for sipping-archive@odin.ietf.org; Wed, 22 Jan 2003 23:28:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N4SuJ12902 for ; Wed, 22 Jan 2003 23:28:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16569 for ; Wed, 22 Jan 2003 23:10:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N4P8J12707; Wed, 22 Jan 2003 23:25:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N4NHJ12631 for ; Wed, 22 Jan 2003 23:23:17 -0500 Received: from mail.deldsl.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16336 for ; Wed, 22 Jan 2003 23:04:22 -0500 (EST) Received: from dexceldesigns.com ([202.131.154.221]) by mail.deldsl.com (8.11.0/8.8.7) with ESMTP id h0N9U6512404 for ; Thu, 23 Jan 2003 09:30:18 GMT Message-ID: <001a01c2c296$265a24c0$17010a64@DOMAIN.dexceldesigns.com> From: margaretmary To: Date: Thu, 23 Jan 2003 09:46:06 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C2C2C4.400197E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Subject: [Sipping] query on conference server Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C2C2C4.400197E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello sir, Can any one tell me about the conference server application using SIP. Are these two drafts "Models for Multi Party Conferencing SIP" and " A = Multi-Party Application Framework for SIP" specify for conference = server application. Is their any other draft for this, please tell me. Is it a simple SIP User Agent required to develop conference server. can SIP proxy server /Redirect server can come along with conference = server. Please help me out with this. Since i am new to SIPPING Regards, Margaret ------=_NextPart_000_0017_01C2C2C4.400197E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello sir,
 
Can any one tell me about the = conference server=20 application using SIP.
 
Are these two drafts "Models for = Multi Party=20 Conferencing SIP" and " A Multi-Party Application Framework for = SIP" =20 specify for conference server application.
 
Is their any other draft for this, = please tell=20 me.
 
Is it a simple SIP User Agent required = to develop=20 conference server.
can SIP proxy server /Redirect server = can come=20 along with conference server.
 
Please help me out with = this.
Since i am new to SIPPING
 
 
 
 
Regards,
Margaret

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0017_01C2C2C4.400197E0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 23 07:50:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04981 for ; Thu, 23 Jan 2003 07:50:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ND8UT22973 for sipping-archive@odin.ietf.org; Thu, 23 Jan 2003 08:08:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND8UJ22970 for ; Thu, 23 Jan 2003 08:08:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04946 for ; Thu, 23 Jan 2003 07:49:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND7pJ22914; Thu, 23 Jan 2003 08:07:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND5eJ22136 for ; Thu, 23 Jan 2003 08:05:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04750; Thu, 23 Jan 2003 07:46:39 -0500 (EST) Message-Id: <200301231246.HAA04750@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 23 Jan 2003 07:46:38 -0500 Subject: [Sipping] I-D ACTION:draft-niemi-sipping-event-throttle-reqs-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Limiting the Rate of Event Notifications Author(s) : A. Niemi Filename : draft-niemi-sipping-event-throttle-reqs-00.txt Pages : 8 Date : 2003-1-22 All event packages are required to specify a maximum rate at which event notifications are generated by a single notifier. Such a limit is provided in order to reduce network congestion. In addition to the fixed limits introduced by specific event packages, further mechanisms for limiting the rate of event notification are also allowed to be defined by event package specifications but none have been specified so far. This memo discusses the requirements for a throttle mechanism that allows a subscriber to further limit the rate of event notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-niemi-sipping-event-throttle-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-22111439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-sipping-event-throttle-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-22111439.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 23 08:38:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07094 for ; Thu, 23 Jan 2003 08:38:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NDvKN26320 for sipping-archive@odin.ietf.org; Thu, 23 Jan 2003 08:57:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NDvKJ26317 for ; Thu, 23 Jan 2003 08:57:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07075 for ; Thu, 23 Jan 2003 08:38:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NDuXJ26263; Thu, 23 Jan 2003 08:56:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LDaTJ16356 for ; Tue, 21 Jan 2003 08:36:29 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28319 for ; Tue, 21 Jan 2003 08:18:24 -0500 (EST) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h0LDLph6001968 for ; Tue, 21 Jan 2003 07:21:51 -0600 (CST) Received: from fisherlatitude ([135.210.114.145]) by maillennium.att.com (mailgw1) with SMTP id <20030121132119gw100kscdke>; Tue, 21 Jan 2003 13:21:19 +0000 From: "Steve Fisher" To: "'Eric Burger'" Cc: Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? Date: Tue, 21 Jan 2003 08:21:42 -0500 Message-ID: <000601c2c150$09f2b280$9172d287@fisherlatitude> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D248669@zoe.office.snowshore.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, Thanks for the quick reply. Does the design team intend to create new versions of draft-burger-sipping-kpml-00 and draft-jennings-sip-app-info-00 to reflect "inline" KPML and the use of NOTIFY instead of HTTP? Also, do you plan on issuing a new version of the MSCML draft? Thanks! Steve -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Eric Burger Sent: Monday, January 20, 2003 10:10 PM To: Steve Fisher Cc: sipping@ietf.org Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps? I fully agree on items 1 & 2 in your message, as it is the direction MSCML is going (NOTIFY for INFO). On item 3, I'm personally not that fond of the idea of an application doing per-digit collection. This is more especially so if the application server is doing timing related activities. Remember, SIP does not have timely delivery. For that matter, in a wireless network, you are virtually guaranteed to have SLOW signaling (as you will be traversing at least two proxies, probably more in reality). I would offer three possible directions to go: A. Use H.248: If you really want to manage digit detectors and get per-digit notifications, treat the gateway as a device. My guess is that you will find (1) you will use digit maps and (2) you can't do it, because two devices cannot control the same resources in H.248. B. Send RFC2833 events to the application: If the application wants digit events with timing, then it should get an RFC2833 stream. That may be easier for a cheap device to do than for it to have a KPML interpreter. This does constitute a "send everything" policy, however. On the other hand, once one goes down the road of sending digit masks (or maps), you might as well go all the way (see C, below). C. Use markup: There is an area of "It is, or it isn't." Either a device will be able to interpret KPML (which doesn't even really need DOM or SAX) or it won't. At some point one has to say that the device is "too stupid." That is, it isn't worth trying to run stuff on it. > -----Original Message----- > From: Steve Fisher [mailto:sfisher1@att.com] > Sent: Sunday, January 19, 2003 1:41 PM > To: Eric Burger > Cc: sipping@ietf.org > Subject: RE: [Sipping] Stimulus Signaling/Markup between > complex SIP UAs > and apps? > > > Eric, > > I've been meeting with several colleagues over the past few weeks > discussing KPML and we had some comments and questions that we thought > we'd pass on: > > 1) We very much prefer the use of SIP NOTIFY, instead of > HTTP, to notify > application servers when a UA has detected the specified key presses. > Given that all entities, and the network infrastructure that connects > them, are already SIP-capable, it would be much simpler to have the > notification also be over SIP. Further, it seems to us that this would > be an appropriate use of the NOTIFY method, and thus would not be > abusing SIP simply for convenience. > > 2) It seems to us that the "subscription" could be established as part > of the session setup process (and not via a SUBSCRIBE, for the reasons > you indicated). This also seems to us to be a reasonable use of SIP, > since detecting key presses is one aspect of the session. We > envisioned that this would occur along the lines of what's described > in draft-jennings-sip-app-info-00, although the KPML would be > "inlined", rather than fetched via HTTP. > > 3) The other area of debate that we had concerned the > appropriate place > to put the logic for managing the "digit maps". In the KPML draft, you > wrote: > > An interested application could request notifications of every key > press. However, many of the use cases for such signaling has > the > application interested in only one or a few keystrokes. Thus we > > need a mechanism for specifying to the user device what stimulus the > application would like notification of. > > Our concern is that the specific mechanism defined in KPML will impose > significant requirements on the KPML interpreters, which will > frequently be either inexpensive devices, or will be PSTN gateways > that are optimized for media processing at scale, and not for the type > of processing required by KPML. We were wondering if you are open to > an alternative approach, in which the application servers indicate to > the device which key presses they're interested in, but not the > ordering of > those digits, leaving it to the application servers to manage the > sequencing of the key presses (checking intervals, etc.). Thus, this > mechanism would not be as simple as "signal for all key presses", but > would not require that the devices maintain any state other than the > list of key presses and the name of the Application Server to NOTIFY > (i.e. no state machines, regular expression interpreters, etc.). > > What do you think? > > Steve Fisher > Division Manager > AT&T Labs > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 23 16:45:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21024 for ; Thu, 23 Jan 2003 16:45:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NM4Ni28401 for sipping-archive@odin.ietf.org; Thu, 23 Jan 2003 17:04:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NM4MJ28394 for ; Thu, 23 Jan 2003 17:04:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21008 for ; Thu, 23 Jan 2003 16:45:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NM3SJ28343; Thu, 23 Jan 2003 17:03:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NM1jJ28282 for ; Thu, 23 Jan 2003 17:01:45 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20943 for ; Thu, 23 Jan 2003 16:42:32 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H9600CISSDZ5U@firewall.wcom.com> for sipping@ietf.org; Thu, 23 Jan 2003 21:44:23 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H9600I01S6D6C@pmismtp02.wcomnet.com>; Thu, 23 Jan 2003 21:44:23 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.33.61]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H9600I1FSCGAT@pmismtp02.wcomnet.com>; Thu, 23 Jan 2003 21:43:30 +0000 (GMT) Date: Thu, 23 Jan 2003 15:43:25 -0600 From: Alan Johnston Subject: Re: [Sipping] query on conference server In-reply-to: <001a01c2c296$265a24c0$17010a64@DOMAIN.dexceldesigns.com> X-Sender: Alan.Johnston@pop.mcit.com To: margaretmary , sipping@ietf.org Message-id: <5.1.1.6.0.20030123153908.03e6b1c0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi Margaret, There is a SIPPING design team working on conferencing. Information about the work is at: http://www.softarmor.com/sipping/teams/conf/ I'd recommend you start reading the conferencing framework document which may answer your questions: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-conferencing-framework-00.txt Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 09:46 AM 1/23/2003 +0530, margaretmary wrote: >hello sir, > >Can any one tell me about the conference server application using SIP. > >Are these two drafts "Models for Multi Party Conferencing SIP" and " A >Multi-Party Application Framework for SIP" specify for conference server >application. > >Is their any other draft for this, please tell me. > >Is it a simple SIP User Agent required to develop conference server. >can SIP proxy server /Redirect server can come along with conference server. > >Please help me out with this. >Since i am new to SIPPING > > > > >Regards, >Margaret > >-------------------------------------------------------------- >Dexcel Electronics Designs (P) Ltd., Bangalore, India _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 04:22:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13918 for ; Fri, 24 Jan 2003 04:22:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0O9ffs16048 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 04:41:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9ffJ16045 for ; Fri, 24 Jan 2003 04:41:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13883 for ; Fri, 24 Jan 2003 04:22:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9eWJ15980; Fri, 24 Jan 2003 04:40:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O9b0J15197 for ; Fri, 24 Jan 2003 04:37:00 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13839 for ; Fri, 24 Jan 2003 04:17:33 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0O9NLt04642 for ; Fri, 24 Jan 2003 11:23:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 24 Jan 2003 11:20:59 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 11:20:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 24 Jan 2003 11:20:59 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com> Thread-Topic: Event notification rate limiting requirements Thread-Index: AcLDiehMGkk5LTXaRPOpoRstiCSBEA== To: X-OriginalArrivalTime: 24 Jan 2003 09:20:59.0867 (UTC) FILETIME=[E8839AB0:01C2C389] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0O9b0J15198 Subject: [Sipping] Event notification rate limiting requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi All, In IETF55 it was agreed that the filtering requirements need to be package specific, while rate limiting might be generic across all packages. There is now a new draft available that discusses the requirements for a generic event notification rate limiting mechanism, or event throttle mechanism: http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt One issue that has come up is that there are scenarios, where throttles in fact need to be closely combined with event filters. For example, assigning specific throttles to notifications from specific presentities in a presence-list event requires that a single event subscription applies several different throttles. So the main question is: should there be a generic throttle mechanism, or are throttles event-package or filter-specific? Or do we in fact need both types? Any comments? Cheers, Aki _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 10:51:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23106 for ; Fri, 24 Jan 2003 10:51:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OGAt408955 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 11:10:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OGAtJ08952 for ; Fri, 24 Jan 2003 11:10:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23097 for ; Fri, 24 Jan 2003 10:51:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OGAGJ08934; Fri, 24 Jan 2003 11:10:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OG7nJ08782 for ; Fri, 24 Jan 2003 11:07:49 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23041 for ; Fri, 24 Jan 2003 10:48:14 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21687; Fri, 24 Jan 2003 10:51:41 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11303; Fri, 24 Jan 2003 10:51:41 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 10:51:40 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D63@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'jh@lohi.eng.song.fi'" , Henning Schulzrinne Cc: Christer Holmberg , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" Date: Fri, 24 Jan 2003 10:51:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] RE: [Iptel] Re: [Sip] TEL-URL local numbers Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , [I put this on sipping because it's a sip issue. When we settle what we want in a tel uri, we can go to IPTEL to get it] We just went through a thread on dial string expansion. This is just more of the same issue. At this point, I think we should take a step back and figure out where we want to end up, because it seems to me that we are going to have to make something non-backwards-compatible. I think there are only two reasonable endpoints: 1. The UA does it all. UAs never send anything that can't be sent to the right gateway and succeed. Proxies can route to the appropriate gateway, but they never add (or subtract) anything from a tel uri (or any other header) - the UA always sends a full phone number (of course, redirect is still possible). This means that the UA has a dialing plan, which it must learn from the local environment, so that it can translate from something the user enters into a full address. It also means context disappears as a concept (it's in the dialing plan). 2. The UA sends a dialing string and downstream proxies translate to routable numbers. We can argue what tel URIs and headers look like to do this. It's possible a proxy adds a context if it knows some of the expansion rules. but not all of them. It doesn't seem reasonable to me to try to walk a tightrope between these two extremes. We keep getting tripped by reality. Brian > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Friday, January 24, 2003 9:17 AM > To: Henning Schulzrinne > Cc: Christer Holmberg; Conroy, Lawrence (SMTP); iptel@ietf.org > Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > Henning Schulzrinne writes: > > > One of the underlying SIP assumptions is that we should treat each > > terminal as mobile, i.e., you should be able to plug it in > anywhere in > > the Internet and it should work (modulo NATs and firewalls). > > even mobile terminals using local numbers would work ok w/o context > configuration if the terminal is using a local proxy. only in case > where the terminal uses some non-local proxy and local numbers the > context needs to be configured. and if it does so, how does the user > know what to put in to the local context? are you suggesting > it learns > it via dhcp or how? where is the spec for that? > > > If I take my shiny IP phone home from work, my outbound > proxy changes. > > If the phone has no context, I will likely get obscure > failures or, in > > the worst case, reach the wrong destination. > > we could say that the lack of explicit context means use the > context of > the user's home proxy. that would cause the call via a > foreign proxy to > fail w/o context. > > > Nobody can keep you from omitting phone-context in a phone and > > back-fixing this in a proxy. However, that does not mean > that the WG > > should endorse such behavior in documents, particularly > given that the > > cost of configuring IP devices with phone context is close to zero. > > configuration complexity will certainly increase in many > common cases if > the context is made mandatory. and how about backwards compatibility > with today's sip phones? i don't know any that supports context > configuration. > > -- juha > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www.ietf.org/mailman/listinfo/iptel > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 13:36:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28003 for ; Fri, 24 Jan 2003 13:36:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OItSo20343 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 13:55:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OItSJ20340 for ; Fri, 24 Jan 2003 13:55:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27994 for ; Fri, 24 Jan 2003 13:35:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OIsZJ20304; Fri, 24 Jan 2003 13:54:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OIpuJ20213 for ; Fri, 24 Jan 2003 13:51:56 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27864 for ; Fri, 24 Jan 2003 13:32:18 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0OIZUKV007470; Fri, 24 Jan 2003 19:35:30 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNPAXRA; Fri, 24 Jan 2003 19:35:30 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0OIZUH7017361; Fri, 24 Jan 2003 20:35:30 +0200 (EET) Message-ID: <3E318782.BCB9C2DA@lmf.ericsson.se> Date: Fri, 24 Jan 2003 20:35:46 +0200 X-Sybari-Trust: d49d07d1 9ffcebbb c096fb41 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'jh@lohi.eng.song.fi'" , Henning Schulzrinne , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" References: <313680C9A886D511A06000204840E1CF030B5D63@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > [I put this on sipping because it's a sip issue. When we settle what > we want in a tel uri, we can go to IPTEL to get it] > > We just went through a thread on dial string expansion. > This is just more of the same issue. > > At this point, I think we should take a step back and figure > out where we want to end up, because it seems to me that > we are going to have to make something non-backwards-compatible. > > I think there are only two reasonable endpoints: > 1. The UA does it all. UAs never send anything that can't be > sent to the right gateway and succeed. Proxies can route to the > appropriate gateway, but they never add (or subtract) anything > from a tel uri (or any other header) - the UA always sends > a full phone number (of course, redirect is still possible). [CHH] I don't think that is true. Proxies can replace the Request-URI, and who says that the replacement can't be the same header as received, but with some additional parameters? > This means that the UA has a dialing plan, which it must learn > from the local environment, so that it can translate from > something the user enters into a full address. It also > means context disappears as a concept (it's in the dialing plan). [CHH] I don't think the UAC has to send something which can be routed all the way to the UAS. Intermediate proxies can take the Request-URI, do whatever lookups to find where to route the message, and, again, replace the received Request-URI value with a new value if needed. Regards, Christer Holmberg Ericsson Finland > > > 2. The UA sends a dialing string and downstream proxies > translate to routable numbers. We can argue what tel URIs > and headers look like to do this. It's possible a proxy > adds a context if it knows some of the expansion rules. > but not all of them. > > It doesn't seem reasonable to me to try to walk a tightrope > between these two extremes. We keep getting tripped by > reality. > > Brian > > > -----Original Message----- > > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > Sent: Friday, January 24, 2003 9:17 AM > > To: Henning Schulzrinne > > Cc: Christer Holmberg; Conroy, Lawrence (SMTP); iptel@ietf.org > > Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > > Henning Schulzrinne writes: > > > > > One of the underlying SIP assumptions is that we should treat each > > > terminal as mobile, i.e., you should be able to plug it in > > anywhere in > > > the Internet and it should work (modulo NATs and firewalls). > > > > even mobile terminals using local numbers would work ok w/o context > > configuration if the terminal is using a local proxy. only in case > > where the terminal uses some non-local proxy and local numbers the > > context needs to be configured. and if it does so, how does the user > > know what to put in to the local context? are you suggesting > > it learns > > it via dhcp or how? where is the spec for that? > > > > > If I take my shiny IP phone home from work, my outbound > > proxy changes. > > > If the phone has no context, I will likely get obscure > > failures or, in > > > the worst case, reach the wrong destination. > > > > we could say that the lack of explicit context means use the > > context of > > the user's home proxy. that would cause the call via a > > foreign proxy to > > fail w/o context. > > > > > Nobody can keep you from omitting phone-context in a phone and > > > back-fixing this in a proxy. However, that does not mean > > that the WG > > > should endorse such behavior in documents, particularly > > given that the > > > cost of configuring IP devices with phone context is close to zero. > > > > configuration complexity will certainly increase in many > > common cases if > > the context is made mandatory. and how about backwards compatibility > > with today's sip phones? i don't know any that supports context > > configuration. > > > > -- juha > > > > > > > > _______________________________________________ > > Iptel mailing list > > Iptel@ietf.org > > https://www.ietf.org/mailman/listinfo/iptel > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 13:53:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28531 for ; Fri, 24 Jan 2003 13:53:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OJCdR21872 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 14:12:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJCdJ21869 for ; Fri, 24 Jan 2003 14:12:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28519 for ; Fri, 24 Jan 2003 13:53:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJC8J21851; Fri, 24 Jan 2003 14:12:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ9vJ21759 for ; Fri, 24 Jan 2003 14:09:57 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28485 for ; Fri, 24 Jan 2003 13:50:19 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA00650; Fri, 24 Jan 2003 13:53:44 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09886; Fri, 24 Jan 2003 13:53:45 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 13:53:44 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D66@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Christer Holmberg'" Cc: "'jh@lohi.eng.song.fi'" , Henning Schulzrinne , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" Date: Fri, 24 Jan 2003 13:53:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] RE: [Iptel] Re: [Sip] TEL-URL local numbers Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Either we treat a tel URI like a sip URI, which means you can do substitution on the Request-URI, but we have no concept of "context" or we should implement dial strings and let the proxies do the expansion. It doesn't make any sense to me to have the UA have some knowledge of translating dial strings to fully routable numbers, but not all the knowledge. This thread, and the dial string thread have yielded lots of examples of why context is not a functional mechanism. So, I propose we get rid of it, one way or the other. Brian > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, January 24, 2003 1:36 PM > To: Rosen, Brian > Cc: 'jh@lohi.eng.song.fi'; Henning Schulzrinne; Conroy, > Lawrence (SMTP); > 'sipping@ietf.org' > Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > Hi, > > > [I put this on sipping because it's a sip issue. When we > settle what > > we want in a tel uri, we can go to IPTEL to get it] > > > > We just went through a thread on dial string expansion. > > This is just more of the same issue. > > > > At this point, I think we should take a step back and figure > > out where we want to end up, because it seems to me that > > we are going to have to make something non-backwards-compatible. > > > > I think there are only two reasonable endpoints: > > 1. The UA does it all. UAs never send anything that can't be > > sent to the right gateway and succeed. Proxies can route to the > > appropriate gateway, but they never add (or subtract) anything > > from a tel uri (or any other header) - the UA always sends > > a full phone number (of course, redirect is still possible). > > [CHH] I don't think that is true. Proxies can replace the > Request-URI, and > who says that the replacement can't be the same header as > received, but with > some additional parameters? > > > This means that the UA has a dialing plan, which it must learn > > from the local environment, so that it can translate from > > something the user enters into a full address. It also > > means context disappears as a concept (it's in the dialing plan). > > [CHH] I don't think the UAC has to send something which can > be routed all > the way to the UAS. Intermediate proxies can take the Request-URI, do > whatever lookups to find where to route the message, and, > again, replace the > received Request-URI value with a new value if needed. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > 2. The UA sends a dialing string and downstream proxies > > translate to routable numbers. We can argue what tel URIs > > and headers look like to do this. It's possible a proxy > > adds a context if it knows some of the expansion rules. > > but not all of them. > > > > It doesn't seem reasonable to me to try to walk a tightrope > > between these two extremes. We keep getting tripped by > > reality. > > > > Brian > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 14:36:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00095 for ; Fri, 24 Jan 2003 14:36:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OJtsS24445 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 14:55:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJtsJ24442 for ; Fri, 24 Jan 2003 14:55:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00078 for ; Fri, 24 Jan 2003 14:36:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJsBJ24342; Fri, 24 Jan 2003 14:54:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJpSJ24192 for ; Fri, 24 Jan 2003 14:51:28 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29843 for ; Fri, 24 Jan 2003 14:31:49 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0OJYxdS009008 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Jan 2003 14:35:07 -0500 (EST) Message-ID: <3E319568.2060905@cs.columbia.edu> Date: Fri, 24 Jan 2003 14:35:04 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Christer Holmberg'" , "'jh@lohi.eng.song.fi'" , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" References: <313680C9A886D511A06000204840E1CF030B5D66@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D66@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There seem to be at least three scenarios: (1) The end system has a dialplan, learned automatically, and can easily translate dialed digits into an E.164 number. We clearly need this and I should have a micro-draft on this shortly. This hinges on the whole UA configuration mess, which has not made much progress. I think this solution has the greatest flexibility, as it allows users to carry their dialplans with them as well as get local ones. It also allows inspection - a device can easily display what will happen to a digit string. If the proxy does translation, you only find out when what you thought was a local extension gets translated to dial-a-prayer. (Or, worse, doesn't get answered at all, in which case one may not suspect anything amiss.) (2) However, there are apparently some numbers that are not translatable to E.164 numbers. Effectively, they are a different namespace that is valid only locally. As I've mentioned before, IBM has two phone namespaces internally, judging from their business cards. The extension is *not* directly related to the externally reachable number. Thus, the end system cannot produce an E.164 number without doing some kind of directory lookup. (3) The end system has no dialplan (e.g., because the current products don't support this). Then, the local proxy needs to do the translation. Here, there seem to be two options: (3a) Allow this non-unique, non-global dialed number and effectively declare it "whatever this happens to mean at the first proxy this request meets - and good luck". (3b) Mark with context, so that you can detect if expectation and reality don't match. In general, as 2806bis tries to express, globally unique URIs are best for everyone - no confusion, no ambiguity. The question is whether we can get rid of the cases (2) and (3) above that don't work that way. I don't think just having (3a) is a viable option if we want to build reliable and testable systems. Rosen, Brian wrote: > Either we treat a tel URI like a sip URI, which means you can > do substitution on the Request-URI, but we have no concept of > "context" or we should implement dial strings and let the > proxies do the expansion. It doesn't make any sense to me > to have the UA have some knowledge of translating dial strings > to fully routable numbers, but not all the knowledge. > > This thread, and the dial string thread have yielded lots of > examples of why context is not a functional mechanism. So, > I propose we get rid of it, one way or the other. I have heard examples of why it might be inconvenient for current shipping phones. I have not heard why it would not work. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 15:34:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01675 for ; Fri, 24 Jan 2003 15:34:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OKs9t27902 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 15:54:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKs9J27899 for ; Fri, 24 Jan 2003 15:54:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01657 for ; Fri, 24 Jan 2003 15:34:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKqHJ27849; Fri, 24 Jan 2003 15:52:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKmqJ27718 for ; Fri, 24 Jan 2003 15:48:52 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01539 for ; Fri, 24 Jan 2003 15:29:11 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05387; Fri, 24 Jan 2003 15:32:36 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25705; Fri, 24 Jan 2003 15:32:38 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 15:32:37 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D69@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'Christer Holmberg'" , "'jh@lohi.eng.song.fi'" , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Fri, 24 Jan 2003 15:32:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Okay, let's get specific, because it's hard on my head to deal with too many abstractions. Around here, I can dial 7844 to get a local extension, 9-1-703-559-2348 to reach a colleague in one of our outlying offices, or 304-2349 to reach the same colleague using our internal network. Just for the moment, ignore the possibility that some entity could recognize that 9-1-703-559-2348 could be translated into 304-2348. The point is that in my domain, 304-2348 is a routable number, but not a global number. We in fact do have numbers that are routable, but not accessible as E.164s. We have a gateway to our PBX. If you send it a uri of the form tel:3042348, it will dial it correctly. However, if you send that uri to a gateway in my home, it won't dial my colleague. Until a year ago, it would have connected you to 724-304-2349, but today you would just get an intercept. So, what is my "context"? And how do I use it? Right now, my sipphone is dumb, it sends dial strings. My proxy has a dial plan, and it expands dial strings to numbers. You are advocating that we move the dial plan processing into the UA. I'll agree that that would work. What I don't understand is what I can then do with context. If I have the dial plan in the UA, then what it emits is a legal number in the domain represented by that dial plan. Subsequent proxies should be able to route it. They might even substitute the number in the Request-URI (doing the translation from 9-1-703-559-2348 to 304-2348 for example). I might indeed know that the local context is "Marconi Pittsburgh", but what would any downstream entity do with that? Any call within the domain has that context, and if the call got outside the domain, the number is probably wrong. For example, the "304" doesn't work in Marconi, UK, they have a different prefix. The only way that the call can get outside the domain is to have some routing error. If I had the context, I could return an error if I didn't understand it. I think we get into heaps of trouble when the routing sends you through a domain that doesn't know the context, but can route the number none-the-less, to a domain that does understand the context (Marconi Pittsburgh -> WorldCom -> Marconi UK) The same problem can happen with a sip uri, and we don't do anything to detect or repair damage in that case, why would we do so in this case? Not all sip uri's are globally routable! My home proxy would know that 304-2348 is not a legal number, because the local (ie home) dialing plan wouldn't include it. The closest I can come to having a use for context is that if I had a contact database, I could have 304-2348 in it with a context of "Marconi Pittsburgh". Then, my UA could figure out that it can't use that number unless I'm in that domain. That is not something we could really say is part of our charter. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, January 24, 2003 2:35 PM > To: Rosen, Brian > Cc: 'Christer Holmberg'; 'jh@lohi.eng.song.fi'; Conroy, > Lawrence (SMTP); > 'sipping@ietf.org' > Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > There seem to be at least three scenarios: > > (1) The end system has a dialplan, learned automatically, and > can easily > translate dialed digits into an E.164 number. We clearly need > this and I > should have a micro-draft on this shortly. This hinges on the > whole UA > configuration mess, which has not made much progress. I think this > solution has the greatest flexibility, as it allows users to > carry their > dialplans with them as well as get local ones. It also allows > inspection > - a device can easily display what will happen to a digit > string. If the > proxy does translation, you only find out when what you thought was a > local extension gets translated to dial-a-prayer. (Or, worse, doesn't > get answered at all, in which case one may not suspect > anything amiss.) > > (2) However, there are apparently some numbers that are not > translatable > to E.164 numbers. Effectively, they are a different namespace that is > valid only locally. As I've mentioned before, IBM has two phone > namespaces internally, judging from their business cards. The > extension > is *not* directly related to the externally reachable number. > Thus, the > end system cannot produce an E.164 number without doing some kind of > directory lookup. > > (3) The end system has no dialplan (e.g., because the current > products > don't support this). Then, the local proxy needs to do the > translation. > Here, there seem to be two options: > > (3a) Allow this non-unique, non-global dialed number and effectively > declare it "whatever this happens to mean at the first proxy this > request meets - and good luck". > > (3b) Mark with context, so that you can detect if expectation and > reality don't match. > > In general, as 2806bis tries to express, globally unique URIs > are best > for everyone - no confusion, no ambiguity. The question is whether we > can get rid of the cases (2) and (3) above that don't work > that way. I > don't think just having (3a) is a viable option if we want to build > reliable and testable systems. > > Rosen, Brian wrote: > > Either we treat a tel URI like a sip URI, which means you can > > do substitution on the Request-URI, but we have no concept of > > "context" or we should implement dial strings and let the > > proxies do the expansion. It doesn't make any sense to me > > to have the UA have some knowledge of translating dial strings > > to fully routable numbers, but not all the knowledge. > > > > This thread, and the dial string thread have yielded lots of > > examples of why context is not a functional mechanism. So, > > I propose we get rid of it, one way or the other. > > I have heard examples of why it might be inconvenient for current > shipping phones. I have not heard why it would not work. > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 15:53:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02071 for ; Fri, 24 Jan 2003 15:53:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OLCvJ29126 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 16:12:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLCvJ29123 for ; Fri, 24 Jan 2003 16:12:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02055 for ; Fri, 24 Jan 2003 15:53:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLCGJ29107; Fri, 24 Jan 2003 16:12:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OL9gJ29010 for ; Fri, 24 Jan 2003 16:09:42 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01929 for ; Fri, 24 Jan 2003 15:50:01 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0OKrRdS017534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Jan 2003 15:53:29 -0500 (EST) Message-ID: <3E31A7CB.6020006@cs.columbia.edu> Date: Fri, 24 Jan 2003 15:53:31 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <313680C9A886D511A06000204840E1CF030B5D69@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D69@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Just for the moment, ignore the possibility that some entity could > recognize that 9-1-703-559-2348 could be translated into 304-2348. > The point is that in my domain, 304-2348 is a routable number, > but not a global number. We in fact do have numbers that are > routable, but not accessible as E.164s. Glad there's another example... > What I don't understand is what I can then do with context. > If I have the dial plan in the UA, then what it emits is a legal > number in the domain represented by that dial plan. > Subsequent proxies should be able to route it. > They might even substitute the number in the Request-URI > (doing the translation from 9-1-703-559-2348 to 304-2348 > for example). I might indeed know that the local context > is "Marconi Pittsburgh", but what would any downstream entity do > with that? Any call within the domain has that context, and Leaving aside that existing SIP phones aren't configured with this (which is presumably a fixable problem): Your phone in your office would be configured with the context, just like it now gets configured with the local outbound proxy. This configuration can be part of the permanent device configuration or it can be acquired dynamically from the outbound proxy. Both approaches have value: (1) Device-associated configuration of the context means that the dial strings have the same meaning (or no meaning) wherever you take the phone, but you'll never get a dial string that means something to mean something else in a different place. (2) Proxy-associated configuration of the context has the opposite properties: you guarantee that the dial string is meant to be translated by it, but you might mistakenly dial your intra-office extension at home and get whatever the proxy makes it to be. Both are valid and useful depending on the type of user interface characteristics you want, but you need the context to reliable detect what's going on, rather than having the proxy guess. One way to think of the context is as a token that identifies the translation table ("dialing plan"). > if the call got outside the domain, the number is probably wrong. > For example, the "304" doesn't work in Marconi, UK, they have a > different prefix. The only way that the call can get outside > the domain is to have some routing error. If I had the context, > I could return an error if I didn't understand it. I think we get > into heaps of trouble when the routing sends you through a domain > that doesn't know the context, but can route the number > none-the-less, to a domain that does understand the context > (Marconi Pittsburgh -> WorldCom -> Marconi UK) That was never the intent. All tel URIs are either resolved by the first proxy or they are ditched with an error response (404, presumably). The context intentionally does not have enough information to route it to some other entity. (It comes close in the DNS form, but I don't want to go there.) > > The same problem can happen with a sip uri, and we don't do anything > to detect or repair damage in that case, why would we do so in > this case? Not all sip uri's are globally routable! They should be globally unique, even if they are not globally routable. A SIP URI should never mean Alice in one place and Bob in another. > > My home proxy would know that 304-2348 is not a legal number, > because the local (ie home) dialing plan wouldn't include it. You are lucky in this case. For many dialing plans, the shape of the number may well be the same. > The closest I can come to having a use for context is that > if I had a contact database, I could have 304-2348 in it with > a context of "Marconi Pittsburgh". Then, my UA could figure > out that it can't use that number unless I'm in that domain. > That is not something we could really say is part of our charter. > > Brian > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 16:25:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02874 for ; Fri, 24 Jan 2003 16:25:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OLj5p31003 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 16:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLj5J31000 for ; Fri, 24 Jan 2003 16:45:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02854 for ; Fri, 24 Jan 2003 16:25:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLiPJ30939; Fri, 24 Jan 2003 16:44:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLefJ30768 for ; Fri, 24 Jan 2003 16:40:41 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02762 for ; Fri, 24 Jan 2003 16:20:59 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA07747; Fri, 24 Jan 2003 16:24:25 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04049; Fri, 24 Jan 2003 16:24:26 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 16:24:26 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Fri, 24 Jan 2003 16:24:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > Your phone in your office would be configured with the context, just > like it now gets configured with the local outbound proxy. This > configuration can be part of the permanent device configuration or it > can be acquired dynamically from the outbound proxy. Both approaches > have value: > > (1) Device-associated configuration of the context means that > the dial > strings have the same meaning (or no meaning) wherever you take the > phone, but you'll never get a dial string that means > something to mean > something else in a different place. > > (2) Proxy-associated configuration of the context has the opposite > properties: you guarantee that the dial string is meant to be > translated > by it, but you might mistakenly dial your intra-office > extension at home > and get whatever the proxy makes it to be. There is a third possibility, which is that the dialing plan is associated with the AOR. I dial the same way on every sipphone I register with, wherever I am. We've been around this dilemma (do you want the dial string to remain constant when you roam, or do you want the local context). As you seem to agree, there is no really right answer. We've come to the conclusion that it should be the local dialing plan for where you are. There seem to be fewer problems and it's the way the PSTN and all PBXs work now. I actually think we are best to standardize the behavior one way or the other. It is a standards issue, regardless of how we implement it (if you substitute "dialing plan" for "context" your explanation above makes the same argument). > > Both are valid and useful depending on the type of user interface > characteristics you want, but you need the context to reliable detect > what's going on, rather than having the proxy guess. I don't think so, or rather, I think there are too many problems to make it be that way. This whole thread is about problems with context. As yet another example, what is my context? Is it "Marconi Pittsburgh". Is that globally unique? Or is it "+1724742"? That's globally unique, but may or may not be useable by my first hop proxy. I think we either get rid of it, making the dialing plan the last word, or make the dialing plan the job of the first hop proxy. I fail to see the advantage of dialing plan in the UA and first hop proxy interpreting context. > > One way to think of the context is as a token that identifies the > translation table ("dialing plan"). Yeah, I got that. ...snip... > That was never the intent. All tel URIs are either resolved > by the first > proxy or they are ditched with an error response (404, > presumably). The > context intentionally does not have enough information to route it to > some other entity. (It comes close in the DNS form, but I > don't want to > go there.) To me, that makes context even less interesting. You require the first hop proxy to understand all contexts that could be generated by any UA it serves. That would make it pretty hard for you to bring your office phone home if your ISP provided your first hop proxy. I think it's best to either have the dialing plan have to make sense to the first hop proxy (by making the local domain the source of the dialing plan, your #2 above), or make the proxy responsible for turning digit strings into routable numbers. I don't see enough utility in having the dialing plan associated with the phone itself. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 16:30:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02984 for ; Fri, 24 Jan 2003 16:30:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OLnY531164 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 16:49:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLnYJ31161 for ; Fri, 24 Jan 2003 16:49:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02950 for ; Fri, 24 Jan 2003 16:29:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLn5J31133; Fri, 24 Jan 2003 16:49:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLkQJ31060 for ; Fri, 24 Jan 2003 16:46:26 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02923 for ; Fri, 24 Jan 2003 16:26:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OLUEYH008268; Fri, 24 Jan 2003 16:30:15 -0500 (EST) Message-ID: <3E31B05F.5050706@dynamicsoft.com> Date: Fri, 24 Jan 2003 16:30:07 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: margaretmary , sipping@ietf.org Subject: Re: [Sipping] query on conference server References: <5.1.1.6.0.20030123153908.03e6b1c0@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One additional note. The "models for multiparty conferencing in sip" is not going to move forward. Its content has been moved into the framework document Alan has pointed out, along with other documents that the framework references. To briefly answer your questions, a conference server (called a focus in SIP) is a SIP user agent. Proxies don't know anything about conferences. They just route requests to URIs, and a URI might represent a conference. -Jonathan R. Alan Johnston wrote: > Hi Margaret, > > There is a SIPPING design team working on conferencing. Information > about the work is at: > > http://www.softarmor.com/sipping/teams/conf/ > > I'd recommend you start reading the conferencing framework document > which may answer your questions: > > > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-conferencing-framework-00.txt > > > Thanks, > Alan Johnston > WorldCom > sip:alan@digitalari.com > > At 09:46 AM 1/23/2003 +0530, margaretmary wrote: > >> hello sir, >> >> Can any one tell me about the conference server application using SIP. >> >> Are these two drafts "Models for Multi Party Conferencing SIP" and " A >> Multi-Party Application Framework for SIP" specify for conference >> server application. >> >> Is their any other draft for this, please tell me. >> >> Is it a simple SIP User Agent required to develop conference server. >> can SIP proxy server /Redirect server can come along with conference >> server. >> >> Please help me out with this. >> Since i am new to SIPPING >> >> >> >> >> Regards, >> Margaret >> >> -------------------------------------------------------------- >> Dexcel Electronics Designs (P) Ltd., Bangalore, India > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 16:42:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03333 for ; Fri, 24 Jan 2003 16:42:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OM27K32258 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 17:02:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OM27J32255 for ; Fri, 24 Jan 2003 17:02:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03329 for ; Fri, 24 Jan 2003 16:42:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OM1PJ32016; Fri, 24 Jan 2003 17:01:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLwHJ31570 for ; Fri, 24 Jan 2003 16:58:17 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03131 for ; Fri, 24 Jan 2003 16:38:35 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OLg4YH008290; Fri, 24 Jan 2003 16:42:05 -0500 (EST) Message-ID: <3E31B325.60906@dynamicsoft.com> Date: Fri, 24 Jan 2003 16:41:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: Dean Willis , "PRATI,LUCA (HP-Italy,ex1)" , sipping@ietf.org Subject: Re: [Sipping] SIP <-> XMPP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One final note. Like many technologies, there are ways they can work together, and ways they overlap in functionality. The draft below explains ways in which SIP can be used to set up XMPP session, and in that way, they are complementary. In other ways, there is overlap. XMPP has its own presence mechanism, as does SIP (the SIMPLE specs). SIP can also do IM using the page mode messaging (rfc 3428) which does not require XMPP. I won't attempt to go into a pro/con analysis here, but just want to make sure the various angles of the relationship are understood. -Jonathan R. Peter Saint-Andre wrote: > On 16 Jan 2003, Dean Willis wrote: > > >>Historically speaking, XMPP was not on the radar screen of the IETF when >>3261 was published. > > > True, so we would not expect mention of XMPP in 3261. > > >>I believe there is a SIMPLE draft dealing with using SIP to set up an >>XMPP session for messaging. > > > http://www.ietf.org/internet-drafts/draft-sparks-simple-jabber-sessions-00.txt > > Peter > > -- > Peter Saint-Andre > Jabber Software Foundation > http://www.jabber.org/people/stpeter.php > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 18:05:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04961 for ; Fri, 24 Jan 2003 18:05:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ONODP04335 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 18:24:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONOCJ04332 for ; Fri, 24 Jan 2003 18:24:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04954 for ; Fri, 24 Jan 2003 18:04:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONMTJ04254; Fri, 24 Jan 2003 18:22:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONJNJ04140 for ; Fri, 24 Jan 2003 18:19:23 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04775 for ; Fri, 24 Jan 2003 17:59:39 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0ON37dS029180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Jan 2003 18:03:08 -0500 (EST) Message-ID: <3E31C62F.3080904@cs.columbia.edu> Date: Fri, 24 Jan 2003 18:03:11 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > As yet another example, what is my context? Is it "Marconi Pittsburgh". > Is that globally unique? Or is it "+1724742"? That's globally unique, > but may or may not be useable by my first hop proxy. The point is that you and your first hop proxy better agree on something, choosing one of the mechanism in 2806bis, such as a prefix or a domain name. What you pick is immaterial - it is invisible to the user. If you can't agree on that, it is very unlikely that you can agree on what actually happens in the translation. Once you have automated configuration (at the device, AOR or outbound proxy level), it doesn't matter what it is called, as long as you pick something that's unique. 2806bis provides two reasonable mechanisms. I don't see this as an issue. > > I think we either get rid of it, making the dialing plan the last word, > or make the dialing plan the job of the first hop proxy. I fail to see > the advantage of dialing plan in the UA and first hop proxy interpreting > context. You would never have both at the same time in the same installation, but I don't think we're in the business of picking architectures here. My proposal allows choice. If you don't like to run context in your products or installation, don't. I happen to think that UA-translation is best, as it is in the endsystem-is-smart spirit, but others seem to want proxy translation. Proxy translation without context is extremely brittle. > To me, that makes context even less interesting. You require the > first hop proxy to understand all contexts that could be generated by > any UA it serves. That would make it pretty hard for you to bring > your office phone home if your ISP provided your first hop proxy. > > I think it's best to either have the dialing plan have to make sense > to the first hop proxy (by making the local domain the source of > the dialing plan, your #2 above), or make the proxy responsible for > turning digit strings into routable numbers. I don't see enough > utility in having the dialing plan associated with the phone itself. The point is that I want to be warned if the translation is done by somebody that shouldn't. This becomes even more important when you put tel URIs on web pages. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 18:25:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05232 for ; Fri, 24 Jan 2003 18:25:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ONiDG05608 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 18:44:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONiDJ05605 for ; Fri, 24 Jan 2003 18:44:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05229 for ; Fri, 24 Jan 2003 18:24:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONgCJ05560; Fri, 24 Jan 2003 18:42:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONbpJ05422 for ; Fri, 24 Jan 2003 18:37:51 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05184 for ; Fri, 24 Jan 2003 18:18:06 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0ONMGb6005409; Fri, 24 Jan 2003 18:22:17 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY53228; Fri, 24 Jan 2003 18:26:29 -0500 (EST) Message-ID: <3E31CA76.4040603@cisco.com> Date: Fri, 24 Jan 2003 18:21:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Henning Schulzrinne'" , "'Christer Holmberg'" , "'jh@lohi.eng.song.fi'" , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <313680C9A886D511A06000204840E1CF030B5D69@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, I think you have provided some good questions to pursue, and I don't have the final answers on them. But I will venture an opinion: If your phone had an internal dial plan, it should know the context it is in. So if from your phone you dial 304-2349, it could translate that to something like: tel:304-2349;phone-context=pittsburgh.marconi.com This is then sent to your local proxy, which understands the context and knows how to route the call. Now suppose that same phone calls me at sip:pkyzivat@cisco.com. It isn't a globally routable phone, so it puts that same address in the From header. My phone is smart and remembers the From address for future reference, in my address book. I may eventually try to return the call using the saved url. Two things can happen: 1a) the proxy I use never heard of the context, and fails the call. (That would certainly be the case if I tried it from inside Cisco. 2a) maybe I was visiting a marconi facility and have plugged into the network there. With a great deal of luck and provisioning, I might find myself sending requests to a marconi proxy that understands the context and can route the call. This could even work if I was visiting marconi in the UK. OTOH, suppose the phone doesn't bother with context and simply encodes the dial string as tel:3042349. Then different things happen in the cases above: 1b) if my local proxy uses the same sorts of conventions, it will try to interpret the number 3042349 in my local context. With luck it will just fail. It is also possible that it might work, which would be worse since it will be calling the wrong destination. 2b) if I happen to be visiting marconi pittsburg, the call will perhaps work. If I am visiting marconi uk I guess it will fail. I think including the context in numbers helps. It ensures that numbers are at least universally unambiguous even when they aren't universally dialable. Paul Rosen, Brian wrote: > Okay, let's get specific, because it's hard on my head to deal > with too many abstractions. > > Around here, I can dial 7844 to get a local extension, > 9-1-703-559-2348 to reach a colleague in one of our outlying offices, > or 304-2349 to reach the same colleague using our internal network. > Just for the moment, ignore the possibility that some entity could > recognize that 9-1-703-559-2348 could be translated into 304-2348. > The point is that in my domain, 304-2348 is a routable number, > but not a global number. We in fact do have numbers that are > routable, but not accessible as E.164s. > > We have a gateway to our PBX. If you send it a uri of the > form tel:3042348, it will dial it correctly. However, if you > send that uri to a gateway in my home, it won't dial my colleague. > Until a year ago, it would have connected you to 724-304-2349, > but today you would just get an intercept. > > So, what is my "context"? And how do I use it? > Right now, my sipphone is dumb, it sends dial strings. My proxy > has a dial plan, and it expands dial strings to numbers. > You are advocating that we move the dial plan processing into > the UA. I'll agree that that would work. > > What I don't understand is what I can then do with context. > If I have the dial plan in the UA, then what it emits is a legal > number in the domain represented by that dial plan. > Subsequent proxies should be able to route it. > They might even substitute the number in the Request-URI > (doing the translation from 9-1-703-559-2348 to 304-2348 > for example). I might indeed know that the local context > is "Marconi Pittsburgh", but what would any downstream entity do > with that? Any call within the domain has that context, and > if the call got outside the domain, the number is probably wrong. > For example, the "304" doesn't work in Marconi, UK, they have a > different prefix. The only way that the call can get outside > the domain is to have some routing error. If I had the context, > I could return an error if I didn't understand it. I think we get > into heaps of trouble when the routing sends you through a domain > that doesn't know the context, but can route the number > none-the-less, to a domain that does understand the context > (Marconi Pittsburgh -> WorldCom -> Marconi UK) > > The same problem can happen with a sip uri, and we don't do anything > to detect or repair damage in that case, why would we do so in > this case? Not all sip uri's are globally routable! > > My home proxy would know that 304-2348 is not a legal number, > because the local (ie home) dialing plan wouldn't include it. > The closest I can come to having a use for context is that > if I had a contact database, I could have 304-2348 in it with > a context of "Marconi Pittsburgh". Then, my UA could figure > out that it can't use that number unless I'm in that domain. > That is not something we could really say is part of our charter. > > Brian > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Friday, January 24, 2003 2:35 PM >>To: Rosen, Brian >>Cc: 'Christer Holmberg'; 'jh@lohi.eng.song.fi'; Conroy, >>Lawrence (SMTP); >>'sipping@ietf.org' >>Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers >> >> >>There seem to be at least three scenarios: >> >>(1) The end system has a dialplan, learned automatically, and >>can easily >>translate dialed digits into an E.164 number. We clearly need >>this and I >>should have a micro-draft on this shortly. This hinges on the >>whole UA >>configuration mess, which has not made much progress. I think this >>solution has the greatest flexibility, as it allows users to >>carry their >>dialplans with them as well as get local ones. It also allows >>inspection >>- a device can easily display what will happen to a digit >>string. If the >>proxy does translation, you only find out when what you thought was a >>local extension gets translated to dial-a-prayer. (Or, worse, doesn't >>get answered at all, in which case one may not suspect >>anything amiss.) >> >>(2) However, there are apparently some numbers that are not >>translatable >>to E.164 numbers. Effectively, they are a different namespace that is >>valid only locally. As I've mentioned before, IBM has two phone >>namespaces internally, judging from their business cards. The >>extension >>is *not* directly related to the externally reachable number. >>Thus, the >>end system cannot produce an E.164 number without doing some kind of >>directory lookup. >> >>(3) The end system has no dialplan (e.g., because the current >>products >>don't support this). Then, the local proxy needs to do the >>translation. >>Here, there seem to be two options: >> >>(3a) Allow this non-unique, non-global dialed number and effectively >>declare it "whatever this happens to mean at the first proxy this >>request meets - and good luck". >> >>(3b) Mark with context, so that you can detect if expectation and >>reality don't match. >> >>In general, as 2806bis tries to express, globally unique URIs >>are best >>for everyone - no confusion, no ambiguity. The question is whether we >>can get rid of the cases (2) and (3) above that don't work >>that way. I >>don't think just having (3a) is a viable option if we want to build >>reliable and testable systems. >> >>Rosen, Brian wrote: >> >>>Either we treat a tel URI like a sip URI, which means you can >>>do substitution on the Request-URI, but we have no concept of >>>"context" or we should implement dial strings and let the >>>proxies do the expansion. It doesn't make any sense to me >>>to have the UA have some knowledge of translating dial strings >>>to fully routable numbers, but not all the knowledge. >>> >>>This thread, and the dial string thread have yielded lots of >>>examples of why context is not a functional mechanism. So, >>>I propose we get rid of it, one way or the other. >> >>I have heard examples of why it might be inconvenient for current >>shipping phones. I have not heard why it would not work. >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 18:42:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05502 for ; Fri, 24 Jan 2003 18:42:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P01qT06216 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 19:01:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P01qJ06213 for ; Fri, 24 Jan 2003 19:01:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05488 for ; Fri, 24 Jan 2003 18:42:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P01GJ06200; Fri, 24 Jan 2003 19:01:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ONwFJ06077 for ; Fri, 24 Jan 2003 18:58:15 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05470 for ; Fri, 24 Jan 2003 18:38:30 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0ONgftQ007207; Fri, 24 Jan 2003 18:42:42 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY53375; Fri, 24 Jan 2003 18:46:54 -0500 (EST) Message-ID: <3E31CF40.7080806@cisco.com> Date: Fri, 24 Jan 2003 18:41:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Rosen, Brian" , "'Christer Holmberg'" , "'jh@lohi.eng.song.fi'" , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <313680C9A886D511A06000204840E1CF030B5D66@whq-msgusr-02.pit.comms.marconi.com> <3E319568.2060905@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > There seem to be at least three scenarios: > > (1) The end system has a dialplan, learned automatically, and can easily > translate dialed digits into an E.164 number. ... It also allows inspection > - a device can easily display what will happen to a digit string. If the > proxy does translation, you only find out when what you thought was a > local extension gets translated to dial-a-prayer. (Or, worse, doesn't > get answered at all, in which case one may not suspect anything amiss.) There is a solution to this problem when using proxy expansion: The proxy can do the expansion and then return the result as a redirect (probably 301). The phone will then retry, but can display the new number. But this doesn't work for From. The calling phone had better know an expanded form of its own address. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 22:24:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08741 for ; Fri, 24 Jan 2003 22:24:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P3hMN18667 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 22:43:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3hLJ18664 for ; Fri, 24 Jan 2003 22:43:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08737 for ; Fri, 24 Jan 2003 22:23:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3dYJ18513; Fri, 24 Jan 2003 22:39:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3Z6J17735 for ; Fri, 24 Jan 2003 22:35:06 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08679 for ; Fri, 24 Jan 2003 22:15:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P3InYH008480; Fri, 24 Jan 2003 22:18:49 -0500 (EST) Message-ID: <3E320215.8050607@dynamicsoft.com> Date: Fri, 24 Jan 2003 22:18:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-req-00.txt References: <200301071328.IAA12023@ietf.org> <3E1B024A.1020309@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for taking so long to respond. Comments inline. Paul Kyzivat wrote: > This document provides many detailed requirements. But I am still left > with a feeling of uncertainty about the overall scope. For instance: > > - I'm not sure what is in scope and out of scope for a media policy. Is > there anything that can be negotiated via an offer/answer exchange that > is out of scope? Certain specific features that are encoded in SDP are > called out specifically. This might imply that it is intended that > features not mentioned are out of scope. Well, Section 3.2 listed a very specific set of policies. Its not any apsect of the O/A exchange. Anything else is out of scope. Of course, I am happy to discuss the scope. > > An example of a specific feature not mentioned, is the a=direction > attribute used by comedia. It is possible to imagine an intermediate > node might want to alter an a=direction:both to be only > a=direction:active. Does this need to be listed as a requirement before > it can be addressed by policy? Yes. > > I am somewhat concerned that this is a slippery slope. Unless we can > clearly define what is in scope and what is out, I think we will find > that we are simply defining a new representation of SDP, one syntactic > element at a time. At the least, this seems to require a sort of > meta-model for offers and answers that transcends SDP and SDPng. Nowhere in this document does it describe the syntax or encoding. It may very well be that the right way to do this is to have the proxy include some kind of SDP. But, thats mechanism. For now, I am trying to focus on requirements, and their implications on the overall information flow. > > - Continuing the scope question a bit, is there any intent to support > policies that can't already be expressed via an offer/answer exchange? > (I don't think so, but just checking.) As above, the set of policies that are to be enabled are explicitly enumerated. > > - There is much mention of proxies as the nodes that want to specify > policy. But I think there are other kinds of servers that may also take > on this role. Specifically, a B2BUA may also want to work cooperatively > with the endpoints in same way. Of course a B2BUA already has more > capabilities to modify the SDP directly, but it may want to be more > subtle and friendly in its manipulations. For instance, this mechanism > may permit a more extended pre-alert negotiation than is currently > possible. So I would like to see these requirements phrased to permit a > B2BUA as a policy setter if that makes sense. I suppose it makes sense, but I must admit the central aim was to allow these intermediary things to be standards compliant proxies, yet carry out the policy actions that people want to see. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 22:26:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08761 for ; Fri, 24 Jan 2003 22:26:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P3jf218750 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 22:45:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3jfJ18747 for ; Fri, 24 Jan 2003 22:45:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08758 for ; Fri, 24 Jan 2003 22:25:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3g5J18630; Fri, 24 Jan 2003 22:42:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3dOJ18507 for ; Fri, 24 Jan 2003 22:39:24 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08712 for ; Fri, 24 Jan 2003 22:19:35 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P3LNYH008484; Fri, 24 Jan 2003 22:21:23 -0500 (EST) Message-ID: <3E3202AF.7000803@dynamicsoft.com> Date: Fri, 24 Jan 2003 22:21:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Paul Kyzivat'" , sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-rosenberg-sipping-session-policy-r eq-00.txt References: <313680C9A886D511A06000204840E1CF030B5CCF@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > Agree. I specifically want to have the mechanism allowed to > specify the bandwidth parameters (I ask for a 6MB video stream, > the proxy tells me I can only send 4, everything else is the same). > So, is this in scope or out? I'd be happy to add it in. > > I'll point out that this is an interesting one because there is no > middle box; there is simply a bandwidth manager that is doing > something much better than simplistic call admission control. However, > I don't see any reason to judge why one SDP parameter is subject > to policy, and another one is not. Well, I am willing to consider that this itself may be a requirement, i.e., that its a requirement for a proxy to be able to ask the client to do any specific modification to its SDP. However, generally a requirements process is about determining exactly what the real problem is, and not putting in everything under the sun. Practically speaking, I suspect proxies really are interested in a limited number of things. SO long as the mechanism is extensible to other aspects of the session, is there really a compelling need to support everything at the outset? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 23:10:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09589 for ; Fri, 24 Jan 2003 23:10:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P4Tqd20233 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 23:29:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4TpJ20230 for ; Fri, 24 Jan 2003 23:29:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09563 for ; Fri, 24 Jan 2003 23:10:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4THJ20214; Fri, 24 Jan 2003 23:29:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4Q0J20156 for ; Fri, 24 Jan 2003 23:26:00 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09553 for ; Fri, 24 Jan 2003 23:06:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P49aYH008502; Fri, 24 Jan 2003 23:09:37 -0500 (EST) Message-ID: <3E320DFC.90805@dynamicsoft.com> Date: Fri, 24 Jan 2003 23:09:32 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Henning Schulzrinne'" , Adam Roach , "'Paul Kyzivat'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Slightly old thread here, but I wanted to add my own two cents. Firstly, I too support the development of some kind of dial plan document that can be downloaded into a UA. I think such a mechanism should be incorporated into some kind of BCP that describes the construction of enterprise phoen systems with SIP; I believe Brian mentioned he is working on such a thing. More inline. Rosen, Brian wrote: > Actually, I'm happy with a "Dial" button. > > I'll note most existing SIP phones don't do this (or at least don't > have a physical "Dial" button, I've seen some with softkeys). > > However, the issue remains. If I dial 6744 on my sip phone (and press > dial), the sipphone on my admin's desk should ring. I should not have > to dial +17247426744. The fact that I dialed a 4 digit number with > a 6 as the starting digit tells my system that it is an internal > extension. A dial plan is the thing that "knows" this. > > What do you want to have happen: > 1) tel:6744; context=+1724742 > 2) tel:6744; context=marconi-pittsburgh-local-extension > 3) tel:+17247426744 The notion of an identity that exists within a local context is exactly what a SIP URI is for. I always thought that if the user entered 6744, the most likely result would be the following URI: sip:6744@example.com where example.com is the local domain, configured into the phone. Unlike the tel URI, which has no clear way to determine where to go to resolve a number with a local context, the SIP URI does. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 24 23:19:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09713 for ; Fri, 24 Jan 2003 23:19:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P4cYo21146 for sipping-archive@odin.ietf.org; Fri, 24 Jan 2003 23:38:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4cYJ21143 for ; Fri, 24 Jan 2003 23:38:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09710 for ; Fri, 24 Jan 2003 23:18:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4c6J21122; Fri, 24 Jan 2003 23:38:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P4XGJ20322 for ; Fri, 24 Jan 2003 23:33:16 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09642 for ; Fri, 24 Jan 2003 23:13:26 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P4GuYH008505; Fri, 24 Jan 2003 23:16:59 -0500 (EST) Message-ID: <3E320FB4.9080304@dynamicsoft.com> Date: Fri, 24 Jan 2003 23:16:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: wenkai CC: sipping@ietf.org Subject: Re: [Sipping] a question about 3pcc References: <002801c2b845$94f91040$af064d0a@w07087a> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit wenkai wrote: > Hi, > The following is the "Mid-Call Announcement" call flow from > "draft-ietf-sipping-3pcc-02.txt". > After hanging up with the media server, the controller reconnects the > Pre-Paid user to the called party. I think the media stream(stream 3) > established between Pre-Paid user and the Called Party maybe is not the > same as the original media stream(stream 1). > In practice, maybe we want to have the same media codec as original one > when we restore a call. > Could you please give the call flow to reach this requirment? The media is re-established to the caller with an offer/answer exchange. Everything is done with sequences of offer/answer exchanges. Codec negotiation is fundamental to this exchange. So, if the called party decides, when its reconnected to the caller, to all of a sudden expand its proposed list of codecs (which it may do in offer3), the caller can pick the one it wants - which can be the one it was using before - in the answer (answer3). So, in summary, negotiation is already part of the flow below, and it would allow the caller to make sure the same codec is used throughout. -Jonathan R. > > Best Regards > Kevin > > > Pre-Paid User Controller Called Party Media > Server > | | | | > |..........stream 1.....................| | > | |(1) INV SDP c=0 | | > | |------------------>| | > | |(2) 200 answer1 | | > | |<------------------| | > | |(3) ACK | | > | |------------------>| | > |(4) INV no SDP | | | > |<------------------| | | > |(5) 200 offer2 | | | > |------------------>| | | > | |(6) INV offer2 | | > | |-------------------------------------->| > | |(7) 200 answer2 | | > | |<--------------------------------------| > |(8) ACK answer2 | | | > |<------------------| | | > | |(9) ACK | | > | |-------------------------------------->| > |(10) RTP | | | > |..........stream 2.........................................| > | |(11) BYE | | > | |-------------------------------------->| > | |(12) 200 OK | | > | |<--------------------------------------| > | |(13) INV no SDP | | > | |------------------>| | > | |(14) 200 offer3 | | > | |<------------------| | > |(15) INV offer3' | | | > |<------------------| | | > |(16) 200 answer3' | | | > |------------------>| | | > | |(17) ACK answer3' | | > | |------------------>| | > |(18) ACK | | | > |<------------------| | | > |(19) RTP | | | > |..........stream 3.....................| | -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 25 00:12:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10501 for ; Sat, 25 Jan 2003 00:12:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P5VOh23595 for sipping-archive@odin.ietf.org; Sat, 25 Jan 2003 00:31:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P5VOJ23592 for ; Sat, 25 Jan 2003 00:31:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10495 for ; Sat, 25 Jan 2003 00:11:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P5UUJ23535; Sat, 25 Jan 2003 00:30:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P5RGJ23454 for ; Sat, 25 Jan 2003 00:27:16 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10468 for ; Sat, 25 Jan 2003 00:07:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P5AvYH008512; Sat, 25 Jan 2003 00:10:57 -0500 (EST) Message-ID: <3E321C5D.3050200@dynamicsoft.com> Date: Sat, 25 Jan 2003 00:10:53 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: sipping@ietf.org Subject: Re: [Sipping] Event notification rate limiting requirements References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for writing this up. It seems to me that the main issue is, as you point out, how this relates to filters. The question really is, how is it that the notifier reduces the notification rate to the desired limit? I can see a few choices here: 1. the notifier implements a simple, package-independent algorithm that merely drops notifications that would cause the notification rate to be exceeded. 2. the notifier implements a vendor-proprietary algorithm that selectively discards notifications in an intelligent, package-specific way, meeting the desired notification rate limit. 3. the notifier implements a subscriber-provided filter, and its up to the definition of this filter to make sure that the rate is kept low enough 4. the notifier implements a subscriber-provided filter, and if the resulting notification rate is still not below the limit, it implements 1 or 2 above. Approach 1 is a mistake, I think. You need to intelligently filter in order to still provide a useful service (approach 2). In the case of buddy list presence, for example, the PA may choose an algorithm which round-robins through the buddy list, selecting the next buddy whose state has changed since the last notification to the watcher, and sends their state to the watcher. THis guarantees that no buddy is "starved" in terms of getting its updates through to the watcher. I would tend to think that approach 2 (having the client provide just the rate, and having the server implement a proprietary algorithm to meet it) is useful, as is supplying a filter to limit the rate, along with the orthogonal combination of the two. A few comments on the requirements: > REQ3: The subscriber SHOULD be allowed to indicate support for the > throttle mechanism without requiring it. what is the point of this requiremetn? > REQ8: The notifier MUST be allowed to use a maximum rate lower than > the one given by the subscriber. is this implying some kind of rate negotiation mechanism, akin to the Expires value in registrations? If so, there are some more requirements you need, such as conveying the final maximum rate back to the client. Is the assumption that the rate is a limit on the peak transmission rate, or is it a leaky-bucket style limit which provides an average maximum but allows for small bursts? -Jonathan R. aki.niemi@nokia.com wrote: > Hi All, > > In IETF55 it was agreed that the filtering requirements need to be > package specific, while rate limiting might be generic across all > packages. > > There is now a new draft available that discusses the requirements > for a generic event notification rate limiting mechanism, or event > throttle mechanism: > > http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttl- > e-reqs-00.txt > > One issue that has come up is that there are scenarios, where > throttles in fact need to be closely combined with event filters. For > example, assigning specific throttles to notifications from specific > presentities in a presence-list event requires that a single event > subscription applies several different throttles. > > So the main question is: should there be a generic throttle > mechanism, or are throttles event-package or filter-specific? Or do > we in fact need both types? > > Any comments? > > Cheers, Aki > > _______________________________________________ Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW > development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jan 25 03:51:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22080 for ; Sat, 25 Jan 2003 03:51:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P9B3p11552 for sipping-archive@odin.ietf.org; Sat, 25 Jan 2003 04:11:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P9B2J11549 for ; Sat, 25 Jan 2003 04:11:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22075 for ; Sat, 25 Jan 2003 03:51:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P9AQJ11530; Sat, 25 Jan 2003 04:10:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P8v7J10324 for ; Sat, 25 Jan 2003 03:57:08 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22007 for ; Sat, 25 Jan 2003 03:37:12 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18cLrj-00050f-00; Sat, 25 Jan 2003 10:40:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15922.19847.493726.836956@harjus.eng.song.fi> Date: Sat, 25 Jan 2003 10:40:39 +0200 To: "Rosen, Brian" Cc: "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF030B5D6D@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian writes: > I actually think we are best to standardize the behavior one way or > the other. It is a standards issue, regardless of how we implement > it (if you substitute "dialing plan" for "context" your explanation > above makes the same argument). i don't agree that is the task of a standards body to decide that a user needs to always the local dial plan. it should be up to the user to decide if he/she wants local dialing or "home" dialing. one way of making this decision is by the phone's preloaded route set. en empty route set results in local dialing via the outbound proxy and a route set that includes the user's home proxy results in "home" dialing. why would i need in addition to the preloaded route set specify the context of the number in the tel uri? looks to me that brian raised the same issue. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Jan 26 19:54:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24030 for ; Sun, 26 Jan 2003 19:54:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0R1EwL02378 for sipping-archive@odin.ietf.org; Sun, 26 Jan 2003 20:14:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1EwJ02375 for ; Sun, 26 Jan 2003 20:14:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24023 for ; Sun, 26 Jan 2003 19:54:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1ENJ02358; Sun, 26 Jan 2003 20:14:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1ApJ02266 for ; Sun, 26 Jan 2003 20:10:51 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23992 for ; Sun, 26 Jan 2003 19:50:06 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R0rvnB018297; Sun, 26 Jan 2003 19:53:58 -0500 (EST) Received: from cisco.com (rtp-vpn1-523.cisco.com [10.82.226.11]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY57150; Sun, 26 Jan 2003 19:58:09 -0500 (EST) Message-ID: <3E3482F2.8020505@cisco.com> Date: Sun, 26 Jan 2003 19:53:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Rosen, Brian" , "'Henning Schulzrinne'" , Adam Roach , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E320DFC.90805@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >> However, the issue remains. If I dial 6744 on my sip phone (and press >> dial), the sipphone on my admin's desk should ring. I should not have >> to dial +17247426744. The fact that I dialed a 4 digit number with >> a 6 as the starting digit tells my system that it is an internal >> extension. A dial plan is the thing that "knows" this. >> >> What do you want to have happen: >> 1) tel:6744; context=+1724742 >> 2) tel:6744; context=marconi-pittsburgh-local-extension >> 3) tel:+17247426744 > > > The notion of an identity that exists within a local context is exactly > what a SIP URI is for. I always thought that if the user entered 6744, > the most likely result would be the following URI: > > sip:6744@example.com > > where example.com is the local domain, configured into the phone. Unlike > the tel URI, which has no clear way to determine where to go to resolve > a number with a local context, the SIP URI does. I don't think there is any single right answer to this. But if the device has the form factor of a phone, with only a number pad rather than a full keyboard for entering the address, then I think sip:6744@example.com;user=phone would be a better choice than omitting the user=phone. This makes explicit a request to have the address interpretted (and probably expanded) as a phone number. And I think another choice that is at least as good is: tel:6744;phone-context=example.com It expresses the same intent more explicitly, and is not overtly dependent on the sip protocol. This doesn't matter a great deal in the request uri, but it might matter in the From address, because that might be captured by the recipient and saved for use in other contexts. The definition of the tel: uri specifies that a local number should only be used if there is no global number. (This is of course helpful because it maximizes the number of contexts in which the address may be successfully used.) So ideally, tel:+17247426744 would really be preferred. It requires that the phone contain the dial plan expansion. All these other possibilities are when there are good reasons why that can't or shouldn't be done. There is a lot to be said for canonical forms for addresses too. If a non-canonical form is used in the To address, it might not be understood by the recipient. For instance, suppose Alice calls Bob, but Bob has his calls forwarded to Charlie. Perhaps Charlie's phone checks the To address to see if the call was intended for him. If not it puts up a special indicator of a forwarded call and attempts to show who the call was actually for. If the To header has the full global form of the number called, then it is easy to figure out it is Bob's address. But if the To address has some local short form that makes sense only in Alice's domain, then Charlie's phone can't do much more than display it, and Charlie himself may be equally unlikely to recognize it. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Jan 26 20:19:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24323 for ; Sun, 26 Jan 2003 20:19:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0R1dOw03674 for sipping-archive@odin.ietf.org; Sun, 26 Jan 2003 20:39:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1dOJ03671 for ; Sun, 26 Jan 2003 20:39:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24315 for ; Sun, 26 Jan 2003 20:18:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1ctJ03572; Sun, 26 Jan 2003 20:38:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R1I2J02519 for ; Sun, 26 Jan 2003 20:18:02 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24116 for ; Sun, 26 Jan 2003 19:57:17 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0R11RnW018591; Sun, 26 Jan 2003 20:01:27 -0500 (EST) Received: from cisco.com (rtp-vpn1-523.cisco.com [10.82.226.11]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY57157; Sun, 26 Jan 2003 20:05:39 -0500 (EST) Message-ID: <3E3484B4.3000405@cisco.com> Date: Sun, 26 Jan 2003 20:00:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: aki.niemi@nokia.com, sipping@ietf.org Subject: Re: [Sipping] Event notification rate limiting requirements References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com> <3E321C5D.3050200@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Is the assumption that the rate is a limit on the peak transmission > rate, or is it a leaky-bucket style limit which provides an average > maximum but allows for small bursts? This is important! For instance, I believe the limit on presence notifications is currently 5 seconds. Now suppose you have a phone that changes presence state to indicate "On the Phone". This means that there are two presence changes per call. Now limiting calls to one every 10 seconds may be reasonable. But saying that you must wait 5 seconds after completing one call before answering another (or reporting it) isn't so reasonable. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 04:26:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10642 for ; Mon, 27 Jan 2003 04:26:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0R9lGh07350 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 04:47:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R9lGJ07347 for ; Mon, 27 Jan 2003 04:47:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10638 for ; Mon, 27 Jan 2003 04:26:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R9jsJ07242; Mon, 27 Jan 2003 04:45:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R9gcJ07094 for ; Mon, 27 Jan 2003 04:42:38 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10582 for ; Mon, 27 Jan 2003 04:21:43 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0R9Rag02669 for ; Mon, 27 Jan 2003 11:27:36 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 11:25:11 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 11:25:11 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] query on conference server X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 27 Jan 2003 11:25:10 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE719B@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] query on conference server Thread-Index: AcLD8V1kZBDfMhfVS3yM3ks8PUmAvAB9EAKQ To: , Cc: , X-OriginalArrivalTime: 27 Jan 2003 09:25:11.0402 (UTC) FILETIME=[FDAE0CA0:01C2C5E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0R9gdJ07095 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Is focus a conference server or an instance of a conference? I thought it was the latter, unless you mean the server of a particular conference is a focus. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, January 24, 2003 11:30 PM > To: Alan Johnston > Cc: margaretmary; sipping@ietf.org > Subject: Re: [Sipping] query on conference server > > > One additional note. The "models for multiparty conferencing > in sip" is > not going to move forward. Its content has been moved into > the framework > document Alan has pointed out, along with other documents that the > framework references. > > To briefly answer your questions, a conference server (called > a focus in > SIP) is a SIP user agent. Proxies don't know anything about > conferences. > They just route requests to URIs, and a URI might represent a > conference. > > -Jonathan R. > > Alan Johnston wrote: > > Hi Margaret, > > > > There is a SIPPING design team working on conferencing. > Information > > about the work is at: > > > > http://www.softarmor.com/sipping/teams/conf/ > > > > I'd recommend you start reading the conferencing framework document > > which may answer your questions: > > > > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-co > nferencing-framework-00.txt > > > > > > Thanks, > > Alan Johnston > > WorldCom > > sip:alan@digitalari.com > > > > At 09:46 AM 1/23/2003 +0530, margaretmary wrote: > > > >> hello sir, > >> > >> Can any one tell me about the conference server > application using SIP. > >> > >> Are these two drafts "Models for Multi Party Conferencing > SIP" and " A > >> Multi-Party Application Framework for SIP" specify for conference > >> server application. > >> > >> Is their any other draft for this, please tell me. > >> > >> Is it a simple SIP User Agent required to develop > conference server. > >> can SIP proxy server /Redirect server can come along with > conference > >> server. > >> > >> Please help me out with this. > >> Since i am new to SIPPING > >> > >> > >> > >> > >> Regards, > >> Margaret > >> > >> -------------------------------------------------------------- > >> Dexcel Electronics Designs (P) Ltd., Bangalore, India > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 04:47:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10896 for ; Mon, 27 Jan 2003 04:46:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RA7Nj08725 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 05:07:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RA7NJ08722 for ; Mon, 27 Jan 2003 05:07:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10893 for ; Mon, 27 Jan 2003 04:46:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RA6nJ08181; Mon, 27 Jan 2003 05:06:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RA38J08004 for ; Mon, 27 Jan 2003 05:03:08 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10843 for ; Mon, 27 Jan 2003 04:42:13 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0R9m8g21869 for ; Mon, 27 Jan 2003 11:48:08 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 11:45:42 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 11:45:42 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 27 Jan 2003 11:45:42 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE719C@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLFo2oQvQGoBCg5TMCDC3ERD0GmgQARUXWA To: , Cc: , X-OriginalArrivalTime: 27 Jan 2003 09:45:42.0729 (UTC) FILETIME=[DB9BA390:01C2C5E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RA38J08005 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit We have to have a number here that doesn't jeopardise a service but also doesn't wake watchers susceptible to DoS attacks. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, January 27, 2003 3:01 AM > To: Jonathan Rosenberg > Cc: Niemi Aki (NMP/Helsinki); sipping@ietf.org > Subject: Re: [Sipping] Event notification rate limiting requirements > > > Jonathan Rosenberg wrote: > > > > Is the assumption that the rate is a limit on the peak transmission > > rate, or is it a leaky-bucket style limit which provides an average > > maximum but allows for small bursts? > > This is important! For instance, I believe the limit on presence > notifications is currently 5 seconds. Now suppose you have a > phone that > changes presence state to indicate "On the Phone". This means > that there > are two presence changes per call. Now limiting calls to one every 10 > seconds may be reasonable. But saying that you must wait 5 > seconds after > completing one call before answering another (or reporting > it) isn't so > reasonable. > > Paul > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 06:33:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12282 for ; Mon, 27 Jan 2003 06:33:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RBrqU14844 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 06:53:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBrqJ14841 for ; Mon, 27 Jan 2003 06:53:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12279 for ; Mon, 27 Jan 2003 06:32:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBrCJ14806; Mon, 27 Jan 2003 06:53:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBpSJ14715 for ; Mon, 27 Jan 2003 06:51:28 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12227 for ; Mon, 27 Jan 2003 06:30:31 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RBWvn28066 for ; Mon, 27 Jan 2003 13:32:57 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 13:33:59 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 13:33:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements Date: Mon, 27 Jan 2003 13:33:57 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1EB@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQ To: Cc: X-OriginalArrivalTime: 27 Jan 2003 11:33:59.0271 (UTC) FILETIME=[FBD94770:01C2C5F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RBpSJ14716 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Comments inline. > It seems to me that the main issue is, as you point out, how this > relates to filters. The question really is, how is it that > the notifier > reduces the notification rate to the desired limit? I can see a few > choices here: > > 1. the notifier implements a simple, package-independent > algorithm that > merely drops notifications that would cause the notification > rate to be > exceeded. > > 2. the notifier implements a vendor-proprietary algorithm that > selectively discards notifications in an intelligent, > package-specific > way, meeting the desired notification rate limit. > > 3. the notifier implements a subscriber-provided filter, and > its up to > the definition of this filter to make sure that the rate is > kept low enough > > 4. the notifier implements a subscriber-provided filter, and if the > resulting notification rate is still not below the limit, it > implements > 1 or 2 above. > > > Approach 1 is a mistake, I think. You need to intelligently filter in > order to still provide a useful service (approach 2). In the case of > buddy list presence, for example, the PA may choose an > algorithm which > round-robins through the buddy list, selecting the next buddy whose > state has changed since the last notification to the watcher, > and sends > their state to the watcher. THis guarantees that no buddy is > "starved" > in terms of getting its updates through to the watcher. I think this sounds reasonable. And I agree, option 1 doesn't sound usable. So in my opinion, option 4 combined with option 2 is the preferred approach. > I would tend to think that approach 2 (having the client provide just > the rate, and having the server implement a proprietary algorithm to > meet it) is useful, as is supplying a filter to limit the rate, along > with the orthogonal combination of the two. I agree. > A few comments on the requirements: > > > REQ3: The subscriber SHOULD be allowed to indicate support for the > > throttle mechanism without requiring it. > > what is the point of this requiremetn? This means that the client provides the rate but doesn't require that the server abide by it. This is less strict than REQ2 in which a client provided rate is required to be used by the notifier. So REQ3 tries to lay out the leaky-bucket style limit you mention below. > > REQ8: The notifier MUST be allowed to use a maximum rate lower than > > the one given by the subscriber. > > is this implying some kind of rate negotiation mechanism, akin to the > Expires value in registrations? If so, there are some more > requirements > you need, such as conveying the final maximum rate back to the client. This tries to say that the notifier is always allowed to send less frequent notifications than what the throttle indicates, e.g., based on some local policy decision. Since the client is only really interested in limiting the rate to a specific maximum, it doesn't really matter what the actual rate is as long as it stays below the given maximum. In any case, with a very low maximum rate, say once per subscription expiration, the net effect would actually be equivalent to polling -- a throttle might limit the notifications to exactly two per subscription. So I'm open to suggestions on whether there is a requirement here to have a way for the notifier to at least decline a client provided rate, if it is unacceptable. > Is the assumption that the rate is a limit on the peak transmission > rate, or is it a leaky-bucket style limit which provides an average > maximum but allows for small bursts? Both, I guess. In one model, the throttle would be given as advice to the notifier, and in the other, its use would be strictly required. In other words, a throttle could be given two ways with "Require" and without it. ;) Overall, the model I had in mind is the one that the MWI uses. The throttle would set a minimum quarantine period for the notifications. Like in the mwi, the way notifications would be handled in this quarantine (e.g., does state get replaced and how) would have to be package specific, just like you say in option 2 above. I'm beginning to think maybe some of this discussion should already be present in the requirements I-D? Cheers, Aki _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 07:05:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13189 for ; Mon, 27 Jan 2003 07:05:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RCQEW16780 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 07:26:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCQEJ16777 for ; Mon, 27 Jan 2003 07:26:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13184 for ; Mon, 27 Jan 2003 07:05:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCPNJ16723; Mon, 27 Jan 2003 07:25:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCL0J16511 for ; Mon, 27 Jan 2003 07:21:00 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13078 for ; Mon, 27 Jan 2003 07:00:01 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RC5ug03912 for ; Mon, 27 Jan 2003 14:05:56 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 14:03:30 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 14:03:30 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 27 Jan 2003 14:03:30 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71A1@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yA= To: , Cc: X-OriginalArrivalTime: 27 Jan 2003 12:03:30.0652 (UTC) FILETIME=[1BAC91C0:01C2C5FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RCL0J16512 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Monday, January 27, 2003 1:34 PM > To: jdrosen@dynamicsoft.com > Cc: sipping@ietf.org > Subject: RE: [Sipping] Event notification rate limiting requirements > > > > > > REQ8: The notifier MUST be allowed to use a maximum rate > lower than > > > the one given by the subscriber. > > > > is this implying some kind of rate negotiation mechanism, > akin to the > > Expires value in registrations? If so, there are some more > > requirements > > you need, such as conveying the final maximum rate back to > the client. > > This tries to say that the notifier is always allowed to send > less frequent notifications than what the throttle indicates, > e.g., based on some local policy decision. Since the client > is only really interested in limiting the rate to a specific > maximum, it doesn't really matter what the actual rate is as > long as it stays below the given maximum. > > In any case, with a very low maximum rate, say once per > subscription expiration, the net effect would actually be > equivalent to polling -- a throttle might limit the > notifications to exactly two per subscription. > > So I'm open to suggestions on whether there is a requirement > here to have a way for the notifier to at least decline a > client provided rate, if it is unacceptable. > > > Is the assumption that the rate is a limit on the peak transmission > > rate, or is it a leaky-bucket style limit which provides an average > > maximum but allows for small bursts? > > Both, I guess. In one model, the throttle would be given as > advice to the notifier, and in the other, its use would be > strictly required. In other words, a throttle could be given > two ways with "Require" and without > it. ;) > I viewed this requirement from another angle; the notifier must be also able to increase the rate limit, or simply reject the request if the rate is too low. One reason for this is that local policies at servers, say Presence server, may have a limit on the frequency of notifications for security as well as bandwidth reasons. In this case, you don't want the subscriber to override this limit, hence the requirement I state above. To be in line with registration, one would suggest rejecting the request if rate limit is too low compared to local server policy. But is it needed? Can a server just increase the limit? Do the same reasonings applied to registration apply here? (I can't remember them anymore). Certainly a require-header type solution means rejecting the request, but lets examine the requirements first. > I'm beginning to think maybe some of this discussion should > already be present in the requirements I-D? I guess. Regards, Hisham > > Cheers, > Aki > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 07:32:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14058 for ; Mon, 27 Jan 2003 07:32:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RCqkb18514 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 07:52:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCqjJ18511 for ; Mon, 27 Jan 2003 07:52:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14048 for ; Mon, 27 Jan 2003 07:31:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCpWJ18485; Mon, 27 Jan 2003 07:51:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCo8J18440 for ; Mon, 27 Jan 2003 07:50:08 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14024 for ; Mon, 27 Jan 2003 07:29:08 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RCZ3g28599 for ; Mon, 27 Jan 2003 14:35:03 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 14:32:37 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 14:32:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements Date: Mon, 27 Jan 2003 14:32:37 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945132@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yAAAHIVgA== To: , Cc: X-OriginalArrivalTime: 27 Jan 2003 12:32:37.0594 (UTC) FILETIME=[2CEEC3A0:01C2C600] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RCo8J18441 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Hisham, Inline. > > > > REQ8: The notifier MUST be allowed to use a maximum rate > > lower than > > > > the one given by the subscriber. > > > > > > is this implying some kind of rate negotiation mechanism, > > akin to the > > > Expires value in registrations? If so, there are some more > > > requirements > > > you need, such as conveying the final maximum rate back to > > the client. > > > > This tries to say that the notifier is always allowed to send > > less frequent notifications than what the throttle indicates, > > e.g., based on some local policy decision. Since the client > > is only really interested in limiting the rate to a specific > > maximum, it doesn't really matter what the actual rate is as > > long as it stays below the given maximum. > > > > In any case, with a very low maximum rate, say once per > > subscription expiration, the net effect would actually be > > equivalent to polling -- a throttle might limit the > > notifications to exactly two per subscription. > > > > So I'm open to suggestions on whether there is a requirement > > here to have a way for the notifier to at least decline a > > client provided rate, if it is unacceptable. > > > > > Is the assumption that the rate is a limit on the peak > transmission > > > rate, or is it a leaky-bucket style limit which provides > an average > > > maximum but allows for small bursts? > > > > Both, I guess. In one model, the throttle would be given as > > advice to the notifier, and in the other, its use would be > > strictly required. In other words, a throttle could be given > > two ways with "Require" and without > > it. ;) > > > > I viewed this requirement from another angle; the notifier > must be also able to increase the rate limit, or simply > reject the request if the rate is too low. One reason for > this is that local policies at servers, say Presence server, > may have a limit on the frequency of notifications for > security as well as bandwidth reasons. In this case, you > don't want the subscriber to override this limit, hence the > requirement I state above. "Rate" may be confusing me here. In terms of quarantine period, or time between two consecutive notifications, Are you saying that the notifier should be able to increase the quarantine time, or decrease it? If you mean increasing the time, I think that's what the requirements already say (a lower rate means higher time between notifications). And this is similar to the registrar declining with a min-expires - it's saving its own resources, by sending less frequent notifications. If it's decrease, then I agree we would need some way for the notifier to either reject, or reject and adjust the client-given rate. I just don't see a huge need for this. If we assume more frequent notifications require more resources - this behavior would make things "worse" for the notifier. Having said that, I believe rejecting (or making recommendations to that effect) throttles with ridiculously low rates may be a good idea, e.g., when the throttle achieves the same effect as doing a fetch every few hours or once a week... > To be in line with registration, one would suggest rejecting > the request if rate limit is too low compared to local server > policy. But is it needed? Can a server just increase the > limit? Do the same reasonings applied to registration apply > here? (I can't remember them anymore). Certainly a > require-header type solution means rejecting the request, but > lets examine the requirements first. To be in line with registrations, I don't think we necessarily need the ability to reject a throttle - with the above exceptions. > > I'm beginning to think maybe some of this discussion should > > already be present in the requirements I-D? > > I guess. I'll fire up my emacs then. ;) Cheers, Aki _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 07:38:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14393 for ; Mon, 27 Jan 2003 07:38:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RCwje18698 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 07:58:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCwjJ18695 for ; Mon, 27 Jan 2003 07:58:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14343 for ; Mon, 27 Jan 2003 07:37:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCwDJ18668; Mon, 27 Jan 2003 07:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RCvaJ18649 for ; Mon, 27 Jan 2003 07:57:36 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14274 for ; Mon, 27 Jan 2003 07:36:37 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RCgWg04846 for ; Mon, 27 Jan 2003 14:42:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 14:40:07 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 14:40:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements Date: Mon, 27 Jan 2003 14:40:06 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1F0@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLFn4l9vrW/NDZfQky3haoE8G0/IAAYUR1Q To: , Cc: X-OriginalArrivalTime: 27 Jan 2003 12:40:07.0185 (UTC) FILETIME=[38E8E810:01C2C601] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RCvaJ18650 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, > Jonathan Rosenberg wrote: > > > > Is the assumption that the rate is a limit on the peak transmission > > rate, or is it a leaky-bucket style limit which provides an average > > maximum but allows for small bursts? > > This is important! For instance, I believe the limit on presence > notifications is currently 5 seconds. Now suppose you have a > phone that > changes presence state to indicate "On the Phone". This means > that there > are two presence changes per call. Now limiting calls to one every 10 > seconds may be reasonable. But saying that you must wait 5 > seconds after > completing one call before answering another (or reporting > it) isn't so > reasonable. I agree. But isn't then the use of a throttle mechanism ill-adviced, if one requires more frequent updates than what a throttled subscription would give? Cheers, Aki _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 07:48:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14576 for ; Mon, 27 Jan 2003 07:48:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RD8aV19817 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 08:08:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RD8aJ19814 for ; Mon, 27 Jan 2003 08:08:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14561 for ; Mon, 27 Jan 2003 07:47:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RD86J19791; Mon, 27 Jan 2003 08:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RD7TJ19719 for ; Mon, 27 Jan 2003 08:07:29 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14507 for ; Mon, 27 Jan 2003 07:46:28 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RCmun02134 for ; Mon, 27 Jan 2003 14:48:56 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 14:49:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 14:49:57 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 27 Jan 2003 14:49:57 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71A8@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yAAAHIVgAABLtJQ To: , Cc: X-OriginalArrivalTime: 27 Jan 2003 12:49:57.0473 (UTC) FILETIME=[98BFB510:01C2C602] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RD7TJ19720 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I guess I confused myself as well as others. Yes, lower rate means higher period of time between notifies. I was talking about subscribers increasing the rate to a number that is higher than the server's allowed maximum. If the server has a rate limit of the typical once per 5 seconds, the subscriber must not be able to increase this rate to, say, 5 times per 5 seconds. So the requirement is: The notifier must be able to reject a subscription containing a rate limit higher that is local configured maximum. You are talking about the subscriber lowering that rate to a ridiculously low rate as to once per hour. I think this is ok and no need to reject those types of requests. Regards, Hisham > -----Original Message----- > From: Niemi Aki (NMP/Helsinki) > Sent: Monday, January 27, 2003 2:33 PM > To: Khartabil Hisham (NMP/Helsinki); 'jdrosen@dynamicsoft.com' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] Event notification rate limiting requirements > > > Hi Hisham, > > Inline. > > > > > > REQ8: The notifier MUST be allowed to use a maximum rate > > > lower than > > > > > the one given by the subscriber. > > > > > > > > is this implying some kind of rate negotiation mechanism, > > > akin to the > > > > Expires value in registrations? If so, there are some more > > > > requirements > > > > you need, such as conveying the final maximum rate back to > > > the client. > > > > > > This tries to say that the notifier is always allowed to send > > > less frequent notifications than what the throttle indicates, > > > e.g., based on some local policy decision. Since the client > > > is only really interested in limiting the rate to a specific > > > maximum, it doesn't really matter what the actual rate is as > > > long as it stays below the given maximum. > > > > > > In any case, with a very low maximum rate, say once per > > > subscription expiration, the net effect would actually be > > > equivalent to polling -- a throttle might limit the > > > notifications to exactly two per subscription. > > > > > > So I'm open to suggestions on whether there is a requirement > > > here to have a way for the notifier to at least decline a > > > client provided rate, if it is unacceptable. > > > > > > > Is the assumption that the rate is a limit on the peak > > transmission > > > > rate, or is it a leaky-bucket style limit which provides > > an average > > > > maximum but allows for small bursts? > > > > > > Both, I guess. In one model, the throttle would be given as > > > advice to the notifier, and in the other, its use would be > > > strictly required. In other words, a throttle could be given > > > two ways with "Require" and without > > > it. ;) > > > > > > > I viewed this requirement from another angle; the notifier > > must be also able to increase the rate limit, or simply > > reject the request if the rate is too low. One reason for > > this is that local policies at servers, say Presence server, > > may have a limit on the frequency of notifications for > > security as well as bandwidth reasons. In this case, you > > don't want the subscriber to override this limit, hence the > > requirement I state above. > > "Rate" may be confusing me here. In terms of quarantine > period, or time between two consecutive notifications, Are > you saying that the notifier should be able to increase the > quarantine time, or decrease it? > > If you mean increasing the time, I think that's what the > requirements already say (a lower rate means higher time > between notifications). And this is similar to the registrar > declining with a min-expires - it's saving its own resources, > by sending less frequent notifications. > > If it's decrease, then I agree we would need some way for the > notifier to either reject, or reject and adjust the > client-given rate. I just don't see a huge need for this. If > we assume more frequent notifications require more resources > - this behavior would make things "worse" for the notifier. > > Having said that, I believe rejecting (or making > recommendations to that effect) throttles with ridiculously > low rates may be a good idea, e.g., when the throttle > achieves the same effect as doing a fetch every few hours or > once a week... > > > To be in line with registration, one would suggest rejecting > > the request if rate limit is too low compared to local server > > policy. But is it needed? Can a server just increase the > > limit? Do the same reasonings applied to registration apply > > here? (I can't remember them anymore). Certainly a > > require-header type solution means rejecting the request, but > > lets examine the requirements first. > > To be in line with registrations, I don't think we > necessarily need the ability to reject a throttle - with the > above exceptions. > > > > I'm beginning to think maybe some of this discussion should > > > already be present in the requirements I-D? > > > > I guess. > > I'll fire up my emacs then. ;) > > Cheers, > Aki > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 07:57:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14814 for ; Mon, 27 Jan 2003 07:57:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RDHt920151 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 08:17:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDHtJ20148 for ; Mon, 27 Jan 2003 08:17:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14802 for ; Mon, 27 Jan 2003 07:56:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDHFJ20115; Mon, 27 Jan 2003 08:17:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDGfJ20088 for ; Mon, 27 Jan 2003 08:16:41 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14782 for ; Mon, 27 Jan 2003 07:55:41 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RD1bg20838 for ; Mon, 27 Jan 2003 15:01:37 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 14:59:05 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 14:59:05 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 14:59:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements Date: Mon, 27 Jan 2003 14:59:04 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1F2@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yAAAHIVgAABLtJQAABtPjA= To: , Cc: X-OriginalArrivalTime: 27 Jan 2003 12:59:04.0544 (UTC) FILETIME=[DED41E00:01C2C603] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RDGfJ20089 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I'm still confused... Hey, it's Monday so bear with me ;) > I guess I confused myself as well as others. > > Yes, lower rate means higher period of time between notifies. > > I was talking about subscribers increasing the rate to a > number that is higher than the server's allowed maximum. If > the server has a rate limit of the typical once per 5 > seconds, the subscriber must not be able to increase this > rate to, say, 5 times per 5 seconds. > > So the requirement is: The notifier must be able to reject a > subscription containing a rate limit higher that is local > configured maximum. My point was that there is no need to reject such a limit, as long as the notifier MUST be allowed to use a lower rate. So the notifier may accept, and still abide by its own internal default policy of 1 notification per 5 seconds. The subscriber is still happy, since its max rate is not exceeded. Such a throttle will be utterly useless, but won't break anything... > You are talking about the subscriber lowering that rate to a > ridiculously low rate as to once per hour. I think this is ok > and no need to reject those types of requests. Except if the effects of such a filter become worse than for example, polling at the same frequency. Cheers, Aki _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 08:31:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15410 for ; Mon, 27 Jan 2003 08:31:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RDpaA22029 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 08:51:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDpaJ22026 for ; Mon, 27 Jan 2003 08:51:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15387 for ; Mon, 27 Jan 2003 08:30:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDoIJ21928; Mon, 27 Jan 2003 08:50:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDjvJ21693 for ; Mon, 27 Jan 2003 08:45:57 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15290 for ; Mon, 27 Jan 2003 08:24:56 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RDRPn05506 for ; Mon, 27 Jan 2003 15:27:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 15:28:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 15:28:26 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 27 Jan 2003 15:28:26 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLEMCadrtdES+TVQryKAg+tt0lgpgBpgLTQAAkf2yAAAHIVgAABLtJQAABtPjAAAK2GMA== To: , Cc: X-OriginalArrivalTime: 27 Jan 2003 13:28:26.0980 (UTC) FILETIME=[F9528240:01C2C607] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RDjvJ21694 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Niemi Aki (NMP/Helsinki) > Sent: Monday, January 27, 2003 2:59 PM > To: Khartabil Hisham (NMP/Helsinki); 'jdrosen@dynamicsoft.com' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] Event notification rate limiting requirements > > > I'm still confused... Hey, it's Monday so bear with me ;) > > > I guess I confused myself as well as others. > > > > Yes, lower rate means higher period of time between notifies. > > > > I was talking about subscribers increasing the rate to a > > number that is higher than the server's allowed maximum. If > > the server has a rate limit of the typical once per 5 > > seconds, the subscriber must not be able to increase this > > rate to, say, 5 times per 5 seconds. > > > > So the requirement is: The notifier must be able to reject a > > subscription containing a rate limit higher that is local > > configured maximum. > > My point was that there is no need to reject such a limit, as > long as the notifier MUST be allowed to use a lower rate. So > the notifier may accept, and still abide by its own internal > default policy of 1 notification per 5 seconds. The > subscriber is still happy, since its max rate is not > exceeded. Such a throttle will be utterly useless, but won't > break anything... Looking at the registration solution; a registrar can lower the expiration time and therefore increase the rate of registration requests. The registrar must not increase the expiration time, i.e. registrar cannot lower the rate of registration and must reject with 423. I don't have strong feeling either way. Any other opinions? > > > You are talking about the subscriber lowering that rate to a > > ridiculously low rate as to once per hour. I think this is ok > > and no need to reject those types of requests. > > Except if the effects of such a filter become worse than for > example, polling at the same frequency. Polling, aka fetching, has an extra subscribe/200 that can be avoided with this mechanism. I used this example in a separate discussion and I'll use it again here: If Aki was driving down from Lapland to Helsinki, I'm interested to get his presence info once every hour or so. By subscribing to his presence and limiting the rate of notifications to 1 per hour is a good thing. I get the notifications automatically. I don't have to manually subscribe every hour and waste bandwidth. The only scenario where I think a subscription with rate limit may be rejected is when the rate allows 0 notifies to be sent with the subscription duration. I.e. Subscription duration is 1 hour and rate limit is once per 2 hours. I think this scenario is worse than fetching (It might be ok to accept the subscription and only generate the first notify). Regards, Hisham > > Cheers, > Aki > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 08:39:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15627 for ; Mon, 27 Jan 2003 08:39:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RDxtt22585 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 08:59:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDxtJ22582 for ; Mon, 27 Jan 2003 08:59:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15621 for ; Mon, 27 Jan 2003 08:38:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDxJJ22526; Mon, 27 Jan 2003 08:59:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RDwUJ22462 for ; Mon, 27 Jan 2003 08:58:30 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15586 for ; Mon, 27 Jan 2003 08:37:31 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0RDeqUP011116 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jan 2003 08:40:53 -0500 (EST) Message-ID: <3E353700.3040506@cs.columbia.edu> Date: Mon, 27 Jan 2003 08:41:20 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , aki.niemi@nokia.com, sipping@ietf.org Subject: Re: [Sipping] Event notification rate limiting requirements References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com> <3E321C5D.3050200@dynamicsoft.com> <3E3484B4.3000405@cisco.com> In-Reply-To: <3E3484B4.3000405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Complexity can get out of hand pretty quickly here. Once you have a leaky bucket with queueing, you have to start worrying about removing pending announcements that cancel each other. No point sending 'on the phone' 30 minutes later if the person has long since ceased talking, particularly since the user interface may not be able to tell whether this notification is still current or not, particularly after you gateway into other systems. If you just drop notifications, you can get 'stuck' in the wrong state, like 'talking on the phone', for very long periods of time. Paul Kyzivat wrote: > Jonathan Rosenberg wrote: > >> >> Is the assumption that the rate is a limit on the peak transmission >> rate, or is it a leaky-bucket style limit which provides an average >> maximum but allows for small bursts? > > > This is important! For instance, I believe the limit on presence > notifications is currently 5 seconds. Now suppose you have a phone that > changes presence state to indicate "On the Phone". This means that there > are two presence changes per call. Now limiting calls to one every 10 > seconds may be reasonable. But saying that you must wait 5 seconds after > completing one call before answering another (or reporting it) isn't so > reasonable. > > Paul > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 08:49:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15824 for ; Mon, 27 Jan 2003 08:49:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RE9jN23698 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 09:09:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RE9jJ23695 for ; Mon, 27 Jan 2003 09:09:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15821 for ; Mon, 27 Jan 2003 08:48:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RE99J23653; Mon, 27 Jan 2003 09:09:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RE8tJ23624 for ; Mon, 27 Jan 2003 09:08:55 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15790 for ; Mon, 27 Jan 2003 08:47:56 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0RDpNUP015299 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jan 2003 08:51:24 -0500 (EST) Message-ID: <3E353977.2030802@cs.columbia.edu> Date: Mon, 27 Jan 2003 08:51:51 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, jdrosen@dynamicsoft.com, sipping@ietf.org Subject: Re: [Sipping] Event notification rate limiting requirements References: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I used this example in a separate discussion and I'll use it again > here: If Aki was driving down from Lapland to Helsinki, I'm > interested to get his presence info once every hour or so. By > subscribing to his presence and limiting the rate of notifications to > 1 per hour is a good thing. I get the notifications automatically. I > don't have to manually subscribe every hour and waste bandwidth. There are two classes of notifications: stateless and stateful. Presence (closed/busy) is stateful, in that it persists at the receiver until the next announcement. Location is stateless - the accuracy of estimation of the variable just decreases as the rate of updates decreases. In many cases, physical constraints limit the error. If I know you are in a land vehicle, I can draw a circle around a last position report that increases its radius at around 70 mph and have high confidence that the entity hasn't suddenly gone into hyperspace. It's relatively easy to ratelimit the latter, much harder to ratelimit the former. > > The only scenario where I think a subscription with rate limit may be > rejected is when the rate allows 0 notifies to be sent with the > subscription duration. I.e. Subscription duration is 1 hour and rate > limit is once per 2 hours. I think this scenario is worse than > fetching (It might be ok to accept the subscription and only generate > the first notify). > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 09:05:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16069 for ; Mon, 27 Jan 2003 09:05:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0REQ6924333 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 09:26:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REQ5J24330 for ; Mon, 27 Jan 2003 09:26:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16062 for ; Mon, 27 Jan 2003 09:05:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REPGJ24297; Mon, 27 Jan 2003 09:25:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REO9J24241 for ; Mon, 27 Jan 2003 09:24:09 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16036 for ; Mon, 27 Jan 2003 09:03:09 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0RE5an10828 for ; Mon, 27 Jan 2003 16:05:36 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 16:06:38 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 16:06:36 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 16:06:36 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 27 Jan 2003 16:06:36 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71AD@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLGCtMqj1YkMIuqTRqfJ5QdiRHT6wAAU3RQ To: , Cc: , , X-OriginalArrivalTime: 27 Jan 2003 14:06:36.0498 (UTC) FILETIME=[4DFB3B20:01C2C60D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0REO9J24242 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit One would think that there is only one notify in the queue that gets replaced by an update to, for example, presence of a presentity. If I am "on the phone" for 20 mins (which results in another presence state change to "available" after that), but my watcher is notified every 30 mins. Then I would expect the presence service to send the newest notify which carries the info that I'm available. -5 mins - "available" <-- NOTIFY to watcher "available" 0 mins - "on the phone" 20 mins - "available" 30 mins - "available" <-- NOTIFY to watcher "available" You don't want to queue and send all notifies, just the most recent one at the time of sending a notify. /Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, January 27, 2003 3:41 PM > To: Paul Kyzivat > Cc: Jonathan Rosenberg; Niemi Aki (NMP/Helsinki); sipping@ietf.org > Subject: Re: [Sipping] Event notification rate limiting requirements > > > Complexity can get out of hand pretty quickly here. Once you have a > leaky bucket with queueing, you have to start worrying about removing > pending announcements that cancel each other. No point > sending 'on the > phone' 30 minutes later if the person has long since ceased talking, > particularly since the user interface may not be able to tell whether > this notification is still current or not, particularly after you > gateway into other systems. > > If you just drop notifications, you can get 'stuck' in the > wrong state, > like 'talking on the phone', for very long periods of time. > > Paul Kyzivat wrote: > > Jonathan Rosenberg wrote: > > > >> > >> Is the assumption that the rate is a limit on the peak > transmission > >> rate, or is it a leaky-bucket style limit which provides > an average > >> maximum but allows for small bursts? > > > > > > This is important! For instance, I believe the limit on presence > > notifications is currently 5 seconds. Now suppose you have > a phone that > > changes presence state to indicate "On the Phone". This > means that there > > are two presence changes per call. Now limiting calls to > one every 10 > > seconds may be reasonable. But saying that you must wait 5 > seconds after > > completing one call before answering another (or reporting > it) isn't so > > reasonable. > > > > Paul > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 09:17:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16276 for ; Mon, 27 Jan 2003 09:17:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0REc2d25431 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 09:38:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REc2J25428 for ; Mon, 27 Jan 2003 09:38:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16264 for ; Mon, 27 Jan 2003 09:17:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REbHJ25160; Mon, 27 Jan 2003 09:37:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REa1J24698 for ; Mon, 27 Jan 2003 09:36:01 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16236 for ; Mon, 27 Jan 2003 09:15:01 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0REKtg01014 for ; Mon, 27 Jan 2003 16:20:55 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Jan 2003 16:18:30 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 16:18:30 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Jan 2003 16:18:29 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Event notification rate limiting requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 27 Jan 2003 16:18:29 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71AE@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Event notification rate limiting requirements Thread-Index: AcLGCzPKBHKM8ZC6TMOnBGpkQebmRQAAl6tA To: Cc: , , X-OriginalArrivalTime: 27 Jan 2003 14:18:29.0738 (UTC) FILETIME=[F71B04A0:01C2C60E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0REa1J24699 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit If the presence info sent to the watcher is the most recently available, then fetching is no more accurate than what I described. If the location entity, that reports one's position to the presence server, only sends updates every 30 mins, and the presence server sends the watcher that last presence update when the rate limit allows it to, then its as accurate as it can get, stateless or not. Regards, Hisham > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, January 27, 2003 3:52 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Niemi Aki (NMP/Helsinki); jdrosen@dynamicsoft.com; > sipping@ietf.org > Subject: Re: [Sipping] Event notification rate limiting requirements > > > > I used this example in a separate discussion and I'll use it again > > here: If Aki was driving down from Lapland to Helsinki, I'm > > interested to get his presence info once every hour or so. By > > subscribing to his presence and limiting the rate of > notifications to > > 1 per hour is a good thing. I get the notifications automatically. I > > don't have to manually subscribe every hour and waste bandwidth. > > There are two classes of notifications: stateless and > stateful. Presence > (closed/busy) is stateful, in that it persists at the > receiver until the > next announcement. Location is stateless - the accuracy of > estimation of > the variable just decreases as the rate of updates decreases. In many > cases, physical constraints limit the error. If I know you > are in a land > vehicle, I can draw a circle around a last position report that > increases its radius at around 70 mph and have high > confidence that the > entity hasn't suddenly gone into hyperspace. > > It's relatively easy to ratelimit the latter, much harder to > ratelimit > the former. > > > > > The only scenario where I think a subscription with rate > limit may be > > rejected is when the rate allows 0 notifies to be sent with the > > subscription duration. I.e. Subscription duration is 1 hour and rate > > limit is once per 2 hours. I think this scenario is worse than > > fetching (It might be ok to accept the subscription and > only generate > > the first notify). > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 09:40:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16503 for ; Mon, 27 Jan 2003 09:40:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RF1OS26287 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 10:01:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RF1OJ26284 for ; Mon, 27 Jan 2003 10:01:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16498 for ; Mon, 27 Jan 2003 09:40:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RF0cJ26255; Mon, 27 Jan 2003 10:00:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RExQJ26150 for ; Mon, 27 Jan 2003 09:59:26 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16483 for ; Mon, 27 Jan 2003 09:38:25 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0REfndS011892 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jan 2003 09:41:50 -0500 (EST) Message-ID: <3E354548.4030908@cs.columbia.edu> Date: Mon, 27 Jan 2003 09:42:16 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , "Rosen, Brian" , Adam Roach , "'sipping@ietf.org'" Subject: Re: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt References: <313680C9A886D511A06000204840E1CF030B5D01@whq-msgusr-02.pit.comms.marconi.com> <3E320DFC.90805@dynamicsoft.com> <3E3482F2.8020505@cisco.com> In-Reply-To: <3E3482F2.8020505@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I don't think there is any single right answer to this. But we may be able to avoid many of the fruitless discussions by recommending easier alternatives in certain cases. Let me try to summarize and see if we can agree on this: - For web pages and other non-SIP contexts such as address books, global tel URIs are preferred since they avoid extraneous information. Local tel URIs would be used only in exceptional cases, but the context is extremely important here in case a web page "leaks" to another context. - For SIP phones, local dialplans should translate dialed digits into either global tel URIs or SIP URIs within either the local SIP domain (if the dialing plan is local) or the user's AOR domain. This affords maximum flexibility - users can decide whether they want to take their dialing plan with them or use the local one in places they visit. One way to learn about the dialing plan is to send OPTIONS to the outbound proxy (found via DHCP, say), either directly or via content indirection. - If there is no dialing plan, a translation into a SIP URI with the digits + local domain seems safest. - Local tel URIs without context MUST NOT be used in From and Reply-To, Local tel URIs with context SHOULD NOT be used in that context. - Local tel URIs without context are a bad idea in To headers. My inclination is MUST NOT. (This is nothing new, since context is required anyway.) - There may be cases for a context-based local tel URI in SIP phones, but I'm having a hard time seeing the advantage compared to the SIP URI with user=phone. The SIP URI allows much more flexibility in terms of who does the resolution, rather than just rejecting out-of-context URIs. - Given the above, I can't see a case for a context-free local tel URI (tel:1234). Using a SIP URI seems much less likely to cause trouble and requires no more configuration beyond knowing the outbound proxy server. I'm considering adding a non-normative annex to 2806bis to capture these guidelines. > > But if the device has the form factor of a phone, with only a number pad > rather than a full keyboard for entering the address, then I think > > sip:6744@example.com;user=phone > > would be a better choice than omitting the user=phone. This makes > explicit a request to have the address interpretted (and probably > expanded) as a phone number. > > And I think another choice that is at least as good is: > > tel:6744;phone-context=example.com > > It expresses the same intent more explicitly, and is not overtly > dependent on the sip protocol. This doesn't matter a great deal in the > request uri, but it might matter in the From address, because that might > be captured by the recipient and saved for use in other contexts. > > The definition of the tel: uri specifies that a local number should only > be used if there is no global number. (This is of course helpful because > it maximizes the number of contexts in which the address may be > successfully used.) So ideally, > > tel:+17247426744 > > would really be preferred. It requires that the phone contain the dial > plan expansion. All these other possibilities are when there are good > reasons why that can't or shouldn't be done. > > There is a lot to be said for canonical forms for addresses too. If a > non-canonical form is used in the To address, it might not be understood > by the recipient. For instance, suppose Alice calls Bob, but Bob has his > calls forwarded to Charlie. Perhaps Charlie's phone checks the To > address to see if the call was intended for him. If not it puts up a > special indicator of a forwarded call and attempts to show who the call > was actually for. If the To header has the full global form of the > number called, then it is easy to figure out it is Bob's address. But if > the To address has some local short form that makes sense only in > Alice's domain, then Charlie's phone can't do much more than display it, > and Charlie himself may be equally unlikely to recognize it. > > Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 09:53:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16757 for ; Mon, 27 Jan 2003 09:53:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RFDex27374 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 10:13:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFDeJ27371 for ; Mon, 27 Jan 2003 10:13:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16677 for ; Mon, 27 Jan 2003 09:52:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFDBJ27335; Mon, 27 Jan 2003 10:13:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFCDJ27308 for ; Mon, 27 Jan 2003 10:12:13 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16661 for ; Mon, 27 Jan 2003 09:51:13 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0REtEdi021969; Mon, 27 Jan 2003 09:55:15 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY58909; Mon, 27 Jan 2003 09:59:26 -0500 (EST) Message-ID: <3E354820.5010401@cisco.com> Date: Mon, 27 Jan 2003 09:54:24 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org CC: Henning Schulzrinne , Jonathan Rosenberg , aki.niemi@nokia.com, hisham.khartabil@nokia.com Subject: Re: [Sipping] Event notification rate limiting requirements References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1D4@esebe013.ntc.nokia.com> <3E321C5D.3050200@dynamicsoft.com> <3E3484B4.3000405@cisco.com> <3E353700.3040506@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Replying to a bunch of comments: My point is that a single number, strictly enforced, isn't sufficient to achieve this. In general it may be rare for a call to last less than 30 seconds, so I am satisfied to limit to an average rate of no more than 2 notifications per 30 seconds. But limiting to one notification per 15 seconds may be unacceptable, because in general it means 15 seconds of idle time before another call. Hisham's approach has a fatal flaw. Suppose I want to call you, but you are on the phone most of the time - you take 30 second breaks between 30 minute phone calls. At what rate must you accept notifications in order to have a chance to get a call through to me? If there is no averaging, you probably have to set your rate at no less than 4/minute (15 seconds) to have a chance. But you don't want to be getting them at that rate continuously. Perhaps it is sufficient to specify this as two numbers: N/T. (Than is, N notifications per time interval T.) At least that seems sufficient for this case. And it isn't inordinately complex to implement. So, as a client you will in general get better results with (X*N)/(X*T) than with N/T, at the cost of some potential bursts of X messages. In my example an X of 2 is sufficient because the presentity is alternating between two states. Paul hisham.khartabil@nokia.com wrote: > We have to have a number here that doesn't jeopardise a service but also doesn't wake watchers susceptible to DoS attacks. aki.niemi@nokia.com wrote: > > I agree. But isn't then the use of a throttle mechanism ill-adviced, if one requires more frequent updates than what a throttled subscription would give? Henning Schulzrinne wrote: > Complexity can get out of hand pretty quickly here. Once you have a > leaky bucket with queueing, you have to start worrying about removing > pending announcements that cancel each other. No point sending 'on the > phone' 30 minutes later if the person has long since ceased talking, > particularly since the user interface may not be able to tell whether > this notification is still current or not, particularly after you > gateway into other systems. > > If you just drop notifications, you can get 'stuck' in the wrong state, > like 'talking on the phone', for very long periods of time. hisham.khartabil@nokia.com wrote: > One would think that there is only one notify in the queue that gets replaced by an update to, for example, presence of a presentity. > > If I am "on the phone" for 20 mins (which results in another presence state change to "available" after that), but my watcher is notified every 30 mins. Then I would expect the presence service to send the newest notify which carries the info that I'm available. > > -5 mins - "available" > <-- NOTIFY to watcher "available" > 0 mins - "on the phone" > 20 mins - "available" > 30 mins - "available" > <-- NOTIFY to watcher "available" > > You don't want to queue and send all notifies, just the most recent one at the time of sending a notify. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 14:10:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23138 for ; Mon, 27 Jan 2003 14:10:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RJUmC10870 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 14:30:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJUmJ10867 for ; Mon, 27 Jan 2003 14:30:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23133 for ; Mon, 27 Jan 2003 14:09:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJQWJ10690; Mon, 27 Jan 2003 14:26:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJNvJ10588 for ; Mon, 27 Jan 2003 14:23:57 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22955 for ; Mon, 27 Jan 2003 14:02:48 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23904; Mon, 27 Jan 2003 14:06:13 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12356; Mon, 27 Jan 2003 14:06:11 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 14:06:10 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D74@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Mon, 27 Jan 2003 14:06:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I can see including a context token as a confirmation, or even selection of the dial plan domain to be interpreted by a proxy. I see the value. The text in 2806bis can get considerably smaller and more focused, right? It would seem that most of the confusion on context then goes away. So, summarizing: a) The preferred mechanism is UA has dialing plan. We will standardize a notation, and a method to learn it b) We support a proxy translation of dial string to routable numbers. We should choose ONE way to send a dial string. I personally like sip:dialsting@domain, with or without user=phone. It could have the context parameter. If we use a tel uri, then text in 2806bis about dial strings must change c) The context is either learned from the environment (DHCP?), or provisioned. It is always included in the URI when the number is not known to be directly routable (not correct to say global) A UAC either expands dialstrings to routable numbers and emits a tel uri, or it sends dialstrings with a context. A proxy server either routes a tel uri without a context, or expands a dialstring to a routable uri from the dialstring+context. Contexts need to be unique within the domain of a proxy server and all the UAs that might get service from it. I think that if you allow contexts to be provisioned in the phone, that we should have some kind of naming convention or something. If they were always learned, then they would just have to be unique within the domain they were learned from. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, January 24, 2003 6:03 PM > To: Rosen, Brian > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > As yet another example, what is my context? Is it "Marconi > Pittsburgh". > > Is that globally unique? Or is it "+1724742"? That's > globally unique, > > but may or may not be useable by my first hop proxy. > > The point is that you and your first hop proxy better agree on > something, choosing one of the mechanism in 2806bis, such as > a prefix or > a domain name. What you pick is immaterial - it is invisible > to the user. > > If you can't agree on that, it is very unlikely that you can agree on > what actually happens in the translation. Once you have automated > configuration (at the device, AOR or outbound proxy level), > it doesn't > matter what it is called, as long as you pick something > that's unique. > 2806bis provides two reasonable mechanisms. I don't see this > as an issue. > > > > > I think we either get rid of it, making the dialing plan > the last word, > > or make the dialing plan the job of the first hop proxy. I > fail to see > > the advantage of dialing plan in the UA and first hop proxy > interpreting > > context. > > You would never have both at the same time in the same > installation, but > I don't think we're in the business of picking architectures here. My > proposal allows choice. If you don't like to run context in your > products or installation, don't. I happen to think that > UA-translation > is best, as it is in the endsystem-is-smart spirit, but > others seem to > want proxy translation. Proxy translation without context is > extremely > brittle. > > > > To me, that makes context even less interesting. You require the > > first hop proxy to understand all contexts that could be > generated by > > any UA it serves. That would make it pretty hard for you to bring > > your office phone home if your ISP provided your first hop proxy. > > > > I think it's best to either have the dialing plan have to make sense > > to the first hop proxy (by making the local domain the source of > > the dialing plan, your #2 above), or make the proxy responsible for > > turning digit strings into routable numbers. I don't see enough > > utility in having the dialing plan associated with the phone itself. > > The point is that I want to be warned if the translation is done by > somebody that shouldn't. This becomes even more important > when you put > tel URIs on web pages. > > Henning > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 14:12:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23218 for ; Mon, 27 Jan 2003 14:12:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RJWgi10977 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 14:32:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJWgJ10974 for ; Mon, 27 Jan 2003 14:32:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23196 for ; Mon, 27 Jan 2003 14:11:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJV9J10911; Mon, 27 Jan 2003 14:31:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJUUJ10853 for ; Mon, 27 Jan 2003 14:30:30 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23112 for ; Mon, 27 Jan 2003 14:09:22 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24227; Mon, 27 Jan 2003 14:12:49 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13098; Mon, 27 Jan 2003 14:12:46 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 14:12:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D76@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" , Henning Schulzrinne Cc: "'Christer Holmberg'" , "'jh@lohi.eng.song.fi'" , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Mon, 27 Jan 2003 14:12:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is actually an interesting problem. In my environment, if I dial 304-3859, then I would show my FROM as 300-7826, because if I'm calling within my local network, then my network number is the best way to call me back. If I call the same fellow at 703-455-7826, then I might show my +17247426826 as my From: If I had the dialing plan in the UA, I could do this. If the expansion is in a proxy, it can't modify From:. I don't think we do anything about it. It's more argument why dial plan expansion in the UA is a better way to go. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, January 24, 2003 6:42 PM > To: Henning Schulzrinne > Cc: Rosen, Brian; 'Christer Holmberg'; 'jh@lohi.eng.song.fi'; Conroy, > Lawrence (SMTP); 'sipping@ietf.org' > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > Henning Schulzrinne wrote: > > There seem to be at least three scenarios: > > > > (1) The end system has a dialplan, learned automatically, > and can easily > > translate dialed digits into an E.164 number. ... It also > allows inspection > > - a device can easily display what will happen to a digit > string. If the > > proxy does translation, you only find out when what you > thought was a > > local extension gets translated to dial-a-prayer. (Or, > worse, doesn't > > get answered at all, in which case one may not suspect > anything amiss.) > > There is a solution to this problem when using proxy expansion: The > proxy can do the expansion and then return the result as a redirect > (probably 301). The phone will then retry, but can display > the new number. > > But this doesn't work for From. The calling phone had better know an > expanded form of its own address. > > Paul > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 14:22:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23482 for ; Mon, 27 Jan 2003 14:22:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RJhL812109 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 14:43:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJhLJ12106 for ; Mon, 27 Jan 2003 14:43:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23477 for ; Mon, 27 Jan 2003 14:22:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJdAJ11964; Mon, 27 Jan 2003 14:39:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJcrJ11929 for ; Mon, 27 Jan 2003 14:38:53 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23340 for ; Mon, 27 Jan 2003 14:17:45 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24559; Mon, 27 Jan 2003 14:21:14 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13888; Mon, 27 Jan 2003 14:21:16 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 14:21:15 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D78@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Subject: RE: [Sipping] URIs for Gateways Date: Mon, 27 Jan 2003 14:21:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Sorry about the tardy reply > Some of your comments seem so confusing to me that I think I must be > misunderstanding them in some fundamental way. > > Are you talking about a situation where a particular port on > a gateway > is intended to map 1:1 to a particular phone number in the > PSTN and to a > particular sip uri in the sip network? (To be specific, lets > call these > +1-987-654-3210, sip:foo@bar.com, sip:port3@gw.bar.com.) Yes, or at least, yes for many interesting systems There are two cases: a) the SIP system is the only phone system at the site, gateways are connected to the PSTN. For small sites, you have one line of gateway per user to get CallerID correct. If you don't need outgoing CallerId, then you can use "pool" mode and this problem doesn't arise. For large sites, you use PRI and the outgoing callerId is set by the gateway. b) The sip system is connected to a PBX. In this case you are pretty much forced to have port of gateway per user unless you can have a PRI interface to the PBX operating as a "remote". > Do you then want take all outbound calls to the pstn from > sip:foo@bar to > be routed thru sip:port3@gw.bar.com, and all inbound calls > from the pstn > to arrive at port3 on the gateway and then be sent to sip:foo@bar.com? Yes if it's a small site and line per gateway. With PRI type gateways the port number often doesn't matter (although it may). > > If the above are true, do you then want to put knowledge of these > mappings in your translator proxy rather than in the gateway? Many small gateways have the mappings in the gateway. Many larger gateways don't. The reason we use a translator is mostly because the sipphones don't "know" their PSTN numbers, they know their SIP identities, and even if they did, they don't put both numbers out on an INVITE. You don't have to do that, but it's pretty helpful. > > Under those assumptions, I can start to make some sense of your > comments. If the gw always sends inbound calls from the pstn to the > translator, putting the port address (sip:port2@gw.bar.com) > in the From > header, then I suppose the translator could use the from > address to map > sip:port3@gw.bar.com to sip:foo@bar.com. Most gateways we have use the port number as the user in the From. Yes, the translator can map. Gateways that have mapping functions can send calls directly to the associated user, meaning you don't need the translator, but some of the larger gateways don't map. > > But it seems like an odd thing to do. It would make way more > sense to me > in this case for the gw to put tel:+1-987-654-3210 in the To > and request > addresses, and then send the request to the translator. The > translator > could then look that up and forward the request to sip:foo@bar.com. Not really arguing with you. I think that is better. It's not what most of them do, although I've seen a couple that do. > > Going the other way - a call from sip:foo@bar.com to some > phone number > in the pstn (e.g. +1-789-456-0123), I would expect the UAC to put its > own address in the From, and a tel: uri in the To and request > uris. Then > it would probably deliver this to the translator. The > translator would > look up +1-789-456-0123, and discover it isn't in the sip > network and > so must be in the pstn. Given the assumptions I think you are > making, it > would then decide it must route this call to the gateway port > associated > with the caller. So it would look up the From address > (sip:foo@bar.com) > and translate it to a gateway address (sip:port3@gw.bar.com) > and forward > the request there. But that breaks down, because the gw has > no good way > to learn called number. right > > This simplest answer I can see to this is for the translator > to simply > translate the From address to the FQDN of the gateway, and > then to use > that to convert the request address from tel: format to sip format: > and also insert an NAI of > the caller as tel:+1-987-654-3210. This gets the call to the right > gateway with the necessary information. It would be up to the > gateway to > figure out that calls from NAI tel:+1-987-654-3210 should use port3. Yes, that could work, but you lose the port number. The gateway may need to know what port number to use. It actually is not much of a problem, because mapping gateways usually map the From: sip identity into which port to use. The bigger gateways which tend to not have mapping usually don't need ports (next available DS0 is usually enough). However, I don't think you can REQUIRE mapping in small gateways, and if there is trunk differentiation on a large gateway, you may have to differentiate ports. For example, you may have local (ILEC) trunks on ports 1-4 and long distance (IXC) trunks on ports 5-7. A proxy that did least cost routing would need to specify the port (actually, a port group would be best). > > Further comments inline below. > > Paul > > Rosen, Brian wrote: > > > > Let's start with inbound calls. The gateway has calling and called > > numbers, it may have a calledId name. If it has mapping, it has the > > sip URI of the intended recipient. I now see that this works: > > > > The text of 3325 talks about asserting the identity of the entity > > the message is from. For an inbound call, this is really > the gateway, > > but in this case, I think we would assume that we would use it for > > the calling party identity as you say. Two of them can be > used to get > > both the number and the name. The Request URI, if the gateway > > has mapping, could be the end UAS, but if it doesn't, > either it has to be > > a translator URI, or it just sends it with a tel URI, and > the proxies > > handle it. > > The last makes the most sense to me. > > > The gateway could use a tel URI as the From field which > > would be the called party number, > ^^^^^^ > calling??? > > I hope this was a typo. Why would you put the *called* number in the > From field? I was confused. This confuses me often, sorry. Let's see, the gateway knows: What port the call came in on The callerId information from the call (calling party name and number). Some gateways would know the called party number, but not all would. Every gateway can be told where to send INVITES. Gateways that map have a URI per port. Gateways that don't either have a fixed URI, or a domain+calling number. It never made too much sense to me to used the calling number in the Request-URI, but I can show you several gateways that do that. > > > but it would have to get the port > > number in as a parameter to the tel URI because if translation is > > needed, that information is essential to the translation. > > Why? It would be a lot simpler if the gw at least knew, or could get, > the phone number corresponding to each port, so it can form a > tel: uri > to use as the To address. Then the translator will have > something useful > to work from. > > > If the gateway doesn't have translation, the translator takes the > > called party from the Request URI, or if necessary, the From: > ^^^^^ > ????? > The above is still worrying me. > > > and changes the Request URI to the sip URI of the UAS. Okay, > > that works. Never saw a gateway that came even close to it (okay, > > well I've seen some gateways take a tel uri in the Request URI > > for the calling number), but it seems to work. > > > > On outgoing calls, the originating UAC could construct a tel URI, > > or a phone number@gateway sip uri for the Request URI and To: and > > it would clearly put it's sip URI, not it's phone number in > the From. > > If there was a translator, it would put a P-Asserted-Identity of the > >>From (the sip UAC) as a phone number (and name if it wanted). > > Tat seems ok. > > > It would have to add the port number to the Request URI as > a parameter > > to the tel URI and forward it to the gateway. > > See above for a way to finesse this. > > > I guess the UAC could > > put the P-Asserted-Identity in the original INVITE just > like the gateway > > does if there is no translator. I'm not sure I understand how > > routing is done if the proxy that knows which gateway is associated > > with the user's line (or destination phone number if that's > the routing > > decision) would construct a Request URI with the port@gateway > > addressing and still keep the number to dial. That means the > > routing gateway has to be next-to-last proxy in the path, which is > > clearly not always true. > > Possible answer above. > > > Probably not the thread for a discussion like this, but it does seem > > to me that the "right" way we want to move to is to have the UAC set > > identity correctly, and have the trusted proxy sign it to > authenticate > > it. I think there is then no reason to keep P-Asserted-Identity for > > any NAI application, including 3G and PSTN interwork. The only > > thing that won't do is allow the "trusted" network to have some > > identity that the UAC is unaware of. I don't think that is a good > > plan although you still need the phone number AND the UAC sip uri, > > which is what we are really talking about, so the P-A-I morphs > > into a UAC (or local, untrusted, proxy) thing, and not a trusted > > proxy thing, and the trusted proxy signs it, authenticating it. > > I'm not confident that I understand all the issues yet. Jon's > proposal > seems pretty heavyweight - so I am not yet confident that it can be a > total solution on its own. Also, I think as long as we have > to deal with > the PSTN, which assumes trusted network components, we may > continue to > need the NAI approach. But maybe not. > > Paul > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 14:32:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23770 for ; Mon, 27 Jan 2003 14:32:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RJqtS12444 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 14:52:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJqsJ12441 for ; Mon, 27 Jan 2003 14:52:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23728 for ; Mon, 27 Jan 2003 14:31:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJp9J12347; Mon, 27 Jan 2003 14:51:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJlSJ12206 for ; Mon, 27 Jan 2003 14:47:28 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23582 for ; Mon, 27 Jan 2003 14:26:20 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RJUYN9016031; Mon, 27 Jan 2003 14:30:34 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-77.cisco.com [161.44.87.77]) by cia.cisco.com (Mirapoint) with ESMTP id ABN71776; Mon, 27 Jan 2003 14:19:42 -0500 (EST) Message-Id: <4.3.2.7.2.20030127142021.03e5dc80@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Jan 2003 14:29:42 -0500 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Cc: "'Henning Schulzrinne'" , "'sipping@ietf.org'" In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D74@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Brian,

You use context in singular fashion as though the UAC only has one.  Could it not be operating within multiple contexts?  I can imagine that it may have to learn and store more than one, depending on who is intended to consume the URI.  (such as a home and visited context)

I would hope that "A proxy server either routes a tel uri without a context" means that a proxy can accept such a tel uri as an incoming value, but never as an outgoing value.

Wouldn't the context need to be globally unique, so that a tel uri that leaves the domain can be understood.  Did you mean that the tel: value must be only unique within the identified context?  Or did you mean to say that there are multiple contexts passed out by a proxy server that will make all addresses unique before exiting the domain of that proxy?  Not sure I followed that last paragraph fully.

Mike


At 02:06 PM 1/27/2003 -0500, Rosen, Brian wrote:
I can see including a context token as a confirmation, or even selection
of the dial plan domain to be interpreted by a proxy.  I see the value. 
The text in 2806bis can get considerably smaller and more focused, right?
It would seem that most of the confusion on context then goes away.

So, summarizing:
 a) The preferred mechanism is UA has dialing plan.  We will standardize
        a notation, and a method to learn it
 b) We support a proxy translation of dial string to routable numbers. 
        We should choose ONE way to send a dial string. 
        I personally like sip:dialsting@domain, with or without user=phone.

        It could have the context parameter.
        If we use a tel uri, then text in 2806bis about dial strings must
change
 c) The context is either learned from the environment (DHCP?),
        or provisioned.  It is always included in the URI when the number
        is not known to be directly routable (not correct to say global)

A UAC either expands dialstrings to routable numbers and emits a tel uri,
or it sends dialstrings with a context.  A proxy server either routes
a tel uri without a context, or expands a dialstring to a routable uri
from the dialstring+context.

Contexts need to be unique within the domain of a proxy server and all
the UAs that might get service from it.  I think that if you allow
contexts to be provisioned in the phone, that we should have some kind
of naming convention or something.  If they were always learned, then
they would just have to be unique within the domain they were learned
from.



Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, January 24, 2003 6:03 PM
> To: Rosen, Brian
> Cc: 'sipping@ietf.org'
> Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
>
>
> > As yet another example, what is my context?  Is it "Marconi
> Pittsburgh".
> > Is that globally unique?  Or is it "+1724742"?  That's
> globally unique,
> > but may or may not be useable by my first hop proxy.
>
> The point is that you and your first hop proxy better agree on
> something, choosing one of the mechanism in 2806bis, such as
> a prefix or
> a domain name. What you pick is immaterial - it is invisible
> to the user.
>
> If you can't agree on that, it is very unlikely that you can agree on
> what actually happens in the translation. Once you have automated
> configuration (at the device, AOR or outbound proxy level),
> it doesn't
> matter what it is called, as long as you pick something
> that's unique.
> 2806bis provides two reasonable mechanisms. I don't see this
> as an issue.
>
> >
> > I think we either get rid of it, making the dialing plan
> the last word,
> > or make the dialing plan the job of the first hop proxy.  I
> fail to see
> > the advantage of dialing plan in the UA and first hop proxy
> interpreting
> > context.
>
> You would never have both at the same time in the same
> installation, but
> I don't think we're in the business of picking architectures here. My
> proposal allows choice. If you don't like to run context in your
> products or installation, don't. I happen to think that
> UA-translation
> is best, as it is in the endsystem-is-smart spirit, but
> others seem to
> want proxy translation. Proxy translation without context is
> extremely
> brittle.
>
>
> > To me, that makes context even less interesting.  You require the
> > first hop proxy to understand all contexts that could be
> generated by
> > any UA it serves.  That would make it pretty hard for you to bring
> > your office phone home if your ISP provided your first hop proxy.
> >
> > I think it's best to either have the dialing plan have to make sense
> > to the first hop proxy (by making the local domain the source of
> > the dialing plan, your #2 above), or make the proxy responsible for
> > turning digit strings into routable numbers.  I don't see enough
> > utility in having the dialing plan associated with the phone itself.
>
> The point is that I want to be warned if the translation is done by
> somebody that shouldn't. This becomes even more important
> when you put
> tel URIs on web pages.
>
> Henning
>
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 14:47:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24236 for ; Mon, 27 Jan 2003 14:47:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RK8S713718 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 15:08:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK8SJ13715 for ; Mon, 27 Jan 2003 15:08:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24220 for ; Mon, 27 Jan 2003 14:47:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK7NJ13538; Mon, 27 Jan 2003 15:07:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK6OJ12945 for ; Mon, 27 Jan 2003 15:06:24 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24111 for ; Mon, 27 Jan 2003 14:45:18 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18dFFL-0000vv-00; Mon, 27 Jan 2003 21:48:43 +0200 To: "Rosen, Brian" Cc: "'Paul Kyzivat'" , Henning Schulzrinne , "'Christer Holmberg'" , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D76@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF030B5D76@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Message-Id: Date: Mon, 27 Jan 2003 21:48:43 +0200 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Rosen, Brian writes: > In my environment, if I dial 304-3859, then I would > show my FROM as 300-7826, because if I'm calling within > my local network, then my network number is the best way > to call me back. If I call the same fellow at > 703-455-7826, then I might show my +17247426826 as > my From: no matter how you call, it makes sense to always have a globally unique uri in the from field. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 14:48:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24249 for ; Mon, 27 Jan 2003 14:48:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RK8eN13740 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 15:08:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK8eJ13737 for ; Mon, 27 Jan 2003 15:08:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24233 for ; Mon, 27 Jan 2003 14:47:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK84J13696; Mon, 27 Jan 2003 15:08:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RK7UJ13578 for ; Mon, 27 Jan 2003 15:07:30 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24181 for ; Mon, 27 Jan 2003 14:46:24 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RJoJOf019072; Mon, 27 Jan 2003 14:50:19 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY61988; Mon, 27 Jan 2003 14:54:32 -0500 (EST) Message-ID: <3E358D49.3010108@cisco.com> Date: Mon, 27 Jan 2003 14:49:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: Henning Schulzrinne , "'Christer Holmberg'" , "'jh@lohi.eng.song.fi'" , "Conroy, Lawrence (SMTP)" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <313680C9A886D511A06000204840E1CF030B5D76@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, I think it is a *bad* idea for the UAC to be trying to figure out the best representation of the From address based on the To address. There are all sorts of cases where this does the wrong thing. It makes way more sense for the UAC to represent the From address with maximal information, in the most universally understood form possible, and for each UAS to then transform the From into the form that is "best" for its user. (With the possibility of configuring the definition of "best".) So I might dial a coworker using "1234", my From address is populated with my global address tel:+197855554321. My coworker's phone then might "reverse engineer" the dial plan to realize that number could be dialed as "4321", and so displays the number that way. If my number wasn't globally reachable, my From address could be tel:4321;phone-context=lowell.cisco.com. Once again, the recipients phone could reverse engineer the dial plan and still show the number as just 4321. If somebody called in from outside (From:tel:+12125554321), then the reverse engineering of the dial plan might result in it being displayed as: 9-1-212-555-4321. Reverse engineering the dial plan imposes some new requirements. For one, it can't easily be done in the proxy, because there is no good way to convey it. Paul Rosen, Brian wrote: > This is actually an interesting problem. > In my environment, if I dial 304-3859, then I would > show my FROM as 300-7826, because if I'm calling within > my local network, then my network number is the best way > to call me back. If I call the same fellow at > 703-455-7826, then I might show my +17247426826 as > my From: > > If I had the dialing plan in the UA, I could do this. > If the expansion is in a proxy, it can't modify From:. > > I don't think we do anything about it. It's more argument > why dial plan expansion in the UA is a better way to go. > > Brian > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] [snip] >>But this doesn't work for From. The calling phone had better know an >>expanded form of its own address. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 16:24:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27409 for ; Mon, 27 Jan 2003 16:24:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RLjIM19158 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 16:45:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLjIJ19155 for ; Mon, 27 Jan 2003 16:45:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27361 for ; Mon, 27 Jan 2003 16:24:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLh0J19043; Mon, 27 Jan 2003 16:43:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLfZJ18987 for ; Mon, 27 Jan 2003 16:41:35 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27210 for ; Mon, 27 Jan 2003 16:20:26 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA00162; Mon, 27 Jan 2003 16:23:54 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA05201; Mon, 27 Jan 2003 16:23:56 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 16:23:55 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Michael Hammer'" Cc: "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Mon, 27 Jan 2003 16:23:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , >You use context in singular fashion as though the UAC only has one. >Could it not be operating within multiple contexts? I can imagine >that it may have to learn and store more than one, depending on who >is intended to consume the URI. (such as a home and visited context) I don't know. I guess I'm not opposed if it doesn't make things a lot more complicated. I think as a practical matter, it's pretty hard to manage more than one. You would need some kind of UI that let you choose, so that your dial string could be interpreted differently. That's an implementation issue. From a standards perspective, you can only get one from something like DHCP. You could get one each for every AOR if you had more than one, if instead of learning through DHCP it was, say, PUBLISHED as a consequence of registration. I've thought of that. You also get one per phone if it's provisioned in the phone. On the other hand, there is no reason to restrict the UA from having more than one. >I would hope that "A proxy server either routes a tel uri without a >context" means that a proxy can accept such a tel uri as an incoming >value, but never as an outgoing value. Confusion. A tel uri without a context means it's either global or at least routable with no further expansion. So, a proxy server would definitely put such a uri as an outgoing value. >Wouldn't the context need to be globally unique, so that a tel uri >that leaves the domain can be understood. Did you mean that the >tel: value must be only unique within the identified context? Or >did you mean to say that there are multiple contexts passed out by >a proxy server that will make all addresses unique before exiting >the domain of that proxy? Not sure I followed that last paragraph fully. I thought that contexts needed to be globally unique but Henning asserted otherwise. As long as the UA and the interpreting proxy agree on a naming, it's okay. How it figures that out is not specified. I think that's okay; if Marconi's domain has a convention that, say, contexts are of the form "-marconi", and all contexts the UA learns/provisioned are in that form, all is well. So, the requirement is that the proxy understand the context, or it will return an error. The proxy has to output a routable (which could be global) tel uri for the combination of dial string and context, for all contexts it implements. Actually, it's not clear to me that we have to be quite so restrictive. It is possible that the rule is actually that the proxy has to be able to either translate to a fully routable tel uri OR that it has to forward it to a proxy that can do that. If, for example, I send 8977@pitt.marconi.com; context="coventry-marconi", the local (roaming) proxy at pit could forward the call to coventry.marconi.com for processing using the coventry-marconi context. The pitt proxy would need routing rules to be able to do that. Having said that, if my home is pitt, I roam to coventry and invite someone in coventry, I don't want pitt's routing to send the call to a gateway in Pittsburgh! If pitt expands the number to a globally routable number and redirects the call, coventry can "least cost route" it. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 16:43:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28029 for ; Mon, 27 Jan 2003 16:43:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RM3iA20436 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 17:03:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM3iJ20432 for ; Mon, 27 Jan 2003 17:03:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28011 for ; Mon, 27 Jan 2003 16:42:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM28J20357; Mon, 27 Jan 2003 17:02:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM13J20194 for ; Mon, 27 Jan 2003 17:01:03 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27935 for ; Mon, 27 Jan 2003 16:39:54 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RLi6or006030; Mon, 27 Jan 2003 16:44:07 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-77.cisco.com [161.44.87.77]) by cia.cisco.com (Mirapoint) with ESMTP id ABN73603; Mon, 27 Jan 2003 16:33:16 -0500 (EST) Message-Id: <4.3.2.7.2.20030127163253.00b45788@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Jan 2003 16:43:15 -0500 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Cc: "'Henning Schulzrinne'" , "'sipping@ietf.org'" In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Brian, I'm following you now. Part of my problem was reading the statements within the context of "how to handle non-global tel: URI." I was reading it as forwarding on to an arbitrary server with a non-global URI without context. The onward routing with global URI or full context is now clear. Your example option of configuration to route by exception handling to another proxy that is expected to figure it out shows that this will be implementation dependent. Mike At 04:23 PM 1/27/2003 -0500, Rosen, Brian wrote: > >You use context in singular fashion as though the UAC only has one. > >Could it not be operating within multiple contexts? I can imagine > >that it may have to learn and store more than one, depending on who > >is intended to consume the URI. (such as a home and visited context) >I don't know. I guess I'm not opposed if it doesn't make things >a lot more complicated. > >I think as a practical matter, it's pretty hard to manage more than one. >You would need some kind of UI that let you choose, so that your >dial string could be interpreted differently. That's an >implementation issue. > > From a standards perspective, you can only get one from something like >DHCP. You could get one each for every AOR if you had more than one, >if instead of learning through DHCP it was, say, PUBLISHED as a >consequence of registration. I've thought of that. You also get one >per phone if it's provisioned in the phone. > >On the other hand, there is no reason to restrict the UA from having >more than one. > > >I would hope that "A proxy server either routes a tel uri without a > >context" means that a proxy can accept such a tel uri as an incoming > >value, but never as an outgoing value. >Confusion. A tel uri without a context means it's either global or >at least routable with no further expansion. So, a proxy server would >definitely put such a uri as an outgoing value. > > > >Wouldn't the context need to be globally unique, so that a tel uri > >that leaves the domain can be understood. Did you mean that the > >tel: value must be only unique within the identified context? Or > >did you mean to say that there are multiple contexts passed out by > >a proxy server that will make all addresses unique before exiting > >the domain of that proxy? Not sure I followed that last paragraph fully. >I thought that contexts needed to be globally unique but Henning >asserted otherwise. As long as the UA and the interpreting proxy >agree on a naming, it's okay. How it figures that out is not >specified. I think that's okay; if Marconi's domain has a convention >that, say, contexts are of the form "-marconi", and >all contexts the UA learns/provisioned are in that form, all is well. > >So, the requirement is that the proxy understand the context, or it >will return an error. The proxy has to output a routable (which could >be global) tel uri for the combination of dial string and context, >for all contexts it implements. > >Actually, it's not clear to me that we have to be quite so >restrictive. It is possible that the rule is actually that the proxy >has to be able to either translate to a fully routable tel uri OR that >it has to forward it to a proxy that can do that. If, for example, >I send 8977@pitt.marconi.com; context="coventry-marconi", the local >(roaming) proxy at pit could forward the call to coventry.marconi.com >for processing using the coventry-marconi context. The pitt proxy >would need routing rules to be able to do that. > >Having said that, if my home is pitt, I roam to coventry and invite >someone in coventry, I don't want pitt's routing to send the call to >a gateway in Pittsburgh! If pitt expands the number to a globally >routable number and redirects the call, coventry can "least cost >route" it. > >Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 16:47:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28135 for ; Mon, 27 Jan 2003 16:47:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RM8Hb21333 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 17:08:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM8HJ21330 for ; Mon, 27 Jan 2003 17:08:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28124 for ; Mon, 27 Jan 2003 16:47:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM2BJ20377; Mon, 27 Jan 2003 17:02:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM1LJ20319 for ; Mon, 27 Jan 2003 17:01:21 -0500 Received: from dewberry.cc.columbia.edu (dewberry.cc.columbia.edu [128.59.59.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27754 for ; Mon, 27 Jan 2003 16:38:01 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0RLd5Sr014937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jan 2003 16:39:07 -0500 (EST) Message-ID: <3E35A713.2060900@cs.columbia.edu> Date: Mon, 27 Jan 2003 16:39:31 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Michael Hammer'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I thought that contexts needed to be globally unique but Henning > asserted otherwise. As long as the UA and the interpreting proxy Wait - where did I say that the context identifier is not globally unique? That's the whole point of the identifier... It may not be uniquely determined in the sense that a single context could have several different possible names (all unique), so there is way of just guessing the right name. For example, you can name your context marconi.com, your global phone prefix or some other DNS-based identifier that's yours. > agree on a naming, it's okay. How it figures that out is not > specified. I think that's okay; if Marconi's domain has a convention > that, say, contexts are of the form "-marconi", and > all contexts the UA learns/provisioned are in that form, all is well. > > Actually, it's not clear to me that we have to be quite so > restrictive. It is possible that the rule is actually that the proxy > has to be able to either translate to a fully routable tel uri OR that > it has to forward it to a proxy that can do that. If, for example, > I send 8977@pitt.marconi.com; context="coventry-marconi", the local > (roaming) proxy at pit could forward the call to coventry.marconi.com > for processing using the coventry-marconi context. The pitt proxy > would need routing rules to be able to do that. I agree it shouldn't be outlawed, but it will always be manual configuration, with the attendant problems. > > Having said that, if my home is pitt, I roam to coventry and invite > someone in coventry, I don't want pitt's routing to send the call to > a gateway in Pittsburgh! If pitt expands the number to a globally > routable number and redirects the call, coventry can "least cost > route" it. Once you get through all the complexity, I suspect that it's easier to just use SIP URIs with phone user parts. However, since the point is to document all the variations and this is certainly one of them. > > Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jan 27 18:06:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00270 for ; Mon, 27 Jan 2003 18:06:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RNRUr25426 for sipping-archive@odin.ietf.org; Mon, 27 Jan 2003 18:27:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNRUJ25423 for ; Mon, 27 Jan 2003 18:27:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00259 for ; Mon, 27 Jan 2003 18:06:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNOoJ25330; Mon, 27 Jan 2003 18:24:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RNNxJ25271 for ; Mon, 27 Jan 2003 18:23:59 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00166 for ; Mon, 27 Jan 2003 18:02:48 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RN6vJ0016913; Mon, 27 Jan 2003 18:06:58 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY63723; Mon, 27 Jan 2003 18:11:10 -0500 (EST) Message-ID: <3E35BB5F.4040903@cisco.com> Date: Mon, 27 Jan 2003 18:06:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Michael Hammer'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <313680C9A886D511A06000204840E1CF030B5D7C@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > > Actually, it's not clear to me that we have to be quite so > restrictive. It is possible that the rule is actually that the proxy > has to be able to either translate to a fully routable tel uri OR that > it has to forward it to a proxy that can do that. If, for example, > I send 8977@pitt.marconi.com; context="coventry-marconi", the local > (roaming) proxy at pit could forward the call to coventry.marconi.com > for processing using the coventry-marconi context. The pitt proxy > would need routing rules to be able to do that. Detail: I can't quite figure out what you intend. I think you are proposing sending to sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone but that isn't quite legal. Things that would be are: tel:8977;phone-context=coventry.marconi.com sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;user=phone There there isn't necessarily any relationship between the proxy names and the context names, but I have made them the same to suggest there might be a meaningful relationship in this case. > Having said that, if my home is pitt, I roam to coventry and invite > someone in coventry, I don't want pitt's routing to send the call to > a gateway in Pittsburgh! If pitt expands the number to a globally > routable number and redirects the call, coventry can "least cost > route" it. There are several possibilities here. (I assume when you roam to coventry your outbound calls transit the coventry.marconi.com proxy first.) 1) if you use the tel: form above, the proxy naturally understands the context and routes the call directly. Your home proxy isn't involved at all. 2) if you use the sip form above, the coventry proxy is supposed to honor the domain, and forward the call to the pitt.marconi.com proxy. 2a) the pitt proxy might use a pitt gateway - your worst fear confirmed 2b) the pitt proxy might redirect to some global number (e.g. tel:+445558977) and then the local proxy would use a local gateway to get there. Now instead, assume that you had roamed to coventry and are trying to dial a number 1234 in pitt: 3) you might use tel:1234;phone-context=pitt.marconi.com and send it to the coventry proxy. 3a) the coventry proxy might know the context and know that the best way to get the call there. For instance it might by default forward the call to the pitt.marconi.com proxy, but if that fails it could also know to translate the address and use a local GW. 3b) the coventry proxy might not know the context, but might have a convention to automatically route calls to unknown FQDN style contexts to a sip proxy with that name. 4) you might use sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and send it to the coventry proxy. In this case the coventry proxy must forward to the pitt proxy which will then probably use a local gw. This is almost as good as (3a) except with the sip path is down between convenry and pitt. My conclusion is that using a tel: gives the most options to do things well. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 28 08:30:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25519 for ; Tue, 28 Jan 2003 08:30:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SDpRH20254 for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 08:51:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SDpRJ20251 for ; Tue, 28 Jan 2003 08:51:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25516 for ; Tue, 28 Jan 2003 08:29:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SDoVJ20191; Tue, 28 Jan 2003 08:50:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SDnxJ20134 for ; Tue, 28 Jan 2003 08:49:59 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25509 for ; Tue, 28 Jan 2003 08:28:30 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA17030; Tue, 28 Jan 2003 08:32:00 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA18549; Tue, 28 Jan 2003 08:32:00 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 08:32:00 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D82@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Michael Hammer'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Tue, 28 Jan 2003 08:31:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I observe that if you know a context name you (can) know the domain that the context is valid in. That is true however the UA learns the context. If we make a naming convention on contexts that includes the domain (ie. contextname@domain), then a proxy can, if it does not understand that context, forward to a proxy in the domain which would. I'll note that I really dislike putting parameters in the 'user' part of a uri. URI parameters are inexpensive, we should use them. On the other hand, I'd prefer ONE way to do things. So, a tel uri, with a uri parameter of context, might be the best one way to go, rather than putting more stuff into sip:... ;user=phone. The contrary point of view is that the sip form has a domain, which makes it more easily routable by intermediaries, most of whom won't know how to route a generic tel uri. It might be interesting to document somewhere that redirect should be used when a proxy interprets a context where the call did not originate in the domain of the proxy that does the interpretation. Might be best if that was only if the translated number is globally routable (otherwise you could have a translated number that is a different destination in the originating domain than in the translating domain). If it's not globally routable, then the translating domain is probably best to just route the call rather than redirecting it. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, January 27, 2003 6:06 PM > To: Rosen, Brian > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > Rosen, Brian wrote: > > > > Actually, it's not clear to me that we have to be quite so > > restrictive. It is possible that the rule is actually that > the proxy > > has to be able to either translate to a fully routable tel > uri OR that > > it has to forward it to a proxy that can do that. If, for example, > > I send 8977@pitt.marconi.com; context="coventry-marconi", the local > > (roaming) proxy at pit could forward the call to > coventry.marconi.com > > for processing using the coventry-marconi context. The pitt proxy > > would need routing rules to be able to do that. > > Detail: I can't quite figure out what you intend. I think you are > proposing sending to > > sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone > > but that isn't quite legal. Things that would be are: > > tel:8977;phone-context=coventry.marconi.com > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u > ser=phone > > There there isn't necessarily any relationship between the > proxy names > and the context names, but I have made them the same to suggest there > might be a meaningful relationship in this case. > > > Having said that, if my home is pitt, I roam to coventry and invite > > someone in coventry, I don't want pitt's routing to send the call to > > a gateway in Pittsburgh! If pitt expands the number to a globally > > routable number and redirects the call, coventry can "least cost > > route" it. > > There are several possibilities here. (I assume when you roam to > coventry your outbound calls transit the coventry.marconi.com > proxy first.) > > 1) if you use the tel: form above, the proxy naturally > understands the > context and routes the call directly. Your home proxy isn't > involved at all. > > 2) if you use the sip form above, the coventry proxy is supposed to > honor the domain, and forward the call to the pitt.marconi.com proxy. > > 2a) the pitt proxy might use a pitt gateway - your worst fear > confirmed > > 2b) the pitt proxy might redirect to some global number (e.g. > tel:+445558977) and then the local proxy would use a local gateway to > get there. > > Now instead, assume that you had roamed to coventry and are trying to > dial a number 1234 in pitt: > > 3) you might use tel:1234;phone-context=pitt.marconi.com and > send it to > the coventry proxy. > > 3a) the coventry proxy might know the context and know that > the best way > to get the call there. For instance it might by default > forward the call > to the pitt.marconi.com proxy, but if that fails it could > also know to > translate the address and use a local GW. > > 3b) the coventry proxy might not know the context, but might have a > convention to automatically route calls to unknown FQDN style > contexts > to a sip proxy with that name. > > 4) you might use > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and > send it to > the coventry proxy. In this case the coventry proxy must > forward to the > pitt proxy which will then probably use a local gw. This is > almost as > good as (3a) except with the sip path is down between > convenry and pitt. > > > My conclusion is that using a tel: gives the most options to > do things well. > > Paul > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 28 10:21:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27688 for ; Tue, 28 Jan 2003 10:21:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFgPa27554 for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 10:42:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFgOJ27551 for ; Tue, 28 Jan 2003 10:42:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27677 for ; Tue, 28 Jan 2003 10:20:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFfXJ27508; Tue, 28 Jan 2003 10:41:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFetJ27456 for ; Tue, 28 Jan 2003 10:40:55 -0500 Received: from elmer.LEAPSTONE.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27638 for ; Tue, 28 Jan 2003 10:19:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Tue, 28 Jan 2003 10:23:46 -0500 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107A920@elmer> Thread-Topic: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Thread-Index: AcLG0jrBwsycvyEIQ32Tqb/eBS6cdQADK9fg From: "Dusan Mudric" To: "Rosen, Brian" , "Paul Kyzivat" Cc: "Michael Hammer" , "Henning Schulzrinne" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SFetJ27457 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit With introduction of a new technology, VoIP, legacy attributes should stay at the edge. By introducing Tel routing in IP, unnecessary dimension is used. IP already has a clean way to route. Why not just keep tel numbers in PSTN and names and IP's in IP? Every tel number has its owner with a name. It would be straightforward to route from IP to PSTN edge based on the name and at the edge translate that name into a tel number. From PSTN to IP, translate a virtual tel number into a name and get to the IP UA. In the near future, when everybody switches to IP (I wish :-) ), we will call friends by names only. Dusan Mudric -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, January 28, 2003 8:32 AM To: 'Paul Kyzivat' Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers I observe that if you know a context name you (can) know the domain that the context is valid in. That is true however the UA learns the context. If we make a naming convention on contexts that includes the domain (ie. contextname@domain), then a proxy can, if it does not understand that context, forward to a proxy in the domain which would. I'll note that I really dislike putting parameters in the 'user' part of a uri. URI parameters are inexpensive, we should use them. On the other hand, I'd prefer ONE way to do things. So, a tel uri, with a uri parameter of context, might be the best one way to go, rather than putting more stuff into sip:... ;user=phone. The contrary point of view is that the sip form has a domain, which makes it more easily routable by intermediaries, most of whom won't know how to route a generic tel uri. It might be interesting to document somewhere that redirect should be used when a proxy interprets a context where the call did not originate in the domain of the proxy that does the interpretation. Might be best if that was only if the translated number is globally routable (otherwise you could have a translated number that is a different destination in the originating domain than in the translating domain). If it's not globally routable, then the translating domain is probably best to just route the call rather than redirecting it. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, January 27, 2003 6:06 PM > To: Rosen, Brian > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > Rosen, Brian wrote: > > > > Actually, it's not clear to me that we have to be quite so > > restrictive. It is possible that the rule is actually that > the proxy > > has to be able to either translate to a fully routable tel > uri OR that > > it has to forward it to a proxy that can do that. If, for example, > > I send 8977@pitt.marconi.com; context="coventry-marconi", the local > > (roaming) proxy at pit could forward the call to > coventry.marconi.com > > for processing using the coventry-marconi context. The pitt proxy > > would need routing rules to be able to do that. > > Detail: I can't quite figure out what you intend. I think you are > proposing sending to > > sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone > > but that isn't quite legal. Things that would be are: > > tel:8977;phone-context=coventry.marconi.com > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u > ser=phone > > There there isn't necessarily any relationship between the > proxy names > and the context names, but I have made them the same to suggest there > might be a meaningful relationship in this case. > > > Having said that, if my home is pitt, I roam to coventry and invite > > someone in coventry, I don't want pitt's routing to send the call to > > a gateway in Pittsburgh! If pitt expands the number to a globally > > routable number and redirects the call, coventry can "least cost > > route" it. > > There are several possibilities here. (I assume when you roam to > coventry your outbound calls transit the coventry.marconi.com > proxy first.) > > 1) if you use the tel: form above, the proxy naturally > understands the > context and routes the call directly. Your home proxy isn't > involved at all. > > 2) if you use the sip form above, the coventry proxy is supposed to > honor the domain, and forward the call to the pitt.marconi.com proxy. > > 2a) the pitt proxy might use a pitt gateway - your worst fear > confirmed > > 2b) the pitt proxy might redirect to some global number (e.g. > tel:+445558977) and then the local proxy would use a local gateway to > get there. > > Now instead, assume that you had roamed to coventry and are trying to > dial a number 1234 in pitt: > > 3) you might use tel:1234;phone-context=pitt.marconi.com and > send it to > the coventry proxy. > > 3a) the coventry proxy might know the context and know that > the best way > to get the call there. For instance it might by default > forward the call > to the pitt.marconi.com proxy, but if that fails it could > also know to > translate the address and use a local GW. > > 3b) the coventry proxy might not know the context, but might have a > convention to automatically route calls to unknown FQDN style > contexts > to a sip proxy with that name. > > 4) you might use > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and > send it to > the coventry proxy. In this case the coventry proxy must > forward to the > pitt proxy which will then probably use a local gw. This is > almost as > good as (3a) except with the sip path is down between > convenry and pitt. > > > My conclusion is that using a tel: gives the most options to > do things well. > > Paul > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 28 11:38:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00297 for ; Tue, 28 Jan 2003 11:38:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SGxuL01596 for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 11:59:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGxuJ01593 for ; Tue, 28 Jan 2003 11:59:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00282 for ; Tue, 28 Jan 2003 11:38:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGw6J01420; Tue, 28 Jan 2003 11:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SGuYJ01337 for ; Tue, 28 Jan 2003 11:56:34 -0500 Received: from elmer.LEAPSTONE.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00165 for ; Tue, 28 Jan 2003 11:35:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Tue, 28 Jan 2003 11:39:27 -0500 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520B5ADB@elmer> Thread-Topic: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Thread-Index: AcLG4sltLIzEsdlFT/muKtTIZJfXfwACPTVg From: "Dusan Mudric" To: "Michael Hammer" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SGuYJ01338 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit There are translators at the IP-PSTN edges. Existing tel number subscribers get registered at the PSTN-IP edge device with {name, tel_number}, which we already have in telephone books. Their names are visible from the edge device to the rest of the IP world. When an IP UA-A calls a party B in a PSTN by name, the call gets routed to the edge device that registered a PSTN subscriber B. From there on, a PSTN routs the call to a party B based on its tel number. Dusan -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Tuesday, January 28, 2003 10:34 AM To: Dusan Mudric Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers How would you route to someone who has only a telephone number and no SIP address? The SIP network is only useful if it can route to everyone on the PSTN. Mike At 10:23 AM 1/28/2003 -0500, you wrote: >With introduction of a new technology, VoIP, legacy attributes should stay >at the edge. By introducing Tel routing in IP, unnecessary dimension is >used. IP already has a clean way to route. > >Why not just keep tel numbers in PSTN and names and IP's in IP? Every tel >number has its owner with a name. It would be straightforward to route >from IP to PSTN edge based on the name and at the edge translate that name >into a tel number. From PSTN to IP, translate a virtual tel number into a >name and get to the IP UA. In the near future, when everybody switches to >IP (I wish :-) ), we will call friends by names only. > >Dusan Mudric > >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >Sent: Tuesday, January 28, 2003 8:32 AM >To: 'Paul Kyzivat' >Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' >Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > >I observe that if you know a context name you (can) know the domain that >the context is valid in. That is true however the UA learns the >context. > >If we make a naming convention on contexts that includes the domain >(ie. contextname@domain), then a proxy can, if it does not understand >that context, forward to a proxy in the domain which would. > >I'll note that I really dislike putting parameters in the 'user' part >of a uri. URI parameters are inexpensive, we should use them. >On the other hand, I'd prefer ONE way to do things. So, a tel uri, >with a uri parameter of context, might be the best one way to go, >rather than putting more stuff into sip:... ;user=phone. >The contrary point of view is that the sip form has a domain, >which makes it more easily routable by intermediaries, most of whom >won't know how to route a generic tel uri. > >It might be interesting to document somewhere that redirect should >be used when a proxy interprets a context where the call did not >originate in the domain of the proxy that does the interpretation. >Might be best if that was only if the translated number is globally >routable (otherwise you could have a translated number that >is a different destination in the originating domain than in the >translating domain). If it's not globally routable, then the >translating domain is probably best to just route the call rather >than redirecting it. > >Brian > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, January 27, 2003 6:06 PM > > To: Rosen, Brian > > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > > > > > > Rosen, Brian wrote: > > > > > > Actually, it's not clear to me that we have to be quite so > > > restrictive. It is possible that the rule is actually that > > the proxy > > > has to be able to either translate to a fully routable tel > > uri OR that > > > it has to forward it to a proxy that can do that. If, for example, > > > I send 8977@pitt.marconi.com; context="coventry-marconi", the local > > > (roaming) proxy at pit could forward the call to > > coventry.marconi.com > > > for processing using the coventry-marconi context. The pitt proxy > > > would need routing rules to be able to do that. > > > > Detail: I can't quite figure out what you intend. I think you are > > proposing sending to > > > > sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone > > > > but that isn't quite legal. Things that would be are: > > > > tel:8977;phone-context=coventry.marconi.com > > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u > > ser=phone > > > > There there isn't necessarily any relationship between the > > proxy names > > and the context names, but I have made them the same to suggest there > > might be a meaningful relationship in this case. > > > > > Having said that, if my home is pitt, I roam to coventry and invite > > > someone in coventry, I don't want pitt's routing to send the call to > > > a gateway in Pittsburgh! If pitt expands the number to a globally > > > routable number and redirects the call, coventry can "least cost > > > route" it. > > > > There are several possibilities here. (I assume when you roam to > > coventry your outbound calls transit the coventry.marconi.com > > proxy first.) > > > > 1) if you use the tel: form above, the proxy naturally > > understands the > > context and routes the call directly. Your home proxy isn't > > involved at all. > > > > 2) if you use the sip form above, the coventry proxy is supposed to > > honor the domain, and forward the call to the pitt.marconi.com proxy. > > > > 2a) the pitt proxy might use a pitt gateway - your worst fear > > confirmed > > > > 2b) the pitt proxy might redirect to some global number (e.g. > > tel:+445558977) and then the local proxy would use a local gateway to > > get there. > > > > Now instead, assume that you had roamed to coventry and are trying to > > dial a number 1234 in pitt: > > > > 3) you might use tel:1234;phone-context=pitt.marconi.com and > > send it to > > the coventry proxy. > > > > 3a) the coventry proxy might know the context and know that > > the best way > > to get the call there. For instance it might by default > > forward the call > > to the pitt.marconi.com proxy, but if that fails it could > > also know to > > translate the address and use a local GW. > > > > 3b) the coventry proxy might not know the context, but might have a > > convention to automatically route calls to unknown FQDN style > > contexts > > to a sip proxy with that name. > > > > 4) you might use > > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and > > send it to > > the coventry proxy. In this case the coventry proxy must > > forward to the > > pitt proxy which will then probably use a local gw. This is > > almost as > > good as (3a) except with the sip path is down between > > convenry and pitt. > > > > > > My conclusion is that using a tel: gives the most options to > > do things well. > > > > Paul > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 28 13:08:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02594 for ; Tue, 28 Jan 2003 13:08:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SITtP07883 for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 13:29:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SITtJ07880 for ; Tue, 28 Jan 2003 13:29:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02588 for ; Tue, 28 Jan 2003 13:08:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SIQTJ07771; Tue, 28 Jan 2003 13:26:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SIOgJ07686 for ; Tue, 28 Jan 2003 13:24:42 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02511 for ; Tue, 28 Jan 2003 13:03:06 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03129; Tue, 28 Jan 2003 13:06:35 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08619; Tue, 28 Jan 2003 13:06:36 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 13:06:36 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D8B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dusan Mudric'" Cc: sipping@ietf.org Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Tue, 28 Jan 2003 13:06:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , The assumption you are making is that every person who does not have a sipphone is in a database that the gateway can access. I think that's pretty tough to arrange. Also has the small problem of multiple people with the same name. Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@leapstone.com] > Sent: Tuesday, January 28, 2003 11:39 AM > To: Michael Hammer > Cc: sipping@ietf.org > Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > There are translators at the IP-PSTN edges. Existing tel > number subscribers get registered at the PSTN-IP edge device > with {name, tel_number}, which we already have in telephone > books. Their names are visible from the edge device to the > rest of the IP world. When an IP UA-A calls a party B in a > PSTN by name, the call gets routed to the edge device that > registered a PSTN subscriber B. From there on, a PSTN routs > the call to a party B based on its tel number. > > Dusan > > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, January 28, 2003 10:34 AM > To: Dusan Mudric > Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > How would you route to someone who has only a telephone > number and no SIP > address? > > The SIP network is only useful if it can route to everyone on > the PSTN. > > Mike > > > At 10:23 AM 1/28/2003 -0500, you wrote: > >With introduction of a new technology, VoIP, legacy > attributes should stay > >at the edge. By introducing Tel routing in IP, unnecessary > dimension is > >used. IP already has a clean way to route. > > > >Why not just keep tel numbers in PSTN and names and IP's in > IP? Every tel > >number has its owner with a name. It would be > straightforward to route > >from IP to PSTN edge based on the name and at the edge > translate that name > >into a tel number. From PSTN to IP, translate a virtual tel > number into a > >name and get to the IP UA. In the near future, when > everybody switches to > >IP (I wish :-) ), we will call friends by names only. > > > >Dusan Mudric > > > >-----Original Message----- > >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >Sent: Tuesday, January 28, 2003 8:32 AM > >To: 'Paul Kyzivat' > >Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > >Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > >I observe that if you know a context name you (can) know the > domain that > >the context is valid in. That is true however the UA learns the > >context. > > > >If we make a naming convention on contexts that includes the domain > >(ie. contextname@domain), then a proxy can, if it does not understand > >that context, forward to a proxy in the domain which would. > > > >I'll note that I really dislike putting parameters in the 'user' part > >of a uri. URI parameters are inexpensive, we should use them. > >On the other hand, I'd prefer ONE way to do things. So, a tel uri, > >with a uri parameter of context, might be the best one way to go, > >rather than putting more stuff into sip:... ;user=phone. > >The contrary point of view is that the sip form has a domain, > >which makes it more easily routable by intermediaries, most of whom > >won't know how to route a generic tel uri. > > > >It might be interesting to document somewhere that redirect should > >be used when a proxy interprets a context where the call did not > >originate in the domain of the proxy that does the interpretation. > >Might be best if that was only if the translated number is globally > >routable (otherwise you could have a translated number that > >is a different destination in the originating domain than in the > >translating domain). If it's not globally routable, then the > >translating domain is probably best to just route the call rather > >than redirecting it. > > > >Brian > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Monday, January 27, 2003 6:06 PM > > > To: Rosen, Brian > > > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > > > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > > > > > > > > > > > Rosen, Brian wrote: > > > > > > > > Actually, it's not clear to me that we have to be quite so > > > > restrictive. It is possible that the rule is actually that > > > the proxy > > > > has to be able to either translate to a fully routable tel > > > uri OR that > > > > it has to forward it to a proxy that can do that. If, > for example, > > > > I send 8977@pitt.marconi.com; > context="coventry-marconi", the local > > > > (roaming) proxy at pit could forward the call to > > > coventry.marconi.com > > > > for processing using the coventry-marconi context. The > pitt proxy > > > > would need routing rules to be able to do that. > > > > > > Detail: I can't quite figure out what you intend. I think you are > > > proposing sending to > > > > > > > sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone > > > > > > but that isn't quite legal. Things that would be are: > > > > > > tel:8977;phone-context=coventry.marconi.com > > > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u > > > ser=phone > > > > > > There there isn't necessarily any relationship between the > > > proxy names > > > and the context names, but I have made them the same to > suggest there > > > might be a meaningful relationship in this case. > > > > > > > Having said that, if my home is pitt, I roam to > coventry and invite > > > > someone in coventry, I don't want pitt's routing to > send the call to > > > > a gateway in Pittsburgh! If pitt expands the number to > a globally > > > > routable number and redirects the call, coventry can "least cost > > > > route" it. > > > > > > There are several possibilities here. (I assume when you roam to > > > coventry your outbound calls transit the coventry.marconi.com > > > proxy first.) > > > > > > 1) if you use the tel: form above, the proxy naturally > > > understands the > > > context and routes the call directly. Your home proxy isn't > > > involved at all. > > > > > > 2) if you use the sip form above, the coventry proxy is > supposed to > > > honor the domain, and forward the call to the > pitt.marconi.com proxy. > > > > > > 2a) the pitt proxy might use a pitt gateway - your worst fear > > > confirmed > > > > > > 2b) the pitt proxy might redirect to some global number (e.g. > > > tel:+445558977) and then the local proxy would use a > local gateway to > > > get there. > > > > > > Now instead, assume that you had roamed to coventry and > are trying to > > > dial a number 1234 in pitt: > > > > > > 3) you might use tel:1234;phone-context=pitt.marconi.com and > > > send it to > > > the coventry proxy. > > > > > > 3a) the coventry proxy might know the context and know that > > > the best way > > > to get the call there. For instance it might by default > > > forward the call > > > to the pitt.marconi.com proxy, but if that fails it could > > > also know to > > > translate the address and use a local GW. > > > > > > 3b) the coventry proxy might not know the context, but > might have a > > > convention to automatically route calls to unknown FQDN style > > > contexts > > > to a sip proxy with that name. > > > > > > 4) you might use > > > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and > > > send it to > > > the coventry proxy. In this case the coventry proxy must > > > forward to the > > > pitt proxy which will then probably use a local gw. This is > > > almost as > > > good as (3a) except with the sip path is down between > > > convenry and pitt. > > > > > > > > > My conclusion is that using a tel: gives the most options to > > > do things well. > > > > > > Paul > > > > >_______________________________________________ > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >This list is for NEW development of the application of SIP > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 28 14:05:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03917 for ; Tue, 28 Jan 2003 14:05:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SJQaF11512 for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 14:26:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJQaJ11509 for ; Tue, 28 Jan 2003 14:26:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03901 for ; Tue, 28 Jan 2003 14:04:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJNYJ11402; Tue, 28 Jan 2003 14:23:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJM1J11329 for ; Tue, 28 Jan 2003 14:22:01 -0500 Received: from elmer.LEAPSTONE.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03731 for ; Tue, 28 Jan 2003 14:00:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Date: Tue, 28 Jan 2003 14:04:51 -0500 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107A923@elmer> Thread-Topic: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Thread-Index: AcLG+CPjcKvkLeriQEqDOm+zokAi6QABkoVw From: "Dusan Mudric" To: "Rosen, Brian" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SJM1J11330 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit >The assumption you are making is that every person who does not >have a sipphone is in a database that the gateway can access. > >I think that's pretty tough to arrange. It's feasible. It will be even tougher to introduce, maintain and phase out another (telephone number based) routing schema in IP. > >Also has the small problem of multiple people with the same name. That was just an example. A globally unique or unique name within a domain is what everybody got accustomed to using emails. > >Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@leapstone.com] > Sent: Tuesday, January 28, 2003 11:39 AM > To: Michael Hammer > Cc: sipping@ietf.org > Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > There are translators at the IP-PSTN edges. Existing tel > number subscribers get registered at the PSTN-IP edge device > with {name, tel_number}, which we already have in telephone > books. Their names are visible from the edge device to the > rest of the IP world. When an IP UA-A calls a party B in a > PSTN by name, the call gets routed to the edge device that > registered a PSTN subscriber B. From there on, a PSTN routs > the call to a party B based on its tel number. > > Dusan > > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, January 28, 2003 10:34 AM > To: Dusan Mudric > Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > How would you route to someone who has only a telephone > number and no SIP > address? > > The SIP network is only useful if it can route to everyone on > the PSTN. > > Mike > > > At 10:23 AM 1/28/2003 -0500, you wrote: > >With introduction of a new technology, VoIP, legacy > attributes should stay > >at the edge. By introducing Tel routing in IP, unnecessary > dimension is > >used. IP already has a clean way to route. > > > >Why not just keep tel numbers in PSTN and names and IP's in > IP? Every tel > >number has its owner with a name. It would be > straightforward to route > >from IP to PSTN edge based on the name and at the edge > translate that name > >into a tel number. From PSTN to IP, translate a virtual tel > number into a > >name and get to the IP UA. In the near future, when > everybody switches to > >IP (I wish :-) ), we will call friends by names only. > > > >Dusan Mudric > > > >-----Original Message----- > >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >Sent: Tuesday, January 28, 2003 8:32 AM > >To: 'Paul Kyzivat' > >Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > >Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > >I observe that if you know a context name you (can) know the > domain that > >the context is valid in. That is true however the UA learns the > >context. > > > >If we make a naming convention on contexts that includes the domain > >(ie. contextname@domain), then a proxy can, if it does not understand > >that context, forward to a proxy in the domain which would. > > > >I'll note that I really dislike putting parameters in the 'user' part > >of a uri. URI parameters are inexpensive, we should use them. > >On the other hand, I'd prefer ONE way to do things. So, a tel uri, > >with a uri parameter of context, might be the best one way to go, > >rather than putting more stuff into sip:... ;user=phone. > >The contrary point of view is that the sip form has a domain, > >which makes it more easily routable by intermediaries, most of whom > >won't know how to route a generic tel uri. > > > >It might be interesting to document somewhere that redirect should > >be used when a proxy interprets a context where the call did not > >originate in the domain of the proxy that does the interpretation. > >Might be best if that was only if the translated number is globally > >routable (otherwise you could have a translated number that > >is a different destination in the originating domain than in the > >translating domain). If it's not globally routable, then the > >translating domain is probably best to just route the call rather > >than redirecting it. > > > >Brian > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Monday, January 27, 2003 6:06 PM > > > To: Rosen, Brian > > > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > > > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > > > > > > > > > > > Rosen, Brian wrote: > > > > > > > > Actually, it's not clear to me that we have to be quite so > > > > restrictive. It is possible that the rule is actually that > > > the proxy > > > > has to be able to either translate to a fully routable tel > > > uri OR that > > > > it has to forward it to a proxy that can do that. If, > for example, > > > > I send 8977@pitt.marconi.com; > context="coventry-marconi", the local > > > > (roaming) proxy at pit could forward the call to > > > coventry.marconi.com > > > > for processing using the coventry-marconi context. The > pitt proxy > > > > would need routing rules to be able to do that. > > > > > > Detail: I can't quite figure out what you intend. I think you are > > > proposing sending to > > > > > > > sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone > > > > > > but that isn't quite legal. Things that would be are: > > > > > > tel:8977;phone-context=coventry.marconi.com > > > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u > > > ser=phone > > > > > > There there isn't necessarily any relationship between the > > > proxy names > > > and the context names, but I have made them the same to > suggest there > > > might be a meaningful relationship in this case. > > > > > > > Having said that, if my home is pitt, I roam to > coventry and invite > > > > someone in coventry, I don't want pitt's routing to > send the call to > > > > a gateway in Pittsburgh! If pitt expands the number to > a globally > > > > routable number and redirects the call, coventry can "least cost > > > > route" it. > > > > > > There are several possibilities here. (I assume when you roam to > > > coventry your outbound calls transit the coventry.marconi.com > > > proxy first.) > > > > > > 1) if you use the tel: form above, the proxy naturally > > > understands the > > > context and routes the call directly. Your home proxy isn't > > > involved at all. > > > > > > 2) if you use the sip form above, the coventry proxy is > supposed to > > > honor the domain, and forward the call to the > pitt.marconi.com proxy. > > > > > > 2a) the pitt proxy might use a pitt gateway - your worst fear > > > confirmed > > > > > > 2b) the pitt proxy might redirect to some global number (e.g. > > > tel:+445558977) and then the local proxy would use a > local gateway to > > > get there. > > > > > > Now instead, assume that you had roamed to coventry and > are trying to > > > dial a number 1234 in pitt: > > > > > > 3) you might use tel:1234;phone-context=pitt.marconi.com and > > > send it to > > > the coventry proxy. > > > > > > 3a) the coventry proxy might know the context and know that > > > the best way > > > to get the call there. For instance it might by default > > > forward the call > > > to the pitt.marconi.com proxy, but if that fails it could > > > also know to > > > translate the address and use a local GW. > > > > > > 3b) the coventry proxy might not know the context, but > might have a > > > convention to automatically route calls to unknown FQDN style > > > contexts > > > to a sip proxy with that name. > > > > > > 4) you might use > > > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and > > > send it to > > > the coventry proxy. In this case the coventry proxy must > > > forward to the > > > pitt proxy which will then probably use a local gw. This is > > > almost as > > > good as (3a) except with the sip path is down between > > > convenry and pitt. > > > > > > > > > My conclusion is that using a tel: gives the most options to > > > do things well. > > > > > > Paul > > > > >_______________________________________________ > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >This list is for NEW development of the application of SIP > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 28 14:12:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04136 for ; Tue, 28 Jan 2003 14:12:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SJXHg11833 for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 14:33:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJXHJ11830 for ; Tue, 28 Jan 2003 14:33:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04123 for ; Tue, 28 Jan 2003 14:11:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJSGJ11597; Tue, 28 Jan 2003 14:28:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJQwJ11532 for ; Tue, 28 Jan 2003 14:26:58 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03912 for ; Tue, 28 Jan 2003 14:05:19 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0SJ9cnU006123; Tue, 28 Jan 2003 14:09:38 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-85.cisco.com [161.44.87.85]) by cia.cisco.com (Mirapoint) with ESMTP id ABN82179; Tue, 28 Jan 2003 13:58:47 -0500 (EST) Message-Id: <4.3.2.7.2.20030128135439.00b38e08@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Jan 2003 14:08:46 -0500 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers Cc: "'Dusan Mudric'" , sipping@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D8B@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Actually, every UAC would need to be able to access such a directory of every PSTN phone number in the world and a map to a SIP address to avoid sending a tel: URI into the SIP network. And it would have to change every time a new person gets a new phone number or a phone number changes. Why should the SIP community set up a directory to create and manage SIP addresses which map to PSTN phone numbers for non-SIP users? Mike At 01:06 PM 1/28/2003 -0500, Rosen, Brian wrote: >The assumption you are making is that every person who does not >have a sipphone is in a database that the gateway can access. > >I think that's pretty tough to arrange. > >Also has the small problem of multiple people with the same name. > >Brian > > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@leapstone.com] > > Sent: Tuesday, January 28, 2003 11:39 AM > > To: Michael Hammer > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > > There are translators at the IP-PSTN edges. Existing tel > > number subscribers get registered at the PSTN-IP edge device > > with {name, tel_number}, which we already have in telephone > > books. Their names are visible from the edge device to the > > rest of the IP world. When an IP UA-A calls a party B in a > > PSTN by name, the call gets routed to the edge device that > > registered a PSTN subscriber B. From there on, a PSTN routs > > the call to a party B based on its tel number. > > > > Dusan > > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Tuesday, January 28, 2003 10:34 AM > > To: Dusan Mudric > > Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > > How would you route to someone who has only a telephone > > number and no SIP > > address? > > > > The SIP network is only useful if it can route to everyone on > > the PSTN. > > > > Mike > > > > > > At 10:23 AM 1/28/2003 -0500, you wrote: > > >With introduction of a new technology, VoIP, legacy > > attributes should stay > > >at the edge. By introducing Tel routing in IP, unnecessary > > dimension is > > >used. IP already has a clean way to route. > > > > > >Why not just keep tel numbers in PSTN and names and IP's in > > IP? Every tel > > >number has its owner with a name. It would be > > straightforward to route > > >from IP to PSTN edge based on the name and at the edge > > translate that name > > >into a tel number. From PSTN to IP, translate a virtual tel > > number into a > > >name and get to the IP UA. In the near future, when > > everybody switches to > > >IP (I wish :-) ), we will call friends by names only. > > > > > >Dusan Mudric > > > > > >-----Original Message----- > > >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > >Sent: Tuesday, January 28, 2003 8:32 AM > > >To: 'Paul Kyzivat' > > >Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > > >Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > > > > >I observe that if you know a context name you (can) know the > > domain that > > >the context is valid in. That is true however the UA learns the > > >context. > > > > > >If we make a naming convention on contexts that includes the domain > > >(ie. contextname@domain), then a proxy can, if it does not understand > > >that context, forward to a proxy in the domain which would. > > > > > >I'll note that I really dislike putting parameters in the 'user' part > > >of a uri. URI parameters are inexpensive, we should use them. > > >On the other hand, I'd prefer ONE way to do things. So, a tel uri, > > >with a uri parameter of context, might be the best one way to go, > > >rather than putting more stuff into sip:... ;user=phone. > > >The contrary point of view is that the sip form has a domain, > > >which makes it more easily routable by intermediaries, most of whom > > >won't know how to route a generic tel uri. > > > > > >It might be interesting to document somewhere that redirect should > > >be used when a proxy interprets a context where the call did not > > >originate in the domain of the proxy that does the interpretation. > > >Might be best if that was only if the translated number is globally > > >routable (otherwise you could have a translated number that > > >is a different destination in the originating domain than in the > > >translating domain). If it's not globally routable, then the > > >translating domain is probably best to just route the call rather > > >than redirecting it. > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: Monday, January 27, 2003 6:06 PM > > > > To: Rosen, Brian > > > > Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' > > > > Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers > > > > > > > > > > > > > > > > > > > > Rosen, Brian wrote: > > > > > > > > > > Actually, it's not clear to me that we have to be quite so > > > > > restrictive. It is possible that the rule is actually that > > > > the proxy > > > > > has to be able to either translate to a fully routable tel > > > > uri OR that > > > > > it has to forward it to a proxy that can do that. If, > > for example, > > > > > I send 8977@pitt.marconi.com; > > context="coventry-marconi", the local > > > > > (roaming) proxy at pit could forward the call to > > > > coventry.marconi.com > > > > > for processing using the coventry-marconi context. The > > pitt proxy > > > > > would need routing rules to be able to do that. > > > > > > > > Detail: I can't quite figure out what you intend. I think you are > > > > proposing sending to > > > > > > > > > > sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone > > > > > > > > but that isn't quite legal. Things that would be are: > > > > > > > > tel:8977;phone-context=coventry.marconi.com > > > > sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u > > > > ser=phone > > > > > > > > There there isn't necessarily any relationship between the > > > > proxy names > > > > and the context names, but I have made them the same to > > suggest there > > > > might be a meaningful relationship in this case. > > > > > > > > > Having said that, if my home is pitt, I roam to > > coventry and invite > > > > > someone in coventry, I don't want pitt's routing to > > send the call to > > > > > a gateway in Pittsburgh! If pitt expands the number to > > a globally > > > > > routable number and redirects the call, coventry can "least cost > > > > > route" it. > > > > > > > > There are several possibilities here. (I assume when you roam to > > > > coventry your outbound calls transit the coventry.marconi.com > > > > proxy first.) > > > > > > > > 1) if you use the tel: form above, the proxy naturally > > > > understands the > > > > context and routes the call directly. Your home proxy isn't > > > > involved at all. > > > > > > > > 2) if you use the sip form above, the coventry proxy is > > supposed to > > > > honor the domain, and forward the call to the > > pitt.marconi.com proxy. > > > > > > > > 2a) the pitt proxy might use a pitt gateway - your worst fear > > > > confirmed > > > > > > > > 2b) the pitt proxy might redirect to some global number (e.g. > > > > tel:+445558977) and then the local proxy would use a > > local gateway to > > > > get there. > > > > > > > > Now instead, assume that you had roamed to coventry and > > are trying to > > > > dial a number 1234 in pitt: > > > > > > > > 3) you might use tel:1234;phone-context=pitt.marconi.com and > > > > send it to > > > > the coventry proxy. > > > > > > > > 3a) the coventry proxy might know the context and know that > > > > the best way > > > > to get the call there. For instance it might by default > > > > forward the call > > > > to the pitt.marconi.com proxy, but if that fails it could > > > > also know to > > > > translate the address and use a local GW. > > > > > > > > 3b) the coventry proxy might not know the context, but > > might have a > > > > convention to automatically route calls to unknown FQDN style > > > > contexts > > > > to a sip proxy with that name. > > > > > > > > 4) you might use > > > > sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and > > > > send it to > > > > the coventry proxy. In this case the coventry proxy must > > > > forward to the > > > > pitt proxy which will then probably use a local gw. This is > > > > almost as > > > > good as (3a) except with the sip path is down between > > > > convenry and pitt. > > > > > > > > > > > > My conclusion is that using a tel: gives the most options to > > > > do things well. > > > > > > > > Paul > > > > > > >_______________________________________________ > > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > >This list is for NEW development of the application of SIP > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > >Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jan 28 16:53:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09169 for ; Tue, 28 Jan 2003 16:53:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SME7f24176 for sipping-archive@odin.ietf.org; Tue, 28 Jan 2003 17:14:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SME7J24173 for ; Tue, 28 Jan 2003 17:14:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09134 for ; Tue, 28 Jan 2003 16:52:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SM80J23799; Tue, 28 Jan 2003 17:08:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SM5AJ23056 for ; Tue, 28 Jan 2003 17:05:10 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08902 for ; Tue, 28 Jan 2003 16:43:30 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0SLlfbV001638; Tue, 28 Jan 2003 16:47:42 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY71000; Tue, 28 Jan 2003 16:51:53 -0500 (EST) Message-ID: <3E36FA4B.3060902@cisco.com> Date: Tue, 28 Jan 2003 16:46:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Michael Hammer'" , "'Henning Schulzrinne'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <313680C9A886D511A06000204840E1CF030B5D82@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I observe that if you know a context name you (can) know the domain that > the context is valid in. That is true however the UA learns the > context. No. At least all I suggested is that if you know the context name you may be able to guess *a* (not *the*) domain the context is valid in. The context may be valid in many domains. (In fact, I gave an example where a context was valid in two domains.) > If we make a naming convention on contexts that includes the domain > (ie. contextname@domain), then a proxy can, if it does not understand > that context, forward to a proxy in the domain which would. Well, that particular convention won't work, but yes I was suggesting a convention with this property - if the context is in FQDN format, try using that as a next hop domain name. > I'll note that I really dislike putting parameters in the 'user' part > of a uri. Why? The sip representation of a tel: url uses them. Life is tough. > URI parameters are inexpensive, we should use them. Parsing is parsing. What does it matter which part of the url you parse to get them? If you use a tel: url directly, then they are url parameters. Does that make you happier? > On the other hand, I'd prefer ONE way to do things. So, a tel uri, > with a uri parameter of context, might be the best one way to go, > rather than putting more stuff into sip:... ;user=phone. > The contrary point of view is that the sip form has a domain, > which makes it more easily routable by intermediaries, most of whom > won't know how to route a generic tel uri. Its ok to switch to the sip: form once you are in a position to intelligently decide what domain to use. From then on intermediaries don't need to understand tel: This decision can even be made in the UAC if its smart enough. But this still leaves the To in tel: form. It isn't used in routing so it can and should stay that way. > It might be interesting to document somewhere that redirect should > be used when a proxy interprets a context where the call did not > originate in the domain of the proxy that does the interpretation. > Might be best if that was only if the translated number is globally > routable (otherwise you could have a translated number that > is a different destination in the originating domain than in the > translating domain). If it's not globally routable, then the > translating domain is probably best to just route the call rather > than redirecting it. It might take a lot of talking to come to agreement on the details. But perhaps we could agree that when a proxy decides a translation is something the caller would like to know it should use a redirect, and when the UAC receives such a redirect is should display the action to the caller. Paul >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Monday, January 27, 2003 6:06 PM >>To: Rosen, Brian >>Cc: 'Michael Hammer'; 'Henning Schulzrinne'; 'sipping@ietf.org' >>Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers >> >> >> >> >>Rosen, Brian wrote: >> >>>Actually, it's not clear to me that we have to be quite so >>>restrictive. It is possible that the rule is actually that >> >>the proxy >> >>>has to be able to either translate to a fully routable tel >> >>uri OR that >> >>>it has to forward it to a proxy that can do that. If, for example, >>>I send 8977@pitt.marconi.com; context="coventry-marconi", the local >>>(roaming) proxy at pit could forward the call to >> >>coventry.marconi.com >> >>>for processing using the coventry-marconi context. The pitt proxy >>>would need routing rules to be able to do that. >> >>Detail: I can't quite figure out what you intend. I think you are >>proposing sending to >> >>sip:8977;phone-context=coventry-marconi@pitt.marconi.com;user=phone >> >>but that isn't quite legal. Things that would be are: >> >>tel:8977;phone-context=coventry.marconi.com >>sip:8977;phone-context=coventry.marconi.com@pitt.marconi.com;u >>ser=phone >> >>There there isn't necessarily any relationship between the >>proxy names >>and the context names, but I have made them the same to suggest there >>might be a meaningful relationship in this case. >> >> >>>Having said that, if my home is pitt, I roam to coventry and invite >>>someone in coventry, I don't want pitt's routing to send the call to >>>a gateway in Pittsburgh! If pitt expands the number to a globally >>>routable number and redirects the call, coventry can "least cost >>>route" it. >> >>There are several possibilities here. (I assume when you roam to >>coventry your outbound calls transit the coventry.marconi.com >>proxy first.) >> >>1) if you use the tel: form above, the proxy naturally >>understands the >>context and routes the call directly. Your home proxy isn't >>involved at all. >> >>2) if you use the sip form above, the coventry proxy is supposed to >>honor the domain, and forward the call to the pitt.marconi.com proxy. >> >>2a) the pitt proxy might use a pitt gateway - your worst fear >>confirmed >> >>2b) the pitt proxy might redirect to some global number (e.g. >>tel:+445558977) and then the local proxy would use a local gateway to >>get there. >> >>Now instead, assume that you had roamed to coventry and are trying to >>dial a number 1234 in pitt: >> >>3) you might use tel:1234;phone-context=pitt.marconi.com and >>send it to >>the coventry proxy. >> >>3a) the coventry proxy might know the context and know that >>the best way >>to get the call there. For instance it might by default >>forward the call >>to the pitt.marconi.com proxy, but if that fails it could >>also know to >>translate the address and use a local GW. >> >>3b) the coventry proxy might not know the context, but might have a >>convention to automatically route calls to unknown FQDN style >>contexts >>to a sip proxy with that name. >> >>4) you might use >>sip:1234;phone-context=pitt.marconi.com@pitt.marconi.com and >>send it to >>the coventry proxy. In this case the coventry proxy must >>forward to the >>pitt proxy which will then probably use a local gw. This is >>almost as >>good as (3a) except with the sip path is down between >>convenry and pitt. >> >> >>My conclusion is that using a tel: gives the most options to >>do things well. >> >> Paul >> > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 30 07:58:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26252 for ; Thu, 30 Jan 2003 07:58:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UDKYB30298 for sipping-archive@odin.ietf.org; Thu, 30 Jan 2003 08:20:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDKYJ30295 for ; Thu, 30 Jan 2003 08:20:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26234 for ; Thu, 30 Jan 2003 07:58:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDJaJ30204; Thu, 30 Jan 2003 08:19:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDHDJ30125 for ; Thu, 30 Jan 2003 08:17:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26119; Thu, 30 Jan 2003 07:54:47 -0500 (EST) Message-Id: <200301301254.HAA26119@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 30 Jan 2003 07:54:47 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Interworking between SIP and QSIG Author(s) : J. Elwell Filename : draft-ietf-sipping-qsig2sip-00.txt Pages : 54 Date : 2003-1-29 This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application- layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be able to establish, modify and terminate sessions involving a participant in the SIP network and a participant in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-qsig2sip-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-qsig2sip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-29154918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-qsig2sip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-qsig2sip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-29154918.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 30 10:20:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00826 for ; Thu, 30 Jan 2003 10:20:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UFNuH07796 for sipping-archive@odin.ietf.org; Thu, 30 Jan 2003 10:23:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFNuJ07792 for ; Thu, 30 Jan 2003 10:23:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00817 for ; Thu, 30 Jan 2003 10:20:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFN7J07734; Thu, 30 Jan 2003 10:23:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFIOJ07149 for ; Thu, 30 Jan 2003 10:18:24 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00680 for ; Thu, 30 Jan 2003 10:14:49 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H9J00D019600G@siemenscomms.co.uk> for sipping@ietf.org; Thu, 30 Jan 2003 15:18:01 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H9J00C4I95AXH@siemenscomms.co.uk> for sipping@ietf.org; Thu, 30 Jan 2003 15:17:34 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Jan 2003 15:17:52 +0000 Content-return: allowed Date: Thu, 30 Jan 2003 15:18:07 +0000 From: "Elwell, John" Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-00.txt To: "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Compared with draft-elwell-sipping-qsig2sip-03 the following changes have been made: - change to wording of first bullet of 8.2.1.3 concerning handling of 180 response; - changes to some references and definitions. The authors feel that this draft is now quite mature and that working group last call could be considered soon. John Elwell e-mail: mailto:john.elwell@siemens.com > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 30 January 2003 12:55 > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Session Initiation Proposal > Investigation Working Group of the IETF. > > Title : Interworking between SIP and QSIG > Author(s) : J. Elwell > Filename : draft-ietf-sipping-qsig2sip-00.txt > Pages : 54 > Date : 2003-1-29 > > This document specifies interworking between the Session Initiation > Protocol (SIP) and QSIG within corporate telecommunication networks > (also known as enterprise networks). SIP is an Internet application- > layer control (signalling) protocol for creating, modifying, and > terminating sessions with one or more participants. These sessions > include, in particular, telephone calls. QSIG is a signalling > protocol for creating, modifying and terminating circuit-switched > calls, in particular telephone calls, within Private Integrated > Services Networks (PISNs). QSIG is specified in a number of ECMA > Standards and published also as ISO/IEC standards. > As the support of telephony within corporate networks evolves from > circuit-switched technology to Internet technology, the two > technologies will co-exist in many networks for a period, perhaps > several years. Therefore there is a need to be able to establish, > modify and terminate sessions involving a participant in the SIP > network and a participant in the QSIG network. Such calls are > supported by gateways that perform interworking between SIP and QSIG. > This document is a product of the authors' activities in ECMA > (www.ecma.ch) on interoperability of QSIG with IP networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sipping-qsig2sip-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sipping-qsig2sip-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 30 10:45:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01958 for ; Thu, 30 Jan 2003 10:45:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UFmVZ09985 for sipping-archive@odin.ietf.org; Thu, 30 Jan 2003 10:48:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFmVJ09982 for ; Thu, 30 Jan 2003 10:48:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01893 for ; Thu, 30 Jan 2003 10:44:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFlvJ09858; Thu, 30 Jan 2003 10:47:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFijJ09676 for ; Thu, 30 Jan 2003 10:44:45 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01812 for ; Thu, 30 Jan 2003 10:41:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Date: Thu, 30 Jan 2003 10:44:41 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24871C@zoe.office.snowshore.com> Thread-Topic: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt Thread-Index: AcK38cohl2KDlweyR5aGeUEnMoefnQP9kEBA From: "Eric Burger" To: "Rosen, Brian" , "Paul Kyzivat" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UFijJ09677 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Why are we doing it at all? Can't it be a local matter? For example, a PingTel phone "does it all". A Marconi IP PBX has a local understanding between the phone and the outbound proxy. Is there real value in casting this in stone? > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, January 09, 2003 10:12 AM > To: 'Paul Kyzivat'; 'sipping@ietf.org' > Subject: [Sipping] Do Phones Have Dial Plans, or do Proxies > map? was RE: > [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > This comes up a lot. I think we should decide. > > Who translates a dial string into a tel uri? > > tel uris, as of now, explicitly don't handle dialing strings, > only dialed numbers. In essentially all existing systems, > phones don't have dialing plans in them; central elements > map dialing strings to dialed numbers. What's our story? > Does every UA that has a dial pad have to have a dialing plan > loaded in it that maps dialing strings to dialed numbers, > or does a proxy server do it? > > If it's the former, then how do we standardize the mapping? > If it's the latter, then how does a UA send a dialing string? > > Brian > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, January 09, 2003 9:53 AM > > To: 'sipping@ietf.org' > > Subject: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt > > > > > > I have a few comments about draft-schulzrinne-sipping-sos-04.txt. > > (I haven't been following this work very closely, so > perhaps some of > > these pertain to things that were in earlier drafts.) > > > > I must say, these are really messy problems, so I am glad you are > > working on them. > > > > Section 3.2 says: > > > > ... a UAC MAY use a "tel" URI [3,4] without > phone-context, such as > > > > tel:911 > > tel:112 > > > > The latest and greatest definition of the tel: uri that I > can find is > > draft-antti-rfc2806bis-07.txt. According to that, the above > tel: uris > > are syntactically incorrect. Either the number must be global > > or else it > > must contain a phone-context parameter. > > > > Are there plans to change the definition of the tel uri, or is this > > language going to change? > > > > In the case of a UAC that is using a local outbound proxy, is it > > required that the UAC specifically recognize these strings > > and deliver > > them to the proxy, or is it sufficient for it to deliver > any and all > > dialed digit strings to the proxy as tel uris without attempting to > > recognize them itself? Is it sufficient to determine that > the dialed > > number is complete by timeout on the input rather than by > recognition? > > > > Section 5 specifies that the UAC should insert location > > information into > > emergency calls. However, presumably location information should in > > general not be placed in non-emergency calls, so it is > important that > > the UAC realize it is making an emergency call. In the case > of dialed > > digit strings, it may only be the outbound proxy that can > > determine if > > the call is an emergency call. One way to handle this would > > be for the > > local outbound proxy to redirect requests to tel: emergency > > numbers to > > the corresponding sip:sos number. Then the UAC would be able to > > positively determine this is an emergency call and include > > the location > > information. > > > > Section 9 says: > > > > We propose a new DHCP option that enumerates the valid local > > emergency identifiers, as a list of "tel", "sip" or "sips" URIs. > > > > This doesn't seem sufficient. Most phone-like devices have > > provision for > > entering primarily sequences of digits, not tel: uris. It is > > up to the > > phone to translate a digit sequence into a valid uri. In > general this > > requires some sort of dial plan. Without the dial plan, the > phone may > > well not be able to generate anything that matches one of the > > specified > > tel uris. > > > > Paul > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jan 30 10:45:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01971 for ; Thu, 30 Jan 2003 10:45:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UFmb010009 for sipping-archive@odin.ietf.org; Thu, 30 Jan 2003 10:48:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFmbJ10006 for ; Thu, 30 Jan 2003 10:48:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01900 for ; Thu, 30 Jan 2003 10:44:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFlxJ09881; Thu, 30 Jan 2003 10:47:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFimJ09680 for ; Thu, 30 Jan 2003 10:44:48 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01817 for ; Thu, 30 Jan 2003 10:41:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RFC 3351 and Generic Transcoding Date: Thu, 30 Jan 2003 10:44:41 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24871D@zoe.office.snowshore.com> Thread-Topic: [Sipping] RFC 3351 and Generic Transcoding Thread-Index: AcKdJoP3GDzzn6gnRi2BfhvQOTx8FAqwftQQ From: "Eric Burger" To: "A vWijk" , , Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UFimJ09682 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I would offer that the burden of transcoding is "whomever wishes to pay." If you notice you cannot match any of the offered SDP, you can request a transcoding service. In the worst case, both parties invoke transcoding services. Is that really likely to happen often? If not, I wouldn't worry about it. > -----Original Message----- > From: A vWijk [mailto:A.vWijk@viataal.nl] > Sent: Friday, December 06, 2002 7:49 AM > To: sipping@ietf.org; mwatson@nortelnetworks.com > Cc: Gonzalo.Camarillo@lmf.ericsson.se; drage@lucent.com; > Guido.Gybels@rnid.org.uk; Eric Burger > Subject: RE: [Sipping] RFC 3351 and Generic Transcoding > > > Hello everybody, > > The negotiation of who will/can insert the transcoding > service is something that is required, but we have to look at > it on HOW to do so. > It would be useless if both users start the same transcoding service. > > I am thinking perhaps that any user can invoke the > transcoding service by default, but that the other party has > to be notified that such a tanscoding service is inserted. > The RNID and ViaTaal plan to describe usecases and scenarios > on when a transcoding service will be invoked/inserted (among others). > Ofcourse, our angle will be the hearing impaired. But the > solution will be just as useful for interworking between 3GPP > and 3GPP2 systems etc. > > Basically it boils down that A and B have to decide which of > them invokes the transcoding service. > Perhaps a SIP NOTIFY message? We should indeed look deeper at this. > Perhaps combined with a master/slave setting in the caller > preferences (let's make Jonathan crazy :-)? Meaning that the > Master will send a message to the slave UA that the > transcoding service is to be inserted? And that the slave UA > will by default wait for such a message unless timed out on > which it will then invoke the transcoding service itself. > > This is just from the top of my mind. I haven't had time to > play with those scenarios yet. > > greetz > > Arnoud van Wijk > > > **************************************** > > Gonzalo, > > I imagine the requirement from 3GPP will be something like: > 1) Insertion of a transcoding device between two UAs which do > not support a > common codec. > 2) Achieve (1) when only 1 of the end devices (UAC or UAS) > supports the > procedures for inviting/inserting/invoking the transcoding service > 3) Achieve (1) when neither of the devices (UAC and UAS) support the > procedures for inviting/inserting/invoking the transcoding service > > I guess the requirements in RFC3351 probably cover (1) and > perhaps (2), > although I do not remember much about negotiation of who > will/can insert the > transcoding service. I'm not sure (3) has been addressed anywhere. > > I think (3) is required for interworking between 3GPP and > 3GPP2 systems > (where the terminals may not support a common codec). I am > assuming that the > first release of the 3GPP2 SIP system will not include > mandatory support at > the UA for the procedures for inviting/inserting/invoking the > transcoding > service. Happy to be proved wrong on this! > > As Keith says, some review is required in 3GPP & when this is > done I hope > 3GPP will be able to provide a concrete statement of transcoding > requirements. > > Regards, > > Mark > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 26 November 2002 06:42 > > To: Drage, Keith (Keith) > > Cc: Guido Gybels; sipping@ietf.org; Eric Burger > > Subject: Re: [Sipping] RFC 3351 and Generic Transcoding > > > > > > Keith, > > > > we have heard several times from several folks that we might > > be missing > > requirements. What we would like to have is *examples* of such > > requirements. This way we can decide whether we have to > come up with a > > more formal document on requirements or, on the other hand, we are > > already taking them into account. > > > > I am not assuming that new requirements will be related to SDP. I am > > only guessing, since I have not seen any new requirement so far. > > > > Thanks, > > > > Gonzalo > > > > > > "Drage, Keith (Keith)" wrote: > > > > > > If you are referring to what I said in plenary, then it was > > not this. > > > > > > To further clarify what I said in plenary: > > > > > > RFC3351 was developed as a set of requirements for the hard > > of hearing, not as a general set of transcoding requirements. > > Presumably, as it had that limited scope, that was what it > > was reviewed for. > > > > > > Now that the design team has decided to design a solution > > for general transcoding, the SIPPING group should do a quick > > pass through RFC 3351 to see if any requirements are missed. > > > > > > At the moment I do not have any requirements in mind, > > related to SIP, SDP or otherwise, but please do not assume > > that they can only be SDP issues. > > > > > > As I said in an earlier mail, it will take some time to get > > a review by some interested 3GPP people, but I am sure that > > it would be appropriate to try and take into account 3GPP > > Release 6 requirements now rather than when the design > > process has solidified. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: 25 November 2002 12:14 > > > > To: Guido Gybels > > > > Cc: sipping@ietf.org; Eric Burger > > > > Subject: Re: [Sipping] RFC 3351 and Generic Transcoding > > > > > > > > > > > > Folks, > > > > > > > > as Eric pointed out, some folks said that there are SIP > > requirements > > > > beyong RFC 3351 that we have to take into consideration. > > > > > > > > It seems to me that what people have in mind will be > > requirements that > > > > are more related to SDP than to SIP (i.e., they would affect the > > > > plumbing draft rather than the framework that describes SIP > > > > procedures), > > > > but in any event we would like to hear them all. > > > > > > > > We will be working on SDP issues (i.e., media policies) > > together with > > > > the conferencing team. > > > > > > > > Thanks, > > > > > > > > Gonzalo > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > ------_=_NextPart_001_01C29D13.1BC2EB76 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Diso-8859-1"> > 5.5.2655.35"> > RE: [Sipping] RFC 3351 and Generic Transcoding > > > >

Gonzalo, >

> >

I imagine the requirement from 3GPP will be > something = > like: >
1) Insertion of a transcoding device > between two UAs = > which do not support a common codec. >
2) Achieve (1) when only 1 of the end > devices (UAC = > or UAS) supports the procedures for inviting/inserting/invoking the = > transcoding service

> >

3) Achieve (1) when neither of the devices > (UAC and = > UAS) support the procedures for inviting/inserting/invoking the = > transcoding service

> >

I guess the requirements in RFC3351 probably cover = > (1) and perhaps (2), although I do not remember much about > negotiation = > of who will/can insert the transcoding service. I'm not sure (3) has = > been addressed anywhere.

> >

I think (3) is required for interworking > between 3GPP = > and 3GPP2 systems (where the terminals may not support a > common codec). = > I am assuming that the first release of the 3GPP2 SIP system > will not = > include mandatory support at the UA for the procedures for = > inviting/inserting/invoking the transcoding service. Happy to > be proved = > wrong on this!

> >

As Keith says, some review is required in > 3GPP & = > when this is done I hope 3GPP will be able to provide a concrete = > statement of transcoding requirements.

> >

Regards, >

> >

Mark >

>
> >

> -----Original Message----- >
> From: Gonzalo Camarillo [ HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonza > lo.Camaril= > lo@lmf.ericsson.se] >
> Sent: 26 November 2002 06:42 >
> To: Drage, Keith (Keith) >
> Cc: Guido Gybels; sipping@ietf.org; Eric = > Burger >
> Subject: Re: [Sipping] RFC 3351 and Generic = > Transcoding >
> >
> >
> Keith, >
> >
> we have heard several times from > several folks = > that we might >
> be missing >
> requirements. What we would like to have is = > *examples* of such >
> requirements. This way we can decide > whether we = > have to come up with a >
> more formal document on requirements > or, on the = > other hand, we are >
> already taking them into account. >
> >
> I am not assuming that new > requirements will be = > related to SDP. I am >
> only guessing, since I have not seen any new = > requirement so far. >
> >
> Thanks, >
> >
> Gonzalo >
> >
> >
> "Drage, Keith (Keith)" wrote: >
> > >
> > If you are referring to what I said in = > plenary, then it was >
> not this. >
> > >
> > To further clarify what I said in = > plenary: >
> > >
> > RFC3351 was developed as a set of = > requirements for the hard >
> of hearing, not as a general set of > transcoding = > requirements. >
> Presumably, as it had that limited > scope, that = > was what it >
> was reviewed for. >
> > >
> > Now that the design team has decided to = > design a solution >
> for general transcoding, the SIPPING group = > should do a quick >
> pass through RFC 3351 to see if any = > requirements are missed. >
> > >
> > At the moment I do not have any = > requirements in mind, >
> related to SIP, SDP or otherwise, but > please do = > not assume >
> that they can only be SDP issues. >
> > >
> > As I said in an earlier mail, it > will take = > some time to get >
> a review by some interested 3GPP > people, but I = > am sure that >
> it would be appropriate to try and take into = > account 3GPP >
> Release 6 requirements now rather > than when the = > design >
> process has solidified. >
> > >
> > Keith >
> > >
> > Keith Drage >
> > Lucent Technologies >
> > Tel: +44 1793 776249 >
> > Email: drage@lucent.com >
> > >
> > > -----Original Message----- >
> > > From: Gonzalo Camarillo [ HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonza > lo.Camaril= > lo@lmf.ericsson.se] >
> > > Sent: 25 November 2002 12:14 >
> > > To: Guido Gybels >
> > > Cc: sipping@ietf.org; Eric = > Burger >
> > > Subject: Re: [Sipping] RFC > 3351 and = > Generic Transcoding >
> > > >
> > > >
> > > Folks, >
> > > >
> > > as Eric pointed out, some > folks said = > that there are SIP >
> requirements >
> > > beyong RFC 3351 that we > have to take = > into consideration. >
> > > >
> > > It seems to me that what > people have = > in mind will be >
> requirements that >
> > > are more related to SDP > than to SIP = > (i.e., they would affect the >
> > > plumbing draft rather than the = > framework that describes SIP >
> > > procedures), >
> > > but in any event we would like to = > hear them all. >
> > > >
> > > We will be working on SDP issues = > (i.e., media policies) >
> together with >
> > > the conferencing team. >
> > > >
> > > Thanks, >
> > > >
> > > Gonzalo >
> > > = > _______________________________________________ >
> > > Sipping mailing list  >
> HREF=3D"https://www1.ietf.org/mailman/listinfo/sipping" = > TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sippi > ng NT> >
> > > This list is for NEW > development of = > the application of SIP >
> > > Use > sip-implementors@cs.columbia.edu = > for questions on current sip >
> > > Use sip@ietf.org for new > developments = > of core SIP >
> > > >
> > = > _______________________________________________ >
> > Sippin > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 31 11:36:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11375 for ; Fri, 31 Jan 2003 11:36:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VGdjT04655 for sipping-archive@odin.ietf.org; Fri, 31 Jan 2003 11:39:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGdjJ04652 for ; Fri, 31 Jan 2003 11:39:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11353 for ; Fri, 31 Jan 2003 11:35:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGd2J04613; Fri, 31 Jan 2003 11:39:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGbTJ04544 for ; Fri, 31 Jan 2003 11:37:29 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11320 for ; Fri, 31 Jan 2003 11:33:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0VGaqYH013071; Fri, 31 Jan 2003 11:36:52 -0500 (EST) Message-ID: <3E3AA61E.7060305@dynamicsoft.com> Date: Fri, 31 Jan 2003 11:36:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sipping@ietf.org Subject: Re: [Sipping] Event notification rate limiting requirements References: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com> <3E353977.2030802@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> I used this example in a separate discussion and I'll use it again >> here: If Aki was driving down from Lapland to Helsinki, I'm >> interested to get his presence info once every hour or so. By >> subscribing to his presence and limiting the rate of notifications >> to 1 per hour is a good thing. I get the notifications >> automatically. I don't have to manually subscribe every hour and >> waste bandwidth. > > > There are two classes of notifications: stateless and stateful. > Presence (closed/busy) is stateful, in that it persists at the > receiver until the next announcement. Location is stateless - the > accuracy of estimation of the variable just decreases as the rate of > updates decreases. In many cases, physical constraints limit the > error. If I know you are in a land vehicle, I can draw a circle > around a last position report that increases its radius at around 70 > mph and have high confidence that the entity hasn't suddenly gone > into hyperspace. > > It's relatively easy to ratelimit the latter, much harder to > ratelimit the former. True. Inevitably the result of the rate-limiting will be inaccurate or obsolete information for longer periods of time. I think that is the consequence of asking for lower notification rates. Is there any other choice? Aki Niemi wrote: > I was talking about subscribers increasing the rate to a >> number that is higher than the server's allowed maximum. If the >> server has a rate limit of the typical once per 5 seconds, the >> subscriber must not be able to increase this rate to, say, 5 times >> per 5 seconds. >> >> So the requirement is: The notifier must be able to reject a >> subscription containing a rate limit higher that is local >> configured maximum. > > > My point was that there is no need to reject such a limit, as long as > the notifier MUST be allowed to use a lower rate. So the notifier may > accept, and still abide by its own internal default policy of 1 > notification per 5 seconds. The subscriber is still happy, since its > max rate is not exceeded. Such a throttle will be utterly useless, > but won't break anything. Indeed. In fact, the server needs to support the peak notification rate for the presentity anyway. Thats because their may be subscribers who don't even have rate limiting, and in that case, they get the regular rate. The only case where this doesnt hold is the "stateless" data, such as location, that Hennign mentions above. IN that case, there is no natural notification rate of the data. It changes infinitely fast (theoretically). So, the server has its own maximum rate that it will send notifications at. In such a case, does the subscriber need to know that its requested rate won't be honored, and it willg et a lower rate? Perhaps. It depends on the application of the location data. If its being used in some kind of tracking application, the lower rate may be insufficient. However, one could say the same about presence genreally. I might have some application where I NEED to know the presence of your cell phone, and if I dont get it, the subscription is useless. That would require some kind of presence-require mechanism. I would rather lump all of these together and deal with them in the future if a true need arises. So, to summarize my ramble, I do not think at this time that there is a need to reject a subscription because the requested rate is too high. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 31 11:37:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11415 for ; Fri, 31 Jan 2003 11:37:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VGebo04765 for sipping-archive@odin.ietf.org; Fri, 31 Jan 2003 11:40:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGeaJ04762 for ; Fri, 31 Jan 2003 11:40:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11391 for ; Fri, 31 Jan 2003 11:36:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGe5J04704; Fri, 31 Jan 2003 11:40:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VGcGJ04581 for ; Fri, 31 Jan 2003 11:38:16 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11328 for ; Fri, 31 Jan 2003 11:34:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0VGbjYH013075; Fri, 31 Jan 2003 11:37:46 -0500 (EST) Message-ID: <3E3AA654.9080308@dynamicsoft.com> Date: Fri, 31 Jan 2003 11:37:40 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: alan.johnston@wcom.com, margaret_mary@dexceldesigns.com, sipping@ietf.org Subject: Re: [Sipping] query on conference server References: <2038BCC78B1AD641891A0D1AE133DBB7FE719B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It is an instance. Sorry for being inaccurate with my terminology. -Jonathan R. hisham.khartabil@nokia.com wrote: > Is focus a conference server or an instance of a conference? I > thought it was the latter, unless you mean the server of a particular > conference is a focus. > > Regards, Hisham > > >> -----Original Message----- From: ext Jonathan Rosenberg >> [mailto:jdrosen@dynamicsoft.com] Sent: Friday, January 24, 2003 >> 11:30 PM To: Alan Johnston Cc: margaretmary; sipping@ietf.org >> Subject: Re: [Sipping] query on conference server >> >> >> One additional note. The "models for multiparty conferencing in >> sip" is not going to move forward. Its content has been moved into >> the framework document Alan has pointed out, along with other >> documents that the framework references. >> >> To briefly answer your questions, a conference server (called a >> focus in SIP) is a SIP user agent. Proxies don't know anything >> about conferences. They just route requests to URIs, and a URI >> might represent a conference. >> >> -Jonathan R. >> >> Alan Johnston wrote: >> >>> Hi Margaret, >>> >>> There is a SIPPING design team working on conferencing. >> >> Information >> >>> about the work is at: >>> >>> http://www.softarmor.com/sipping/teams/conf/ >>> >>> I'd recommend you start reading the conferencing framework >>> document which may answer your questions: >>> >>> >>> >> >> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-co >> nferencing-framework-00.txt >> >>> >>> Thanks, Alan Johnston WorldCom sip:alan@digitalari.com >>> >>> At 09:46 AM 1/23/2003 +0530, margaretmary wrote: >>> >>> >>>> hello sir, >>>> >>>> Can any one tell me about the conference server >>> >> application using SIP. >> >>>> Are these two drafts "Models for Multi Party Conferencing >>> >> SIP" and " A >> >>>> Multi-Party Application Framework for SIP" specify for >>>> conference server application. >>>> >>>> Is their any other draft for this, please tell me. >>>> >>>> Is it a simple SIP User Agent required to develop >>> >> conference server. >> >>>> can SIP proxy server /Redirect server can come along with >>> >> conference >> >>>> server. >>>> >>>> Please help me out with this. Since i am new to SIPPING >>>> >>>> >>>> >>>> >>>> Regards, Margaret >>>> >>>> -------------------------------------------------------------- >>>> Dexcel Electronics Designs (P) Ltd., Bangalore, India >>> >>> >>> _______________________________________________ Sipping mailing >>> list https://www1.ietf.org/mailman/listinfo/sipping This list is >>> for NEW development of the application of SIP Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sip@ietf.org for new developments of core SIP >>> >> >> -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >> Chief Scientist First Floor dynamicsoft >> East Hanover, NJ 07936 jdrosen@dynamicsoft.com >> FAX: (973) 952-5050 http://www.jdrosen.net >> PHONE: (973) 952-5000 http://www.dynamicsoft.com >> >> _______________________________________________ Sipping mailing >> list https://www1.ietf.org/mailman/listinfo/sipping This list is >> for NEW development of the application of SIP Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sip@ietf.org for new developments of core SIP >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jan 31 15:31:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17994 for ; Fri, 31 Jan 2003 15:31:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VKZbU17539 for sipping-archive@odin.ietf.org; Fri, 31 Jan 2003 15:35:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKZbJ17536 for ; Fri, 31 Jan 2003 15:35:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17977 for ; Fri, 31 Jan 2003 15:31:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKYpJ17491; Fri, 31 Jan 2003 15:34:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VKWqJ17407 for ; Fri, 31 Jan 2003 15:32:52 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17932 for ; Fri, 31 Jan 2003 15:28:41 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0VKW9HA025026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Jan 2003 15:32:10 -0500 (EST) Message-ID: <3E3ADD4E.4070901@cs.columbia.edu> Date: Fri, 31 Jan 2003 15:32:14 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sipping@ietf.org Subject: Re: [Sipping] Event notification rate limiting requirements References: <2038BCC78B1AD641891A0D1AE133DBB7FE71AA@esebe019.ntc.nokia.com> <3E353977.2030802@cs.columbia.edu> <3E3AA61E.7060305@dynamicsoft.com> In-Reply-To: <3E3AA61E.7060305@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > True. Inevitably the result of the rate-limiting will be inaccurate or > obsolete information for longer periods of time. I think that is the > consequence of asking for lower notification rates. Is there any other > choice? In practice, I suspect that people will use rate-limiting for things like location information where reducing the rate reduces the accuracy in some predictable fashion, rather than where one 'throttled' notification turns the information from useful to completely misleading. However, we can leave this up to the subscriber and the implementation. In many cases, the better thing is to provide several different subscriptions, e.g., one that tracks my detailed presence state (do not disturb, individual media reachability, etc.), another one that basically only tells me if (sum of all OPEN) has changed from zero to some positive number. (A poor man's version of a filter.) Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP