From exim@www1.ietf.org Fri Aug 1 02:59:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10869 for ; Fri, 1 Aug 2003 02:59:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTrg-0002o1-M0 for sipping-archive@odin.ietf.org; Fri, 01 Aug 2003 02:58:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h716wCFE010780 for sipping-archive@odin.ietf.org; Fri, 1 Aug 2003 02:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTre-0002nn-R6 for sipping-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 02:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10834 for ; Fri, 1 Aug 2003 02:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iTra-0002tT-00 for sipping-web-archive@ietf.org; Fri, 01 Aug 2003 02:58:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iTra-0002tP-00 for sipping-web-archive@ietf.org; Fri, 01 Aug 2003 02:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTrW-0002ms-3R; Fri, 01 Aug 2003 02:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTqq-0002mH-9N for sipping@optimus.ietf.org; Fri, 01 Aug 2003 02:57:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10810 for ; Fri, 1 Aug 2003 02:57:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iTql-0002tG-00 for sipping@ietf.org; Fri, 01 Aug 2003 02:57:15 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19iTql-0002tA-00 for sipping@ietf.org; Fri, 01 Aug 2003 02:57:15 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sipping@ietf.org; Fri, 1 Aug 2003 08:56:45 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Aug 2003 08:56:45 +0200 Message-Id: From: "Beck01, Wolfgang" To: sipping@ietf.org Subject: [Sipping] smartcards and SIP, was: FYI: RADIUS & SIP Date: Fri, 1 Aug 2003 08:56:43 +0200 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: , Henning Schulzrinne [mailto:hgs@cs.columbia.edu] wrote: > Also, while SIM cards work ok when kept in the cell phone, the existing > card mechanics don't seem to work well if you want to, say, quickly use > the phone in the meeting room. Would you need to remove and insert the > SIM card each time? "Oops, I left the card in my office phone, I can't > make a call from home right now." "Oops, i forgot to remove my home identity from my office phone. Now my co-worker will be disturbed by aunt Hillary's phone calls." Seriously, there are problems with smartcards: you will need to have one for every phone you want to use in parallel. The usage is different, too. A cell phone is a personal item and there is no need to change SIM cards frequently. If people 'personalize' stationary SIP phones, this would be different. In this case, a credit card sized SIM card would be better than the thumbnail-sized variety. With WiFi SIP phones, the need to change SIM cars would go away. There are problems with soft clients, too. Some companies are using smartcards instead of login passwords. How many smartcard readers fit into a laptop? -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 1 03:17:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01169 for ; Fri, 1 Aug 2003 03:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUA2-0003tq-Ek for sipping-archive@odin.ietf.org; Fri, 01 Aug 2003 03:17:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h717HAqa014984 for sipping-archive@odin.ietf.org; Fri, 1 Aug 2003 03:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUA1-0003tb-3k for sipping-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 03:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01111 for ; Fri, 1 Aug 2003 03:17:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iU9y-000319-00 for sipping-web-archive@ietf.org; Fri, 01 Aug 2003 03:17:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iU9x-000316-00 for sipping-web-archive@ietf.org; Fri, 01 Aug 2003 03:17:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iU9u-0003sh-0S; Fri, 01 Aug 2003 03:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iU9o-0003sG-SQ for sipping@optimus.ietf.org; Fri, 01 Aug 2003 03:16:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01086 for ; Fri, 1 Aug 2003 03:16:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iU9m-00030b-00 for sipping@ietf.org; Fri, 01 Aug 2003 03:16:54 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19iU9l-0002zX-00 for sipping@ietf.org; Fri, 01 Aug 2003 03:16:53 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sipping@ietf.org; Fri, 1 Aug 2003 09:16:19 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Aug 2003 09:16:19 +0200 Message-Id: From: "Beck01, Wolfgang" To: sipping@ietf.org Date: Fri, 1 Aug 2003 09:16:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] smartcards and SIP, was: FYI: RADIUS & SIP 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: , Michael, you wrote: > The way GSM authentication works is that the Authentication Center produces > "triplets" (tuples of precomputed challenge, matching response and session > key) for a given IMSI. I've been told that getting IMSIs without having a GSM account is not that easy. There seem to be regulatory issues and political pressure from mobile operators, at least in some European countries. Do you know details about this? -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 1 10:18:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24115 for ; Fri, 1 Aug 2003 10:18:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iajQ-0005R5-5l for sipping-archive@odin.ietf.org; Fri, 01 Aug 2003 10:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71EI8wu020891 for sipping-archive@odin.ietf.org; Fri, 1 Aug 2003 10:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iajQ-0005Qs-2T for sipping-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 10:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24102 for ; Fri, 1 Aug 2003 10:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iajN-0002oW-00 for sipping-web-archive@ietf.org; Fri, 01 Aug 2003 10:18:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iajN-0002oT-00 for sipping-web-archive@ietf.org; Fri, 01 Aug 2003 10:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iajJ-0005Pk-BJ; Fri, 01 Aug 2003 10:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iajD-0005PR-F3 for sipping@optimus.ietf.org; Fri, 01 Aug 2003 10:17:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24091 for ; Fri, 1 Aug 2003 10:17:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iajB-0002oE-00 for sipping@ietf.org; Fri, 01 Aug 2003 10:17:53 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iajA-0002nv-00 for sipping@ietf.org; Fri, 01 Aug 2003 10:17:52 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h71EHKLH018519; Fri, 1 Aug 2003 07:17:20 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-140.cisco.com [64.100.229.140]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJD36654; Fri, 1 Aug 2003 07:17:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030801101031.00b37110@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Aug 2003 10:17:19 -0400 To: "Beck01, Wolfgang" From: Michael Hammer Subject: Re: [Sipping] smartcards and SIP, was: FYI: RADIUS & SIP Cc: sipping@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3428219==_.ALT" 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: , --=====================_3428219==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed For what it's worth: A number of U.S. Federal Agencies are issuing smart-cards for authentication of users on PCs and similar devices. For some (i.e. military ID-smart-cards) there are serious consequences if they leave that lying around. Smart card readers can connect through USB ports. GSM triplets: this may be outdated technology. Try quintuplets. Mike At 08:56 AM 8/1/2003 +0200, Beck01, Wolfgang wrote: >Henning Schulzrinne [mailto:hgs@cs.columbia.edu] wrote: > > Also, while SIM cards work ok when kept in the cell phone, the existing > > card mechanics don't seem to work well if you want to, say, quickly use > > the phone in the meeting room. Would you need to remove and insert the > > SIM card each time? "Oops, I left the card in my office phone, I can't > > make a call from home right now." >"Oops, i forgot to remove my home identity from my office phone. Now my >co-worker will be disturbed by aunt Hillary's phone calls." > >Seriously, there are problems with smartcards: you will need to have one >for every phone you want to use in parallel. The usage is different, too. >A cell phone is a personal item and there is no need to change SIM cards >frequently. If people 'personalize' stationary SIP phones, this would be >different. In this case, a credit card sized SIM card would be better >than the thumbnail-sized variety. With WiFi SIP phones, the need to >change SIM cars would go away. > >There are problems with soft clients, too. Some companies are using >smartcards instead of login passwords. How many smartcard readers >fit into a laptop? > >-- >Wolfgang Beck >T-Systems Nova GmbH > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP --=====================_3428219==_.ALT Content-Type: text/html; charset="us-ascii" For what it's worth:

A number of U.S. Federal Agencies are issuing smart-cards for authentication of users on PCs and similar devices.  For some (i.e. military ID-smart-cards) there are serious consequences if they leave that lying around.

Smart card readers can connect through USB ports.

GSM triplets: this may be outdated technology.  Try quintuplets.

Mike

At 08:56 AM 8/1/2003 +0200, Beck01, Wolfgang wrote:


Henning Schulzrinne [mailto:hgs@cs.columbia.edu] wrote:
> Also, while SIM cards work ok when kept in the cell phone, the existing
> card mechanics don't seem to work well if you want to, say, quickly use
> the phone in the meeting room. Would you need to remove and insert the
> SIM card each time? "Oops, I left the card in my office phone, I can't
> make a call from home right now."
"Oops, i forgot to remove my home identity from my office phone. Now my
co-worker will be disturbed by aunt Hillary's phone calls."

Seriously, there are problems with smartcards: you will need to have one
for every phone you want to use in parallel. The usage is different, too.
A cell phone is a personal item and there is no need to change SIM cards
frequently. If people 'personalize' stationary SIP phones, this would be
different. In this case, a credit card sized SIM card would be better
than the thumbnail-sized variety. With WiFi SIP phones, the need to
change SIM cars would go away.

There are problems with soft clients, too. Some companies are using
smartcards instead of login passwords. How many smartcard readers
fit into a laptop?

--
Wolfgang Beck
T-Systems Nova GmbH

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
--=====================_3428219==_.ALT-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Sat Aug 2 08:05:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12143 for ; Sat, 2 Aug 2003 08:05:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iv8L-0007Gc-Up for sipping-archive@odin.ietf.org; Sat, 02 Aug 2003 08:05:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h72C5DTG027928 for sipping-archive@odin.ietf.org; Sat, 2 Aug 2003 08:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iv8L-0007GN-Ri for sipping-web-archive@optimus.ietf.org; Sat, 02 Aug 2003 08:05:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12132 for ; Sat, 2 Aug 2003 08:05:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iv8K-0003Ap-00 for sipping-web-archive@ietf.org; Sat, 02 Aug 2003 08:05:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iv8K-0003Al-00 for sipping-web-archive@ietf.org; Sat, 02 Aug 2003 08:05:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iv89-0007FJ-Ll; Sat, 02 Aug 2003 08:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iv7L-0007CL-TA for sipping@optimus.ietf.org; Sat, 02 Aug 2003 08:04:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12122 for ; Sat, 2 Aug 2003 08:04:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iv7K-0003Ab-00 for sipping@ietf.org; Sat, 02 Aug 2003 08:04:10 -0400 Received: from natsmtp01.webmailer.de ([192.67.198.81] helo=post.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 19iv7K-0003AY-00 for sipping@ietf.org; Sat, 02 Aug 2003 08:04:10 -0400 Received: from discofox (pD9E6BE17.dip.t-dialin.net [217.230.190.23]) by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h72C485O025641 for ; Sat, 2 Aug 2003 14:04:08 +0200 (MEST) From: "Christian Stredicke" To: Date: Sat, 2 Aug 2003 14:04:19 +0200 Message-ID: <001601c358ee$34a95840$1e02a8c0@discofox> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sipping] Late Media 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 prepared a document on "Late Media". It provides a (as I think) cool way to finish a call like in the James Bond films (video) and allows tones known from good old PSTN. Please take a look at http://www.snom.com/draft-stredicke-late-media-00.txt and let me know what you think. Christian P.S. Maybe someone can tell me how to publish this document properly? -- Christian Stredicke sip:christian@stredicke.de _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Sun Aug 3 13:21:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22368 for ; Sun, 3 Aug 2003 13:21:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jMXu-0002fV-GY for sipping-archive@odin.ietf.org; Sun, 03 Aug 2003 13:21:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h73HLQTL010253 for sipping-archive@odin.ietf.org; Sun, 3 Aug 2003 13:21:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jMXu-0002fI-Du for sipping-web-archive@optimus.ietf.org; Sun, 03 Aug 2003 13:21:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22359 for ; Sun, 3 Aug 2003 13:21:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jMXs-0002uq-00 for sipping-web-archive@ietf.org; Sun, 03 Aug 2003 13:21:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jMXr-0002um-00 for sipping-web-archive@ietf.org; Sun, 03 Aug 2003 13:21:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jMXU-0002eK-UF; Sun, 03 Aug 2003 13:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jMX9-0002e2-79 for sipping@optimus.ietf.org; Sun, 03 Aug 2003 13:20:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22352 for ; Sun, 3 Aug 2003 13:20:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jMX7-0002ui-00 for sipping@ietf.org; Sun, 03 Aug 2003 13:20:37 -0400 Received: from web10901.mail.yahoo.com ([216.136.131.37]) by ietf-mx with smtp (Exim 4.12) id 19jMX6-0002uf-00 for sipping@ietf.org; Sun, 03 Aug 2003 13:20:36 -0400 Message-ID: <20030803172034.43720.qmail@web10901.mail.yahoo.com> Received: from [24.211.179.114] by web10901.mail.yahoo.com via HTTP; Sun, 03 Aug 2003 10:20:34 PDT Date: Sun, 3 Aug 2003 10:20:34 -0700 (PDT) From: "g.jayadevan \(Yahoo!\)" Subject: RE: [Sipping] Re: Update to 3pcc - corrected To: sipping@ietf.org 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: , Here's my take the e2e vs. a centralized model. When considering best practices, I prefer to think in term of building blocks. The c-t-d is only one application of the 3pcc model. If we took the REFER approach, it becomes a point solution applicable well only to a single 3pcc call. The 3pcc model can be generalized to many call legs allowing a whole class of application that require these manipulations to be built. Should we build efficient point solutions or a generalized service layer that will allow me to reuse capability? Imagine from one customer service agent, I will like to xfer the call to another. And possibly add a supervisor. Seems to me that all the phones at the call center will have to have intelligent applications loaded to perform these nifty manipulations. Reliability of the controller approach can be made up in other ways. The controller itself can be made reliable by a distibuted protocols such as persisting call information, and adding protocol fault tolerance via SCTP or a distributive proxy. In the 3GPP world, a model borrowed from the IN world, an application server is a key player. e2e is a great concept, but I prefer not to architect solution in order to adhere to the principle when it does not buy me convenience of deployment. Like others have pointed out billing issues get confusing. And the controller must be thought of as being an end player too. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.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 exim@www1.ietf.org Mon Aug 4 05:44:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20726 for ; Mon, 4 Aug 2003 05:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jbsz-0000QB-49 for sipping-archive@odin.ietf.org; Mon, 04 Aug 2003 05:44:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h749iDF8001615 for sipping-archive@odin.ietf.org; Mon, 4 Aug 2003 05:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jbsz-0000Py-0W for sipping-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 05:44:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20721 for ; Mon, 4 Aug 2003 05:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jbsv-0007T6-00 for sipping-web-archive@ietf.org; Mon, 04 Aug 2003 05:44:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jbsu-0007T3-00 for sipping-web-archive@ietf.org; Mon, 04 Aug 2003 05:44:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jbsn-0000Oy-Io; Mon, 04 Aug 2003 05:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jbsg-0000OA-0y for sipping@optimus.ietf.org; Mon, 04 Aug 2003 05:43:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20715 for ; Mon, 4 Aug 2003 05:43:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jbsc-0007So-00 for sipping@ietf.org; Mon, 04 Aug 2003 05:43:50 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19jbsb-0007Sk-00 for sipping@ietf.org; Mon, 04 Aug 2003 05:43:49 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 4 Aug 2003 10:46:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35A6C.E5511E87" Date: Mon, 4 Aug 2003 10:43:44 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219B065@gbnewp0758m.eu.ubiquity.net> Thread-Topic: draft-melanchuk-sipping-msml-00.txt Thread-Index: AcNabOSLStaSuUIwSXiyi6l//HMV9Q== From: "Chris Boulton" To: "Garland Sharratt" , Cc: Subject: [Sipping] draft-melanchuk-sipping-msml-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: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35A6C.E5511E87 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Garland,Tim, =20 I finally had the opportunity to review the draft 'draft-melanchuk-sipping-msml-00.txt' - very impressive. This certainly seems a flexible and powerful approach to media server control in conjunction with 'draft-melanchuk-sipping-moml-00.txt'. Please find enclosed a couple of questions raised during my review as well as a couple of minor 'nits'. =20 Questions =20 - Would any benefit be gained from including an optional 'order' attribute on primitive elements so that when 'pipe' is used, the order is determined explicitly rather than following a logical path? =20 - Was there a reason that JOIN/UNJOIN were limited to id1 + id2. Could it not have just been id, that was forced to appear at least twice? This would allow you to join >2 media streams in one transaction. =20 - element should say that the response code corresponds to the SIP response code received for the transaction. =20 - P17 - Media objects may be defined using MOML or other suitable media=20 resource description languages. A media server which supports=20 and must support MOML and may support other=20 languages. Those languages must support the ability to identify the=20 left hand and right hand streams of full duplex objects. Should this be a 'MUST' or is it not possible to only use another 'suitable media resource description language' with MSML? =20 Nits =20 From Abstract:- Clients can use it define how media sessions interact on a media server and to apply services to individual or groups of users. Should read:- Clients can use it to define how media sessions interact on a media server and to apply services to individual or groups of users. =20 2.2 reads:- Future references to that object must use that name in a structured format as defined below. Should:- Make reference to explicit section/table. =20 2.2 reads:- Terms may be either an object class or an object class followed by a colon ':' followed by qualifier which identifies an object within the class. Should read:- Terms may be either an object class or an object class followed by a colon ':', followed by a qualifier which identifies an object within the class. =20 2.2 reads:- Dialogs contexts, and object instances of application defined classes, have identifiers relative to a connection or conference. Should read:- Dialog contexts, and object instances of application defined classes, have identifiers relative to a connection or conference. =20 4.0 reads:- Transaction results are returned as part of the SIP request response. Should read:- Transaction results are returned as part of the SIP request/response model. =20 The Document Footer reads:- Media Sessions Markup Language (MOML) Should read:- Media Sessions Markup Language (MSML) =20 5.8 - The example does not have an id attribute BUT it is mandatory. =20 A number of MAY, MUST etc have not been capitalised throughout the document e.g. section 5.9.=20 =20 =20 HTH, =20 Best Regards, =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 ------_=_NextPart_001_01C35A6C.E5511E87 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Garland,Tim,

 

I finally had the opportunity to review the draft = ‘draft-melanchuk-sipping-msml-00.txt’ – very impressive. This certainly seems a flexible and powerful = approach to media server control in conjunction with = ‘draft-melanchuk-sipping-moml-00.txt’.  Please find enclosed a couple = of questions raised during my review as well as a couple of minor = ‘nits’.

 

Ques= tions

 

- Would any benefit be = gained from including an optional ‘order’ attribute on primitive = elements so that when ‘pipe’ is used, the order is determined = explicitly rather than following a logical path?

 

- Was there a reason = that JOIN/UNJOIN were limited to id1 + id2.  Could it not have just been id, that = was forced to appear at least twice?  = This would allow you to join >2 media streams in one = transaction.

 

- <result> = element should say that the response code corresponds to the SIP response code = received for the transaction.

 

- P17 - Media objects = may be defined using MOML or other suitable media

   resource description languages. A media server which supports =

   <insert> and <remove> must support MOML and may support other =

   languages. Those languages must support the ability to identify the =

   left hand and right hand streams of full duplex = objects.

Should this be a ‘MUST’ or is it not possible to only use another = ‘suitable media resource description language’ with = MSML?

 

Nits=

 

From = Abstract:-

Clients can use it = define how media sessions interact on a media server and to apply services to = individual or groups of users.

Should = read:-

Clients can use it to = define how media sessions interact on a media server and to apply services to individual or groups of users.

 

2.2 = reads:-

Future references to = that object must use that name in a structured format as defined = below.

Should:-

Make reference to = explicit section/table.

 

2.2 = reads:-

Terms may be either an = object class or an object class followed by a colon ':' followed by qualifier = which identifies an object within the class.

Should = read:-

Terms may be either an = object class or an object class followed by a colon ':', followed by a = qualifier which identifies an object within the class.

 

2.2 = reads:-

Dialogs contexts, and = object instances of application defined classes, have identifiers relative to a connection or conference.

Should = read:-

Dialog contexts, and = object instances of application defined classes, have identifiers relative to a = connection or conference.

 

4.0 = reads:-

Transaction results = are returned as part of the SIP request = response.

Should = read:-

Transaction results = are returned as part of the SIP request/response = model.

 

The Document Footer = reads:-

Media Sessions Markup Language = (MOML)

Should = read:-

Media Sessions Markup Language = (MSML)

 

5.8 – The = <dialogend> example does not have an id = attribute BUT it is mandatory.

 

A number of MAY, MUST = etc have not been capitalised throughout the document e.g. section 5.9. =

 

 

HTH,

 

Best Regards,

 

Chris.

 

 

------------------------------------------------

Chris Boulton=

Ubiquity = Software

 =

Tel : +44 = (0) 1633765600

Fax : +44 = (0) 1633765601

------------------------------------------------=

 

 

=00 ------_=_NextPart_001_01C35A6C.E5511E87-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Mon Aug 4 05:58:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20977 for ; Mon, 4 Aug 2003 05:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jc6P-0000p0-CI for sipping-archive@odin.ietf.org; Mon, 04 Aug 2003 05:58:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h749w5rt003156 for sipping-archive@odin.ietf.org; Mon, 4 Aug 2003 05:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jc6P-0000op-72 for sipping-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 05:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20971 for ; Mon, 4 Aug 2003 05:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jc6L-0007ab-00 for sipping-web-archive@ietf.org; Mon, 04 Aug 2003 05:58:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jc6L-0007aY-00 for sipping-web-archive@ietf.org; Mon, 04 Aug 2003 05:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jc6L-0000nu-3v; Mon, 04 Aug 2003 05:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jc5t-0000nF-HW for sipping@optimus.ietf.org; Mon, 04 Aug 2003 05:57:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20967 for ; Mon, 4 Aug 2003 05:57:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jc5p-0007aL-00 for sipping@ietf.org; Mon, 04 Aug 2003 05:57:29 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19jc5p-0007aI-00 for sipping@ietf.org; Mon, 04 Aug 2003 05:57:29 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 4 Aug 2003 11:00:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35A6E.CE9BE3CA" Date: Mon, 4 Aug 2003 10:57:25 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219B066@gbnewp0758m.eu.ubiquity.net> Thread-Topic: draft-melanchuk-sipping-moml-00.txt Thread-Index: AcNabs25uQEysWFISQiYvKC7A7aLwg== From: "Chris Boulton" To: "Garland Sharratt" , Cc: Subject: [Sipping] draft-melanchuk-sipping-moml-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: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35A6E.CE9BE3CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Garland, Tim, =20 Just a follow-up mail regarding some questions/nits from this draft. Again, seems extremely flexible. Hope the comments are productive. =20 Questions =20 - Is there an alternative method for defining unlimited occurrences using the 'max' attribute =3D 0 (e.g. pattern element uses max within = DTMF primitive). This seemed a little confusing. =20 - 4.5.1.1 The description of and needs to be made more explicit.=20 =20 Nits =20 Use of lower case for may and must not on p7, p8, p15. =20 4.6 reads:- Gain is used to adjust of the gain of a media stream by a specific amount. =20 Should read:- The child element is used to adjust the gain of a media stream by a specific amount. =20 =20 =20 Best Regards, =20 Chris. =20 =20 ------------------------------------------------ Chris Boulton Ubiquity Software =20 Tel : +44 (0) 1633765600 Fax : +44 (0) 1633765601=20 ------------------------------------------------ =20 =20 ------_=_NextPart_001_01C35A6E.CE9BE3CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Garland, Tim,

 

Just a follow-up mail = regarding some questions/nits from this draft.  Again, seems extremely = flexible.  Hope the comments are = productive.

 

Ques= tions

 

- Is there an = alternative method for defining unlimited occurrences using the ‘max’ = attribute =3D 0 (e.g. pattern element uses max within DTMF primitive).  This seemed a little = confusing.

 

- 4.5.1.1 The = description of <tvoice> and <tsilence> needs to be made more explicit.

 

Nits=

 

Use of lower case for = may and must not on p7, p8, p15.

 

4.6 = reads:-

Gain is used to adjust = of the gain of a media stream by a specific amount. 

Should = read:-

The <gain> child element is used to adjust the gain of a media stream by a specific = amount. 

 

 

Best Regards,

 

Chris.

 

 

------------------------------------------------

Chris Boulton=

Ubiquity = Software

 =

Tel : +44 = (0) 1633765600

Fax : +44 = (0) 1633765601

------------------------------------------------=

 

 

=00 ------_=_NextPart_001_01C35A6E.CE9BE3CA-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Mon Aug 4 11:32:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01603 for ; Mon, 4 Aug 2003 11:32:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhJk-0001v4-Jk for sipping-archive@odin.ietf.org; Mon, 04 Aug 2003 11:32:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74FWCTZ007374 for sipping-archive@odin.ietf.org; Mon, 4 Aug 2003 11:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhJk-0001ur-Gl for sipping-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 11:32:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01562 for ; Mon, 4 Aug 2003 11:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jhJj-0002wg-00 for sipping-web-archive@ietf.org; Mon, 04 Aug 2003 11:32:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jhJj-0002wd-00 for sipping-web-archive@ietf.org; Mon, 04 Aug 2003 11:32:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhJZ-0001rY-Og; Mon, 04 Aug 2003 11:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhIu-0001qM-EJ for sipping@optimus.ietf.org; Mon, 04 Aug 2003 11:31:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01504 for ; Mon, 4 Aug 2003 11:31:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jhF6-0002uD-00 for sipping@ietf.org; Mon, 04 Aug 2003 11:27:24 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19jhF5-0002u6-00 for sipping@ietf.org; Mon, 04 Aug 2003 11:27:23 -0400 Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJ300434PDNIX@firewall.wcom.com> for sipping@ietf.org; Mon, 04 Aug 2003 15:22:35 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJ300301PDIYY@pmismtp06.wcomnet.com>; Mon, 04 Aug 2003 15:22:35 +0000 (GMT) Received: from hsinnreich2 ([166.50.136.29]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJ300352PDKNR@pmismtp06.wcomnet.com>; Mon, 04 Aug 2003 15:22:33 +0000 (GMT) Date: Mon, 04 Aug 2003 10:22:31 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: Update to 3pcc - corrected In-reply-to: <20030803172034.43720.qmail@web10901.mail.yahoo.com> To: "'g.jayadevan (Yahoo!)'" , sipping@ietf.org Message-id: <0HJ300353PDKNR@pmismtp06.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNZ495jMvpALYp5Q/mLDSXBeKLYtwAt3lhg 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 > e2e is a great concept, but I prefer not to > architect solution in order to adhere to the > principle when it does not buy me convenience > of deployment. Think of the example of one or more ISP's in the path of a call from an enterprise local SIP outgoing proxy to a call center with complex services at both ends that the ISP's need not necessarily understand. This is clearly a case where only the e2e service model will work. Inserting a B2BUA in the middle would break any usefulness to the caller and basically make the user avoid the offending ISP. Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > g.jayadevan (Yahoo!) > Sent: Sunday, August 03, 2003 12:21 PM > To: sipping@ietf.org > Subject: RE: [Sipping] Re: Update to 3pcc - corrected > > Here's my take the e2e vs. a centralized model. > > When considering best practices, I prefer to think > in term of building blocks. The c-t-d is only one > application of the 3pcc model. If we took the > REFER approach, it becomes a point solution > applicable well only to a single 3pcc call. > The 3pcc model can be generalized to many > call legs allowing a whole class of application > that require these manipulations to be built. Should > we build efficient point solutions or a generalized > service layer that will allow me to reuse > capability? > > Imagine from one customer service agent, I will > like to xfer the call to another. And possibly > add a supervisor. Seems to me that all the phones > at the call center will have to have intelligent > applications loaded to perform these nifty > manipulations. > > Reliability of the controller approach can be made > up in other ways. The controller itself can be > made reliable by a distibuted protocols such as > persisting call information, and adding protocol > fault tolerance via SCTP or a distributive proxy. > In the 3GPP world, a model borrowed from the > IN world, an application server is a key player. > > e2e is a great concept, but I prefer not to > architect solution in order to adhere to the > principle when it does not buy me convenience > of deployment. Like others have pointed out > billing issues get confusing. > > And the controller must be thought of as being an > end player too. > > > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.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 exim@www1.ietf.org Tue Aug 5 12:46:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18478 for ; Tue, 5 Aug 2003 12:46:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4ww-0006o0-7g for sipping-archive@odin.ietf.org; Tue, 05 Aug 2003 12:46:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75GkEqS026147 for sipping-archive@odin.ietf.org; Tue, 5 Aug 2003 12:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4ww-0006nb-0J for sipping-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 12:46:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18444 for ; Tue, 5 Aug 2003 12:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k4wu-0003jh-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 12:46:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k4wt-0003jX-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 12:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4wl-0006kR-Gs; Tue, 05 Aug 2003 12:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4wT-0006jJ-CP for sipping@optimus.ietf.org; Tue, 05 Aug 2003 12:45:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18410 for ; Tue, 5 Aug 2003 12:45:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k4wR-0003in-00 for sipping@ietf.org; Tue, 05 Aug 2003 12:45:43 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19k4wQ-0003ii-00 for sipping@ietf.org; Tue, 05 Aug 2003 12:45:42 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id C66513C01; Tue, 5 Aug 2003 18:40:29 +0200 (CEST) Received: from jku07.fokus.fraunhofer.de (dhcp114.fokus.fraunhofer.de [195.37.78.114]) by fox.iptel.org (Postfix) with ESMTP id EB5695B0; Tue, 5 Aug 2003 18:40:28 +0200 (CEST) Message-Id: <5.2.0.9.0.20030805181322.033fa668@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 05 Aug 2003 18:37:32 +0200 To: "g.jayadevan (Yahoo!)" , sipping@ietf.org From: Jiri Kuthan Subject: RE: [Sipping] Re: Update to 3pcc - corrected In-Reply-To: <20030803172034.43720.qmail@web10901.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , At 07:20 PM 8/3/2003, g.jayadevan \(Yahoo!\) wrote: >Here's my take the e2e vs. a centralized model. > >When considering best practices, I prefer to think >in term of building blocks. The c-t-d is only one >application of the 3pcc model. If we took the >REFER approach, it becomes a point solution >applicable well only to a single 3pcc call. >The 3pcc model can be generalized to many >call legs allowing a whole class of application >that require these manipulations to be built. Should >we build efficient point solutions or a generalized >service layer that will allow me to reuse >capability? If we should propose "BCP" tools for a generalized service layer, than we need to make a case. I don't think we make a case with an example which can be better solved other way. >Imagine from one customer service agent, I will >like to xfer the call to another. And possibly >add a supervisor. Seems to me that all the phones >at the call center will have to have intelligent >applications loaded to perform these nifty >manipulations. Well, phones that don't support call transfer/REFER should be better junked than used in architectural discussions. >Reliability of the controller approach can be made >up in other ways. The controller itself can be >made reliable by a distibuted protocols such as >persisting call information, and adding protocol >fault tolerance via SCTP or a distributive proxy. >In the 3GPP world, a model borrowed from the >IN world, an application server is a key player. > >e2e is a great concept, but I prefer not to >architect solution in order to adhere to the >principle when it does not buy me convenience >of deployment. As you might have read previously: REFER is more convenient than b2bua -- so we don't need to open a religious discussion about convenience versus principles. To refresh your mind: there is fair difference in complexity, interoperability and user experience. >Like others have pointed out billing issues get confusing. I still have not seen a problem description, so it is hard to comment. >And the controller must be thought of as being an >end player too. I have no opinion on this statement since I don't understand it. -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 exim@www1.ietf.org Tue Aug 5 12:46:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18479 for ; Tue, 5 Aug 2003 12:46:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4ww-0006oG-Aa for sipping-archive@odin.ietf.org; Tue, 05 Aug 2003 12:46:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75GkEmG026170 for sipping-archive@odin.ietf.org; Tue, 5 Aug 2003 12:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4ww-0006nw-69 for sipping-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 12:46:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18448 for ; Tue, 5 Aug 2003 12:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k4wu-0003jc-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 12:46:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k4ws-0003jU-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 12:46:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4wm-0006lH-C4; Tue, 05 Aug 2003 12:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4wT-0006jO-EA for sipping@optimus.ietf.org; Tue, 05 Aug 2003 12:45:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18418 for ; Tue, 5 Aug 2003 12:45:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k4wR-0003is-00 for sipping@ietf.org; Tue, 05 Aug 2003 12:45:43 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19k4wQ-0003ik-00 for sipping@ietf.org; Tue, 05 Aug 2003 12:45:42 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id E79555B0; Tue, 5 Aug 2003 18:40:29 +0200 (CEST) Received: from jku07.fokus.fraunhofer.de (dhcp114.fokus.fraunhofer.de [195.37.78.114]) by fox.iptel.org (Postfix) with ESMTP id 3C955D85; Tue, 5 Aug 2003 18:40:28 +0200 (CEST) Message-Id: <5.2.0.9.0.20030805180020.033c5e80@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 05 Aug 2003 18:39:22 +0200 To: David Schwartz , "'sipping@ietf.org'" From: Jiri Kuthan Subject: Re: [Sipping] Re: Update to 3pcc In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.5 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , Hello David, I don't see how billing servers are related to method of call initiation. Actually I believe that how a call is initiated (by manual dialing a destination, by REFER-based click-to-dial, by b2bua-based click-to-dial, CTI, etc.) is completely orthogonal to how the call is charged for. Regardless what charging system you use (if any), there will be different methods for initiating calls, some will be better off than others. I maintain that a click-to-dial b2bua is not a BCP. -jiri At 10:10 AM 7/30/2003, David Schwartz wrote: >Hi Jiri > >REFER is good solution if you assume that either there are no billing >issues, or alternatively, that the endpoint/s handle the billing issues. If >this is not the case, for example, in an application where a centralized >controller is setting up a call to two PSTN numbers, then you will need a >centralized billing entity and REFER will not suffice. > >David > >-----Original Message----- >From: sipping-request@ietf.org [mailto:sipping-request@ietf.org] >Sent: Mon, July 28, 2003 7:00 PM >To: sipping@ietf.org >Subject: Sipping digest, Vol 1 #1144 - 2 msgs > > >Send Sipping mailing list submissions to > sipping@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/sipping >or, via email, send a message with subject or body 'help' to > sipping-request@ietf.org > >You can reach the person managing the list at > sipping-admin@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Sipping digest..." > > >Today's Topics: > > 1. Re: Diversion header (Cullen Jennings) > 2. Re: Update to 3pcc (Jiri Kuthan) > >--__--__-- > >Message: 1 >Date: Sun, 27 Jul 2003 19:05:10 -0700 >Subject: Re: [Sipping] Diversion header >From: Cullen Jennings >To: Romel Khan , > > >I assume your question is there some way for for the final destination that >receives the call to know the who the 1st callee was that had some device in >the network redirect the call elsewhere. > >The answer is YES - there has been a lot of confusion over this so think >about my answer carefully - it will seem counter intuitive at first. The >answer is the "To" header but it will take me a second to explain why. > >Imagine case 1 where A send a call to proxy B, that sent to to C. Now C >sent a 302 back B and B then forked the call to D. The To header in the >message D receives will still have the To set to C. C is the element that >sent the first 302. > >Now imagine a case (like your question) where there is not a recursive >proxy. The 302 will go all the way back to A. Now A forms a new invite to >but it can leave the To header set to the same thing it was in the original >message (C in this case). When the message arrives at D, the To header will >be set to C. > >If D was a voice mail system, it might be able to know to act on behalf of C >instead of some other entity. > >There are more complex things that relate to your request. Mary Barnes has >been moving the history work along >http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-04.txt > >There is some work on QSIG mappings with diversion >http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-diversion- >00.txt > >There is a draft-levy-sip-diversion which I (and many others) believe has a >pretty much zero chance of being accepted or becoming a RFC. This work has >been superceded by the history work. Quite a few people do not support the >history work and it is moving very slowly. Don't expect any of this to >resolve quickly. > >Give some careful thought to if the "To" header meets your needs and if it >does use - The To header is widely implemented :-) > > >Cullen > > > > >On 7/21/03 8:55, "Romel Khan" wrote: > >> Is there any SIP header defined in any SIP RFC or Internet Draft that can >> include the address of the 1st callee, who redirected the call using 302, >in >> the 2nd outgoing INVITE? >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > > >--__--__-- > >Message: 2 >Date: Mon, 28 Jul 2003 10:17:51 +0200 >To: Jonathan Rosenberg , sipping >From: Jiri Kuthan >Subject: Re: [Sipping] Update to 3pcc > >I'm actually not convinced that it is proper to show click-to-dial >as a motivating example for use of b2bua and label it BCP. > >Use of REFER seems technically a superior solution worth being called >BCP. Roots of the advantages are in a better application of e2e principle. >REFER takes no middle-box b2bua -- it delegates signaling to end-points. >Advantages include: >- All the pitfalls with media are so straigforward, they don't even > need to be described (like now in sessions 8 and 9). >- It takes no media server to transmit ringing tone. >- There are no SDP compatibility issues on controller's side. > >-jiri > >At 07:51 PM 7/8/2003, Jonathan Rosenberg wrote: >>Folks, >> >>You may have noticed that I posted an update to the 3pcc spec: >> >>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.txt >>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.html >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.txt >> >>The update is based on comments received from IESG while reviewing the >draft. In particular, there were problems with the usage of 0.0.0.0 to >imply that no media nor RTCP should be sent. This IP address is not meant >for that purpose. Rather, the .invalid TLD is much better suited. So, I >changed the draft to make use of .invalid in flows where the controller >doesnt want media to be sent. >> >>Now, there are some concerns with that which folks need to be aware of: >> >>1. It is at odds with RFC 3264, which actually recommends 0.0.0.0. In fact, >the problem is really with RFC 3264, NOT 3pcc. However, 3264 is done, and >this one isnt. I logged a bug against RFC 3264 on this, and we'll need to >work on a way to transition folks towards using .invalid and not 0.0.0.0. >> >>2. One the premises of 3pcc is that it should be compatible with any UA >that is RFC 3261 compliant. If a controller uses .invalid in the SDP, I am >not sure what a SIP endpoint would do. I don't believe anything in RFC 3264 >or in SIP talks about handling the case where there is an issue with a >domain name in the SDP. As such, if you use .invalid, there could be interop >problems. The document mentions this. >> >>Comments or questions welcome. >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>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 > >-- >Jiri Kuthan http://iptel.org/~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 > >End of Sipping Digest > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the 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 exim@www1.ietf.org Tue Aug 5 12:46:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18508 for ; Tue, 5 Aug 2003 12:46:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4ww-0006o1-7w for sipping-archive@odin.ietf.org; Tue, 05 Aug 2003 12:46:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75GkEX1026148 for sipping-archive@odin.ietf.org; Tue, 5 Aug 2003 12:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4wv-0006nZ-U2 for sipping-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 12:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18442 for ; Tue, 5 Aug 2003 12:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k4wu-0003ji-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 12:46:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k4wt-0003jV-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 12:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4wk-0006kH-P1; Tue, 05 Aug 2003 12:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4wT-0006jI-7j for sipping@optimus.ietf.org; Tue, 05 Aug 2003 12:45:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18412 for ; Tue, 5 Aug 2003 12:45:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k4wR-0003ij-00 for sipping@ietf.org; Tue, 05 Aug 2003 12:45:43 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19k4wP-0003iZ-00 for sipping@ietf.org; Tue, 05 Aug 2003 12:45:41 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 8D504D9F; Tue, 5 Aug 2003 18:40:28 +0200 (CEST) Received: from jku07.fokus.fraunhofer.de (dhcp114.fokus.fraunhofer.de [195.37.78.114]) by fox.iptel.org (Postfix) with ESMTP id AA7CE5B0; Tue, 5 Aug 2003 18:40:27 +0200 (CEST) Message-Id: <5.2.0.9.0.20030805175935.02b72d00@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 05 Aug 2003 18:00:08 +0200 To: Jonathan Rosenberg , Bernard Aboba From: Jiri Kuthan Subject: Re: AW: [Sipping] FYI: RADIUS & SIP Cc: "Liess, Laura" , hgs@cs.columbia.edu, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" In-Reply-To: <3F26B925.1010306@dynamicsoft.com> References: <43240544763FB8479F1529372F6197CF053CC8CD@G8PQC.blf01.telekom.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , Thanks, I very much agree; we have received identical feedback so far. -jiri At 08:12 PM 7/29/2003, Jonathan Rosenberg wrote: >I know of several carriers with RADIUS infrastructures that want to use them to support SIP. They are currently using expired I-Ds and proprietary attributes. As a result, I would strongly advocate work on standardizing RADIUS usage with SIP. > >There are two areas of work that I see a need for: > >1. Digest authentication. The sterman draft (http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-sip-00.txt) is used quite a bit, it seems. It would be nice to standardize on this. > >2. Prepaid calling. Many folks are using vendor proprietary radius extensiosn to support prepaid calling. It would be nice to bring those forward and standardize on them. > >-Jonathan R. > >Bernard Aboba wrote: > >>Is there some particular set of draft(s) that you are advocating work on? >>On Fri, 18 Jul 2003, Liess, Laura wrote: >> >>>I think most carriers currently use some kind of RADIUS platform to do user authentication and they would like to reuse it in the future to authenticate their SIP customers. >>>My colleagues who are responsible for the RADIUS Platform of the Deutsche Telekom (CC)are currently on vacation so I could not check with them now about how to answer this mail, but we already talked about this issue a number of times and my strong opinion is that "yes, Deutsche Telekom cares a lot about SIP and RADIUS". Reusing the existing RADIUS platform for SIP authentication is a strong requirement for the development of SIP services within the Deutsche Telekom. >>> >>>Laura (T-Systems/Deutsche Telekom Group) >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the 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. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >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 exim@www1.ietf.org Tue Aug 5 13:09:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19337 for ; Tue, 5 Aug 2003 13:09:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5J4-0007vp-1s for sipping-archive@odin.ietf.org; Tue, 05 Aug 2003 13:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75H9602030483 for sipping-archive@odin.ietf.org; Tue, 5 Aug 2003 13:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5J3-0007va-To for sipping-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 13:09:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19307 for ; Tue, 5 Aug 2003 13:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5J1-0003wB-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 13:09:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k5J1-0003w8-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 13:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Iz-0007uf-1S; Tue, 05 Aug 2003 13:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Ig-0007uO-29 for sipping@optimus.ietf.org; Tue, 05 Aug 2003 13:08:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19288 for ; Tue, 5 Aug 2003 13:08:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5Ic-0003w5-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:08:38 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19k5Ib-0003w2-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:08:38 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 649D25B0; Tue, 5 Aug 2003 19:03:25 +0200 (CEST) Received: from jku07.iptel.org (dhcp114.fokus.fraunhofer.de [195.37.78.114]) by fox.iptel.org (Postfix) with ESMTP id 078255F0; Tue, 5 Aug 2003 19:03:25 +0200 (CEST) Message-Id: <5.2.0.9.0.20030805190044.00bab8a8@mailhost.fokus.gmd.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 05 Aug 2003 19:02:07 +0200 To: Bernard Aboba From: Jiri Kuthan Subject: Re: AW: [Sipping] FYI: RADIUS & SIP Cc: Jonathan Rosenberg , "Liess, Laura" , hgs@cs.columbia.edu, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" In-Reply-To: References: <5.2.0.9.0.20030805175935.02b72d00@mailhost.fokus.gmd.de> <43240544763FB8479F1529372F6197CF053CC8CD@G8PQC.blf01.telekom.de> <5.2.0.9.0.20030805175935.02b72d00@mailhost.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , At 06:34 PM 8/5/2003, Bernard Aboba wrote: >Everyone seems to be in agreement on the required work (am I dreaming, or >is this really the IETF?) :) >There has been some discussion of potentially forming a WG to >handle RADIUS-related work (RADIUSEXT?). The question is whether >SIP-specific items (such as the Sterman draft and the SIP accounting work) >would be appropriate for a new RADIUS-focussed WG, or whether it might be >more appropriate for a SIP-focussed group (such as SIPPING). My esthetical process preference is to create specific extensions in the WG which is involved with the specifics; SIPPING in this particular case. -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 exim@www1.ietf.org Tue Aug 5 13:20:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19549 for ; Tue, 5 Aug 2003 13:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Tg-0008CQ-T9 for sipping-archive@odin.ietf.org; Tue, 05 Aug 2003 13:20:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75HK4Mx031512 for sipping-archive@odin.ietf.org; Tue, 5 Aug 2003 13:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Tg-0008CB-Ms for sipping-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 13:20:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19535 for ; Tue, 5 Aug 2003 13:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5Te-00040I-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 13:20:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k5Te-00040F-00 for sipping-web-archive@ietf.org; Tue, 05 Aug 2003 13:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Td-0008Aw-Ve; Tue, 05 Aug 2003 13:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Su-00089q-Be for sipping@optimus.ietf.org; Tue, 05 Aug 2003 13:19:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19509 for ; Tue, 5 Aug 2003 13:19:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5Ss-0003zp-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:19:14 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19k5Sr-0003zm-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:19:13 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.20) id 19k5Sr-000Ixh-Li; Tue, 05 Aug 2003 17:19:13 +0000 To: Bernard Aboba cc: sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: Message from Jiri Kuthan of "Tue, 05 Aug 2003 19:02:07 +0200." <5.2.0.9.0.20030805190044.00bab8a8@mailhost.fokus.gmd.de> Date: Tue, 05 Aug 2003 10:19:13 -0700 From: Allison Mankin Message-Id: 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: , >There has been some discussion of potentially forming a WG to >handle RADIUS-related work (RADIUSEXT?). The question is whether >SIP-specific items (such as the Sterman draft and the SIP accounting work) >would be appropriate for a new RADIUS-focussed WG, or whether it might be >more appropriate for a SIP-focussed group (such as SIPPING). I believe they'd be more appropriate developed in SIPPING, with cross-review from the RADIUS group. But I think SIPPING needs some information on what the RADIUS working group-to-be is expected to do on RADIUS, in what timeframe. From what I've understood, the charter would not primarily be applications. Could you give us more understanding? Allison _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 6 02:18:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25069 for ; Wed, 6 Aug 2003 02:18:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHci-0008N4-5v for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 02:18:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h766IC6q032179 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 02:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHch-0008Mw-P9 for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 02:18:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24503 for ; Wed, 6 Aug 2003 02:18:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHcd-0000eB-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 02:18:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kHcd-0000e8-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 02:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHcX-0008LP-J9; Wed, 06 Aug 2003 02:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHcF-0008KW-ON for sipping@optimus.ietf.org; Wed, 06 Aug 2003 02:17:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24075 for ; Wed, 6 Aug 2003 02:17:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHcB-0000dn-00 for sipping@ietf.org; Wed, 06 Aug 2003 02:17:39 -0400 Received: from n171-18.deltathree.com ([208.170.171.18] helo=exch-jlm2.deltathree.com) by ietf-mx with esmtp (Exim 4.12) id 19kHcA-0000dd-00 for sipping@ietf.org; Wed, 06 Aug 2003 02:17:39 -0400 Received: by n171-18.deltathree.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Aug 2003 09:17:01 +0300 Message-ID: From: David Schwartz To: "'Jiri Kuthan'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Update to 3pcc Date: Wed, 6 Aug 2003 09:17:00 +0300 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: , Hi Jiri. I was referring specifically to the call teardown issue associated with most pre-paid billing models. David -----Original Message----- From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] Sent: Tue, August 05, 2003 7:39 PM To: David Schwartz; 'sipping@ietf.org' Subject: Re: [Sipping] Re: Update to 3pcc Hello David, I don't see how billing servers are related to method of call initiation. Actually I believe that how a call is initiated (by manual dialing a destination, by REFER-based click-to-dial, by b2bua-based click-to-dial, CTI, etc.) is completely orthogonal to how the call is charged for. Regardless what charging system you use (if any), there will be different methods for initiating calls, some will be better off than others. I maintain that a click-to-dial b2bua is not a BCP. -jiri At 10:10 AM 7/30/2003, David Schwartz wrote: >Hi Jiri > >REFER is good solution if you assume that either there are no billing >issues, or alternatively, that the endpoint/s handle the billing issues. If >this is not the case, for example, in an application where a centralized >controller is setting up a call to two PSTN numbers, then you will need a >centralized billing entity and REFER will not suffice. > >David > >-----Original Message----- >From: sipping-request@ietf.org [mailto:sipping-request@ietf.org] >Sent: Mon, July 28, 2003 7:00 PM >To: sipping@ietf.org >Subject: Sipping digest, Vol 1 #1144 - 2 msgs > > >Send Sipping mailing list submissions to > sipping@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/sipping >or, via email, send a message with subject or body 'help' to > sipping-request@ietf.org > >You can reach the person managing the list at > sipping-admin@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Sipping digest..." > > >Today's Topics: > > 1. Re: Diversion header (Cullen Jennings) > 2. Re: Update to 3pcc (Jiri Kuthan) > >--__--__-- > >Message: 1 >Date: Sun, 27 Jul 2003 19:05:10 -0700 >Subject: Re: [Sipping] Diversion header >From: Cullen Jennings >To: Romel Khan , > > >I assume your question is there some way for for the final destination that >receives the call to know the who the 1st callee was that had some device in >the network redirect the call elsewhere. > >The answer is YES - there has been a lot of confusion over this so think >about my answer carefully - it will seem counter intuitive at first. The >answer is the "To" header but it will take me a second to explain why. > >Imagine case 1 where A send a call to proxy B, that sent to to C. Now C >sent a 302 back B and B then forked the call to D. The To header in the >message D receives will still have the To set to C. C is the element that >sent the first 302. > >Now imagine a case (like your question) where there is not a recursive >proxy. The 302 will go all the way back to A. Now A forms a new invite to >but it can leave the To header set to the same thing it was in the original >message (C in this case). When the message arrives at D, the To header will >be set to C. > >If D was a voice mail system, it might be able to know to act on behalf of C >instead of some other entity. > >There are more complex things that relate to your request. Mary Barnes has >been moving the history work along >http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-04.txt > >There is some work on QSIG mappings with diversion >http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-diversion - >00.txt > >There is a draft-levy-sip-diversion which I (and many others) believe has a >pretty much zero chance of being accepted or becoming a RFC. This work has >been superceded by the history work. Quite a few people do not support the >history work and it is moving very slowly. Don't expect any of this to >resolve quickly. > >Give some careful thought to if the "To" header meets your needs and if it >does use - The To header is widely implemented :-) > > >Cullen > > > > >On 7/21/03 8:55, "Romel Khan" wrote: > >> Is there any SIP header defined in any SIP RFC or Internet Draft that can >> include the address of the 1st callee, who redirected the call using 302, >in >> the 2nd outgoing INVITE? >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > > >--__--__-- > >Message: 2 >Date: Mon, 28 Jul 2003 10:17:51 +0200 >To: Jonathan Rosenberg , sipping >From: Jiri Kuthan >Subject: Re: [Sipping] Update to 3pcc > >I'm actually not convinced that it is proper to show click-to-dial >as a motivating example for use of b2bua and label it BCP. > >Use of REFER seems technically a superior solution worth being called >BCP. Roots of the advantages are in a better application of e2e principle. >REFER takes no middle-box b2bua -- it delegates signaling to end-points. >Advantages include: >- All the pitfalls with media are so straigforward, they don't even > need to be described (like now in sessions 8 and 9). >- It takes no media server to transmit ringing tone. >- There are no SDP compatibility issues on controller's side. > >-jiri > >At 07:51 PM 7/8/2003, Jonathan Rosenberg wrote: >>Folks, >> >>You may have noticed that I posted an update to the 3pcc spec: >> >>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.txt >>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.html >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.txt >> >>The update is based on comments received from IESG while reviewing the >draft. In particular, there were problems with the usage of 0.0.0.0 to >imply that no media nor RTCP should be sent. This IP address is not meant >for that purpose. Rather, the .invalid TLD is much better suited. So, I >changed the draft to make use of .invalid in flows where the controller >doesnt want media to be sent. >> >>Now, there are some concerns with that which folks need to be aware of: >> >>1. It is at odds with RFC 3264, which actually recommends 0.0.0.0. In fact, >the problem is really with RFC 3264, NOT 3pcc. However, 3264 is done, and >this one isnt. I logged a bug against RFC 3264 on this, and we'll need to >work on a way to transition folks towards using .invalid and not 0.0.0.0. >> >>2. One the premises of 3pcc is that it should be compatible with any UA >that is RFC 3261 compliant. If a controller uses .invalid in the SDP, I am >not sure what a SIP endpoint would do. I don't believe anything in RFC 3264 >or in SIP talks about handling the case where there is an issue with a >domain name in the SDP. As such, if you use .invalid, there could be interop >problems. The document mentions this. >> >>Comments or questions welcome. >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>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 > >-- >Jiri Kuthan http://iptel.org/~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 > >End of Sipping Digest > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 6 04:20:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09197 for ; Wed, 6 Aug 2003 04:20:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kJWm-0004mp-Lm for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 04:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h768KCgR018398 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 04:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kJWl-0004me-Fb for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 04:20:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09194 for ; Wed, 6 Aug 2003 04:20:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kJWi-0001Js-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 04:20:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kJWi-0001Jp-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 04:20:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kJWc-0004lV-3A; Wed, 06 Aug 2003 04:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kJWY-0004ky-Ta for sipping@optimus.ietf.org; Wed, 06 Aug 2003 04:19:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09191 for ; Wed, 6 Aug 2003 04:19:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kJWW-0001Jm-00 for sipping@ietf.org; Wed, 06 Aug 2003 04:19:56 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19kJWV-0001Jj-00 for sipping@ietf.org; Wed, 06 Aug 2003 04:19:55 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 6 Aug 2003 10:17:21 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Aug 2003 10:17:20 +0200 Message-Id: <43240544763FB8479F1529372F6197CF053CC910@G8PQC.blf01.telekom.de> From: "Liess, Laura" To: jiri.kuthan@fokus.fraunhofer.de Cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, aboba@internaut.com, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" Subject: AW: AW: [Sipping] FYI: RADIUS & SIP Date: Wed, 6 Aug 2003 10:17:20 +0200 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: , What about the accounting draft draft-schulzrinne-accounting-sip-01.txt? Any reason for not working on it? Laura >-----Ursprungliche Nachricht----- >Von: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] >Gesendet: Dienstag, 5. August 2003 18:00 >An: Jonathan Rosenberg; Bernard Aboba >Cc: Liess, Laura; hgs@cs.columbia.edu; sipping@ietf.org; Dumler, >Alexander; Wolff, Christian >Betreff: Re: AW: [Sipping] FYI: RADIUS & SIP > > >Thanks, I very much agree; we have received identical feedback so far. > >-jiri > >At 08:12 PM 7/29/2003, Jonathan Rosenberg wrote: >>I know of several carriers with RADIUS infrastructures that >want to use them to support SIP. They are currently using >expired I-Ds and proprietary attributes. As a result, I would >strongly advocate work on standardizing RADIUS usage with SIP. >> >>There are two areas of work that I see a need for: >> >>1. Digest authentication. The sterman draft >(http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-si >p-00.txt) is used quite a bit, it seems. It would be nice to >standardize on this. >> >>2. Prepaid calling. Many folks are using vendor proprietary >radius extensiosn to support prepaid calling. It would be nice >to bring those forward and standardize on them. >> >>-Jonathan R. >> >>Bernard Aboba wrote: >> >>>Is there some particular set of draft(s) that you are >advocating work on? >>>On Fri, 18 Jul 2003, Liess, Laura wrote: >>> >>>>I think most carriers currently use some kind of RADIUS >platform to do user authentication and they would like to >reuse it in the future to authenticate their SIP customers. >>>>My colleagues who are responsible for the RADIUS Platform >of the Deutsche Telekom (CC)are currently on vacation so I >could not check with them now about how to answer this mail, >but we already talked about this issue a number of times and >my strong opinion is that "yes, Deutsche Telekom cares a lot >about SIP and RADIUS". Reusing the existing RADIUS platform >for SIP authentication is a strong requirement for the >development of SIP services within the Deutsche Telekom. >>>> >>>>Laura (T-Systems/Deutsche Telekom Group) >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the 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. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>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 exim@www1.ietf.org Wed Aug 6 07:48:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12704 for ; Wed, 6 Aug 2003 07:48:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMm3-0001Gg-GV for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 07:48:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76BmBZ0004870 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 07:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMm3-0001GT-CD for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 07:48:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12689 for ; Wed, 6 Aug 2003 07:48:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMm2-00023Y-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 07:48:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kMm1-00023V-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 07:48:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMls-0001FR-TY; Wed, 06 Aug 2003 07:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMlF-0001EA-U1 for sipping@optimus.ietf.org; Wed, 06 Aug 2003 07:47:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12654 for ; Wed, 6 Aug 2003 07:47:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMlF-00023F-00 for sipping@ietf.org; Wed, 06 Aug 2003 07:47:21 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19kMlE-00023B-00 for sipping@ietf.org; Wed, 06 Aug 2003 07:47:20 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HJ700A014OQRN@siemenscomms.co.uk> for sipping@ietf.org; Wed, 06 Aug 2003 12:46:02 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HJ700AHJ4OQEK@siemenscomms.co.uk>; Wed, 06 Aug 2003 12:46:02 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 06 Aug 2003 12:46:48 +0100 Content-return: allowed Date: Wed, 06 Aug 2003 12:47:17 +0100 From: "Elwell, John" To: "'Rey Jean-Francois'" Cc: sipping@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: Comments on draft-ietf-sipping-qsig2sip-01.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 Jean-Francois, Thanks for your comments. I have dealt with most of the editorials. My responses to your technical comments: #1 - Page 4 - Introduction The document states : "This document specifies signalling interworking for basic services that provide a bi-directional transfer capability for speech, DTMF, facsimile and modem media" There are different drafts and RFCs dealing with DTMF, facsimile and modem media. It's not really explained further down in the text. What about clarifying it or removing it ? [JRE]Good point, because there are other aspects of DTMF, fax and modem that are deliberately outside the scope of this specification. On the other hand the same is true of speech, e.g., the use of RTP is not covered in this document. I propose to add "Other aspects of interworking, e.g., the use of RTP and SDP, will differ according to the type of media concerned and are outside the scope of this specification." #2 - Page 10 - 7 General requirements "In addition, the gateway SHALL support SIP TU behaviour for a UA in accordance with [10] except where stated otherwise in this specification." Where are the parts of the document where the behaviour is different ? If there's no difference, the "except..." part of the sentence should be removed. [JRE] I believe all the requirements of sections 8 to 10 apply at the TU level. Will clarify. #3 - Page 10 - 7 General requirements "SIP methods not defined in [10], [11], [13] or [14] are outside the" Do [13] and [14] define SIP methods ? [JRE] No - will clarify. #4 - Page 10 - 7 General requirements "As a result of DNS look-up by the gateway in order to determine where to send a SIP INVITE request, a number of candidate destinations can be attempted in sequence. The way in which this is handled by the gateway is outside the scope of this specification. However, any behaviour specified in this document on receipt of a SIP final response SHOULD apply only when there are no more candidate destinations to try." Does it mean that the ingress gateway SHOULD try the next retrieved addresses if the first one responded 484 for instance ? I guess that rfc3263 narrows the scope to "network" or "component" failures. [JRE] I guess when overlap signalling applies in the SIP network the statement is not quite true, so I will make an exception. Also I believe the statement is not applicable to 3xx or 6xx responses, so I will limit it to 4xx and 5xx responses. Does this cover all the situations you had in mind? #5 - Page 13 - 8.2.1.1 Receipt of QSIG SETUP message "If information in the QSIG SETUP message is unsuitable for generating any of the mandatory fields in a SIP INVITE request (e.g., if a Request-URI cannot be derived from the QSIG Called party number information element)" I agree in theory, but what could prevent from deriving a R-URI in the real world ? [JRE] It depends what method the gateway uses for mapping a number to a R-URI. It might do it via look-up (e.g., ENUM), in which case if there is no entry for the number concerned this might apply. Obviously it would not apply to a gateway that algorithmically converts any number to a URI. #6 - Page 14 - 8.2.1.3 Receipt of SIP 18x provisional response "NOTE 2. Media streams are established as a result of receiving SDP answer information in a reliable provisional response and can be " I agree that reliable provisional response are better, but why use reliable here ? If a UA that does not support PRACK sends a 183 with a SDP body, the media stream is established too. [JRE] You are correct. However, the text concerned talks about SDP answer but media streams can also be established at this time by means of SDP offer in a provisional response. The text fails to mention this. According to RFC3261 section 13.2.1 an unreliable provisional response cannot be used for SDP offer. I will clarify the statement. Also subsequent modification of the session by means of UPDATE applies only after a offer has been received in a reliable message and answer has been sent, so this too would need qualifying. However, it is not really necessary to mention UPDATE so perhaps that part can be deleted. #7 - Page 15 - 8.2.1.4 Receipt of SIP 2xx response "If the gateway receives a SIP 2xx response other than 200 (OK), the gateway SHALL send a SIP ACK request." What happens on the QSIG side ? [JRE] The intention was to take no action. Will clarify. #8 - Page 23 - 8.3.9 "If a gateway receives a SIP INVITE request with the same Call-ID as an existing call for which the QSIG state is overlap sending and with updated Request-URI and To fields from which a called party number with a superset of digits can be derived, it SHALL" I think that it should read "same Call-ID and the same From header field including the tag, and no tag in the To header field". BTW, the To header field is not so important anyway, since it's not used (9.2.1). Same remark for 7 of figure 5 and for 8 of figure 8. [JRE]I agree. Will clarify. #9 - Page 24 - 8.3.9 "If a gateway receives a SIP INVITE request for a new dialog with the same Call-ID as an existing SIP INVITE request for which the gateway has not yet sent a final response and failing to meet the other conditions above concerning overlap sending, the gateway SHALL respond to the new request with a SIP 485 (Ambiguous) response." It's not very important, but could you explain the motivation of this sentence. Is it related to the merged requests ? [JRE] Its purpose is to prescribe behaviour if the gateway receives an INVITE request that in all respects looks like overlap sending but fails to meet the criterion of the derived called party number being a superset of the previously derived called party number. I will change the wording slightly to complement the changes I made to address comment #8, so see if that helps. Concerning how it arises, I guess merged requests are one possibility. #10 - Page 24 - 8.4.1 "as specified in table 1." Why aren't some status codes symetric in table 1 and table 2. For instance - 408 Request timeout maps 102 Recovery on timer expiry and - 102 Recovery on timer expiry maps 504 Server time-out. BTW, I like the way table 2 is similar to what RFC3398 describes. [JRE] 504 also maps to 102, but it is not possible to make 102 map to both 408 and 504 - we had to pick one. This illustrates the point that there is not a 1:1 correspondence between SIP responses and Q.850 causes and therefore there will be some asymmetries and some rather questionable mappings. Cause mapping was discussed long and hard for ISUP interworking and again for QSIG interworking (resulting in some changes to ISUP interworking to keep alignment). It is not perfect and it never will be, but I would be reluctant to open up the discussion again. I hope you can live with what we have. #11 - Page 24- 8.4.1 Very minor comment. It's obvious that the 200 responses are related to the INVITE transaction, but this is not written. [JRE] Will clarify. #12 - Page 27 - 8.4.4 What is the meaning of () in table 2 403 Forbidden 21 (Call rejected) 404 Not found 1 (Unallocated number) [JRE] Deleted. -- And some remarks regarding other SIPPING drafts #1 draft-ietf-sipping-overlap-04.txt It says : "However, overlap signalling adds a requirement to this process. As a general rule, a media stream corresponding to the response to an INVITE with a greater number of digits should be given more priority than media streams from responses with less digits." Is this requirement applicable here ? [JRE] I remember this was discussed and we thought it best not to try to give guidance in this tricky situation. #2 draft-ietf-sipping-pstn-call-flows-02.txt 2.2, 4.2 I know that qsig2sip deals with QSIG only, but don't you think that people might get confused by the slight difference in the mapping of the messages of the "ISDN PBX" examples of the call-flow draft ? [JRE] There are of course some differences between QSIG and Q.931 that can have impact on the mapping. Also I am not sure of the status of the call-flows draft and in particular the two examples showing Q.931 mapping, because I thought the group had decided not to work on SIP-Q.931 mapping. Regards, John (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 exim@www1.ietf.org Wed Aug 6 07:49:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12759 for ; Wed, 6 Aug 2003 07:49:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMmu-0001Qq-Qf for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 07:49:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Bn4JH005504 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 07:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMmu-0001Qh-Il for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 07:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12728 for ; Wed, 6 Aug 2003 07:49:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMmt-00024L-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 07:49:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kMmt-00024I-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 07:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMmq-0001LP-TO; Wed, 06 Aug 2003 07:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMmR-0001L9-6t for sipping@optimus.ietf.org; Wed, 06 Aug 2003 07:48:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12702 for ; Wed, 6 Aug 2003 07:48:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMmQ-00023i-00 for sipping@ietf.org; Wed, 06 Aug 2003 07:48:34 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19kMmO-00023U-00 for sipping@ietf.org; Wed, 06 Aug 2003 07:48:33 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HJ700A014QQT7@siemenscomms.co.uk> for sipping@ietf.org; Wed, 06 Aug 2003 12:47:14 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HJ700AJS4QQEK@siemenscomms.co.uk>; Wed, 06 Aug 2003 12:47:14 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 06 Aug 2003 12:48:00 +0100 Content-return: allowed Date: Wed, 06 Aug 2003 12:48:29 +0100 From: "Elwell, John" To: "'Francois Audet'" , "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_EM0RCWIARjcw7n0+SbWQfg)" Subject: [Sipping] RE: WGLC for draft-ietf-sipping-qsig2sip-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: , 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. --Boundary_(ID_EM0RCWIARjcw7n0+SbWQfg) Content-type: text/plain Content-Transfer-Encoding: 7BIT Francois, Thanks for your comments. I will address the editorials. Concerning the technical comments: - Section 8.3.1, page 19 5th paragraph: Add ", unless the gateway is aware that in-band information will not be used" to the end of the paragraph. The reason for this is that there are cases where the gateway may have a priori-knowledge that in-band tones and announcements are not used; and out-of-band ALERTING or fast connection (i.e., no PROGRESS and no ALERTING) is always used for example. In that case, there is no reason to reject the call with 488 if the SDP was not included in the INVITE. [JRE] I agree that if there is a priori knowledge that in-band tones and announcements will not be used, then what you propose is reasonable. I am rather doubtful that the gateway will have sufficient knowledge to determine this. The 4th and 5th paragraphs of 8.3.3 mandate the connection of media streams if relevant QSIG progress indicators are present in a PROGRESS or ALERTING message. The presence of these progress indicators is outside the control of the gateway. So how can the gateway have a priori knowledge that these progress indicators will not be received? - Section 8.3.5, page 21 This section mandates the inclusion of SDP in 18x response. This may not be possible, or even required. For example, it is very common for PBXs not to know at the time of rigning where a call will be terminated (i.e., which user): this applies to features such as "hunt group", as well as "multiple line appearances". In those cases, it may be impossible for the gateway to include an SDP in the 18x, because it does not know yet whitch media gateway resource will be used. Furthermore, it is against the spirit of the offer-answer model and SIP to mandate that the SDP must be included in the 18x response (it could be in 200 OK for example). Paragraphs 3 and 4 shall thus be modified as follows: "...SDP answer information SHOULD be included in the SIP 18x provisional response if the SDP information is available." [JRE] This clause was primarily intended to cover the case where an in-band tone or announcement is to be sent. I propose changing it to say the rules SHALL apply if an in-band tone or announcement is available and MAY apply otherwise. Regards, John (john.elwell@siemens.com ) --Boundary_(ID_EM0RCWIARjcw7n0+SbWQfg) Content-type: text/html Content-Transfer-Encoding: 7BIT Message
Francois,
 
Thanks for your comments. I will address the editorials. Concerning the technical comments:
 
<SNIP>
- Section 8.3.1, page 19
 
  5th paragraph: Add ", unless the gateway is aware that in-band information
  will not be used" to the end of the paragraph. The reason for this is that
  there are cases where the gateway may have a priori-knowledge that in-band
  tones and announcements are not used; and out-of-band ALERTING or
  fast connection (i.e., no PROGRESS and no ALERTING) is always
  used for example. In that case, there is no reason to reject the call with
  488 if the SDP was not included in the INVITE.
[JRE] I agree that if there is a priori knowledge that in-band tones and announcements will not be used, then what you propose is reasonable. I am rather doubtful that the gateway will have sufficient knowledge to determine this. The 4th and 5th paragraphs of 8.3.3 mandate the connection of media streams if relevant QSIG progress indicators are present in a PROGRESS or ALERTING message. The presence of these progress indicators is outside the control of the gateway. So how can the gateway have a priori knowledge that these progress indicators will not be received?

- Section 8.3.5, page 21

  This section mandates the inclusion of SDP in 18x response. This may not be
  possible, or even required. For example, it is very common for PBXs not to
  know at the time of rigning where a call will be terminated (i.e., which
  user): this applies to features such as "hunt group", as well as "multiple
  line appearances". In those cases, it may be impossible for the gateway
  to include an SDP in the 18x, because it does not know yet whitch media
  gateway resource will be used. Furthermore, it is against the spirit of
  the offer-answer model and SIP to mandate that the SDP must be included
  in the 18x response (it could be in 200 OK for example).

  Paragraphs 3 and 4 shall thus be modified as follows: "...SDP answer
  information SHOULD be included in the SIP 18x provisional response if
  the SDP information is available."

[JRE] This clause was primarily intended to cover the case where an in-band tone or announcement is to be sent. I propose changing it to say the rules SHALL apply if an in-band  tone or announcement is available and MAY apply otherwise.

</SNIP> 
 Regards,

John (john.elwell@siemens.com)

 

--Boundary_(ID_EM0RCWIARjcw7n0+SbWQfg)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 6 07:50:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12841 for ; Wed, 6 Aug 2003 07:50:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMns-0001dm-NH for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 07:50:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Bo4uw006303 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 07:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMns-0001da-CC for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 07:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12799 for ; Wed, 6 Aug 2003 07:50:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMnq-00025U-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 07:50:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kMnp-00025R-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 07:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMnp-0001YP-3A; Wed, 06 Aug 2003 07:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kMn6-0001R0-Gn for sipping@optimus.ietf.org; Wed, 06 Aug 2003 07:49:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12751 for ; Wed, 6 Aug 2003 07:49:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kMn5-00024h-00 for sipping@ietf.org; Wed, 06 Aug 2003 07:49:15 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19kMn4-00023n-00 for sipping@ietf.org; Wed, 06 Aug 2003 07:49:14 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HJ700A014RPTC@siemenscomms.co.uk> for sipping@ietf.org; Wed, 06 Aug 2003 12:47:49 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HJ700AK54RPEK@siemenscomms.co.uk> for sipping@ietf.org; Wed, 06 Aug 2003 12:47:49 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 06 Aug 2003 12:48:35 +0100 Content-return: allowed Date: Wed, 06 Aug 2003 12:49:05 +0100 From: "Elwell, John" Subject: RE: [Sipping] WGLC for Q.SIP-SIP mapping draft To: "'Stach Thomas'" , "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_aRr8797UZpm4UUyh/ntmyg)" 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. --Boundary_(ID_aRr8797UZpm4UUyh/ntmyg) Content-type: text/plain Content-Transfer-Encoding: 7BIT Thomas, Thanks for your comments. I have taken them all into account except for the following. In Section 8.1 4th para is stated: "The processing of any valid QSIG message that does not satisfy any of these conditions is outside the scope of this specification." This seems to be a little bit vague for somebody not familiar with QSIG. Since the interworking only comprises QSIG Basic Call, you could be more specific and mention the unconsidered features provided by ISO 11582 by adding: "This includes a QSIG SETUP message intended to establish a call-independent signalling connection and connectionless transport as specified in [3]." [JRE] The statements were not really intended to exclude QSIG features beyond basic call, but were intended to cover QSIG messages that are not suitable for mapping to SIP messages because they do not relate to an existing SIP call or, in the case of a QSIG SETUP message, the call is not suitable for routing to SIP. I believe the existing text is adequate for this purpose. There is already a statement in section 1 that QSIG signalling in support of supplementary services is outside the scope. However, I could stress this with a separate statement in 8.1 that call-independent signalling connections and connectionless transport are outside the scope. Do you think this would be helpful? The QSIG SETUP message may optionally transport HLC and LLC Information elements which are not mentioned in the draft. You might want to add something like into section 10: "The gateway SHOULD (or SHALL(?)) not include a Low layer compatibility in the QSIG SETUP message. The gateway SHOULD not include a High layer compatibility information element in the QSIG SETUP message. NOTE: Inclusion of a HLC in the QSIG SETUP message might be useful, if the gateway knows prior to sending the QSIG SETUP message that fax is being transmitted (e.g., because of a corresponding SDP offer), it may include in the QSIG SETUP message a High layer compatibility information element indicating group 3 fax." [JRE] I will add something. In addition I will add something concerning the opposite direction, allowing HLC and LLC to be taken into account when deriving SDP offer information. Regards, John (john.elwell@siemens.com ) --Boundary_(ID_aRr8797UZpm4UUyh/ntmyg) Content-type: text/html Content-Transfer-Encoding: 7BIT Message
Thomas,
 
Thanks for your comments. I have taken them all into account except for the following.
 
<SNIP>
In Section 8.1 4th para is stated:
"The processing of any valid QSIG message that does not satisfy any of
these conditions is outside the scope of this specification."
This seems to be a little bit vague for somebody not familiar with QSIG.
Since the interworking only comprises QSIG Basic Call, you could be more specific and mention the unconsidered features provided by ISO 11582 by adding:

"This includes a QSIG SETUP message intended to establish a call-independent signalling connection and  connectionless transport as specified in [3]."
[JRE] The statements were not really intended to exclude QSIG features beyond basic call, but were intended to cover QSIG messages that are not suitable for mapping to SIP messages because they do not relate to an existing SIP call or, in the case of a QSIG SETUP message, the call is not suitable for routing to SIP. I believe the existing text is adequate for this purpose. There is already a statement in section 1 that QSIG signalling in support of supplementary services is outside the scope. However, I could stress this with a separate statement in 8.1 that call-independent signalling connections and connectionless transport are outside the scope. Do you think this would be helpful?

The QSIG SETUP message may optionally transport HLC and LLC Information elements which are not mentioned in the draft. You might want to add something like into section 10:

"The gateway SHOULD (or SHALL(?)) not include a Low layer compatibility in the QSIG SETUP message. The gateway SHOULD not include a High layer compatibility information element in the QSIG SETUP message.

NOTE: Inclusion of a HLC in the QSIG SETUP message might be useful, if the gateway knows prior to sending the QSIG SETUP message that fax is being transmitted (e.g., because of a corresponding SDP offer), it may include in the QSIG SETUP message a High layer compatibility information element indicating group 3 fax."
[JRE] I will add something. In addition I will add something concerning the opposite direction, allowing HLC and LLC to be taken into account when deriving SDP offer information.

</SNIP>
 
Regards,
 
 --Boundary_(ID_aRr8797UZpm4UUyh/ntmyg)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 6 13:47:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26467 for ; Wed, 6 Aug 2003 13:47:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSNR-0000bp-6u for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 13:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Hl9os002337 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 13:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSNR-0000bc-3Z for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26454 for ; Wed, 6 Aug 2003 13:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSNO-00057U-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 13:47:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSNO-00057Q-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 13:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSNK-0000ah-4N; Wed, 06 Aug 2003 13:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSMU-0000Zm-76 for sipping@optimus.ietf.org; Wed, 06 Aug 2003 13:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26419 for ; Wed, 6 Aug 2003 13:46:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSMR-00057D-00 for sipping@ietf.org; Wed, 06 Aug 2003 13:46:08 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19kSMQ-000579-00 for sipping@ietf.org; Wed, 06 Aug 2003 13:46:07 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h76HjXR17201; Wed, 6 Aug 2003 10:45:33 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Aug 2003 10:45:34 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20A193706@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Elwell, John'" , "'sipping@ietf.org'" Date: Wed, 6 Aug 2003 10:45:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C42.87E2E81C" Subject: [Sipping] RE: WGLC for draft-ietf-sipping-qsig2sip-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: , 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_01C35C42.87E2E81C Content-Type: text/plain Thanks John, see below: -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Wednesday, August 06, 2003 04:48 To: Audet, Francois [SC100:4K02:EXCH]; 'sipping@ietf.org' Subject: RE: WGLC for draft-ietf-sipping-qsig2sip-01 Francois, Thanks for your comments. I will address the editorials. Concerning the technical comments: - Section 8.3.1, page 19 5th paragraph: Add ", unless the gateway is aware that in-band information will not be used" to the end of the paragraph. The reason for this is that there are cases where the gateway may have a priori-knowledge that in-band tones and announcements are not used; and out-of-band ALERTING or fast connection (i.e., no PROGRESS and no ALERTING) is always used for example. In that case, there is no reason to reject the call with 488 if the SDP was not included in the INVITE. [JRE] I agree that if there is a priori knowledge that in-band tones and announcements will not be used, then what you propose is reasonable. I am rather doubtful that the gateway will have sufficient knowledge to determine this. The 4th and 5th paragraphs of 8.3.3 mandate the connection of media streams if relevant QSIG progress indicators are present in a PROGRESS or ALERTING message. The presence of these progress indicators is outside the control of the gateway. So how can the gateway have a priori knowledge that these progress indicators will not be received? I'm talking about the gateway RECEIVING the SETUP, not the one sending it. The case I am thinking of is then the Gateway is an IP PBX (with SIP on one side, QSIG on the other). If the call terminates on a local phone, it may use out-of-band ringing (our PBXs work that way). If we want to be picky about the meaning of Gateway, and dissociate the gateway from the actual QSIG PBX, then it can still happen. The gateway may decide to map the INVITE to SETUP anyways and forward it to the QSIG PBX. If the PBX responds with the ALERTING indicating out-of-band, everything is fine (which is why I would like this change). If on the other hand, the ALERTING indicates in-band, then the gateway could decide to do as per your procedure and send the 488. But I wouldn't want to mandate 488 everytime the SDP is not in the INVITE, especially since it is a very normal occurence in SIP. Even for the second case, where the call ultimately terminates on a line with an in-band signalling, I am not convinced at all that the qsig2sip draft should mandate that the call be terminated. To me this should be a design option. An implementer may decide that it prefers to go through with the call, and provide some sort of indication to the user that the call is "progressing" instead of failing the call (I expect that a proper SIP implemenation would do something like that). I would prefer that the paragraph does not mandate the 488 as other options are doable, and probably much less drastic than call failure (as an out-of-band progress indication would be). - Section 8.3.5, page 21 This section mandates the inclusion of SDP in 18x response. This may not be possible, or even required. For example, it is very common for PBXs not to know at the time of rigning where a call will be terminated (i.e., which user): this applies to features such as "hunt group", as well as "multiple line appearances". In those cases, it may be impossible for the gateway to include an SDP in the 18x, because it does not know yet whitch media gateway resource will be used. Furthermore, it is against the spirit of the offer-answer model and SIP to mandate that the SDP must be included in the 18x response (it could be in 200 OK for example). Paragraphs 3 and 4 shall thus be modified as follows: "...SDP answer information SHOULD be included in the SIP 18x provisional response if the SDP information is available." [JRE] This clause was primarily intended to cover the case where an in-band tone or announcement is to be sent. I propose changing it to say the rules SHALL apply if an in-band tone or announcement is available and MAY apply otherwise. I'm OK with your proposed text. ------_=_NextPart_001_01C35C42.87E2E81C Content-Type: text/html Message
Thanks John, see below:
-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Wednesday, August 06, 2003 04:48
To: Audet, Francois [SC100:4K02:EXCH]; 'sipping@ietf.org'
Subject: RE: WGLC for draft-ietf-sipping-qsig2sip-01

Francois,
 
Thanks for your comments. I will address the editorials. Concerning the technical comments:
 
<SNIP>
- Section 8.3.1, page 19
 
  5th paragraph: Add ", unless the gateway is aware that in-band information
  will not be used" to the end of the paragraph. The reason for this is that
  there are cases where the gateway may have a priori-knowledge that in-band
  tones and announcements are not used; and out-of-band ALERTING or
  fast connection (i.e., no PROGRESS and no ALERTING) is always
  used for example. In that case, there is no reason to reject the call with
  488 if the SDP was not included in the INVITE.
[JRE] I agree that if there is a priori knowledge that in-band tones and announcements will not be used, then what you propose is reasonable. I am rather doubtful that the gateway will have sufficient knowledge to determine this. The 4th and 5th paragraphs of 8.3.3 mandate the connection of media streams if relevant QSIG progress indicators are present in a PROGRESS or ALERTING message. The presence of these progress indicators is outside the control of the gateway. So how can the gateway have a priori knowledge that these progress indicators will not be received?
 
I'm talking about the gateway RECEIVING the SETUP, not the one sending it. The case I am thinking of is then the Gateway is an IP PBX (with SIP on one side, QSIG on the other). If the call terminates on a local phone, it may use out-of-band ringing (our PBXs work that way).
 
If we want to be picky about the meaning of  Gateway, and dissociate the gateway from the actual QSIG PBX, then it can still happen. The gateway may decide to map the INVITE to SETUP anyways and forward it to the QSIG PBX. If the PBX responds with the ALERTING indicating out-of-band, everything is fine (which is why I would like this change). If on the other hand, the ALERTING indicates in-band, then the gateway could decide to do as per your procedure and send the 488. But I wouldn't want to mandate 488 everytime the SDP is not in the INVITE, especially since it is a very normal occurence in SIP.
 
Even for the second case, where the call ultimately terminates on a line with an in-band signalling, I am not convinced at all that the qsig2sip draft should mandate that the call be terminated. To me this should be a design option. An implementer may decide that it prefers to go through with the call, and provide some sort of indication to the user that the call is "progressing" instead of failing the call (I expect that a proper SIP implemenation would do something like that).
 
I would prefer that the paragraph does not mandate the 488 as other options are doable, and probably much less drastic than call failure (as an out-of-band progress indication would be).
 

- Section 8.3.5, page 21

  This section mandates the inclusion of SDP in 18x response. This may not be
  possible, or even required. For example, it is very common for PBXs not to
  know at the time of rigning where a call will be terminated (i.e., which
  user): this applies to features such as "hunt group", as well as "multiple
  line appearances". In those cases, it may be impossible for the gateway
  to include an SDP in the 18x, because it does not know yet whitch media
  gateway resource will be used. Furthermore, it is against the spirit of
  the offer-answer model and SIP to mandate that the SDP must be included
  in the 18x response (it could be in 200 OK for example).

  Paragraphs 3 and 4 shall thus be modified as follows: "...SDP answer
  information SHOULD be included in the SIP 18x provisional response if
  the SDP information is available."

[JRE] This clause was primarily intended to cover the case where an in-band tone or announcement is to be sent. I propose changing it to say the rules SHALL apply if an in-band  tone or announcement is available and MAY apply otherwise. 

I'm OK with your proposed text. 

------_=_NextPart_001_01C35C42.87E2E81C-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 6 20:43:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11739 for ; Wed, 6 Aug 2003 20:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kYs1-0001s3-2P for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 20:43:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h770h9cV007187 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 20:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kYs0-0001rq-Ui for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 20:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11735 for ; Wed, 6 Aug 2003 20:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kYry-0000u4-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 20:43:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kYry-0000u1-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 20:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kYrt-0001qu-CH; Wed, 06 Aug 2003 20:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kYr3-0001pm-Pw for sipping@optimus.ietf.org; Wed, 06 Aug 2003 20:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11713 for ; Wed, 6 Aug 2003 20:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kYr1-0000tT-00 for sipping@ietf.org; Wed, 06 Aug 2003 20:42:07 -0400 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 19kYr0-0000tE-00 for sipping@ietf.org; Wed, 06 Aug 2003 20:42:06 -0400 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id h770bdCW017869; Wed, 6 Aug 2003 17:37:39 -0700 (PDT) Received: from convedia.com (egret.convedia.com [192.168.208.147]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26251; Wed, 6 Aug 2003 17:41:35 -0700 (PDT) Message-ID: <3F31A097.7010204@convedia.com> Date: Wed, 06 Aug 2003 17:43:03 -0700 From: Tim Melanchuk User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Garland Sharratt , sipping@ietf.org Subject: Re: [Sipping] draft-melanchuk-sipping-msml-00.txt References: <45730E094814E44488F789C1CDED27AE0219B065@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B065@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cerbrus.convedia.com id h770bdCW017869 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable thanks for your review and comments! nits will be reflected in the next revision. responses to questions are inline below. cheers, timm Chris Boulton wrote: > - Would any benefit be gained from including an optional =91order=92 > attribute on primitive elements so that when =91pipe=92 is used, the o= rder > is determined explicitly rather than following a logical path? > this question is related to MOML. the goal was to provide several simple topology schemas to cover the common use cases. i think that explicit control of topology (i.e. as in mpcp) may be useful. i'm not sure that explicit ordering in this case would have benefit and may introduce additional error cases. did you have any specific benefits in mind? > - Was there a reason that JOIN/UNJOIN were limited to id1 + id2. Coul= d > it not have just been id, that was forced to appear at least twice? > This would allow you to join >2 media streams in one transaction. > simplicity. msml already allows multiple elements to be present in a single transaction. allowing multiple streams to be identified in a single join introduces more complexity and makes failure handling more difficult. > > - element should say that the response code corresponds to th= e > SIP response code received for the transaction. > i'm not quite sure what you mean here. the response attribute in is for the msml transaction. it just happens to be carried in the respons= e to the sip message which conveyed the msml transaction. however msml is designed to be neutral to the transport mechanism and this correlation may not exist in all cases. > from MSML: Media objects may be defined using MOML or other suitable m= edia > resource description languages. A media server which supports > and must support MOML and may support other > languages. > > Should this be a =91MUST=92 or is it not possible to only use another > =91suitable media resource description language=92 with MSML? > a media resource description language is required. the "must" requires that there be at least one common language to insure interoperability. it does not preclude that other languages are supported. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 6 20:45:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11798 for ; Wed, 6 Aug 2003 20:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kYtt-0002Av-TM for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 20:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h770j5Ps008355 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 20:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kYtt-0002Ag-Ns for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 20:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11777 for ; Wed, 6 Aug 2003 20:45:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kYtr-0000uu-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 20:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kYtq-0000ur-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 20:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kYtp-00022A-OP; Wed, 06 Aug 2003 20:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kYti-00021r-6A for sipping@optimus.ietf.org; Wed, 06 Aug 2003 20:44:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11773 for ; Wed, 6 Aug 2003 20:44:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kYtf-0000un-00 for sipping@ietf.org; Wed, 06 Aug 2003 20:44:51 -0400 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 19kYtf-0000ud-00 for sipping@ietf.org; Wed, 06 Aug 2003 20:44:51 -0400 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id h770eOCW017880; Wed, 6 Aug 2003 17:40:24 -0700 (PDT) Received: from convedia.com (egret.convedia.com [192.168.208.147]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26354; Wed, 6 Aug 2003 17:44:21 -0700 (PDT) Message-ID: <3F31A13D.7080603@convedia.com> Date: Wed, 06 Aug 2003 17:45:49 -0700 From: Tim Melanchuk User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Boulton CC: Garland Sharratt , sipping@ietf.org Subject: Re: [Sipping] draft-melanchuk-sipping-moml-00.txt References: <45730E094814E44488F789C1CDED27AE0219B066@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B066@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cerbrus.convedia.com id h770eOCW017880 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable thanks again for your feedback. answers to questions below. cheers, timm >=20 > - Is there an alternative method for defining unlimited occurrences=20 > using the =91max=92 attribute =3D 0 (e.g. pattern element uses max with= in DTMF=20 > primitive). This seemed a little confusing. >=20 i've had this comment from others. would extending the datatype to include an explicit "unlimited" value be less confusing and/or renaming "max" to "maxoccurs"? >=20 > - 4.5.1.1 The description of and needs to be made=20 > more explicit. >=20 will do. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 6 22:31:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14154 for ; Wed, 6 Aug 2003 22:31:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaYa-0005Dt-6N for sipping-archive@odin.ietf.org; Wed, 06 Aug 2003 22:31:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h772VCE0020078 for sipping-archive@odin.ietf.org; Wed, 6 Aug 2003 22:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaYZ-0005Dl-Q0 for sipping-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 22:31:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14146 for ; Wed, 6 Aug 2003 22:31:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kaYW-0001Xh-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 22:31:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kaYV-0001Xe-00 for sipping-web-archive@ietf.org; Wed, 06 Aug 2003 22:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaYQ-0005CH-TC; Wed, 06 Aug 2003 22:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kaXs-0005Az-60 for sipping@optimus.ietf.org; Wed, 06 Aug 2003 22:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14130 for ; Wed, 6 Aug 2003 22:30:23 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kaXo-0001XU-00 for sipping@ietf.org; Wed, 06 Aug 2003 22:30:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19kaXo-0001XR-00 for sipping@ietf.org; Wed, 06 Aug 2003 22:30:24 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h772UNJ05616 for ; Thu, 7 Aug 2003 05:30:24 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Aug 2003 05:30:23 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 05:30:23 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 05:30:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 7 Aug 2003 05:30:22 +0300 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" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sipping] FYI: RADIUS & SIP Date: Thu, 7 Aug 2003 05:30:22 +0300 Message-ID: Thread-Topic: AW: [Sipping] FYI: RADIUS & SIP Thread-Index: AcNXcfLEmBt0Ixa5T1mz5oIXwsiP0ABgn4DA To: , , Cc: , , , X-OriginalArrivalTime: 07 Aug 2003 02:30:22.0651 (UTC) FILETIME=[DA2408B0:01C35C8B] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, I just want to plug a draft we are working on in the AAA WG: Diameter Credit-control Application draft-ietf-aaa-diameter-cc-01.txt This is primarily Diameter based, though interworking with RADIUS is somewhat covered. This is losely based on=20 some 3GPP solutions, but we are trying to generalize it and make it more useful for the Internet. I do know that there are also some individual drafts covering RADIUS prepaid. I don't have the time,=20 nor energy to specify RADIUS prepaid work. =20 One of the largest problems that I currently see about RADIUS is the under-specified nature of RADIUS. I understand that many different organizations and vendors have defined, but not documented, vendor-specific VSAs. In trying to do any meaningful work with RADIUS, I think we need to document some of this first. Oh, a note to Henry, I have heard some horror stories from various folks (and talking to different IT support people) of how large-scale RADIUS deployments react after a power- outtage. Since backoff is not specified in RADIUS, if multiple NASes comeup at the same time, they can flood the network, causing all sorts of fun things happening ... This is one area in which RADIUS would need fixing. br, John > -----Original Message----- > From: ext Liess, Laura [mailto:Laura.Liess@t-systems.com] > Sent: 31 July, 2003 17:41 > To: jdrosen@dynamicsoft.com; aboba@internaut.com > Cc: hgs@cs.columbia.edu; sipping@ietf.org; Dumler, Alexander; Wolff, > Christian > Subject: AW: AW: [Sipping] FYI: RADIUS & SIP >=20 >=20 > I agree with Jonathan. Support for prepaid calling seems to=20 > me a very good idea. =20 > Laura >=20 > Laura Liess > T-Systems/Deutsche Telekom Group > Am Kavalleriesand 3 > 64295 Darmstadt >=20 > >-----Ursprungliche Nachricht----- > >Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Gesendet: Dienstag, 29. Juli 2003 20:13 > >An: Bernard Aboba > >Cc: Liess, Laura; hgs@cs.columbia.edu; sipping@ietf.org; Dumler, > >Alexander; Wolff, Christian > >Betreff: Re: AW: [Sipping] FYI: RADIUS & SIP > > > > > >I know of several carriers with RADIUS infrastructures that want to=20 > >use them to support SIP. They are currently using expired I-Ds and=20 > >proprietary attributes. As a result, I would strongly=20 > advocate work on=20 > >standardizing RADIUS usage with SIP. > > > >There are two areas of work that I see a need for: > > > >1. Digest authentication. The sterman draft=20 > >(http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-si > >p-00.txt)=20 > >is used quite a bit, it seems. It would be nice to=20 > standardize on this. > > > >2. Prepaid calling. Many folks are using vendor proprietary radius=20 > >extensiosn to support prepaid calling. It would be nice to=20 > bring those=20 > > forward and standardize on them. > > > >-Jonathan R. > > > >Bernard Aboba wrote: > > > >> Is there some particular set of draft(s) that you are=20 > >advocating work on? > >>=20 > >> On Fri, 18 Jul 2003, Liess, Laura wrote: > >>=20 > >>=20 > >>>I think most carriers currently use some kind of RADIUS=20 > >platform to do user authentication and they would like to=20 > >reuse it in the future to authenticate their SIP customers. > >>>My colleagues who are responsible for the RADIUS Platform of=20 > >the Deutsche Telekom (CC)are currently on vacation so I could=20 > >not check with them now about how to answer this mail, but we=20 > >already talked about this issue a number of times and my=20 > >strong opinion is that "yes, Deutsche Telekom cares a lot=20 > >about SIP and RADIUS". Reusing the existing RADIUS platform=20 > >for SIP authentication is a strong requirement for the=20 > >development of SIP services within the Deutsche Telekom. > >>> > >>>Laura (T-Systems/Deutsche Telekom Group) > >>=20 > >>=20 > >> _______________________________________________ > >> Sipping mailing list =20 https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >>=20 > >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >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 exim@www1.ietf.org Thu Aug 7 08:12:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09490 for ; Thu, 7 Aug 2003 08:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjcj-00025h-Df for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 08:12:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77CC5Pm008034 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 08:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjcj-00025V-9w for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 08:12:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09440 for ; Thu, 7 Aug 2003 08:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kjci-0005Qt-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 08:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kjch-0005Qq-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 08:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjcf-00024a-CP; Thu, 07 Aug 2003 08:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjcJ-00024M-1a for sipping@optimus.ietf.org; Thu, 07 Aug 2003 08:11:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09419 for ; Thu, 7 Aug 2003 08:11:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kjcH-0005QH-00 for sipping@ietf.org; Thu, 07 Aug 2003 08:11:37 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19kjcG-0005Po-00 for sipping@ietf.org; Thu, 07 Aug 2003 08:11:36 -0400 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJ900E7A0DHB0@firewall.wcom.com> for sipping@ietf.org; Thu, 07 Aug 2003 12:08:05 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJ900A010DHZE@dgismtp05.wcomnet.com>; Thu, 07 Aug 2003 12:08:05 +0000 (GMT) Received: from hsinnreich2 ([166.50.142.32]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJ9009LG0DFIN@dgismtp05.wcomnet.com>; Thu, 07 Aug 2003 12:08:04 +0000 (GMT) Date: Thu, 07 Aug 2003 07:08:04 -0500 From: Henry Sinnreich Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: To: john.loughney@nokia.com, Laura.Liess@t-systems.com, jdrosen@dynamicsoft.com, aboba@internaut.com Cc: hgs@cs.columbia.edu, sipping@ietf.org, Alexander.Dumler@telekom.de, Christian.Wolff@telekom.de Message-id: <0HJ9009LH0DFIN@dgismtp05.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNXcfLEmBt0Ixa5T1mz5oIXwsiP0ABgn4DAAPmaozA= 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 > Oh, a note to Henry, I have heard some horror stories from > various folks (and talking to different IT support people) > of how large-scale RADIUS deployments react after a power- > outtage. Since we know of no significant DIAMETER deployments at ISPs (except in the minds of its IETF champions), sure, there are no horror stories possible for DIAMETER :-) The SIPPING WG charter is to look out for what is good for SIP applications. Promoting DIAMATER should be done elsewhere. The fact that SIPPING folks are too busy to work on _real_ SIP-AAA should is not a good reason to accept the DIAMETER pitch at face value. One option is to postpone SIP-AAA work until we have some I-D's based on real deployments. Or does anyone come forward? Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > john.loughney@nokia.com > Sent: Wednesday, August 06, 2003 9:30 PM > To: Laura.Liess@t-systems.com; jdrosen@dynamicsoft.com; > aboba@internaut.com > Cc: hgs@cs.columbia.edu; sipping@ietf.org; Alexander.Dumler@telekom.de; > Christian.Wolff@telekom.de > Subject: RE: AW: [Sipping] FYI: RADIUS & SIP > > Hi All, > > I just want to plug a draft we are working on in the AAA WG: > > Diameter Credit-control Application > draft-ietf-aaa-diameter-cc-01.txt > > This is primarily Diameter based, though interworking with > RADIUS is somewhat covered. This is losely based on > some 3GPP solutions, but we are trying to generalize it and > make it more useful for the Internet. I do know that there are also > some individual drafts covering RADIUS prepaid. I don't have the time, > nor energy to specify RADIUS prepaid work. > > One of the largest problems that I currently see about RADIUS > is the under-specified nature of RADIUS. I understand that > many different organizations and vendors have defined, but > not documented, vendor-specific VSAs. In trying to do any > meaningful work with RADIUS, I think we need to document > some of this first. > > Oh, a note to Henry, I have heard some horror stories from > various folks (and talking to different IT support people) > of how large-scale RADIUS deployments react after a power- > outtage. Since backoff is not specified in RADIUS, if > multiple NASes comeup at the same time, they can flood > the network, causing all sorts of fun things happening ... > This is one area in which RADIUS would need fixing. > > br, > John > > > > -----Original Message----- > > From: ext Liess, Laura [mailto:Laura.Liess@t-systems.com] > > Sent: 31 July, 2003 17:41 > > To: jdrosen@dynamicsoft.com; aboba@internaut.com > > Cc: hgs@cs.columbia.edu; sipping@ietf.org; Dumler, Alexander; Wolff, > > Christian > > Subject: AW: AW: [Sipping] FYI: RADIUS & SIP > > > > > > I agree with Jonathan. Support for prepaid calling seems to > > me a very good idea. > > Laura > > > > Laura Liess > > T-Systems/Deutsche Telekom Group > > Am Kavalleriesand 3 > > 64295 Darmstadt > > > > >-----Ursprungliche Nachricht----- > > >Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > >Gesendet: Dienstag, 29. Juli 2003 20:13 > > >An: Bernard Aboba > > >Cc: Liess, Laura; hgs@cs.columbia.edu; sipping@ietf.org; Dumler, > > >Alexander; Wolff, Christian > > >Betreff: Re: AW: [Sipping] FYI: RADIUS & SIP > > > > > > > > >I know of several carriers with RADIUS infrastructures that want to > > >use them to support SIP. They are currently using expired I-Ds and > > >proprietary attributes. As a result, I would strongly > > advocate work on > > >standardizing RADIUS usage with SIP. > > > > > >There are two areas of work that I see a need for: > > > > > >1. Digest authentication. The sterman draft > > >(http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-si > > >p-00.txt) > > >is used quite a bit, it seems. It would be nice to > > standardize on this. > > > > > >2. Prepaid calling. Many folks are using vendor proprietary radius > > >extensiosn to support prepaid calling. It would be nice to > > bring those > > > forward and standardize on them. > > > > > >-Jonathan R. > > > > > >Bernard Aboba wrote: > > > > > >> Is there some particular set of draft(s) that you are > > >advocating work on? > > >> > > >> On Fri, 18 Jul 2003, Liess, Laura wrote: > > >> > > >> > > >>>I think most carriers currently use some kind of RADIUS > > >platform to do user authentication and they would like to > > >reuse it in the future to authenticate their SIP customers. > > >>>My colleagues who are responsible for the RADIUS Platform of > > >the Deutsche Telekom (CC)are currently on vacation so I could > > >not check with them now about how to answer this mail, but we > > >already talked about this issue a number of times and my > > >strong opinion is that "yes, Deutsche Telekom cares a lot > > >about SIP and RADIUS". Reusing the existing RADIUS platform > > >for SIP authentication is a strong requirement for the > > >development of SIP services within the Deutsche Telekom. > > >>> > > >>>Laura (T-Systems/Deutsche Telekom Group) > > >> > > >> > > >> _______________________________________________ > > >> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >> This list is for NEW development of the 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. 600 Lanidex Plaza > >Chief Technology Officer Parsippany, NJ 07054-2711 > >dynamicsoft > >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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 09:12:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11056 for ; Thu, 7 Aug 2003 09:12:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kkYs-0004CE-MB for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 09:12:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77DCAqU016124 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 09:12:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kkYs-0004Bx-HT for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 09:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11046 for ; Thu, 7 Aug 2003 09:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kkYp-0005nQ-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 09:12:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kkYo-0005nN-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 09:12:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kkYj-0004Aw-Cc; Thu, 07 Aug 2003 09:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kkYg-0004Aj-JD for sipping@optimus.ietf.org; Thu, 07 Aug 2003 09:11:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11039 for ; Thu, 7 Aug 2003 09:11:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kkYf-0005nK-00 for sipping@ietf.org; Thu, 07 Aug 2003 09:11:57 -0400 Received: from n197.nomadiclab.com ([131.160.193.197] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 19kkYe-0005nH-00 for sipping@ietf.org; Thu, 07 Aug 2003 09:11:56 -0400 Received: from piuha.net (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h77D8jLQ004462; Thu, 7 Aug 2003 16:08:47 +0300 Message-ID: <3F324F5D.6040903@piuha.net> Date: Thu, 07 Aug 2003 16:08:45 +0300 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich , john.loughney@nokia.com CC: aboba@internaut.com, sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP References: <0HJ9009LH0DFIN@dgismtp05.wcomnet.com> In-Reply-To: <0HJ9009LH0DFIN@dgismtp05.wcomnet.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 Hello folks, I'm not really sure if its productive to debate RADIUS vs. DIAMETER deployment status or deficiences. I don't see them as competing alternatives as much as I see them as complementary approaches. Here's what I'd like to have: 1. Published (RFC) specifications for carrying HTTP Digest over RADIUS. Maybe start from draft-sterman. 2. Published specifications for the same thing and a few additional features over DIAMETER. Start from draft-belinchon, but make it less 3GPP-specific. 3. As a part of 2, interworking specification between RADIUS & DIAMETER (possibly limited to the scope of features supported under 1). 4. Prepaid support module for DIAMETER that can work with any application, such as SIP or network access. This is work in progress, as John noted. 5. Optionally, a prepaid module for RADIUS, constructed in a manner which makes translation to 4 possible. This will enable folks with either RADIUS or DIAMETER servers to put them together with their SIP nodes, and will enable gradual transition from RADIUS to DIAMETER, which will likely take time. The idea is that AAA proxies start supporting both protocols, so you don't have to switch your NASes/ SIP proxies all at the same time. Please also note that SIP is not the only thing where RADIUS vs. DIAMETER issues arise. In network access, for instance, the AAA WG has produced a specification which works over DIAMETER in a manner compatible with the current RADIUS network access usage. Similarly, in EAP authentication over RADIUS can interwork with EAP authentication over DIAMETER, albeit with DIAMETER the security issues related to key transport are easier. --Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 09:28:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11653 for ; Thu, 7 Aug 2003 09:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kkoG-0004oW-TF for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 09:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77DS4hv018497 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 09:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kkoG-0004oG-PD for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 09:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11596 for ; Thu, 7 Aug 2003 09:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kkoE-0005xS-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 09:28:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kkoD-0005xO-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 09:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kkoD-0004my-Nn; Thu, 07 Aug 2003 09:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kknh-0004lw-2b for sipping@optimus.ietf.org; Thu, 07 Aug 2003 09:27:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11563; Thu, 7 Aug 2003 09:27:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kknf-0005wh-00; Thu, 07 Aug 2003 09:27:27 -0400 Received: from [63.163.229.65] (helo=[208.236.204.65]) by ietf-mx with smtp (Exim 4.12) id 19kkna-0005wd-00; Thu, 07 Aug 2003 09:27:23 -0400 Received: from no.name.available by [208.236.204.65] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 7 Aug 2003 09:29:23 -0400 Subject: Re: [Sipping] draft-melanchuk-sipping-msml-00.txt To: Tim Melanchuk Cc: Chris Boulton , Garland Sharratt , sipping@ietf.org, sipping-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: "Vishal Phirke" Date: Thu, 7 Aug 2003 09:24:58 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.12 |February 13, 2003) at 08/07/2003 09:23:03 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Tim, I have question regarding msml. MSML defines three classes of media processing objects, viz., network connection, conference and dialog execution context. Out of these first= two are physical entities within a media server whereas dialog execution context is an abstract thing, and a dialog will be typically bound to a= network connection at the time of creation. The discription of the element says that "A media stream is created between the= dialog execution environment and the connection or conference". I understand the second endpoint but I am not sure what is the definition= of dialog execution environment. As per my understanding, assuming dialog = is made up of MOML constructs such as play and record, the typical require= ment will be to switch the stream between player and recorder. But I can't s= ee how a at dialog level can indicate which resource to connect to.= Can you elaborate more on the dialog execution environment? -Vishal = =20 Tim Melanchuk = =20 =20 m> cc: Garland Sharra= tt , =20 Sent by: = =20 = =20 = =20 = =20 08/06/2003 08:43 = =20 PM = =20 = =20 = =20 thanks for your review and comments! nits will be reflected in the next revision. responses to questions are inline below. cheers, timm Chris Boulton wrote: > - Would any benefit be gained from including an optional 'order' > attribute on primitive elements so that when 'pipe' is used, the ord= er > is determined explicitly rather than following a logical path? > this question is related to MOML. the goal was to provide several simpl= e topology schemas to cover the common use cases. i think that explicit control of topology (i.e. as in mpcp) may be useful. i'm not sure that explicit ordering in this case would have benefit and may introduce additional error cases. did you have any specific benefits in mind? > - Was there a reason that JOIN/UNJOIN were limited to id1 + id2. Co= uld > it not have just been id, that was forced to appear at least twice? > This would allow you to join >2 media streams in one transaction. > simplicity. msml already allows multiple elements to be present in a single transaction. allowing multiple streams to be identified in a single join introduces more complexity and makes failure handling more difficult. > > - element should say that the response code corresponds to = the > SIP response code received for the transaction. > i'm not quite sure what you mean here. the response attribute in is for the msml transaction. it just happens to be carried in the respo= nse to the sip message which conveyed the msml transaction. however msml is= designed to be neutral to the transport mechanism and this correlation may not exist in all cases. > from MSML: Media objects may be defined using MOML or other suitable= media > resource description languages. A media server which supports > and must support MOML and may support other > languages. > > Should this be a 'MUST' or is it not possible to only use another > 'suitable media resource description language' with MSML? > a media resource description language is required. the "must" requires that there be at least one common language to insure interoperability. it does not preclude that other languages are supported. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 10:05:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13363 for ; Thu, 7 Aug 2003 10:05:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19klO5-0006Ia-Im for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 10:05:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77E55m8024211 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 10:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19klO5-0006IQ-DR for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 10:05:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13314 for ; Thu, 7 Aug 2003 10:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19klO3-0006JB-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 10:05:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19klO2-0006J8-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 10:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19klO2-0006HV-IL; Thu, 07 Aug 2003 10:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19klNL-0006GF-FY for sipping@optimus.ietf.org; Thu, 07 Aug 2003 10:04:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13230 for ; Thu, 7 Aug 2003 10:04:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19klNJ-0006J1-00 for sipping@ietf.org; Thu, 07 Aug 2003 10:04:17 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19klNI-0006HL-00 for sipping@ietf.org; Thu, 07 Aug 2003 10:04:16 -0400 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJ9005OU5MA6J@firewall.wcom.com> for sipping@ietf.org; Thu, 07 Aug 2003 14:01:22 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJ9003015D3JJ@dgismtp01.wcomnet.com>; Thu, 07 Aug 2003 14:01:22 +0000 (GMT) Received: from hsinnreich2 ([166.50.142.219]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJ90044G5JEA0@dgismtp01.wcomnet.com>; Thu, 07 Aug 2003 13:59:39 +0000 (GMT) Date: Thu, 07 Aug 2003 08:59:39 -0500 From: Henry Sinnreich Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: <3F324F5D.6040903@piuha.net> To: jarkko@piuha.net, "'Henry Sinnreich'" , john.loughney@nokia.com Cc: aboba@internaut.com, sipping@ietf.org Message-id: <0HJ90044H5JEA0@dgismtp01.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNc5bPHl2ZfkxcdQ/+E6TDDPNy/1QABIxZA 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'm not really sure if its productive to debate RADIUS vs. > DIAMETER deployment status or deficiences. I agree, and we should add WEB SERVICES to the list - probably the most important contender. To get away from this discussion, the draft on SIP-AAA needs an additional chapter with an objective comparison on various options, and to discuss the pros and cons of such as RADIUS, DIAMETER and WEB SERVICES. (BTW: Is there a lack of expertise on web services in the SIPPING WG? Some well know WEB SERVICES vendors come to my mind...Invite them?) A discussion of options is the only basis on which to proceed IMHO. Comments? Thanks, Henry > -----Original Message----- > From: Jari Arkko [mailto:jarkko@piuha.net] > Sent: Thursday, August 07, 2003 8:09 AM > To: Henry Sinnreich; john.loughney@nokia.com > Cc: aboba@internaut.com; sipping@ietf.org > Subject: Re: AW: [Sipping] FYI: RADIUS & SIP > > > Hello folks, > > I'm not really sure if its productive to debate RADIUS vs. > DIAMETER deployment status or deficiences. I don't see > them as competing alternatives as much as I see them > as complementary approaches. > > Here's what I'd like to have: > > 1. Published (RFC) specifications for carrying HTTP > Digest over RADIUS. Maybe start from draft-sterman. > 2. Published specifications for the same thing and > a few additional features over DIAMETER. Start from > draft-belinchon, but make it less 3GPP-specific. > 3. As a part of 2, interworking specification > between RADIUS & DIAMETER (possibly limited > to the scope of features supported under 1). > 4. Prepaid support module for DIAMETER that can > work with any application, such as SIP or network > access. This is work in progress, as John noted. > 5. Optionally, a prepaid module for RADIUS, > constructed in a manner which makes translation > to 4 possible. > > This will enable folks with either RADIUS or > DIAMETER servers to put them together with their > SIP nodes, and will enable gradual transition from > RADIUS to DIAMETER, which will likely take time. The > idea is that AAA proxies start supporting both > protocols, so you don't have to switch your NASes/ > SIP proxies all at the same time. > > Please also note that SIP is not the only thing > where RADIUS vs. DIAMETER issues arise. In network > access, for instance, the AAA WG has produced a > specification which works over DIAMETER in a manner > compatible with the current RADIUS network access > usage. Similarly, in EAP authentication over RADIUS > can interwork with EAP authentication over DIAMETER, > albeit with DIAMETER the security issues related to > key transport are easier. > > --Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 11:05:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17966 for ; Thu, 7 Aug 2003 11:05:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmKN-0000dJ-Pw for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 11:05:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77F5JRv002432 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 11:05:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmKN-0000d9-J5 for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 11:05:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17959 for ; Thu, 7 Aug 2003 11:05:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmKK-0007NC-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 11:05:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kmKK-0007N9-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 11:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmK5-0000c8-2U; Thu, 07 Aug 2003 11:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmJJ-0000au-Od for sipping@optimus.ietf.org; Thu, 07 Aug 2003 11:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17918 for ; Thu, 7 Aug 2003 11:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmJH-0007ME-00 for sipping@ietf.org; Thu, 07 Aug 2003 11:04:11 -0400 Received: from [168.226.49.107] (helo=mail3.telefonica.com.ar) by ietf-mx with esmtp (Exim 4.12) id 19kmJG-0007MA-00 for sipping@ietf.org; Thu, 07 Aug 2003 11:04:10 -0400 Received: from mailhub.telefonica.com.ar ([10.249.7.11]) by mail3 with InterScan Messaging Security Suite; Thu, 07 Aug 2003 12:04:05 -0300 Received: by MAILHUB with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 12:04:04 -0300 Message-ID: From: De Leo Walter To: "'sipping@ietf.org'" Subject: RE: [Sipping] draft-melanchuk-sipping-moml-00.txt Date: Thu, 7 Aug 2003 12:03:52 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable I am interested in knowing if this drafat an msml draft will be = proposed as workgroup items. I think it should there are some proprietary solutions for ms cotnrol = over SIP. Regards > -----Mensaje original----- > De: Tim Melanchuk [SMTP:timm@convedia.com] > Enviado el: Mi=E9rcoles 6 de Agosto de 2003 21:46 > Para: Chris Boulton > CC: Garland Sharratt; sipping@ietf.org > Asunto: Re: [Sipping] draft-melanchuk-sipping-moml-00.txt >=20 > thanks again for your feedback. answers to questions below. >=20 > cheers, > timm >=20 > >=20 > > - Is there an alternative method for defining unlimited occurrences = > > using the 'max' attribute =3D 0 (e.g. pattern element uses max = within DTMF >=20 > > primitive). This seemed a little confusing. > >=20 > i've had this comment from others. would extending the datatype > to include an explicit "unlimited" value be less confusing and/or > renaming "max" to "maxoccurs"? >=20 > >=20 > > - 4.5.1.1 The description of and needs to be = made=20 > > more explicit. > >=20 > will do. >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 11:10:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18146 for ; Thu, 7 Aug 2003 11:10:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmOz-0001Ip-93 for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 11:10:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77FA5mW005001 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 11:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmOx-0001G9-OX for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 11:10:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18125 for ; Thu, 7 Aug 2003 11:09:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmOv-0007Pu-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 11:10:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kmOu-0007Pr-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 11:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmOv-0001FB-PZ; Thu, 07 Aug 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmOr-0001EY-Cr for sipping@optimus.ietf.org; Thu, 07 Aug 2003 11:09:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18120 for ; Thu, 7 Aug 2003 11:09:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmOo-0007Pn-00 for sipping@ietf.org; Thu, 07 Aug 2003 11:09:54 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19kmOn-0007Pc-00 for sipping@ietf.org; Thu, 07 Aug 2003 11:09:53 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HJ9001018Q5N8@siemenscomms.co.uk> for sipping@ietf.org; Thu, 07 Aug 2003 16:08:29 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HJ90015B8Q3J8@siemenscomms.co.uk>; Thu, 07 Aug 2003 16:08:27 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 07 Aug 2003 16:09:13 +0100 Content-return: allowed Date: Thu, 07 Aug 2003 16:09:43 +0100 From: "Elwell, John" To: "'Francois Audet'" , "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: WGLC for draft-ietf-sipping-qsig2sip-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: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Francois, In-line. Regards, John - Section 8.3.1, page 19 5th paragraph: Add ", unless the gateway is aware that in-band information will not be used" to the end of the paragraph. The reason for this is that there are cases where the gateway may have a priori-knowledge that in-band tones and announcements are not used; and out-of-band ALERTING or fast connection (i.e., no PROGRESS and no ALERTING) is always used for example. In that case, there is no reason to reject the call with 488 if the SDP was not included in the INVITE. [JRE] I agree that if there is a priori knowledge that in-band tones and announcements will not be used, then what you propose is reasonable. I am rather doubtful that the gateway will have sufficient knowledge to determine this. The 4th and 5th paragraphs of 8.3.3 mandate the connection of media streams if relevant QSIG progress indicators are present in a PROGRESS or ALERTING message. The presence of these progress indicators is outside the control of the gateway. So how can the gateway have a priori knowledge that these progress indicators will not be received? [FA]I'm talking about the gateway RECEIVING the SETUP, not the one sending it. [JRE]You referred originally to 8.3.1, which deals with receiving INVITE / sending SETUP, not receiving SETUP. From the rest of your remarks below I assume you really do mean 8.3.1 and the gateway receiving the INVITE / sending the SETUP. [FA]The case I am thinking of is then the Gateway is an IP PBX (with SIP on one side, QSIG on the other). If the call terminates on a local phone, it may use out-of-band ringing (our PBXs work that way). If we want to be picky about the meaning of Gateway, and dissociate the gateway from the actual QSIG PBX, then it can still happen. The gateway may decide to map the INVITE to SETUP anyways and forward it to the QSIG PBX. If the PBX responds with the ALERTING indicating out-of-band, everything is fine (which is why I would like this change). If on the other hand, the ALERTING indicates in-band, then the gateway could decide to do as per your procedure and send the 488. But I wouldn't want to mandate 488 everytime the SDP is not in the INVITE, especially since it is a very normal occurence in SIP. [JRE] I would not want to send 488 after receiving a QSIG ALERTING or PROGRESS message indicating in-band information, because by then the called user in the QSIG network might already be being alerted and it would not be good practice to cancel the call at this stage. [FA]Even for the second case, where the call ultimately terminates on a line with an in-band signalling, I am not convinced at all that the qsig2sip draft should mandate that the call be terminated. To me this should be a design option. An implementer may decide that it prefers to go through with the call, and provide some sort of indication to the user that the call is "progressing" instead of failing the call (I expect that a proper SIP implemenation would do something like that). I would prefer that the paragraph does not mandate the 488 as other options are doable, and probably much less drastic than call failure (as an out-of-band progress indication would be). [JRE] On reflection I can see some merit in allowing the call to proceed, even though we cannot guarantee that in-band information will be passed to the caller. If the caller is a user of a SIP device of some sort, even if we pass in-band information back through the SIP network, there is no guarantee that the SIP device will play it to the user. On the other hand, if there is another legacy network on the originating side of the SIP network, it will of course be able to pass in-band information and the SIP network (using unreliable provisional responses) would be the sole cause of failure to pass in-band information end-to-end. In the case of another QSIG network we have mandated support for 100rel (see 8.2.1.1) anyway. So on balance I think I could agree to relax the rules concerning a 488. I propose making it a SHOULD and including the text: "A gateway that has a priori knowledge that essential in-band information will not need to be sent before answer can choose to proceed with the call in these circumstances." _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 11:42:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19286 for ; Thu, 7 Aug 2003 11:42:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmu5-0002sG-7S for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 11:42:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77FgDgp011045 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 11:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmu4-0002s4-Q3 for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 11:42:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19275 for ; Thu, 7 Aug 2003 11:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmu3-0007lh-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 11:42:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kmu3-0007le-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 11:42:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmtt-0002qC-NI; Thu, 07 Aug 2003 11:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmtL-0002pE-9V for sipping@optimus.ietf.org; Thu, 07 Aug 2003 11:41:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19247 for ; Thu, 7 Aug 2003 11:41:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmtK-0007kz-00 for sipping@ietf.org; Thu, 07 Aug 2003 11:41:26 -0400 Received: from [138.26.5.241] (helo=uabexmb1.ad.uab.edu) by ietf-mx with esmtp (Exim 4.12) id 19kmtJ-0007kw-00 for sipping@ietf.org; Thu, 07 Aug 2003 11:41:25 -0400 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" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sipping] FYI: RADIUS & SIP Date: Thu, 7 Aug 2003 10:41:24 -0500 Message-ID: <4297DD64C36B80448637DC966CB492AE01159B1E@UABEXMB1.ad.uab.edu> Thread-Topic: AW: [Sipping] FYI: RADIUS & SIP Thread-Index: AcNc5bPHl2ZfkxcdQ/+E6TDDPNy/1QABIxZAAAPe6IA= From: "Jill B Gemmill" To: "Henry Sinnreich" , , Cc: , Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Why not include PKI (digital certificates) and API to Peterson's Authentication Service http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-01.txt in the options space? > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > Sent: Thursday, August 07, 2003 9:00 AM > To: jarkko@piuha.net; 'Henry Sinnreich'; john.loughney@nokia.com > Cc: aboba@internaut.com; sipping@ietf.org > Subject: RE: AW: [Sipping] FYI: RADIUS & SIP >=20 > > I'm not really sure if its productive to debate RADIUS vs. > > DIAMETER deployment status or deficiences. >=20 > I agree, and we should add WEB SERVICES to the list - probably the most > important contender. To get away from this discussion, the draft on SIP- > AAA > needs an additional chapter with an objective comparison on various > options, > and to discuss the pros and cons of such as RADIUS, DIAMETER and WEB > SERVICES. (BTW: Is there a lack of expertise on web services in the > SIPPING > WG? Some well know WEB SERVICES vendors come to my mind...Invite them?) >=20 > A discussion of options is the only basis on which to proceed IMHO. >=20 > Comments? >=20 > Thanks, Henry >=20 > > -----Original Message----- > > From: Jari Arkko [mailto:jarkko@piuha.net] > > Sent: Thursday, August 07, 2003 8:09 AM > > To: Henry Sinnreich; john.loughney@nokia.com > > Cc: aboba@internaut.com; sipping@ietf.org > > Subject: Re: AW: [Sipping] FYI: RADIUS & SIP > > > > > > Hello folks, > > > > I'm not really sure if its productive to debate RADIUS vs. > > DIAMETER deployment status or deficiences. I don't see > > them as competing alternatives as much as I see them > > as complementary approaches. > > > > Here's what I'd like to have: > > > > 1. Published (RFC) specifications for carrying HTTP > > Digest over RADIUS. Maybe start from draft-sterman. > > 2. Published specifications for the same thing and > > a few additional features over DIAMETER. Start from > > draft-belinchon, but make it less 3GPP-specific. > > 3. As a part of 2, interworking specification > > between RADIUS & DIAMETER (possibly limited > > to the scope of features supported under 1). > > 4. Prepaid support module for DIAMETER that can > > work with any application, such as SIP or network > > access. This is work in progress, as John noted. > > 5. Optionally, a prepaid module for RADIUS, > > constructed in a manner which makes translation > > to 4 possible. > > > > This will enable folks with either RADIUS or > > DIAMETER servers to put them together with their > > SIP nodes, and will enable gradual transition from > > RADIUS to DIAMETER, which will likely take time. The > > idea is that AAA proxies start supporting both > > protocols, so you don't have to switch your NASes/ > > SIP proxies all at the same time. > > > > Please also note that SIP is not the only thing > > where RADIUS vs. DIAMETER issues arise. In network > > access, for instance, the AAA WG has produced a > > specification which works over DIAMETER in a manner > > compatible with the current RADIUS network access > > usage. Similarly, in EAP authentication over RADIUS > > can interwork with EAP authentication over DIAMETER, > > albeit with DIAMETER the security issues related to > > key transport are easier. > > > > --Jari >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 12:26:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21187 for ; Thu, 7 Aug 2003 12:26:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knaX-0005Rg-Gd for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 12:26:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77GQ5es020928 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 12:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knaX-0005RT-DZ for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 12:26:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21174 for ; Thu, 7 Aug 2003 12:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knaU-0000SU-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 12:26:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19knaT-0000SR-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 12:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knaT-0005QY-SR; Thu, 07 Aug 2003 12:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knaM-0005QA-C8 for sipping@optimus.ietf.org; Thu, 07 Aug 2003 12:25:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21169 for ; Thu, 7 Aug 2003 12:25:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knaK-0000SN-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:25:52 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19knaJ-0000SJ-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:25:52 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id D577A43DE; Thu, 7 Aug 2003 18:20:25 +0200 (CEST) Received: from jku07.iptel.org (dhcp114.fokus.fraunhofer.de [195.37.78.114]) by fox.iptel.org (Postfix) with ESMTP id C78C25A7; Thu, 7 Aug 2003 18:20:24 +0200 (CEST) Message-Id: <5.2.0.9.0.20030807180926.053e0eb8@mailhost.fokus.gmd.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 07 Aug 2003 18:11:01 +0200 To: "Liess, Laura" From: Jiri Kuthan Subject: Re: AW: AW: [Sipping] FYI: RADIUS & SIP Cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, aboba@internaut.com, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" In-Reply-To: <43240544763FB8479F1529372F6197CF053CC910@G8PQC.blf01.telek om.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.1 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , There is a believe in the IETF that lack of reliability in RADIUS determines this work to be dropped. (Authentication is a different story, though.) As for us, we took freedom not to wait until a solid answer exists and implemented this draft. -jiri At 10:17 AM 8/6/2003, Liess, Laura wrote: >What about the accounting draft draft-schulzrinne-accounting-sip-01.txt? Any reason for not working on it? >Laura > >>-----Ursprungliche Nachricht----- >>Von: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] >>Gesendet: Dienstag, 5. August 2003 18:00 >>An: Jonathan Rosenberg; Bernard Aboba >>Cc: Liess, Laura; hgs@cs.columbia.edu; sipping@ietf.org; Dumler, >>Alexander; Wolff, Christian >>Betreff: Re: AW: [Sipping] FYI: RADIUS & SIP >> >> >>Thanks, I very much agree; we have received identical feedback so far. >> >>-jiri >> >>At 08:12 PM 7/29/2003, Jonathan Rosenberg wrote: >>>I know of several carriers with RADIUS infrastructures that >>want to use them to support SIP. They are currently using >>expired I-Ds and proprietary attributes. As a result, I would >>strongly advocate work on standardizing RADIUS usage with SIP. >>> >>>There are two areas of work that I see a need for: >>> >>>1. Digest authentication. The sterman draft >>(http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-si >>p-00.txt) is used quite a bit, it seems. It would be nice to >>standardize on this. >>> >>>2. Prepaid calling. Many folks are using vendor proprietary >>radius extensiosn to support prepaid calling. It would be nice >>to bring those forward and standardize on them. >>> >>>-Jonathan R. >>> >>>Bernard Aboba wrote: >>> >>>>Is there some particular set of draft(s) that you are >>advocating work on? >>>>On Fri, 18 Jul 2003, Liess, Laura wrote: >>>> >>>>>I think most carriers currently use some kind of RADIUS >>platform to do user authentication and they would like to >>reuse it in the future to authenticate their SIP customers. >>>>>My colleagues who are responsible for the RADIUS Platform >>of the Deutsche Telekom (CC)are currently on vacation so I >>could not check with them now about how to answer this mail, >>but we already talked about this issue a number of times and >>my strong opinion is that "yes, Deutsche Telekom cares a lot >>about SIP and RADIUS". Reusing the existing RADIUS platform >>for SIP authentication is a strong requirement for the >>development of SIP services within the Deutsche Telekom. >>>>> >>>>>Laura (T-Systems/Deutsche Telekom Group) >>>> >>>>_______________________________________________ >>>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>>This list is for NEW development of the 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. 600 Lanidex Plaza >>>Chief Technology Officer Parsippany, NJ 07054-2711 >>>dynamicsoft >>>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 >> -- Jiri Kuthan http://iptel.org/~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 exim@www1.ietf.org Thu Aug 7 12:38:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21495 for ; Thu, 7 Aug 2003 12:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knm9-0006DV-Ek for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 12:38:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Gc5xQ023891 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 12:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knm9-0006D7-B0 for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 12:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21474 for ; Thu, 7 Aug 2003 12:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knm7-0000X4-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 12:38:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19knm6-0000X1-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 12:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knm7-0006Bm-Ib; Thu, 07 Aug 2003 12:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knli-00065T-Em for sipping@optimus.ietf.org; Thu, 07 Aug 2003 12:37:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21454 for ; Thu, 7 Aug 2003 12:37:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knlg-0000Wj-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:37:36 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19knlf-0000Wg-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:37:35 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 31E2C43DE; Thu, 7 Aug 2003 18:32:10 +0200 (CEST) Received: from jku07.iptel.org (dhcp114.fokus.fraunhofer.de [195.37.78.114]) by fox.iptel.org (Postfix) with ESMTP id E2DEA5A7; Thu, 7 Aug 2003 18:32:08 +0200 (CEST) Message-Id: <5.2.0.9.0.20030807181338.01d1afd0@mailhost.fokus.gmd.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 07 Aug 2003 18:33:28 +0200 To: David Schwartz , "'sipping@ietf.org'" From: Jiri Kuthan Subject: RE: [Sipping] Re: Update to 3pcc In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.5 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , David, ok, I must thave misunderstood your argument. So you are saying prepaid providers need a b2bua for teardown anyhow, so why to bother about REFER? A quick answer is that in an open-service model, there may be other parties than the prepaid provider and these parties may prefer a simple technology over b2bua. And since REFER is technically better, I'm no way happy about calling it BCP in IETF. More details: - c-t-d may be implemented somewhere completely else than prepaid is. For example, prepaid b2bua is in front of your gateway, C-T-D is an application at caller's PC. - Since the prepaid and ctd applications live somewhere else, there is no reason to dictate use of a b2bua mechanism for ctd. Caller simply prefers a simple utility over a B2BUA. - And since REFER is imho doing a better job for ctd (think for example about the ringing problem), there is no reason to call a B2BUA-based construct BCP. I'm not opposed to b2bua middlebox in general -- there are certainly applications which are hard to achieve otherwise, prepaid one of them. What I'm saying is that a BCP should show examples which are really _Best_ Current Practices. That's simply not the case with b2bua/ctd. -Jiri At 08:17 AM 8/6/2003, David Schwartz wrote: >Hi Jiri. > >I was referring specifically to the call teardown issue associated with most >pre-paid billing models. > >David > >-----Original Message----- >From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] >Sent: Tue, August 05, 2003 7:39 PM >To: David Schwartz; 'sipping@ietf.org' >Subject: Re: [Sipping] Re: Update to 3pcc > > >Hello David, > >I don't see how billing servers are related to method of >call initiation. > >Actually I believe that how a call is initiated (by manual >dialing a destination, by REFER-based click-to-dial, by b2bua-based >click-to-dial, CTI, etc.) is completely orthogonal to how the >call is charged for. Regardless what charging system you use >(if any), there will be different methods for initiating calls, >some will be better off than others. I maintain that a click-to-dial >b2bua is not a BCP. > >-jiri > >At 10:10 AM 7/30/2003, David Schwartz wrote: >>Hi Jiri >> >>REFER is good solution if you assume that either there are no billing >>issues, or alternatively, that the endpoint/s handle the billing issues. If >>this is not the case, for example, in an application where a centralized >>controller is setting up a call to two PSTN numbers, then you will need a >>centralized billing entity and REFER will not suffice. >> >>David >> >>-----Original Message----- >>From: sipping-request@ietf.org [mailto:sipping-request@ietf.org] >>Sent: Mon, July 28, 2003 7:00 PM >>To: sipping@ietf.org >>Subject: Sipping digest, Vol 1 #1144 - 2 msgs >> >> >>Send Sipping mailing list submissions to >> sipping@ietf.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://www1.ietf.org/mailman/listinfo/sipping >>or, via email, send a message with subject or body 'help' to >> sipping-request@ietf.org >> >>You can reach the person managing the list at >> sipping-admin@ietf.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of Sipping digest..." >> >> >>Today's Topics: >> >> 1. Re: Diversion header (Cullen Jennings) >> 2. Re: Update to 3pcc (Jiri Kuthan) >> >>--__--__-- >> >>Message: 1 >>Date: Sun, 27 Jul 2003 19:05:10 -0700 >>Subject: Re: [Sipping] Diversion header >>From: Cullen Jennings >>To: Romel Khan , >> >> >>I assume your question is there some way for for the final destination >that >>receives the call to know the who the 1st callee was that had some device >in >>the network redirect the call elsewhere. >> >>The answer is YES - there has been a lot of confusion over this so think >>about my answer carefully - it will seem counter intuitive at first. The >>answer is the "To" header but it will take me a second to explain why. >> >>Imagine case 1 where A send a call to proxy B, that sent to to C. Now C >>sent a 302 back B and B then forked the call to D. The To header in the >>message D receives will still have the To set to C. C is the element that >>sent the first 302. >> >>Now imagine a case (like your question) where there is not a recursive >>proxy. The 302 will go all the way back to A. Now A forms a new invite to >>but it can leave the To header set to the same thing it was in the original >>message (C in this case). When the message arrives at D, the To header will >>be set to C. >> >>If D was a voice mail system, it might be able to know to act on behalf of >C >>instead of some other entity. >> >>There are more complex things that relate to your request. Mary Barnes has >>been moving the history work along >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-04.txt >> >>There is some work on QSIG mappings with diversion >>http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-diversion >- >>00.txt >> >>There is a draft-levy-sip-diversion which I (and many others) believe has a >>pretty much zero chance of being accepted or becoming a RFC. This work has >>been superceded by the history work. Quite a few people do not support the >>history work and it is moving very slowly. Don't expect any of this to >>resolve quickly. >> >>Give some careful thought to if the "To" header meets your needs and if it >>does use - The To header is widely implemented :-) >> >> >>Cullen >> >> >> >> >>On 7/21/03 8:55, "Romel Khan" wrote: >> >>> Is there any SIP header defined in any SIP RFC or Internet Draft that can >>> include the address of the 1st callee, who redirected the call using 302, >>in >>> the 2nd outgoing INVITE? >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> >> >> >>--__--__-- >> >>Message: 2 >>Date: Mon, 28 Jul 2003 10:17:51 +0200 >>To: Jonathan Rosenberg , sipping > >>From: Jiri Kuthan >>Subject: Re: [Sipping] Update to 3pcc >> >>I'm actually not convinced that it is proper to show click-to-dial >>as a motivating example for use of b2bua and label it BCP. >> >>Use of REFER seems technically a superior solution worth being called >>BCP. Roots of the advantages are in a better application of e2e principle. >>REFER takes no middle-box b2bua -- it delegates signaling to end-points. >>Advantages include: >>- All the pitfalls with media are so straigforward, they don't even >> need to be described (like now in sessions 8 and 9). >>- It takes no media server to transmit ringing tone. >>- There are no SDP compatibility issues on controller's side. >> >>-jiri >> >>At 07:51 PM 7/8/2003, Jonathan Rosenberg wrote: >>>Folks, >>> >>>You may have noticed that I posted an update to the 3pcc spec: >>> >>>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.txt >>>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.html >>>http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.txt >>> >>>The update is based on comments received from IESG while reviewing the >>draft. In particular, there were problems with the usage of 0.0.0.0 to >>imply that no media nor RTCP should be sent. This IP address is not meant >>for that purpose. Rather, the .invalid TLD is much better suited. So, I >>changed the draft to make use of .invalid in flows where the controller >>doesnt want media to be sent. >>> >>>Now, there are some concerns with that which folks need to be aware of: >>> >>>1. It is at odds with RFC 3264, which actually recommends 0.0.0.0. In >fact, >>the problem is really with RFC 3264, NOT 3pcc. However, 3264 is done, and >>this one isnt. I logged a bug against RFC 3264 on this, and we'll need to >>work on a way to transition folks towards using .invalid and not 0.0.0.0. >>> >>>2. One the premises of 3pcc is that it should be compatible with any UA >>that is RFC 3261 compliant. If a controller uses .invalid in the SDP, I am >>not sure what a SIP endpoint would do. I don't believe anything in RFC 3264 >>or in SIP talks about handling the case where there is an issue with a >>domain name in the SDP. As such, if you use .invalid, there could be >interop >>problems. The document mentions this. >>> >>>Comments or questions welcome. >>> >>>Thanks, >>>Jonathan R. >>>-- >>>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>Chief Technology Officer Parsippany, NJ 07054-2711 >>>dynamicsoft >>>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 >> >>-- >>Jiri Kuthan http://iptel.org/~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 >> >>End of Sipping Digest >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP -- Jiri Kuthan http://iptel.org/~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 exim@www1.ietf.org Thu Aug 7 12:38:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21498 for ; Thu, 7 Aug 2003 12:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knm9-0006DG-CH for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 12:38:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Gc5bw023875 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 12:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knm9-0006D0-3p for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 12:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21470 for ; Thu, 7 Aug 2003 12:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knm7-0000X0-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 12:38:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19knm6-0000Wx-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 12:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knm6-0006Ag-2W; Thu, 07 Aug 2003 12:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knlH-0005y0-1I for sipping@optimus.ietf.org; Thu, 07 Aug 2003 12:37:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21438 for ; Thu, 7 Aug 2003 12:37:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knlF-0000WX-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:37:09 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19knlE-0000WG-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:37:08 -0400 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJ900K2DCO7KL@firewall.wcom.com> for sipping@ietf.org; Thu, 07 Aug 2003 16:33:43 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJ900D01CNTR3@dgismtp05.wcomnet.com>; Thu, 07 Aug 2003 16:33:43 +0000 (GMT) Received: from hsinnreich2 ([166.50.143.246]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJ900BOTCO54Y@dgismtp05.wcomnet.com>; Thu, 07 Aug 2003 16:33:42 +0000 (GMT) Date: Thu, 07 Aug 2003 11:33:42 -0500 From: Henry Sinnreich Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: <4297DD64C36B80448637DC966CB492AE01159B1E@UABEXMB1.ad.uab.edu> To: "'Jill B Gemmill'" , "'Henry Sinnreich'" , jarkko@piuha.net, john.loughney@nokia.com Cc: aboba@internaut.com, sipping@ietf.org Message-id: <0HJ900BOUCO54Y@dgismtp05.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNc5bPHl2ZfkxcdQ/+E6TDDPNy/1QABIxZAAAPe6IAAAfGIUA== 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 > Why not include PKI (digital certificates) and API to Peterson's > Authentication Service Excellent suggestion! We have now four options to discuss in the SIP-AAA I-D. Thanks, Henry > -----Original Message----- > From: Jill B Gemmill [mailto:JGemmill@uab.edu] > Sent: Thursday, August 07, 2003 10:41 AM > To: Henry Sinnreich; jarkko@piuha.net; john.loughney@nokia.com > Cc: aboba@internaut.com; sipping@ietf.org > Subject: RE: AW: [Sipping] FYI: RADIUS & SIP > > Why not include PKI (digital certificates) and API to Peterson's > Authentication Service > http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-01.txt in > the options space? > > > -----Original Message----- > > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > Sent: Thursday, August 07, 2003 9:00 AM > > To: jarkko@piuha.net; 'Henry Sinnreich'; john.loughney@nokia.com > > Cc: aboba@internaut.com; sipping@ietf.org > > Subject: RE: AW: [Sipping] FYI: RADIUS & SIP > > > > > I'm not really sure if its productive to debate RADIUS vs. > > > DIAMETER deployment status or deficiences. > > > > I agree, and we should add WEB SERVICES to the list - probably the > most > > important contender. To get away from this discussion, the draft on > SIP- > > AAA > > needs an additional chapter with an objective comparison on various > > options, > > and to discuss the pros and cons of such as RADIUS, DIAMETER and WEB > > SERVICES. (BTW: Is there a lack of expertise on web services in the > > SIPPING > > WG? Some well know WEB SERVICES vendors come to my mind...Invite > them?) > > > > A discussion of options is the only basis on which to proceed IMHO. > > > > Comments? > > > > Thanks, Henry > > > > > -----Original Message----- > > > From: Jari Arkko [mailto:jarkko@piuha.net] > > > Sent: Thursday, August 07, 2003 8:09 AM > > > To: Henry Sinnreich; john.loughney@nokia.com > > > Cc: aboba@internaut.com; sipping@ietf.org > > > Subject: Re: AW: [Sipping] FYI: RADIUS & SIP > > > > > > > > > Hello folks, > > > > > > I'm not really sure if its productive to debate RADIUS vs. > > > DIAMETER deployment status or deficiences. I don't see > > > them as competing alternatives as much as I see them > > > as complementary approaches. > > > > > > Here's what I'd like to have: > > > > > > 1. Published (RFC) specifications for carrying HTTP > > > Digest over RADIUS. Maybe start from draft-sterman. > > > 2. Published specifications for the same thing and > > > a few additional features over DIAMETER. Start from > > > draft-belinchon, but make it less 3GPP-specific. > > > 3. As a part of 2, interworking specification > > > between RADIUS & DIAMETER (possibly limited > > > to the scope of features supported under 1). > > > 4. Prepaid support module for DIAMETER that can > > > work with any application, such as SIP or network > > > access. This is work in progress, as John noted. > > > 5. Optionally, a prepaid module for RADIUS, > > > constructed in a manner which makes translation > > > to 4 possible. > > > > > > This will enable folks with either RADIUS or > > > DIAMETER servers to put them together with their > > > SIP nodes, and will enable gradual transition from > > > RADIUS to DIAMETER, which will likely take time. The > > > idea is that AAA proxies start supporting both > > > protocols, so you don't have to switch your NASes/ > > > SIP proxies all at the same time. > > > > > > Please also note that SIP is not the only thing > > > where RADIUS vs. DIAMETER issues arise. In network > > > access, for instance, the AAA WG has produced a > > > specification which works over DIAMETER in a manner > > > compatible with the current RADIUS network access > > > usage. Similarly, in EAP authentication over RADIUS > > > can interwork with EAP authentication over DIAMETER, > > > albeit with DIAMETER the security issues related to > > > key transport are easier. > > > > > > --Jari > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 12:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21802 for ; Thu, 7 Aug 2003 12:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knuq-0006qu-Pc for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 12:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Gl4tc026334 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 12:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knuq-0006qf-K0 for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 12:47:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21782 for ; Thu, 7 Aug 2003 12:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knuo-0000ca-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 12:47:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19knuo-0000cX-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 12:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knuo-0006pZ-51; Thu, 07 Aug 2003 12:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knuS-0006ol-64 for sipping@optimus.ietf.org; Thu, 07 Aug 2003 12:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21762 for ; Thu, 7 Aug 2003 12:46:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knuQ-0000c6-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:46:38 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail2.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 19knuP-0000bf-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:46:37 -0400 Received: from bsf.alcatel.fr (mail205.dit.sxb.bsf.alcatel.fr [155.132.205.115]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id h77GdFCr013766 for ; Thu, 7 Aug 2003 18:39:15 +0200 Received: from mail (mail-bsf-alcatel-fr.dit.sxb.bsf.alcatel.fr [155.132.205.91]) by bsf.alcatel.fr (8.8.8+Sun/8.9.3) with ESMTP id SAA13104 for ; Thu, 7 Aug 2003 18:39:15 +0200 (MET DST) Received: from bst.bsf.alcatel.fr ([155.132.76.46]) by mail (8.8.8+Sun/) with ESMTP id SAA13096; Thu, 7 Aug 2003 18:39:14 +0200 (MET DST) Message-ID: <3F328066.F0496864@bst.bsf.alcatel.fr> Date: Thu, 07 Aug 2003 18:37:58 +0200 From: Jean-Francois Rey Organization: Alcatel X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: "Elwell, John" CC: sipping@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Comments on draft-ietf-sipping-qsig2sip-01.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 Hi John, I agree with your replies to my comments. More details in-line. regards, Jean-Francois. "Elwell, John" wrote : > > Jean-Francois, > > Thanks for your comments. I have dealt with most of the editorials. My > responses to your technical comments: > > > #4 - Page 10 - 7 General requirements > "As a result of DNS look-up by the gateway in order to determine where > to send a SIP INVITE request, a number of candidate destinations can > be attempted in sequence. The way in which this is handled by the > gateway is outside the scope of this specification. However, any > behaviour specified in this document on receipt of a SIP final > response SHOULD apply only when there are no more candidate > destinations to try." > > Does it mean that the ingress gateway SHOULD try the next retrieved > addresses if > the first one responded 484 for instance ? I guess that rfc3263 narrows the > scope to "network" or "component" failures. > [JRE] I guess when overlap signalling applies in the SIP network the > statement is not quite true, so I will make an exception. Also I believe the > statement is not applicable to 3xx or 6xx responses, so I will limit it to > 4xx and 5xx responses. Does this cover all the situations you had in mind? I guess that this behaviour is not specific to qsig2sip, so I'm not sure it is a good idea to mention it. > > #6 - Page 14 - 8.2.1.3 Receipt of SIP 18x provisional response > "NOTE 2. Media streams are established as a result of receiving SDP > answer information in a reliable provisional response and can be " > > I agree that reliable provisional response are better, but why use reliable > here > ? If a UA that does not support PRACK sends a 183 with a SDP body, the media > stream is established too. > [JRE] You are correct. However, the text concerned talks about SDP answer > but media streams can also be established at this time by means of SDP offer > in a provisional response. The text fails to mention this. According to > RFC3261 section 13.2.1 an unreliable provisional response cannot be used for > SDP offer. I will clarify the statement. Also subsequent modification of the > session by means of UPDATE applies only after a offer has been received in a > reliable message and answer has been sent, so this too would need > qualifying. However, it is not really necessary to mention UPDATE so perhaps > that part can be deleted. [JFR] I agree that it would be better to remove it. > #9 - Page 24 - 8.3.9 > "If a gateway receives a SIP INVITE request for a new dialog with the > same Call-ID as an existing SIP INVITE request for which the gateway > > has not yet sent a final response and failing to meet the other > conditions above concerning overlap sending, the gateway SHALL > respond to the new request with a SIP 485 (Ambiguous) response." > It's not very important, but could you explain the motivation of this > sentence. > Is it related to the merged requests ? > [JRE] Its purpose is to prescribe behaviour if the gateway receives an > INVITE request that in all respects looks like overlap sending but fails to > meet the criterion of the derived called party number being a superset of > the previously derived called party number. [JFR] OK. Now, I undertand what you meant. No need to change anything. > #10 - Page 24 - 8.4.1 > "as specified in table 1." > Why aren't some status codes symetric in table 1 and table 2. For instance > - 408 Request timeout maps 102 Recovery on timer expiry and > - 102 Recovery on timer expiry maps 504 Server time-out. > BTW, I like the way table 2 is similar to what RFC3398 describes. > [JRE] 504 also maps to 102, but it is not possible to make 102 map to both > 408 and 504 - we had to pick one. This illustrates the point that there is > not a 1:1 correspondence between SIP responses and Q.850 causes and > therefore there will be some asymmetries and some rather questionable > mappings. Cause mapping was discussed long and hard for ISUP interworking > and again for QSIG interworking (resulting in some changes to ISUP > interworking to keep alignment). It is not perfect and it never will be, but > I would be reluctant to open up the discussion again. I hope you can live > with what we have. [JFR] You are correct. Since it is not a 1:1 mapping, a choice must be made. It suits me. > And some remarks regarding other SIPPING drafts > > #1 draft-ietf-sipping-overlap-04.txt > It says : > "However, overlap signalling adds a requirement to this process. As a > general rule, a media stream corresponding to the response to an > INVITE with a greater number of digits should be given more priority > than media streams from responses with less digits." > > Is this requirement applicable here ? > [JRE] I remember this was discussed and we thought it best not to try to > give guidance in this tricky situation. > [JFR] OK. > #2 draft-ietf-sipping-pstn-call-flows-02.txt 2.2, 4.2 > > I know that qsig2sip deals with QSIG only, but don't you think that people > might > get confused by the slight difference in the mapping of the messages of the > "ISDN PBX" examples of the call-flow draft ? > [JRE] There are of course some differences between QSIG and Q.931 that can > have impact on the mapping. Also I am not sure of the status of the > call-flows draft and in particular the two examples showing Q.931 mapping, > because I thought the group had decided not to work on SIP-Q.931 mapping. [JFR] I'll check with the authors. Anyway a call-flow draft is not normative. > > > > Regards, > > John (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 exim@www1.ietf.org Thu Aug 7 13:13:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22615 for ; Thu, 7 Aug 2003 13:13:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koK6-000846-MN for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:13:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HDAtd030997 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koK5-00083s-SC for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22570 for ; Thu, 7 Aug 2003 13:13:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koK3-0000o1-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:13:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19koK3-0000ny-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:13:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koJx-00081Z-D2; Thu, 07 Aug 2003 13:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koJa-00080z-Od for sipping@optimus.ietf.org; Thu, 07 Aug 2003 13:12:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22560 for ; Thu, 7 Aug 2003 13:12:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koJY-0000np-00 for sipping@ietf.org; Thu, 07 Aug 2003 13:12:36 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19koJY-0000nb-00 for sipping@ietf.org; Thu, 07 Aug 2003 13:12:36 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h77HC2l20247; Thu, 7 Aug 2003 10:12:02 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 10:12:02 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20A1F3F32@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Elwell, John'" , "'sipping@ietf.org'" Date: Thu, 7 Aug 2003 10:11:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35D07.0301A6E0" Subject: [Sipping] RE: WGLC for draft-ietf-sipping-qsig2sip-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: , 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_01C35D07.0301A6E0 Content-Type: text/plain I'm OK with your new wording. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Thursday, August 07, 2003 08:10 > To: Audet, Francois [SC100:4K02:EXCH]; 'sipping@ietf.org' > Subject: RE: WGLC for draft-ietf-sipping-qsig2sip-01 > > > Francois, > > In-line. > > Regards, > > John > > > - Section 8.3.1, page 19 > > 5th paragraph: Add ", unless the gateway is aware that > in-band information > > will not be used" to the end of the paragraph. The reason > for this is that > > there are cases where the gateway may have a > priori-knowledge that in-band > > tones and announcements are not used; and out-of-band ALERTING or > fast connection (i.e., no PROGRESS and no ALERTING) is always > used for example. In that case, there is no reason to > reject the call with > > 488 if the SDP was not included in the INVITE. > [JRE] I agree that if there is a priori knowledge that > in-band tones and announcements will not be used, then what > you propose is reasonable. I am rather doubtful that the > gateway will have sufficient knowledge to determine this. The > 4th and 5th paragraphs of 8.3.3 mandate the connection of > media streams if relevant QSIG progress indicators are > present in a PROGRESS or ALERTING message. The presence of > these progress indicators is outside the control of the > gateway. So how can the gateway have a priori knowledge that > these progress indicators will not be received? > > [FA]I'm talking about the gateway RECEIVING the SETUP, not > the one sending it. > > [JRE]You referred originally to 8.3.1, which deals with > receiving INVITE / sending SETUP, not receiving SETUP. From > the rest of your remarks below I assume you really do mean > 8.3.1 and the gateway receiving the INVITE / sending the SETUP. > > [FA]The case I am thinking of is then the Gateway is an IP > PBX (with SIP on one side, QSIG on the other). If the call > terminates on a local phone, it may use out-of-band ringing > (our PBXs work that way). > > If we want to be picky about the meaning of Gateway, and > dissociate the gateway from the actual QSIG PBX, then it can > still happen. The gateway may decide to map the INVITE to > SETUP anyways and forward it to the QSIG PBX. If the PBX > responds with the ALERTING indicating out-of-band, everything > is fine (which is why I would like this change). If on the > other hand, the ALERTING indicates in-band, then the gateway > could decide to do as per your procedure and send the 488. > But I wouldn't want to mandate 488 everytime the SDP is not > in the INVITE, especially since it is a very normal occurence in SIP. > > [JRE] I would not want to send 488 after receiving a QSIG > ALERTING or PROGRESS message indicating in-band information, > because by then the called user in the QSIG network might > already be being alerted and it would not be good practice to > cancel the call at this stage. > > [FA]Even for the second case, where the call ultimately > terminates on a line with an in-band signalling, I am not > convinced at all that the qsig2sip draft should mandate that > the call be terminated. To me this should be a design option. > An implementer may decide that it prefers to go through with > the call, and provide some sort of indication to the user > that the call is "progressing" instead of failing the call (I > expect that a proper SIP implemenation would do something like that). > > I would prefer that the paragraph does not mandate the 488 as > other options are doable, and probably much less drastic than > call failure (as an out-of-band progress indication would be). > > [JRE] On reflection I can see some merit in allowing the call > to proceed, even though we cannot guarantee that in-band > information will be passed to the caller. If the caller is a > user of a SIP device of some sort, even if we pass in-band > information back through the SIP network, there is no > guarantee that the SIP device will play it to the user. On > the other hand, if there is another legacy network on the > originating side of the SIP network, it will of course be > able to pass in-band information and the SIP network (using > unreliable provisional responses) would be the sole cause of > failure to pass in-band information end-to-end. In the case > of another QSIG network we have mandated support for 100rel > (see 8.2.1.1) anyway. So on balance I think I could agree to > relax the rules concerning a 488. I propose making it a > SHOULD and including the text: "A gateway that has a priori > knowledge that essential in-band information will not need to > be sent before answer can choose to proceed with the call in > these circumstances." > ------_=_NextPart_001_01C35D07.0301A6E0 Content-Type: text/html RE: WGLC for draft-ietf-sipping-qsig2sip-01

I'm OK with your new wording.

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: Thursday, August 07, 2003 08:10
> To: Audet, Francois [SC100:4K02:EXCH]; 'sipping@ietf.org'
> Subject: RE: WGLC for draft-ietf-sipping-qsig2sip-01
>
>
> Francois,
>
> In-line.
>
> Regards,
>
> John
>
>
> - Section 8.3.1, page 19
>  
>   5th paragraph: Add ", unless the gateway is aware that
> in-band information
>
>   will not be used" to the end of the paragraph. The reason
> for this is that
>
>   there are cases where the gateway may have a
> priori-knowledge that in-band
>
>   tones and announcements are not used; and out-of-band ALERTING or
>   fast connection (i.e., no PROGRESS and no ALERTING) is always
>   used for example. In that case, there is no reason to
> reject the call with
>
>   488 if the SDP was not included in the INVITE.
> [JRE] I agree that if there is a priori knowledge that
> in-band tones and announcements will not be used, then what
> you propose is reasonable. I am rather doubtful that the
> gateway will have sufficient knowledge to determine this. The
> 4th and 5th paragraphs of 8.3.3 mandate the connection of
> media streams if relevant QSIG progress indicators are
> present in a PROGRESS or ALERTING message. The presence of
> these progress indicators is outside the control of the
> gateway. So how can the gateway have a priori knowledge that
> these progress indicators will not be received?
> 
> [FA]I'm talking about the gateway RECEIVING the SETUP, not
> the one sending it.
>
> [JRE]You referred originally to 8.3.1, which deals with
> receiving INVITE / sending SETUP, not receiving SETUP. From
> the rest of your remarks below I assume you really do mean
> 8.3.1 and the gateway receiving the INVITE / sending the SETUP.
>
> [FA]The case I am thinking of is then the Gateway is an IP
> PBX (with SIP on one side, QSIG on the other). If the call
> terminates on a local phone, it may use out-of-band ringing
> (our PBXs work that way).
>
> If we want to be picky about the meaning of  Gateway, and
> dissociate the gateway from the actual QSIG PBX, then it can
> still happen. The gateway may decide to map the INVITE to
> SETUP anyways and forward it to the QSIG PBX. If the PBX
> responds with the ALERTING indicating out-of-band, everything
> is fine (which is why I would like this change). If on the
> other hand, the ALERTING indicates in-band, then the gateway
> could decide to do as per your procedure and send the 488.
> But I wouldn't want to mandate 488 everytime the SDP is not
> in the INVITE, especially since it is a very normal occurence in SIP.
>
> [JRE] I would not want to send 488 after receiving a QSIG
> ALERTING or PROGRESS message indicating in-band information,
> because by then the called user in the QSIG network might
> already be being alerted and it would not be good practice to
> cancel the call at this stage.
>
> [FA]Even for the second case, where the call ultimately
> terminates on a line with an in-band signalling, I am not
> convinced at all that the qsig2sip draft should mandate that
> the call be terminated. To me this should be a design option.
> An implementer may decide that it prefers to go through with
> the call, and provide some sort of indication to the user
> that the call is "progressing" instead of failing the call (I
> expect that a proper SIP implemenation would do something like that).
>
> I would prefer that the paragraph does not mandate the 488 as
> other options are doable, and probably much less drastic than
> call failure (as an out-of-band progress indication would be).
>
> [JRE] On reflection I can see some merit in allowing the call
> to proceed, even though we cannot guarantee that in-band
> information will be passed to the caller. If the caller is a
> user of a SIP device of some sort, even if we pass in-band
> information back through the SIP network, there is no
> guarantee that the SIP device will play it to the user. On
> the other hand, if there is another legacy network on the
> originating side of the SIP network, it will of course be
> able to pass in-band information and the SIP network (using
> unreliable provisional responses) would be the sole cause of
> failure to pass in-band information end-to-end. In the case
> of another QSIG network we have mandated support for 100rel
> (see 8.2.1.1) anyway. So on balance I think I could agree to
> relax the rules concerning a 488. I propose making it a
> SHOULD and including the text: "A gateway that has a priori
> knowledge that essential in-band information will not need to
> be sent before answer can choose to proceed with the call in
> these circumstances."
>

------_=_NextPart_001_01C35D07.0301A6E0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23282 for ; Thu, 7 Aug 2003 13:33:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodO-0000jE-LP for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HX6Kh002800 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodO-0000j3-IK for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23194 for ; Thu, 7 Aug 2003 13:33:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodL-0000vq-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodK-0000vl-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodL-0000d8-HR; Thu, 07 Aug 2003 13:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19harn-00035D-Lu for sipping@optimus.ietf.org; Tue, 29 Jul 2003 16:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07762 for ; Tue, 29 Jul 2003 16:14:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19harl-0001W1-00 for sipping@ietf.org; Tue, 29 Jul 2003 16:14:37 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19hark-0001Vm-00 for sipping@ietf.org; Tue, 29 Jul 2003 16:14:36 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 29 Jul 2003 22:14:05 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 22:14:04 +0200 Message-Id: <43240544763FB8479F1529372F6197CF053CC8F9@G8PQC.blf01.telekom.de> From: "Liess, Laura" To: KMcCandless@verisign.com Cc: sipping@ietf.org Subject: AW: [Sipping] FYI: RADIUS & SIP Date: Tue, 29 Jul 2003 22:14:04 +0200 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: , >As I >understood it, the companies that have the embedded base of >RADIUS servers could continue to use them for SIP Current RADIUS does not support Digest Authentication, so you need a RADIUS extension as proposed in http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa-sip-00.txt. There was no problem in using RADIUS together with Basic Authentication for SIP. Possibly the discussion you remember happened before the usage of Basic Authentication has been deprecated. Laura >and the >entities deploying new DIAMETER based servers must be able to >interoperate with the RADIUS servers. > >Kevin.... > > >> -----Original Message----- >> From: Liess, Laura [mailto:Laura.Liess@t-systems.com] >> Sent: Friday, July 18, 2003 4:44 AM >> To: hgs@cs.columbia.edu; sipping@ietf.org; aboba@internaut.com >> Cc: Dumler, Alexander; Wolff, Christian >> Subject: AW: [Sipping] FYI: RADIUS & SIP >> >> >> I think most carriers currently use some kind of RADIUS >> platform to do user authentication and they would like to >> reuse it in the future to authenticate their SIP customers. >> My colleagues who are responsible for the RADIUS Platform of >> the Deutsche Telekom (CC)are currently on vacation so I could >> not check with them now about how to answer this mail, but we >> already talked about this issue a number of times and my >> strong opinion is that "yes, Deutsche Telekom cares a lot >> about SIP and RADIUS". Reusing the existing RADIUS platform >> for SIP authentication is a strong requirement for the >> development of SIP services within the Deutsche Telekom. >> >> Laura (T-Systems/Deutsche Telekom Group) >> >> >> >-----Ursprungliche Nachricht----- >> >Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >Gesendet: Freitag, 18. Juli 2003 09:45 >> >An: sipping@ietf.org >> >Betreff: [Sipping] FYI: RADIUS & SIP >> > >> > >> >Bernard Aboba would like to know about >> >people and >> >companies that care about SIP and RADIUS (for authentication). >> >There is >> >an attempt afoot to rationalize RADIUS-related efforts within >> >the IETF, >> >but there seems to be a lack of representation from SIP >> folks, as per >> >the note to the radius-authors mailing list: >> > >> >"I was not clear about the need for SIP/RADIUS work. >> >Apparently there is >> >ongoing deployment of I-Ds (e.g. the Sterman draft on RADIUS >> attributes >> >for HTTP Digest Authentication), so perhaps standardization would be >> >valuable in documenting what is in use. On the other hand, I >> >also heard >> >that "there >> >isn't much commercial interest." Note sure what to make of >> >this, perhaps >> >someone can clarify." >> > >> >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 exim@www1.ietf.org Thu Aug 7 13:33:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23297 for ; Thu, 7 Aug 2003 13:33:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodV-0000sB-Og for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXDdh003201 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodV-0000nl-4p for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23213 for ; Thu, 7 Aug 2003 13:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodP-0000wF-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodP-0000wC-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodO-0000il-D7; Thu, 07 Aug 2003 13:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htMq-00061t-Qr for sipping@optimus.ietf.org; Wed, 30 Jul 2003 11:59:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06104 for ; Wed, 30 Jul 2003 11:59:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htMd-0001KJ-00 for sipping@ietf.org; Wed, 30 Jul 2003 11:59:43 -0400 Received: from [80.74.106.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19htMb-0001KE-00 for sipping@ietf.org; Wed, 30 Jul 2003 11:59:41 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Wed, 30 Jul 2003 18:57:57 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 18:57:57 +0300 Message-ID: <99FF181D4C99564F8D623069E1DDB25E11E70A@nt-mail.radvision.com> From: Amir Zmora To: "'Henry Sinnreich'" , "'David Schwartz'" , sipping@ietf.org Subject: RE: [Sipping] Re: Update to 3pcc Date: Wed, 30 Jul 2003 18:57:57 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C356B3.583292F0" 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_01C356B3.583292F0 Content-Type: text/plain I'm not sure the REFER option will solve everything. For example if a call is connected via a pre paid system that connected the 2 parties with REFER how will it now disconnect the call or play some warning message to the caller if it is not actively participating in the call. Regarding S/MIME - I don't know of too many implementations actually using it today in real deployment. Many are using TLS and that should work OK with the B2B. Amir -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] Sent: Wednesday, July 30, 2003 6:09 PM To: 'David Schwartz'; sipping@ietf.org Subject: RE: [Sipping] Re: Update to 3pcc This may turn out to be a very productive discussion. David Schwartz writes: > an application where a centralized controller is setting up a > call to two PSTN numbers, then you will need a centralized > billing entity and REFER will not suffice. There may be more attractive billing collecting alternatives: CDRs in the gateways. If the calls are between two IP endpoints, flat rate is a good option. The centralized controller, AKA B2BUA, has however some tremendous drawbacks compared to REFER: - The B2BUA breaks the e2e trust model and security, such as S/MIME. How many B2BUAs would one have to trust in an interdomain call? - The B2BUA keeps state and customer information. If attacked, loss of customer privacy can be a huge liability for the ISP. And an unending source of spam (being criminalized soon by legislators) and telemarketing calls for the unhappy users. - Scalability, single point of failure, etc. Turns actually the ISP into some sort of large PBX. Is this a good idea on the Internet? Add Jiri's and Jonathan's comments to the above. I will take REFER any time instead. What do the people on the list think about this? If anyone cares... Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of David Schwartz > Sent: Wednesday, July 30, 2003 3:11 AM > To: 'sipping@ietf.org' > Subject: [Sipping] Re: Update to 3pcc > > Hi Jiri > > REFER is good solution if you assume that either there are no > billing issues, or alternatively, that the endpoint/s handle > the billing issues. If this is not the case, for example, in > an application where a centralized controller is setting up a > call to two PSTN numbers, then you will need a centralized > billing entity and REFER will not suffice. > > David > > -----Original Message----- > From: sipping-request@ietf.org [mailto:sipping-request@ietf.org] > Sent: Mon, July 28, 2003 7:00 PM > To: sipping@ietf.org > Subject: Sipping digest, Vol 1 #1144 - 2 msgs > > > Send Sipping mailing list submissions to > sipping@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/sipping > or, via email, send a message with subject or body 'help' to > sipping-request@ietf.org > > You can reach the person managing the list at > sipping-admin@ietf.org > > When replying, please edit your Subject line so it is more > specific than "Re: Contents of Sipping digest..." > > > Today's Topics: > > 1. Re: Diversion header (Cullen Jennings) > 2. Re: Update to 3pcc (Jiri Kuthan) > > --__--__-- > > Message: 1 > Date: Sun, 27 Jul 2003 19:05:10 -0700 > Subject: Re: [Sipping] Diversion header > From: Cullen Jennings > To: Romel Khan , > > > I assume your question is there some way for for the final > destination that receives the call to know the who the 1st > callee was that had some device in the network redirect the > call elsewhere. > > The answer is YES - there has been a lot of confusion over > this so think about my answer carefully - it will seem > counter intuitive at first. The answer is the "To" header but > it will take me a second to explain why. > > Imagine case 1 where A send a call to proxy B, that sent to > to C. Now C sent a 302 back B and B then forked the call to > D. The To header in the message D receives will still have > the To set to C. C is the element that sent the first 302. > > Now imagine a case (like your question) where there is not a > recursive proxy. The 302 will go all the way back to A. Now A > forms a new invite to but it can leave the To header set to > the same thing it was in the original message (C in this > case). When the message arrives at D, the To header will be set to C. > > If D was a voice mail system, it might be able to know to act > on behalf of C instead of some other entity. > > There are more complex things that relate to your request. > Mary Barnes has been moving the history work along > http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-his > tory-04.txt > > There is some work on QSIG mappings with diversion > http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2 > sip-diversion- > 00.txt > > There is a draft-levy-sip-diversion which I (and many others) > believe has a pretty much zero chance of being accepted or > becoming a RFC. This work has been superceded by the history > work. Quite a few people do not support the history work and > it is moving very slowly. Don't expect any of this to resolve quickly. > > Give some careful thought to if the "To" header meets your > needs and if it does use - The To header is widely implemented :-) > > > Cullen > > > > > On 7/21/03 8:55, "Romel Khan" wrote: > > > Is there any SIP header defined in any SIP RFC or Internet > Draft that > > can include the address of the 1st callee, who redirected the call > > using 302, > in > > the 2nd outgoing INVITE? > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > > > > --__--__-- > > Message: 2 > Date: Mon, 28 Jul 2003 10:17:51 +0200 > To: Jonathan Rosenberg , sipping > > From: Jiri Kuthan > Subject: Re: [Sipping] Update to 3pcc > > I'm actually not convinced that it is proper to show > click-to-dial as a motivating example for use of b2bua and > label it BCP. > > Use of REFER seems technically a superior solution worth > being called BCP. Roots of the advantages are in a better > application of e2e principle. > REFER takes no middle-box b2bua -- it delegates signaling to > end-points. > Advantages include: > - All the pitfalls with media are so straigforward, they don't even > need to be described (like now in sessions 8 and 9). > - It takes no media server to transmit ringing tone. > - There are no SDP compatibility issues on controller's side. > > -jiri > > At 07:51 PM 7/8/2003, Jonathan Rosenberg wrote: > >Folks, > > > >You may have noticed that I posted an update to the 3pcc spec: > > > >http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.txt > >http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.html > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.txt > > > >The update is based on comments received from IESG while > reviewing the > draft. In particular, there were problems with the usage of > 0.0.0.0 to imply that no media nor RTCP should be sent. This > IP address is not meant for that purpose. Rather, the > .invalid TLD is much better suited. So, I changed the draft > to make use of .invalid in flows where the controller doesnt > want media to be sent. > > > >Now, there are some concerns with that which folks need to > be aware of: > > > >1. It is at odds with RFC 3264, which actually recommends > 0.0.0.0. In > >fact, > the problem is really with RFC 3264, NOT 3pcc. However, 3264 > is done, and this one isnt. I logged a bug against RFC 3264 > on this, and we'll need to work on a way to transition folks > towards using .invalid and not 0.0.0.0. > > > >2. One the premises of 3pcc is that it should be compatible > with any UA > that is RFC 3261 compliant. If a controller uses .invalid in > the SDP, I am not sure what a SIP endpoint would do. I don't > believe anything in RFC 3264 or in SIP talks about handling > the case where there is an issue with a domain name in the > SDP. As such, if you use .invalid, there could be interop > problems. The document mentions this. > > > >Comments or questions welcome. > > > >Thanks, > >Jonathan R. > >-- > >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >Chief Technology Officer Parsippany, NJ 07054-2711 > >dynamicsoft > >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 > > -- > Jiri Kuthan http://iptel.org/~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 > > End of Sipping Digest > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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_01C356B3.583292F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] Re: Update to 3pcc

I'm not sure the = REFER option will solve everything. For example if a call is connected = via a pre paid system that connected the 2 parties with REFER how will it now disconnect the = call or play some warning message to the caller if it is = not actively participating in the call.

Regarding S/MIME - = I don't know of too many implementations actually using it today in = real deployment. Many are using TLS and that should work OK with the = B2B.

Amir

-----Original = Message-----
From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com]
Sent: Wednesday, July 30, 2003 6:09 PM
To: 'David Schwartz'; sipping@ietf.org
Subject: RE: [Sipping] Re: Update to 3pcc

This may turn out = to be a very productive discussion. David Schwartz writes:


> an application = where a centralized controller is setting up a

> call to two = PSTN numbers, then you will need a centralized

> billing entity = and REFER will not suffice.

There may be more = attractive billing collecting alternatives: CDRs in the

gateways. If the = calls are between two IP endpoints, flat rate is a good

option.

The centralized = controller, AKA B2BUA, has however some tremendous drawbacks

compared to = REFER:

- The B2BUA breaks = the e2e trust model and security, such as S/MIME. How

many B2BUAs would = one have to trust in an interdomain call?

- The B2BUA keeps = state and customer information. If attacked, loss of

customer privacy = can be a huge liability for the ISP. And an unending source

of spam (being = criminalized soon by legislators) and telemarketing calls = for

the unhappy = users.

- Scalability, = single point of failure, etc.

Turns actually the = ISP into some sort of large PBX. Is this a good idea on

the Internet? Add = Jiri's and Jonathan's comments to the above. I will take

REFER any time = instead.

What do the people = on the list think about this? If anyone cares...

Thanks, = Henry

> -----Original = Message-----

> From: = sipping-admin@ietf.org [mailto:sipping-admin@ietf.org= ]

> On Behalf Of = David Schwartz

> Sent: = Wednesday, July 30, 2003 3:11 AM

> To: = 'sipping@ietf.org'

> Subject: = [Sipping] Re: Update to 3pcc

>

> Hi = Jiri

>

> REFER is good = solution if you assume that either there are no

> billing = issues, or alternatively, that the endpoint/s handle

> the billing = issues. If this is not the case, for example, in

> an application = where a centralized controller is setting up a

> call to two = PSTN numbers, then you will need a centralized

> billing entity = and REFER will not suffice.

>

> = David

>

> -----Original = Message-----

> From: = sipping-request@ietf.org [mailto:sipping-request@ietf.org= ]

> Sent: Mon, = July 28, 2003 7:00 PM

> To: = sipping@ietf.org

> Subject: = Sipping digest, Vol 1 #1144 - 2 msgs

>

>

> Send Sipping = mailing list submissions to

> =       sipping@ietf.org

>

> To subscribe = or unsubscribe via the World Wide Web, visit

> =       https://www1.ietf.org/mailman/listinfo/sipping

> or, via email, = send a message with subject or body 'help' to

> =       sipping-request@ietf.org

>

> You can reach = the person managing the list at

> =       sipping-admin@ietf.org

>

> When replying, = please edit your Subject line so it is more

> specific than = "Re: Contents of Sipping digest..."

>

>

> Today's = Topics:

>

>    1. Re: Diversion header (Cullen = Jennings)

>    2. Re: Update to 3pcc (Jiri = Kuthan)

>

> = --__--__--

>

> Message: = 1

> Date: Sun, 27 = Jul 2003 19:05:10 -0700

> Subject: Re: = [Sipping] Diversion header

> From: Cullen = Jennings <fluffy@cisco.com>

> To: Romel Khan = <rkhan@net2phone.com>, <sipping@ietf.org>

>

>

> I assume your = question is there some way for  for the final

> destination = that receives the call to know the who the 1st

> callee was = that had some device in the network redirect the

> call = elsewhere.

>

> The answer is = YES - there has been a lot of confusion over

> this so think = about my answer carefully - it will seem

> counter = intuitive at first. The answer is the "To" header but =

> it will take = me a second to explain why.

>

> Imagine case 1 = where A send a call to proxy B,  that sent to

> to C. Now C = sent a 302 back B and B then forked the call to

> D. The To = header in the message D receives will still have

> the To set to = C. C is the element that sent the first 302.

>

> Now imagine a = case (like your question) where there is not a

> recursive = proxy. The 302 will go all the way back to A. Now A

> forms a new = invite to but it can leave the To header set to

> the same thing = it was in the original message (C in this

> case). When = the message arrives at D, the To header will be set to C.

>

> If D was a = voice mail system, it might be able to know to act

> on behalf of C = instead of some other entity.

>

> There are more = complex things that relate to your request.

> Mary Barnes = has been moving the history work along

> http://www.ietf.org/internet-drafts/draft-ietf-sipping= -req-his

> = tory-04.txt

>

> There is some = work on QSIG mappings with diversion

> http://www.ietf.org/internet-drafts/draft-elwell-sippi= ng-qsig2

> = sip-diversion-

> = 00.txt

>

> There is a = draft-levy-sip-diversion which I (and many others)

> believe has a = pretty much zero chance of being accepted or

> becoming a = RFC. This work has been superceded by the history

> work. Quite a = few people do not support the history work and

> it is moving = very slowly. Don't expect any of this to resolve quickly.

>

> Give some = careful thought to if the "To" header meets your

> needs and if = it does use - The To header is widely implemented :-)

>

>

> = Cullen

>

>

>

>

> On 7/21/03 = 8:55, "Romel Khan" <rkhan@net2phone.com> = wrote:

>

> > Is there = any SIP header defined in any SIP RFC or Internet

> Draft that =

> > can = include the address of the 1st callee, who redirected the call =

> > using = 302,

> in

> > the 2nd = outgoing INVITE?

> > =

> > = _______________________________________________

> > Sipping = mailing list  https://www1.ietf.org/mailman/listinfo/sipping

> > This list = is for NEW development of the application of SIP Use

> > = sip-implementors@cs.columbia.edu for questions on current sip Use =

> > = sip@ietf.org for new developments of core SIP

> > =

>

>

>

> = --__--__--

>

> Message: = 2

> Date: Mon, 28 = Jul 2003 10:17:51 +0200

> To: Jonathan = Rosenberg <jdrosen@dynamicsoft.com>, sipping

> = <sipping@ietf.org>

> From: Jiri = Kuthan <jiri@iptel.org>

> Subject: Re: = [Sipping] Update to 3pcc

>

> I'm actually = not convinced that it is proper to show

> click-to-dial = as a motivating example for use of b2bua and

> label it = BCP.

>

> Use of REFER = seems technically a superior solution worth

> being called = BCP. Roots of the advantages are in a better

> application of = e2e principle.

> REFER takes no = middle-box b2bua -- it delegates signaling to

> = end-points.

> Advantages = include:

> - All the = pitfalls with media are so straigforward, they don't even

>   = need to be described (like now in sessions 8 and 9). 

> - It takes no = media server to transmit ringing tone.

> - There are no = SDP compatibility issues on controller's side.

>

> = -jiri

>

> At 07:51 PM = 7/8/2003, Jonathan Rosenberg wrote:

> = >Folks,

> = >

> >You may = have noticed that I posted an update to the 3pcc spec:

> = >

> >http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-= 04.txt

> >http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-= 04.html

> >http://www.ietf.org/internet-drafts/draft-ietf-sip= ping-3pcc-04.txt

> = >

> >The update = is based on comments received from IESG while

> reviewing = the

> draft. In = particular, there were problems with the usage of

> 0.0.0.0 to = imply that no media nor RTCP should be sent. This

> IP address is = not meant for that purpose. Rather, the

> .invalid TLD = is much better suited. So, I changed the draft

> to make use of = .invalid in flows where the controller doesnt

> want media to = be sent.

> = >

> >Now, there = are some concerns with that which folks need to

> be aware = of:

> = >

> >1. It is = at odds with RFC 3264, which actually recommends

> 0.0.0.0. In =

> = >fact,

> the problem is = really with RFC 3264, NOT 3pcc. However, 3264

> is done, and = this one isnt. I logged a bug against RFC 3264

> on this, and = we'll need to work on a way to transition folks

> towards using = .invalid and not 0.0.0.0.

> = >

> >2. One the = premises of 3pcc is that it should be compatible

> with any = UA

> that is RFC = 3261 compliant. If a controller uses .invalid in

> the SDP, I am = not sure what a SIP endpoint would do. I don't

> believe = anything in RFC 3264 or in SIP talks about handling

> the case where = there is an issue with a domain name in the

> SDP. As such, = if you use .invalid, there could be interop

> problems. The = document mentions this.

> = >

> >Comments = or questions welcome.

> = >

> = >Thanks,

> >Jonathan = R.

> >-- =

> >Jonathan = D. Rosenberg, = Ph.D.           &= nbsp;    600 Lanidex Plaza

> >Chief = Technology = Officer           = ;         Parsippany, NJ = 07054-2711

> = >dynamicsoft

> = >jdrosen@dynamicsoft.com       &nb= sp;           &nb= sp; FAX:   (973) 952-5050

> >http://www.jdrosen.net    &nbs= p;           &nbs= p;    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

>

> --

> Jiri = Kuthan           = http://iptel.org/~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

>

> End of Sipping = Digest

>

> = _______________________________________________

> Sipping = mailing list  https://www1.ietf.org/mailman/listinfo/sipping

> This list is = for NEW development of the 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_01C356B3.583292F0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23312 for ; Thu, 7 Aug 2003 13:33:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodZ-0000uB-7e for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXHYf003475 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodZ-0000ty-4W for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23233 for ; Thu, 7 Aug 2003 13:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodW-0000wg-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodU-0000wV-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodU-0000nO-Ib; Thu, 07 Aug 2003 13:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keZW-0007Lq-Mw for sipping@optimus.ietf.org; Thu, 07 Aug 2003 02:48:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02587 for ; Thu, 7 Aug 2003 02:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19keZS-0003RY-00 for sipping@ietf.org; Thu, 07 Aug 2003 02:48:22 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19keZS-0003RD-00 for sipping@ietf.org; Thu, 07 Aug 2003 02:48:22 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h776IVw21898; Wed, 6 Aug 2003 23:18:31 -0700 Date: Wed, 6 Aug 2003 23:18:31 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com cc: sipping@ietf.org Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: Message-ID: References: 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: , > In trying to do any > meaningful work with RADIUS, I think we need to document > some of this first. RFC 2882 does some of this, but it's a moving target, unfortunately. > Since backoff is not specified in RADIUS, if > multiple NASes comeup at the same time, they can flood > the network, causing all sorts of fun things happening. "Fun" is not the first word that comes to mind to describe several thousand APs retransmitting once a second with no backoff. About the only saving grace was that RADIUS accounting packets are relatively small so that the result wasn't congestive collapse in the entire network, only the RADIUS servers. However, if RTOmin had been 300 ms instead of 1 second, that might have happened too. > This is one area in which RADIUS would need fixing. The problem of course is that one cannot "fix" these problems without upgrading deployed implementations. And without a heartbeat, it is not clear whether the "fix" can include a conservative failover algorithm such as the one specified in RFC 3539. So overall, we need to be realistic about what is achievable. It's probably too ambitious a goal to try to truly fix RADIUS transport behavior -- without major surgery about all we can do is remedy the most egregious mis-behavior. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23315 for ; Thu, 7 Aug 2003 13:33:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodP-0000k7-Hm for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HX7jv002848 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodP-0000jo-CK for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23196 for ; Thu, 7 Aug 2003 13:33:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodL-0000vk-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodK-0000vd-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodK-0000cy-PB; Thu, 07 Aug 2003 13:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWrO-0008HP-6P for sipping@optimus.ietf.org; Tue, 29 Jul 2003 11:57:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27123 for ; Tue, 29 Jul 2003 11:57:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hWrN-0006lp-00 for sipping@ietf.org; Tue, 29 Jul 2003 11:57:57 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19hWrM-0006ll-00 for sipping@ietf.org; Tue, 29 Jul 2003 11:57:56 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h6TFTPi06221; Tue, 29 Jul 2003 08:29:26 -0700 Date: Tue, 29 Jul 2003 08:29:25 -0700 (PDT) From: Bernard Aboba To: Henry Sinnreich cc: hgs@cs.columbia.edu, sipping@ietf.org, "'Dumler, Alexander'" , "'Liess, Laura'" , "'Wolff, Christian'" Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: <0HIS006PNLSOCV@pmismtp02.wcomnet.com> Message-ID: References: <0HIS006PNLSOCV@pmismtp02.wcomnet.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: , > Yes, these are good proposals. I was wondering though about the > unreliability of RADIUS AAA, given that ALL Internet dial-up services are > using RADIUS. Were there any reports of compliants? Yes, there are. I've personally seen RADIUS clients that do not implement exponential backoff cause "congestive collapse" of the RADIUS servers after a system-wide reboot. If you've got several thousand NAS devices and they retransmit once a second with no jittering and no backoff, this will result in sufficient load that few RADIUS servers can handle it on a sustained basis. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23343 for ; Thu, 7 Aug 2003 13:33:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodY-0000tv-3I for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXG2A003457 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodX-0000tg-Ug for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23221 for ; Thu, 7 Aug 2003 13:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodV-0000wM-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodT-0000wI-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodQ-0000kE-2X; Thu, 07 Aug 2003 13:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEoP-0004LF-NC for sipping@optimus.ietf.org; Thu, 31 Jul 2003 10:53:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00305 for ; Thu, 31 Jul 2003 10:53:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEoN-0004og-00 for sipping@ietf.org; Thu, 31 Jul 2003 10:53:47 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19iEoL-0004oY-00 for sipping@ietf.org; Thu, 31 Jul 2003 10:53:46 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h6VEPAZ01180; Thu, 31 Jul 2003 07:25:10 -0700 Date: Thu, 31 Jul 2003 07:25:10 -0700 (PDT) From: Bernard Aboba To: jdrosen@dynamicsoft.com cc: sipping@ietf.org In-Reply-To: <43240544763FB8479F1529372F6197CF053CC8FE@G8PQC.blf01.telekom.de> Message-ID: References: <43240544763FB8479F1529372F6197CF053CC8FE@G8PQC.blf01.telekom.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sipping] Re: RADIUS & SIP 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: , Thanks for the feedback. Here is a short summary of the items that have been requested: 1. Sterman draft on digest authentication w/RADIUS. 2. Draft on RADIUS accounting w/SIP. 3. RADIUS Prepaid accounting support. 4. Document on RADIUS transport behavior, to support (2). There is also a request for enhanced SIM/AKA support, but I'm not sure this is specifically RADIUS-related. Anything else? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23345 for ; Thu, 7 Aug 2003 13:33:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodT-0000ms-Jt for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXB8W003018 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodT-0000mb-Cq for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23197 for ; Thu, 7 Aug 2003 13:33:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodL-0000vr-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodK-0000vh-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodJ-0000co-VE; Thu, 07 Aug 2003 13:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hNTr-0004JG-Hp for sipping@optimus.ietf.org; Tue, 29 Jul 2003 01:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01135 for ; Tue, 29 Jul 2003 01:56:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hNTo-0002qs-00 for sipping@ietf.org; Tue, 29 Jul 2003 01:57:00 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19hNTn-0002qo-00 for sipping@ietf.org; Tue, 29 Jul 2003 01:56:59 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h6T5Sc304589; Mon, 28 Jul 2003 22:28:38 -0700 Date: Mon, 28 Jul 2003 22:28:38 -0700 (PDT) From: Bernard Aboba To: Henry Sinnreich cc: hgs@cs.columbia.edu, sipping@ietf.org, "'Dumler, Alexander'" , "'Liess, Laura'" , "'Wolff, Christian'" Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: <0HIR007G2LVS6W@dgismtp04.wcomnet.com> Message-ID: References: <0HIR007G2LVS6W@dgismtp04.wcomnet.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: , > I have to agree with Laura Liess. In my compnay we have a huge installed > base of RADIUS and I don't know anybody in the carrier community who would > prefer to replace RADIUS with DIAMETER. The question under discussion here is whether new RADIUS work is needed in the IETF, and if so, what. So far, there seems to be support for working on the Sterman draft for digest authentication, as well as the SIP accounting draft, and perhaps a document on RADIUS transport behavior that would provide more reliable accounting. Is this sufficient or is something else needed too? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23376 for ; Thu, 7 Aug 2003 13:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koda-0000un-C3 for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXIW4003505 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koda-0000uH-8B for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23231 for ; Thu, 7 Aug 2003 13:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodW-0000wU-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodU-0000wN-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodS-0000ln-3i; Thu, 07 Aug 2003 13:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5LB-00085f-M2 for sipping@optimus.ietf.org; Tue, 05 Aug 2003 13:11:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19426 for ; Tue, 5 Aug 2003 13:11:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5L9-0003yG-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:11:15 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19k5L9-0003yD-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:11:15 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h75Gg7W24070; Tue, 5 Aug 2003 09:42:07 -0700 Date: Tue, 5 Aug 2003 09:42:07 -0700 (PDT) From: Bernard Aboba To: Jiri Kuthan cc: "McCandless, Kevin" , "'Liess, Laura'" , hgs@cs.columbia.edu, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" Subject: RE: [Sipping] FYI: RADIUS & SIP In-Reply-To: <5.2.0.9.0.20030805143333.02b25830@mailhost.fokus.gmd.de> Message-ID: References: <5.2.0.9.0.20030805143333.02b25830@mailhost.fokus.gmd.de> 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: , > I remember a different decision back in San Francisco IETF. That was > RADIUS for SIP Authentication. There were concerns (unresolved, if > I remember right) about what to do with accounting due to lack of > reliability in RADIUS. > > Also, my testimony -- quite some iptel.org users (mostly from ISP crowd) > have been asking us for RADIUS. There was no way around it: they > are much more uncomfortable with changing largely deployed base than > with claimed RADIUS shortcomings. None has ever asked for Diameter. > > -jiri There is now an I-D discussing RADIUS transport behavior: http://www.ietf.org/internet-drafts/draft-lior-radius-reliable-accounting-00.txt The suggestion is that a specification of this nature could address some of the concerns about RADIUS accounting reliability. The debate is how far such a specification could go -- since RADIUS has no "heartbeat" functionality, it isn't clear that failover functionality equivalent to RFC 3539 can be added to it: http://www.ietf.org/rfc/rfc3539.txt Obviously, RADIUS clients and servers would need to change to be compatible with any such specification, if it were to be created. The question is whether the issues of "changing largely deployed base" would represent an obstacle to such an effort. Any opinions? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23375 for ; Thu, 7 Aug 2003 13:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koda-0000v1-EW for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXISp003525 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koda-0000uJ-8M for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23224 for ; Thu, 7 Aug 2003 13:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodV-0000wQ-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodU-0000wK-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodS-0000mD-Uh; Thu, 07 Aug 2003 13:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5RG-00089A-Ik for sipping@optimus.ietf.org; Tue, 05 Aug 2003 13:17:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19496 for ; Tue, 5 Aug 2003 13:17:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5RE-0003zO-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:17:32 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19k5RD-0003zL-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:17:32 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h75GYuJ23701; Tue, 5 Aug 2003 09:34:56 -0700 Date: Tue, 5 Aug 2003 09:34:56 -0700 (PDT) From: Bernard Aboba To: Jiri Kuthan cc: Jonathan Rosenberg , "Liess, Laura" , hgs@cs.columbia.edu, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" Subject: Re: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: <5.2.0.9.0.20030805175935.02b72d00@mailhost.fokus.gmd.de> Message-ID: References: <43240544763FB8479F1529372F6197CF053CC8CD@G8PQC.blf01.telekom.de> <5.2.0.9.0.20030805175935.02b72d00@mailhost.fokus.gmd.de> 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: , Everyone seems to be in agreement on the required work (am I dreaming, or is this really the IETF?) There has been some discussion of potentially forming a WG to handle RADIUS-related work (RADIUSEXT?). The question is whether SIP-specific items (such as the Sterman draft and the SIP accounting work) would be appropriate for a new RADIUS-focussed WG, or whether it might be more appropriate for a SIP-focussed group (such as SIPPING). Any opinions? On Tue, 5 Aug 2003, Jiri Kuthan wrote: > Thanks, I very much agree; we have received identical feedback so far. > > -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 exim@www1.ietf.org Thu Aug 7 13:33:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23374 for ; Thu, 7 Aug 2003 13:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koda-0000ud-Ab for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXI1p003495 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koda-0000uG-5r for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23227 for ; Thu, 7 Aug 2003 13:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodW-0000wY-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodU-0000wR-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodR-0000lJ-76; Thu, 07 Aug 2003 13:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k4wS-0006jD-AI for sipping@optimus.ietf.org; Tue, 05 Aug 2003 12:45:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18407 for ; Tue, 5 Aug 2003 12:45:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k4wQ-0003ih-00 for sipping@ietf.org; Tue, 05 Aug 2003 12:45:42 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19k4wP-0003iX-00 for sipping@ietf.org; Tue, 05 Aug 2003 12:45:41 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 1A8BF5F0; Tue, 5 Aug 2003 18:40:28 +0200 (CEST) Received: from jku07.fokus.fraunhofer.de (dhcp114.fokus.fraunhofer.de [195.37.78.114]) by fox.iptel.org (Postfix) with ESMTP id 30E545F0; Tue, 5 Aug 2003 18:40:27 +0200 (CEST) Message-Id: <5.2.0.9.0.20030805143333.02b25830@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 05 Aug 2003 17:58:14 +0200 To: "McCandless, Kevin" , "'Liess, Laura'" , hgs@cs.columbia.edu, sipping@ietf.org, aboba@internaut.com From: Jiri Kuthan Subject: RE: [Sipping] FYI: RADIUS & SIP Cc: "Dumler, Alexander" , "Wolff, Christian" In-Reply-To: <318266A4431BC549B4C4D6FD3EA6E24D012CE69E@ove1wnexm01.corp. illuminet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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 remember a different decision back in San Francisco IETF. That was RADIUS for SIP Authentication. There were concerns (unresolved, if I remember right) about what to do with accounting due to lack of reliability in RADIUS. Also, my testimony -- quite some iptel.org users (mostly from ISP crowd) have been asking us for RADIUS. There was no way around it: they are much more uncomfortable with changing largely deployed base than with claimed RADIUS shortcomings. None has ever asked for Diameter. -jiri At 04:39 PM 7/29/2003, McCandless, Kevin wrote: >This thread seems to rehash an old issue and that was DIAMETER or RADIUS for SIP authentication. As I remember the discussion and tentative recommendation is that SIP would adopt DIAMETER as the standard for AAA functionality and that DIAMETER servers would interoperate with RADIUS servers. As I understood it, the companies that have the embedded base of RADIUS servers could continue to use them for SIP and the entities deploying new DIAMETER based servers must be able to interoperate with the RADIUS servers. > >Kevin.... > > >> -----Original Message----- >> From: Liess, Laura [mailto:Laura.Liess@t-systems.com] >> Sent: Friday, July 18, 2003 4:44 AM >> To: hgs@cs.columbia.edu; sipping@ietf.org; aboba@internaut.com > Cc: Dumler, Alexander; Wolff, Christian >> Subject: AW: [Sipping] FYI: RADIUS & SIP >> >> >> I think most carriers currently use some kind of RADIUS >> platform to do user authentication and they would like to >> reuse it in the future to authenticate their SIP customers. >> My colleagues who are responsible for the RADIUS Platform of >> the Deutsche Telekom (CC)are currently on vacation so I could >> not check with them now about how to answer this mail, but we >> already talked about this issue a number of times and my >> strong opinion is that "yes, Deutsche Telekom cares a lot >> about SIP and RADIUS". Reusing the existing RADIUS platform >> for SIP authentication is a strong requirement for the >> development of SIP services within the Deutsche Telekom. >> >> Laura (T-Systems/Deutsche Telekom Group) >> >> >> >-----Ursprungliche Nachricht----- >> >Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >Gesendet: Freitag, 18. Juli 2003 09:45 >> >An: sipping@ietf.org >> >Betreff: [Sipping] FYI: RADIUS & SIP >> > >> > >> >Bernard Aboba would like to know about >> >people and >> >companies that care about SIP and RADIUS (for authentication). >> >There is >> >an attempt afoot to rationalize RADIUS-related efforts within >> >the IETF, >> >but there seems to be a lack of representation from SIP >> folks, as per >> >the note to the radius-authors mailing list: >> > >> >"I was not clear about the need for SIP/RADIUS work. >> >Apparently there is >> >ongoing deployment of I-Ds (e.g. the Sterman draft on RADIUS >> attributes >> >for HTTP Digest Authentication), so perhaps standardization would be >> >valuable in documenting what is in use. On the other hand, I >> >also heard >> >that "there >> >isn't much commercial interest." Note sure what to make of >> >this, perhaps >> >someone can clarify." >> > >> >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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23419 for ; Thu, 7 Aug 2003 13:33:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodg-0000w0-Nl for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXO4B003587 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodg-0000vl-KZ for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23253 for ; Thu, 7 Aug 2003 13:33:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kode-0000x1-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodU-0000wZ-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodT-0000mu-OG; Thu, 07 Aug 2003 13:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5nD-0000cV-JV for sipping@optimus.ietf.org; Tue, 05 Aug 2003 13:40:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20054 for ; Tue, 5 Aug 2003 13:40:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5nB-00048A-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:40:13 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19k5nA-000486-00 for sipping@ietf.org; Tue, 05 Aug 2003 13:40:12 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h75HB9925741; Tue, 5 Aug 2003 10:11:09 -0700 Date: Tue, 5 Aug 2003 10:11:09 -0700 (PDT) From: Bernard Aboba To: Allison Mankin cc: sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: Message-ID: References: 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: , > I believe they'd be more appropriate developed in SIPPING, > with cross-review from the RADIUS group. But I think SIPPING needs some > information on what the RADIUS working group-to-be is expected to do on RADIUS, > in what timeframe. From what I've understood, the charter would not primarily > be applications. Could you give us more understanding? Here is a summary of the discussion so far: Basic RADIUS work Since RADIUS is running out of attribute space, it was suggested that a basic attribute extension mechanism (such as one using the reserved vendorid of 0) be added. This item could be handled in a 1-2 page document so it should have a short timeframe (~6 months). There is interest in specifying how RADIUS handles prepaid accounting. Requests for this are coming from the SIP community as well as 3GPP2 and folks interested in WLAN prepaid: http://www.watersprings.org/pub/id/draft-lior-radius-prepaid-extensions-01.txt My understanding is that 3GPP2 intends to include this in a forthcoming standard so that the timeframe needs to be set to meet their needs. In order to address concerns about RADIUS transport behavior and accounting reliability, there has been interest expressed on a draft on RADIUS transport behavior. This would presumably address some of the more egregious problems encountered with existing implementations (such as lack of backoff or jittering) as well as describing how RADIUS might be made to work more reliably: http://www.watersprings.org/pub/id/draft-lior-radius-reliable-accounting-00.txt Without some fundamental changes to RADIUS (such as addition of a heartbeat), it is not clear that it will be possible to specify a demonstrably correct failover algorithm in addition to handling basic transport response issues (e.g. backoff, jittering, RTT estimation, etc.). So there is some question about the scope of a potential transport document (e.g. just basic retransmission behavior or retransmssion + failover). On the face of it, it seems that it would require a lot of changes to make RADIUS as reliable as Diameter: http://www.ietf.org/rfc/rfc3539.txt The timeframe of this work could be short (~9 months) assuming that the scope is containable. WLAN-related A number of different organizations (WFA, IEEE, etc.) have been specifying WLAN-related attributes. There appears to be interest in standardizing the most useful ones. This and some other WLAN-related work is described here: http://www.watersprings.org/pub/id/draft-adrangi-radius-issues-in-pwlan-roaming-00.txt The timeframe for this is hard to estimate, but I'd guess it is ~18 months or so. We also had a request from the IEEE 802.11 Liason, Dorothy Stanley, for work on fast handoff. Bill Arbaugh at the University of Maryland is implementing the draft below: http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-02.txt However, Bill has requested that this work not be considered as an IETF WG work item until his research is complete and the usefulness of the proposed extension can be evaluated. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23420 for ; Thu, 7 Aug 2003 13:33:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodg-0000wS-Re for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXOuc003603 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodg-0000vm-LU for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23252 for ; Thu, 7 Aug 2003 13:33:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kode-0000x3-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodZ-0000wy-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodW-0000tM-N4; Thu, 07 Aug 2003 13:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knxq-00075a-U1 for sipping@optimus.ietf.org; Thu, 07 Aug 2003 12:50:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21884 for ; Thu, 7 Aug 2003 12:50:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knxp-0000e4-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:50:09 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19knxo-0000e1-00 for sipping@ietf.org; Thu, 07 Aug 2003 12:50:08 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h77GKs123690; Thu, 7 Aug 2003 09:20:54 -0700 Date: Thu, 7 Aug 2003 09:20:54 -0700 (PDT) From: Bernard Aboba To: Jiri Kuthan cc: hgs@cs.columbia.edu, sipping@ietf.org Subject: Re: AW: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: <5.2.0.9.0.20030807180926.053e0eb8@mailhost.fokus.gmd.de> Message-ID: References: <5.2.0.9.0.20030807180926.053e0eb8@mailhost.fokus.gmd.de> 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: , > There is a believe in the IETF that lack of reliability in RADIUS > determines this work to be dropped. (Authentication is a different > story, though.) The point of this particular discussion is to understand whether specification of RADIUS transport behavior might be helpful in that regard, or whether we've have to go further (such as specifying failover behavior). Reading RFC 2865, one of the reasons that RADIUS was not made to run over TCP in the first place was that it was desired that failover occur in a timeframe prior to connection failure. RFC 3539 handles this issue by defining application-layer timers and heartbeats that allow the AAA application to re-send an accounting packet over another connection before tearing down a suspect one. Via the heartbeat mechanism, the AAA client can determine whether the issue is due to its immediate connection, or something downstream. Failover only occurs if the immediate connection is found to be suspect, so failover occurs on a hop-by-hop basis. RFC 3539 cannot be applied to the RADIUS protocol as it stands because RADIUS does not support a heartbeat. As a result, a RADIUS client can failover even where its immediate proxy is healthy, because of a problem on a downstream RADIUS server. Since RADIUS failover is typically end-to-end, there may be no failover in proxies, even if a server is not responding to requests proxied to it. Even if one were to define appropriate RTT/RTO measurements, and use traffic from the proxy as a demonstration of "liveness", inappropriate failover can still happen in cases where the time between proxy traffic is greater than the failover timer. The end result is that to be able to apply RFC 3539, one would need to add a heartbeat command to RADIUS. This is a fairly major step, since it would require changing both RADIUS client and server implementations. So the question is: "If a major protocol change were to be made to RADIUS to improve reliability, would such a change be deployed on RADIUS clients and servers and would it be acceptable for the SIP accounting specification to depend on such a change?" If the answer is yes, then a RADIUS failover spec might be worth discussing further. If no, then it seems to me that a RADIUS failover spec it might not be worth doing -- it's not considered important enough to get over the deployment hurdles. That raises the question of whether a dependency even on transport behavior improvements is possible, since even this would still require changes on RADIUS clients (though not servers). Comments? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23421 for ; Thu, 7 Aug 2003 13:33:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodg-0000wY-Si for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXOMX003618 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodg-0000vt-NV for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23247 for ; Thu, 7 Aug 2003 13:33:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodd-0000x4-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodV-0000wh-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodV-0000sI-SO; Thu, 07 Aug 2003 13:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19klwf-0008MO-1x for sipping@optimus.ietf.org; Thu, 07 Aug 2003 10:40:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17112 for ; Thu, 7 Aug 2003 10:40:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19klwc-00077P-00 for sipping@ietf.org; Thu, 07 Aug 2003 10:40:46 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19klwb-00077M-00 for sipping@ietf.org; Thu, 07 Aug 2003 10:40:46 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h77EBRY16419; Thu, 7 Aug 2003 07:11:27 -0700 Date: Thu, 7 Aug 2003 07:11:27 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: Henry Sinnreich , john.loughney@nokia.com, sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: <3F324F5D.6040903@piuha.net> Message-ID: References: <0HJ9009LH0DFIN@dgismtp05.wcomnet.com> <3F324F5D.6040903@piuha.net> 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: , > Here's what I'd like to have: > > 1. Published (RFC) specifications for carrying HTTP > Digest over RADIUS. Maybe start from draft-sterman. > 2. Published specifications for the same thing and > a few additional features over DIAMETER. Start from > draft-belinchon, but make it less 3GPP-specific. > 3. As a part of 2, interworking specification > between RADIUS & DIAMETER (possibly limited > to the scope of features supported under 1). > 4. Prepaid support module for DIAMETER that can > work with any application, such as SIP or network > access. This is work in progress, as John noted. > 5. Optionally, a prepaid module for RADIUS, > constructed in a manner which makes translation > to 4 possible. This is a summary of the work that is being proposed or ongoing (in AAA WG). _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:33:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23465 for ; Thu, 7 Aug 2003 13:33:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodj-0000ws-3n for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXRS9003640 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodj-0000wd-05 for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23251 for ; Thu, 7 Aug 2003 13:33:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kode-0000x2-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodY-0000we-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodP-0000jT-82; Thu, 07 Aug 2003 13:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iC6i-0004aX-9k for sipping@optimus.ietf.org; Thu, 31 Jul 2003 08:00:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21661 for ; Thu, 31 Jul 2003 08:00:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iC6h-0002kt-00 for sipping@ietf.org; Thu, 31 Jul 2003 08:00:31 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19iC6g-0002kj-00 for sipping@ietf.org; Thu, 31 Jul 2003 08:00:30 -0400 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIW006L419KFE@firewall.wcom.com> for sipping@ietf.org; Thu, 31 Jul 2003 11:58:32 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIW00G0119J51@dgismtp02.wcomnet.com>; Thu, 31 Jul 2003 11:58:32 +0000 (GMT) Received: from hsinnreich2 ([166.50.135.133]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HIW00BI019I4L@dgismtp02.wcomnet.com>; Thu, 31 Jul 2003 11:58:32 +0000 (GMT) Date: Thu, 31 Jul 2003 06:58:32 -0500 From: Henry Sinnreich Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: <5.2.0.9.2.20030730002949.043edc48@mail.inode.at> To: "'Michael Haberler'" , "'Jonathan Rosenberg'" , "'Bernard Aboba'" Cc: "'Liess, Laura'" , hgs@cs.columbia.edu, sipping@ietf.org, "'Dumler, Alexander'" , "'Wolff, Christian'" Message-id: <0HIW00BI119I4L@dgismtp02.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNWu7fbAxn9xjDYRkKuntGu4hypsAAnYvdQ 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 this is an excellent proposal! Though a firm believer in the supremacy of IETF technology, sometimes it makes sense to import innovation on to the Internet from other areas. The SIM card is certainly on top of the list for technologies where its creators had their act well together. Thanks, Henry Henry Sinnreich MCI 400 International Parkway Richardson, Texas 75081 USA Have you disconnected the PBX? > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Michael Haberler > Sent: Wednesday, July 30, 2003 11:55 AM > To: Jonathan Rosenberg; Bernard Aboba > Cc: Liess, Laura; hgs@cs.columbia.edu; sipping@ietf.org; > Dumler, Alexander; Wolff, Christian > Subject: Re: AW: [Sipping] FYI: RADIUS & SIP > > authenticating SIP users is very much like authenticating > mobile users in cellular networks, and the solution developed > for GSM - subscriber identity in a smart card - is IMV > somthing we would be well advised to carry over to SIP space. > > The utility of SIM cards has been recognized for > Internet-side authentication like EAP-SIM based WLAN roaming, > in particular as there is an existing billing an > authentication machinery which one can plug into from the > Internet side. However, SIM cards could also be used in a > strictly Internet-only service provider context as well. > Plus, SIM-based authentication could be used as a bootstrap > mechanism for X.509 certficate distribution and therefore for > TLS mutual authentication. > > There is a draft for SIP authentication with Authentication > and Key Agreement (AKA, > http://www.ietf.org/internet-drafts/draft-torvinen-http-digest > -aka-v2-00.txt > and predecessor) which adresses authentication with UMTS SIM > (USIM)cards. > These have superior security properties compared to plain SIM cards. > However, HTTP AKA cannot negotiate down to plain SIM > authentication, and very few operators use USIM cards, so if > we wait for USIM cards to be ubiquitious we might wait very long. > > Therefore, there is more pressing need for authentication > with plain GSM SIM cards (about 900 million cards out > there!), and there is currently no standard way of using > those at the SIP level - although at the WLAN level, this > has been adressed by EAP/SIM which gets around some of the > weaknessess of plain SIM authentication. However, the HTTP > EAP Digest draft apparently fell through, so we cannot > combine HTTP EAP and EAP/SIM. > > So the area of work I see a need for is retrofitting EAP/SIM > authentication flows into Digest authentication to create a > strong interoperable HTTP SIM authentication method, and > appropriate RADIUS support to back it up. Also, the RADIUS > support behind HTTP AKA needs fleshing out. > > my vision is to have both WLAN/LAN access and SIP > authenticated through the same SIM card. I see quite a market > potential for such a feature set. > > -Michael Haberler > > > > At 14:12 29.07.2003 -0400, Jonathan Rosenberg wrote: > > >I know of several carriers with RADIUS infrastructures that > want to use > >them to support SIP. They are currently using expired I-Ds and > >proprietary attributes. As a result, I would strongly > advocate work on > >standardizing RADIUS usage with SIP. > > > >There are two areas of work that I see a need for: > > > >1. Digest authentication. The sterman draft > >(http://www.freeradius.org/radiusd/doc/rfc/draft-sterman-aaa- > sip-00.txt > >) is used quite a bit, it seems. It would be nice to standardize on > >this. > > > >2. Prepaid calling. Many folks are using vendor proprietary radius > >extensiosn to support prepaid calling. It would be nice to > bring those > >forward and standardize on them. > > > >-Jonathan R. > > > >Bernard Aboba wrote: > > > >>Is there some particular set of draft(s) that you are > advocating work on? > >>On Fri, 18 Jul 2003, Liess, Laura wrote: > >> > >>>I think most carriers currently use some kind of RADIUS > platform to > >>>do user authentication and they would like to reuse it in > the future > >>>to authenticate their SIP customers. > >>>My colleagues who are responsible for the RADIUS Platform of the > >>>Deutsche Telekom (CC)are currently on vacation so I could > not check > >>>with them now about how to answer this mail, but we already talked > >>>about this issue a number of times and my strong opinion is that > >>>"yes, Deutsche Telekom cares a lot about SIP and RADIUS". > Reusing the > >>>existing RADIUS platform for SIP authentication is a strong > >>>requirement for the development of SIP services within the > Deutsche Telekom. > >>> > >>>Laura (T-Systems/Deutsche Telekom Group) > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the 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. 600 Lanidex Plaza > >Chief Technology Officer Parsippany, NJ 07054-2711 > >dynamicsoft > >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 exim@www1.ietf.org Thu Aug 7 13:33:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23481 for ; Thu, 7 Aug 2003 13:33:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodl-0000x7-Dp for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXTQX003657 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodl-0000wu-AD for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23207 for ; Thu, 7 Aug 2003 13:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodN-0000w4-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodM-0000w0-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodM-0000gg-Fm; Thu, 07 Aug 2003 13:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfep-0001id-Ns for sipping@optimus.ietf.org; Tue, 29 Jul 2003 21:21:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18536 for ; Tue, 29 Jul 2003 21:21:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hfen-0003pc-00 for sipping@ietf.org; Tue, 29 Jul 2003 21:21:33 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19hfem-0003pY-00 for sipping@ietf.org; Tue, 29 Jul 2003 21:21:32 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h6U1KnKw001751; Tue, 29 Jul 2003 21:20:49 -0400 Message-ID: <01e501c35638$d22b8290$0401a8c0@packetizer.org> From: "Paul E. Jones" To: "A vWijk" , , , Cc: , , , , , , , , , , , , , , , References: Date: Tue, 29 Jul 2003 21:20:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Betr.: Real time streaming text conversations 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 Arnoud, During some earlier discussions, I pointed out that ICQ already has character-at-a-time capability. It's a very popular instant messaging client. I think it's very unfortunate that SIMPLE didn't take that route. The "all at once" text message is really "old style" in my opinion... not better than e-mail, really. OK.. a little. Character-at-a-time is stressful on the servers, though. Rather than processing 100 messages per chat session, for example, it might be 100 * 30 messages. I think that the best solution would have been to design SIMPLE to use SIP for session establishment and simply open an RFC 2793-type of RTP stream. I understand that there was a desire to be able to pass formatting information and other content, which was not precisely compatible with RFC 2793. Even so, I think that if we were to treat the RFC 2793 stream as a stream of HTML, that might have satisfied most people. I don't know what other things people expected to get from passing thing as blocks of text. I really liked ICQ's character-at-a-time mode and I think others would have found it preferable. It allows for much faster message exchange, as one can start typing immediately after the other person finishes.. or even start out right away. It's possible to have a real interactive argument with ICQ :-) Paul ----- Original Message ----- From: "A vWijk" To: ; ; Cc: ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; Sent: Monday, July 28, 2003 9:59 AM Subject: Betr.: Real time streaming text conversations > Hello Cullen. > > Good to "hear" that you agree. :-) > > About IM, I agree. character by character is not going to kill IM. > I already told a few IM people that such real-time streaming text can be added as a "chat" option. > So that I can for example fire off a few IM messages about something. And the other side reacts and we then both enter chat mode to discuss the proceedings. > Will this become popular? Oh yes, think of the good old days before HTML. What was one of the most used functions of the web? IRC and ntalk/talk. > > About the sipdev meeting. Well yes, a MUST is very good. But I see it as the beginning. The first step. We still have a lot of work to do. And a paper explaining to phone manufactures that implementing this requirement gives them a competitive advantage because everyone is going to want it. Is a very good idea. > Do you mean a kind of Internet draft or white paper? > But I am quite willing to help and I am positive that others will help too. > > Greetz > > Arnoud > > PS Currently a BCP is being written, though that is more about implementation itself. > > > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > >>> Cullen Jennings 24-07-03 23:47 >>> > On 7/13/03 5:08, "A vWijk" wrote: > > > I just want to give them a very clear message how important real-time > > streaming text conversation will be for hundred of millions of users. And > > while it will be vitally important for the hearing and speech impaired, other > > users will also benefit from this capability. (RFC 2793 text in every SIP > > telephony device, regardless presence of a keyboard or screen). > > > > greetz > > > > Arnoud van Wijk > > > > I think this is a very good message to get out. The hearing and speech > impaired community has significant experience with using text messaging to > communicate as quickly as possible. This community resoundingly says that > character by character improves the communication experience. I can not see > any reason that this same fact will not apply to anyone using IM. > > The hearing and speech impaired community should make sure that the SIMPLE > and XMPP WG understand that IM systems should include an option of character > by character sending and display of messages. > > The details of how this is implemented are really less important (yah I know > the folks like 3GPP will need a bandwidth efficient way of doing this). > > Cullen > > PS. IMHO, The IETF putting a MUST in some random document is less likely to > make this happen than a bunch of highly qualified people writing a document > that explains to phone manufactures that implementing this requirement gives > them a competitive advantage because everyone is going to want it. > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:34:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23497 for ; Thu, 7 Aug 2003 13:34:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodm-0000xe-O3 for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXUr5003676 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodm-0000xB-EW for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23201 for ; Thu, 7 Aug 2003 13:33:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodL-0000vg-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodK-0000vc-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodJ-0000ce-7S; Thu, 07 Aug 2003 13:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hK9o-0006Fu-2K for sipping@optimus.ietf.org; Mon, 28 Jul 2003 22:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27622 for ; Mon, 28 Jul 2003 22:24:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hK9k-00022K-00 for sipping@ietf.org; Mon, 28 Jul 2003 22:24:04 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19hK9j-00022G-00 for sipping@ietf.org; Mon, 28 Jul 2003 22:24:03 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIR00CGWL2EB8@firewall.wcom.com> for sipping@ietf.org; Tue, 29 Jul 2003 02:18:15 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIR00601L2EP2@dgismtp04.wcomnet.com>; Tue, 29 Jul 2003 02:18:14 +0000 (GMT) Received: from hsinnreich2 ([166.50.153.21]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HIR003DQL255Q@dgismtp04.wcomnet.com>; Tue, 29 Jul 2003 02:18:14 +0000 (GMT) Date: Mon, 28 Jul 2003 21:18:05 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: items for vor voting in the BOF In-reply-to: <002501c34edf$3ff12e30$2a1b550a@cisco.com> To: "'Paul E. Jones'" , "'Rohan Mahy'" Cc: guido.gybels@rnid.org.uk, gv@trace.wisc.edu, "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , "'Mike Spanner'" , andreas.piirimets@omnitor.se, trefor@trefor.plus.com, "'Rajesh Kumar'" , marcelo@envilogg.se, jorgen.bjorkner@hotsip.com, "'James Hamlin'" , Erik.Zetterstrom@omnitor.se, hwildfeu@cisco.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, sipping@ietf.org, "'Andrea Saks'" Message-id: <0HIR003E1L2B5Q@dgismtp04.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNVSHEZr1m9anF0ReydREYdDvEPMgAKqsdA 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 Paul, finally, we disagree! We have 3-4 SIP phones in my house at all times and we are using all of them in various rooms. We would not even dream touching a VoIP phone that does not have a display and without its own web page where we can see the address book and dial from the PC or from some another web absed personal call manager. I would certainly not attempt to sell any friend or family member a SIP phone withou display. Depressing thought. Nor would we ever by a mobile phone without display. Cheers :-) Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Paul E. Jones > Sent: Sunday, July 20, 2003 11:52 AM > To: Rohan Mahy > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; Henry > Sinnreich; Gunnar Hellstrom; Mike Spanner; > andreas.piirimets@omnitor.se; trefor@trefor.plus.com; 'Rajesh > Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > James Hamlin; Erik.Zetterstrom@omnitor.se; > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; > mgarakan@cisco.com; oran@cisco.com; sipping@ietf.org; Andrea Saks > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > Rohan, > > I offered up a few questions to folks that I hoped people > would have voted on. The questions I had was whether or not > there should be a requirement to provide *some* interface to > legacy TTY devices. Whether it's RJ-11 or 2.5mm makes no > difference. However, I think it should be a requirement that > pass-through work at the very least. If this was agreeable, > I could certainly work to craft specific text for such a requirement. > > I do not have stats on how many phones do not have screens. > However, note that requirement 1 also requires a keyboard, > though that's never mentioned. > One could say that text could be entered via some web > interface, but doing so is a bit hard in a hotel room or at a > gas station on the side of the road. Regardless, I've said > before and I'll say it again: I do not expect that most of > the IP phones that will go into mass production will have a > suitable screen for text communication. Most of today's IP > phones have screens, because it is a way to catch people's > eyes. However, there are also many that do not. Would you > consider Cisco's ATA, for example, an IP phone? I think it > qualifies and there is no screen. There are a number of > service providers deploying that and similar devices from > other manufacturers. None of those have displays. > > I assert that in most enterprise environments, the display is > of very little value. It's interesting at first, but it's > not necessary to have a fancy > screen: just something simple to control hold, transfer, > conferencing, etc., is enough. In fact, I'd be happy with > buttons that did that. > > At home, I think it's even less of a requirement to have a > nice-size display. Recognizing that many phones today have a > display for caller ID, etc., such displays are not suitable > for text communication. Requirement 1 is asking for a nice > display... and I think you'll find a much smaller percentage > of those... especially as they become a commodity item. > > Paul > > ----- Original Message ----- > From: "Rohan Mahy" > To: "Paul E. Jones" > Cc: ; ; "Henry Sinnreich" > ; "Gunnar Hellstrom" > ; "Mike Spanner" > ; ; > ; "'Rajesh Kumar'" > ; ; > ; "James Hamlin" > ; ; > ; ; > ; ; ; > "Andrea Saks" > Sent: Saturday, July 19, 2003 11:14 PM > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > Hi Paul, > > > > So it sounds like you wanted an additional requirement for > pass-through > > via a 2.5 mm jack for phones that do not support RFC2793? If I > > understood this correctly, how would you word the requirement? > > > > Also, do you have any data on how many phones currently > exist (number > > or percentage) for which requirement 1 would not apply? I > suspect that > > the number of phones not covered by the first requirement > is actually > > quite small. > > > > thanks, > > -rohan > > > > On Friday, July 18, 2003, at 05:04 PM, Paul E. Jones wrote: > > > > > Guido, > > > > > > I wish I could have attended, but I was attending a TDI conference > > > here in > > > the US. I couldn't be in both places at the same time, > though I wish I > > > could. I was disheartened that the questions were not > presented as I > > > proposed. You should know that, supposedly, work gets > done over the > > > e-mail > > > reflector, not only in the meeting, so not being there > should not have > > > lessened my input on the matter. > > > > > > Looking at the results of the ad-hoc reported by Rohan, I see: > > > 1) *If* an IP phone supports a display (and keyboard??), it > > > must support RFC 2793 > > > 2) IP phones *should* provide a way to input text > > > 3) IP phones *may* provide an RJ-11 interface and *must* > > > support pass-through. > > > > > > Now, my concerns are several. It appears that you have > absolutely no > > > requirement for the mass of products that do not sport a > display to > > > support > > > text in either relay or pass-through mode. Further, there is no > > > mention of > > > a 2.5mm jack being an option. Question 3, as I > mentioned, "pressured" > > > folks > > > more than it should. There should have been no reason to require > > > support of > > > pass-through, at the very least. > > > > > > I told you that my questions were to ensure that we at least get > > > support for > > > text on every phone in one way or another. It looks like > you lost. > > > Company > > > X is now free to build an IP phone without any text > support. I'm not > > > really > > > happy about that and I certainly don't see why you should be. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Guido Gybels" > > > To: "Paul E. Jones" ; > > > Cc: "Henry Sinnreich" ; "Gunnar > Hellstrom" > > > ; "Guido Gybels" > > > ; > > > "Mike Spanner" ; > > > ; > > > ; ; "'Rajesh Kumar'" > > > ; ; > > > ; > > > "James Hamlin" ; > > > ; > > > ; ; > > > ; > > > ; ; > > > Sent: Friday, July 18, 2003 2:31 AM > > > Subject: [Sipping] Re: items for vor voting in the BOF > > > > > > > > >> Paul, > > >> > > >> <> > > >> > > >> The discussion on the sipdev document took place > yesterday, and if you > > > wanted to make a point you were free to attend it. You'll see the > > > results > > > reflected in the next version of the document, and I can > say that both > > > Arnoud and myself believe this result to be extremely > sensible as well > > > as in > > > the best interest of all stakeholders. > > >> I also suggest this no longer belongs here on the > mailing list until > > >> a new > > > issue would arise. I have stopped replying to your emails > a while ago > > > as I > > > see no point in continuing the discussion (and swamping > the list) with > > > someone who, despite being a native English speaker, > seems unable to > > > understand what we are saying and more importantly deliberately > > > misrepresents my statements or attributes words to my > mouth that I did > > > not > > > speak. > > >> > > >> < know you'd say > > >> "no" > > > to > > >> it.>> > > >> > > >> This being a nice example of that. > > >> > > >> > > >> I believe the IETF community has shown great wisdom and a true > > > understanding of what is at stake here. We have now got a > solid path > > > to the > > > future, with a clear strategy to get rid of obsolete and > unsatisfactory > > > solutions allowing a gradual move of deaf, hard of > hearing and speech > > > impaired people into mainstream technology. That will of > course take > > > time > > > during which there will have to be legacy support and all the > > > instruments > > > are put in place to do exactly that. > > >> > > >> Guido > > >> > > >> Guido Gybels > > >> Director of New Technologies > > >> > > >> RNID, 19-23 Featherstone Street > > >> London EC1Y 8SL, UK > > >> Tel +44(0)20-7294 3713 > > >> Fax +44(0)20-7296 8069 > > >> > > >> _______________________________________________ > > >> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > >> This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 13:34:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23496 for ; Thu, 7 Aug 2003 13:34:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodm-0000xd-Nt for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 13:33:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HXUxg003681 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 13:33:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodm-0000xC-Fx for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:33:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23205 for ; Thu, 7 Aug 2003 13:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kodN-0000w7-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kodM-0000w1-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 13:33:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kodN-0000h8-BI; Thu, 07 Aug 2003 13:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hgn5-0003uL-Oq for sipping@optimus.ietf.org; Tue, 29 Jul 2003 22:34:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20190 for ; Tue, 29 Jul 2003 22:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hgn2-0004GN-00 for sipping@ietf.org; Tue, 29 Jul 2003 22:34:08 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19hgn1-0004GK-00 for sipping@ietf.org; Tue, 29 Jul 2003 22:34:07 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h6U2XIKw001924; Tue, 29 Jul 2003 22:33:18 -0400 Message-ID: <023b01c35642$f2aa1950$0401a8c0@packetizer.org> From: "Paul E. Jones" To: "Henry Sinnreich" , "'Rohan Mahy'" Cc: , , "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , "'Mike Spanner'" , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , "'Andrea Saks'" References: <0HIR003E1L2B5Q@dgismtp04.wcomnet.com> Subject: Re: [Sipping] Re: items for vor voting in the BOF Date: Tue, 29 Jul 2003 22:33:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Henry, The same would likely be said by a boss or busy secretary in many companies. Even so, the bulk of the phones in most enterprises are just little dumb phones with no real features (perhaps feature keys... not much else). I don't expect that to change substantially, even with the introduction of VoIP. After all, more and more capability can be moved onto the PC. Why add hundreds of dollars in value to an IP phone when all of the "cool" features that you want can be placed on the PC (and updated much more easily)? The address book, instant messaging, etc., can all be located on the PC. The PC can interface with the server and with your phone. The phone needs little functionality of its own, really. There are people who buy fancy phones for their homes. Even so, there will be a substantial number of people who just don't care and will buy the cheapest thing they can find. I'm sure that manufacturers will try to cut costs at every opportunity and screens are a target. Should we not plan on it? Paul ----- Original Message ----- From: "Henry Sinnreich" To: "'Paul E. Jones'" ; "'Rohan Mahy'" Cc: ; ; "'Henry Sinnreich'" ; "'Gunnar Hellstrom'" ; "'Mike Spanner'" ; ; ; "'Rajesh Kumar'" ; ; ; "'James Hamlin'" ; ; ; ; ; ; ; "'Andrea Saks'" Sent: Monday, July 28, 2003 10:18 PM Subject: RE: [Sipping] Re: items for vor voting in the BOF > Paul, finally, we disagree! > > We have 3-4 SIP phones in my house at all times and we are using all of them > in various rooms. We would not even dream touching a VoIP phone that does > not have a display and without its own web page where we can see the address > book and dial from the PC or from some another web absed personal call > manager. > > I would certainly not attempt to sell any friend or family member a SIP > phone withou display. Depressing thought. > > Nor would we ever by a mobile phone without display. > > Cheers :-) > > Henry > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Paul E. Jones > > Sent: Sunday, July 20, 2003 11:52 AM > > To: Rohan Mahy > > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; Henry > > Sinnreich; Gunnar Hellstrom; Mike Spanner; > > andreas.piirimets@omnitor.se; trefor@trefor.plus.com; 'Rajesh > > Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > James Hamlin; Erik.Zetterstrom@omnitor.se; > > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; > > mgarakan@cisco.com; oran@cisco.com; sipping@ietf.org; Andrea Saks > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > Rohan, > > > > I offered up a few questions to folks that I hoped people > > would have voted on. The questions I had was whether or not > > there should be a requirement to provide *some* interface to > > legacy TTY devices. Whether it's RJ-11 or 2.5mm makes no > > difference. However, I think it should be a requirement that > > pass-through work at the very least. If this was agreeable, > > I could certainly work to craft specific text for such a requirement. > > > > I do not have stats on how many phones do not have screens. > > However, note that requirement 1 also requires a keyboard, > > though that's never mentioned. > > One could say that text could be entered via some web > > interface, but doing so is a bit hard in a hotel room or at a > > gas station on the side of the road. Regardless, I've said > > before and I'll say it again: I do not expect that most of > > the IP phones that will go into mass production will have a > > suitable screen for text communication. Most of today's IP > > phones have screens, because it is a way to catch people's > > eyes. However, there are also many that do not. Would you > > consider Cisco's ATA, for example, an IP phone? I think it > > qualifies and there is no screen. There are a number of > > service providers deploying that and similar devices from > > other manufacturers. None of those have displays. > > > > I assert that in most enterprise environments, the display is > > of very little value. It's interesting at first, but it's > > not necessary to have a fancy > > screen: just something simple to control hold, transfer, > > conferencing, etc., is enough. In fact, I'd be happy with > > buttons that did that. > > > > At home, I think it's even less of a requirement to have a > > nice-size display. Recognizing that many phones today have a > > display for caller ID, etc., such displays are not suitable > > for text communication. Requirement 1 is asking for a nice > > display... and I think you'll find a much smaller percentage > > of those... especially as they become a commodity item. > > > > Paul > > > > ----- Original Message ----- > > From: "Rohan Mahy" > > To: "Paul E. Jones" > > Cc: ; ; "Henry Sinnreich" > > ; "Gunnar Hellstrom" > > ; "Mike Spanner" > > ; ; > > ; "'Rajesh Kumar'" > > ; ; > > ; "James Hamlin" > > ; ; > > ; ; > > ; ; ; > > "Andrea Saks" > > Sent: Saturday, July 19, 2003 11:14 PM > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > > Hi Paul, > > > > > > So it sounds like you wanted an additional requirement for > > pass-through > > > via a 2.5 mm jack for phones that do not support RFC2793? If I > > > understood this correctly, how would you word the requirement? > > > > > > Also, do you have any data on how many phones currently > > exist (number > > > or percentage) for which requirement 1 would not apply? I > > suspect that > > > the number of phones not covered by the first requirement > > is actually > > > quite small. > > > > > > thanks, > > > -rohan > > > > > > On Friday, July 18, 2003, at 05:04 PM, Paul E. Jones wrote: > > > > > > > Guido, > > > > > > > > I wish I could have attended, but I was attending a TDI conference > > > > here in > > > > the US. I couldn't be in both places at the same time, > > though I wish I > > > > could. I was disheartened that the questions were not > > presented as I > > > > proposed. You should know that, supposedly, work gets > > done over the > > > > e-mail > > > > reflector, not only in the meeting, so not being there > > should not have > > > > lessened my input on the matter. > > > > > > > > Looking at the results of the ad-hoc reported by Rohan, I see: > > > > 1) *If* an IP phone supports a display (and keyboard??), it > > > > must support RFC 2793 > > > > 2) IP phones *should* provide a way to input text > > > > 3) IP phones *may* provide an RJ-11 interface and *must* > > > > support pass-through. > > > > > > > > Now, my concerns are several. It appears that you have > > absolutely no > > > > requirement for the mass of products that do not sport a > > display to > > > > support > > > > text in either relay or pass-through mode. Further, there is no > > > > mention of > > > > a 2.5mm jack being an option. Question 3, as I > > mentioned, "pressured" > > > > folks > > > > more than it should. There should have been no reason to require > > > > support of > > > > pass-through, at the very least. > > > > > > > > I told you that my questions were to ensure that we at least get > > > > support for > > > > text on every phone in one way or another. It looks like > > you lost. > > > > Company > > > > X is now free to build an IP phone without any text > > support. I'm not > > > > really > > > > happy about that and I certainly don't see why you should be. > > > > > > > > Paul > > > > > > > > ----- Original Message ----- > > > > From: "Guido Gybels" > > > > To: "Paul E. Jones" ; > > > > Cc: "Henry Sinnreich" ; "Gunnar > > Hellstrom" > > > > ; "Guido Gybels" > > > > ; > > > > "Mike Spanner" ; > > > > ; > > > > ; ; "'Rajesh Kumar'" > > > > ; ; > > > > ; > > > > "James Hamlin" ; > > > > ; > > > > ; ; > > > > ; > > > > ; ; > > > > Sent: Friday, July 18, 2003 2:31 AM > > > > Subject: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > > >> Paul, > > > >> > > > >> <> > > > >> > > > >> The discussion on the sipdev document took place > > yesterday, and if you > > > > wanted to make a point you were free to attend it. You'll see the > > > > results > > > > reflected in the next version of the document, and I can > > say that both > > > > Arnoud and myself believe this result to be extremely > > sensible as well > > > > as in > > > > the best interest of all stakeholders. > > > >> I also suggest this no longer belongs here on the > > mailing list until > > > >> a new > > > > issue would arise. I have stopped replying to your emails > > a while ago > > > > as I > > > > see no point in continuing the discussion (and swamping > > the list) with > > > > someone who, despite being a native English speaker, > > seems unable to > > > > understand what we are saying and more importantly deliberately > > > > misrepresents my statements or attributes words to my > > mouth that I did > > > > not > > > > speak. > > > >> > > > >> < > know you'd say > > > >> "no" > > > > to > > > >> it.>> > > > >> > > > >> This being a nice example of that. > > > >> > > > >> > > > >> I believe the IETF community has shown great wisdom and a true > > > > understanding of what is at stake here. We have now got a > > solid path > > > > to the > > > > future, with a clear strategy to get rid of obsolete and > > unsatisfactory > > > > solutions allowing a gradual move of deaf, hard of > > hearing and speech > > > > impaired people into mainstream technology. That will of > > course take > > > > time > > > > during which there will have to be legacy support and all the > > > > instruments > > > > are put in place to do exactly that. > > > >> > > > >> Guido > > > >> > > > >> Guido Gybels > > > >> Director of New Technologies > > > >> > > > >> RNID, 19-23 Featherstone Street > > > >> London EC1Y 8SL, UK > > > >> Tel +44(0)20-7294 3713 > > > >> Fax +44(0)20-7296 8069 > > > >> > > > >> _______________________________________________ > > > >> Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > >> This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 14:43:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26473 for ; Thu, 7 Aug 2003 14:43:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpjC-0007Nm-SW for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 14:43:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77IhAJv028372 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 14:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpjC-0007NX-OP for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 14:43:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26460 for ; Thu, 7 Aug 2003 14:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpjA-0001hq-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 14:43:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kpj9-0001hm-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 14:43:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpj4-0007MW-45; Thu, 07 Aug 2003 14:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpib-0007Lb-Ep for sipping@optimus.ietf.org; Thu, 07 Aug 2003 14:42:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26422 for ; Thu, 7 Aug 2003 14:42:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpiY-0001hU-00 for sipping@ietf.org; Thu, 07 Aug 2003 14:42:30 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19kpiX-0001gD-00 for sipping@ietf.org; Thu, 07 Aug 2003 14:42:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h77IfxB31991 for ; Thu, 7 Aug 2003 13:41:59 -0500 From: Robert Sparks To: sipping@ietf.org Content-Type: text/plain Message-Id: <1060281712.932.16.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 07 Aug 2003 13:41:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Request for editorial input 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 noted at IETF57, I'm picking up editorship of the torture-test document. One of the things I want to do is disambiguate the printed text examples. There are cases now where the torture consists of having very long text fields. For example: CSeq: 239sdfadfnm34r5u09sdfawetrq3o4t5nodifnaoihesfoiw34foisdfeijjnaosdfj4iosdfnaehnaasoo34ijdfn5kl3neasdfvnazs which gets broken into a format that is not valid for SIP when you try to render withing the 72 column limit of internet drafts. (Its probably also broken badly in this message by many mail readers). I propose making such breaks explicit as follows: If I needed to break the following (short for clarity) header field: Foo: areallybigtoken I'll render it as Foo: areally bigtoken or Foo: areally big token Objections? Alternative suggestions? Additionally, I'm considering including an appendix with an ascii-armored container (a zip-file or compressed tarball perhaps) with each message (so that we can include some torturous whitespace and non-ASCII range UTF8 tests. RjS _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 16:17:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00936 for ; Thu, 7 Aug 2003 16:17:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19krCG-0003ON-JT for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 16:17:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77KHGr8013035 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 16:17:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19krCG-0003OA-GX for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 16:17:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00927 for ; Thu, 7 Aug 2003 16:17:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19krCE-0002TY-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 16:17:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19krCE-0002TV-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 16:17:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19krC2-0003ND-2T; Thu, 07 Aug 2003 16:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19krBd-0003Mk-Vf for sipping@optimus.ietf.org; Thu, 07 Aug 2003 16:16:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00903 for ; Thu, 7 Aug 2003 16:16:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19krBc-0002TE-00 for sipping@ietf.org; Thu, 07 Aug 2003 16:16:36 -0400 Received: from mta1.wss.scd.yahoo.com ([66.218.85.32]) by ietf-mx with esmtp (Exim 4.12) id 19krBb-0002TA-00 for sipping@ietf.org; Thu, 07 Aug 2003 16:16:35 -0400 Received: from pack1 (68.84.54.181) by mta1.wss.scd.yahoo.com (7.0.016) (authenticated as krishnan@packetstrategies.com) id 3F0B40B900A29F33; Thu, 7 Aug 2003 13:16:04 -0700 Message-ID: <014f01c35d20$b7e6aab0$0202a8c0@sumt01.nj.comcast.net> From: "Krishnan Padmanabhan, Packet Strategies" To: "Henry Sinnreich" Cc: References: <0HIR003E1L2B5Q@dgismtp04.wcomnet.com> Subject: Re: [Sipping] Re: items for vor voting in the BOF Date: Thu, 7 Aug 2003 16:15:58 -0400 Organization: Packet Strategies, LLC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 wonder how representative the tastes and preferences in your household are of those of the consumers of SIP service today. We do know that the 40,000+ lines of Vonage's SIP service are based on the Cisco ATA, with at most a Caller ID display on their phones. Ditto for the consumers for VoicePulse and Packet8. Delta3's Iconnecthere SIP service permits consumers to use any SIP phone they want, but provides technical support only for the ATA. OTOH Cisco recently announced their 2 millionth IP Phone shipment. These are probably more representative of the phones in your household (assuming they didn't include the ATAs in this milestone), but it appears Cisco sold the overwhelming majority of these phones to enterprises. Also, the only sub-$100 SIP phone I am aware of today is Grandstream Networks BudgetOne-101, which has only a Caller-ID display. Krishnan ----- Henry Sinnreich wrote ----- From: "Henry Sinnreich" To: "'Paul E. Jones'" et al. Sent: Monday, July 28, 2003 10:18 PM Subject: RE: [Sipping] Re: items for vor voting in the BOF > Paul, finally, we disagree! > > We have 3-4 SIP phones in my house at all times and we are using all of them > in various rooms. We would not even dream touching a VoIP phone that does > not have a display and without its own web page where we can see the address > book and dial from the PC or from some another web absed personal call > manager. > > I would certainly not attempt to sell any friend or family member a SIP > phone withou display. Depressing thought. > > Nor would we ever by a mobile phone without display. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 19:04:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07824 for ; Thu, 7 Aug 2003 19:03:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ktnE-0001Km-Ed for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 19:03:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77N3aOP005127 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 19:03:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ktnE-0001Kc-Ap for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 19:03:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07814 for ; Thu, 7 Aug 2003 19:03:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ktn6-0003XW-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 19:03:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ktn6-0003XT-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 19:03:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ktmf-0001GP-Hi; Thu, 07 Aug 2003 19:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ktlj-0001GA-Cd for sipping@optimus.ietf.org; Thu, 07 Aug 2003 19:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07789 for ; Thu, 7 Aug 2003 19:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ktlg-0003X6-00 for sipping@ietf.org; Thu, 07 Aug 2003 19:02:00 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19ktlf-0003Ws-00 for sipping@ietf.org; Thu, 07 Aug 2003 19:01:59 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJ900CKDUB1HB@firewall.wcom.com> for sipping@ietf.org; Thu, 07 Aug 2003 22:54:37 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJ900101UAZUD@dgismtp04.wcomnet.com>; Thu, 07 Aug 2003 22:54:37 +0000 (GMT) Received: from hsinnreich2 ([166.50.96.107]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJ900LBSUAUX3@dgismtp04.wcomnet.com>; Thu, 07 Aug 2003 22:54:36 +0000 (GMT) Date: Thu, 07 Aug 2003 17:54:31 -0500 From: Henry Sinnreich Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: To: "'Bernard Aboba'" , "'Allison Mankin'" Cc: sipping@ietf.org Message-id: <0HJ900LBYUAZX3@dgismtp04.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNdCp4YwsXOnV71QgSDJSNpSA/81gAKhoWg 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 Bernard, you have got it right: 1. Sterman draft on digest authentication w/RADIUS. 2. Draft on RADIUS accounting w/SIP. 3. RADIUS Prepaid accounting support. 4. Document on RADIUS transport behavior, to support (2). Also, his is an excellent overview of RADIUS. Many of us work however in organizations that either sell/deploy web services and/or actively develop it. How can we get a handle on web services when comparing the options? (This means I am unfortunately not volunteering) BTW: My observations are the same as Jiri's: Nobody has asked for DIAMETER, and all are asking for RADIUS. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Bernard Aboba > Sent: Tuesday, August 05, 2003 12:11 PM > To: Allison Mankin > Cc: sipping@ietf.org > Subject: Re: AW: [Sipping] FYI: RADIUS & SIP > > > I believe they'd be more appropriate developed in SIPPING, > > with cross-review from the RADIUS group. But I think SIPPING needs some > > information on what the RADIUS working group-to-be is expected to do on > RADIUS, > > in what timeframe. From what I've understood, the charter would not > primarily > > be applications. Could you give us more understanding? > > Here is a summary of the discussion so far: > > Basic RADIUS work > > Since RADIUS is running out of attribute space, it was suggested that a > basic attribute extension mechanism (such as one using the reserved > vendorid of 0) be added. > > This item could be handled in a 1-2 page document so it should have a > short timeframe (~6 months). > > There is interest in specifying how RADIUS handles prepaid accounting. > Requests for this are coming from the SIP community as well as 3GPP2 > and folks interested in WLAN prepaid: > > http://www.watersprings.org/pub/id/draft-lior-radius-prepaid-extensions- > 01.txt > > My understanding is that 3GPP2 intends to include this in a forthcoming > standard so that the timeframe needs to be set to meet their needs. > > In order to address concerns about RADIUS transport behavior and > accounting reliability, there has been interest expressed on a draft on > RADIUS transport behavior. This would presumably address some of the more > egregious problems encountered with existing implementations (such as > lack of backoff or jittering) as well as describing how RADIUS might be > made to work more reliably: > > http://www.watersprings.org/pub/id/draft-lior-radius-reliable-accounting- > 00.txt > > Without some fundamental changes to RADIUS (such as addition of > a heartbeat), it is not clear that it will be possible to specify a > demonstrably correct failover algorithm in addition to handling basic > transport response issues (e.g. backoff, jittering, RTT estimation, etc.). > > So there is some question about the scope of a potential transport > document (e.g. just basic retransmission behavior or retransmssion + > failover). On the face of it, it seems that it would require a lot of > changes to make RADIUS as reliable as Diameter: > > http://www.ietf.org/rfc/rfc3539.txt > > The timeframe of this work could be short (~9 months) assuming that the > scope is containable. > > WLAN-related > > A number of different organizations (WFA, IEEE, etc.) have been specifying > WLAN-related attributes. There appears to be interest in standardizing > the most useful ones. This and some other WLAN-related work is described > here: > > http://www.watersprings.org/pub/id/draft-adrangi-radius-issues-in-pwlan- > roaming-00.txt > > The timeframe for this is hard to estimate, but I'd guess it is ~18 months > or so. > > We also had a request from the IEEE 802.11 Liason, Dorothy Stanley, for > work on fast handoff. Bill Arbaugh at the University of Maryland is > implementing the draft below: > > http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-02.txt > > However, Bill has requested that this work not be considered as an IETF WG > work item until his research is complete and the usefulness of the > proposed extension can be evaluated. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 20:24:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09688 for ; Thu, 7 Aug 2003 20:24:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3T-0003rT-FX for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 20:24:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h780ORlF014842 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 20:24:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3T-0003rI-Bv for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 20:24:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09551 for ; Thu, 7 Aug 2003 20:24:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kv3R-0003wH-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 20:24:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kv3P-0003vT-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 20:24:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv37-0003hT-N2; Thu, 07 Aug 2003 20:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kudR-0002t7-2s for sipping@optimus.ietf.org; Thu, 07 Aug 2003 19:57:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08890 for ; Thu, 7 Aug 2003 19:57:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kudP-0003m0-00 for sipping@ietf.org; Thu, 07 Aug 2003 19:57:31 -0400 Received: from dsl-dt-207-34-112-i195-cgy.nucleus.com ([207.34.112.195] helo=yyc.jasomi.com) by ietf-mx with esmtp (Exim 4.12) id 19kudO-0003lx-00 for sipping@ietf.org; Thu, 07 Aug 2003 19:57:30 -0400 Received: from jasomi.com (p-unused-217.jasomi.com [207.34.112.217] (may be forged)) (authenticated bits=0) by yyc.jasomi.com (8.12.9/8.12.6) with ESMTP id h77NfWiT000197 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Aug 2003 17:41:33 -0600 (MDT) Date: Thu, 7 Aug 2003 17:57:20 -0600 Subject: Re: [Sipping] Request for editorial input Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sipping@ietf.org To: Robert Sparks From: Alan Hawrylyshen In-Reply-To: <1060281712.932.16.camel@RjS.localdomain> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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, Aug 7, 2003, at 12:41 Canada/Mountain, Robert Sparks wrote: > As noted at IETF57, I'm picking up editorship of the torture-test > document. > Excellent. > [snip] > I propose making such breaks explicit as follows: > [snip] > Foo: areally > bigtoken > > or > > Foo: areally > big > token > > I'm tempted to suggest something less intrusive like a single EOL marker that indicates that the next line's leading WS is to be elided from the example text. Something like '*' or '~'. eg) Foo: areally~ big~ token equivalent to: Foo: areallybigtoken Of course this means that the above (legal) SIP would be hard to represent in the draft in literal form. Not that this is better, but is IS more readable (IMHO). Perhaps there is a problem that I am overlooking with this, but it is certainly less intrusive. :-) Thoughts? As for the appendix, are you proposing that the published draft would contain the (potentially base 64) encoded compressed archive of example messages -- completely unreadable by humans, but useful for extracting the examples? Alan Hawrylyshen Jasomi Networks Inc. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 7 20:24:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09690 for ; Thu, 7 Aug 2003 20:24:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3T-0003rl-HX for sipping-archive@odin.ietf.org; Thu, 07 Aug 2003 20:24:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h780ORBt014856 for sipping-archive@odin.ietf.org; Thu, 7 Aug 2003 20:24:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3T-0003rJ-DH for sipping-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 20:24:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09548 for ; Thu, 7 Aug 2003 20:24:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kv3Q-0003wC-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 20:24:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kv3P-0003vK-00 for sipping-web-archive@ietf.org; Thu, 07 Aug 2003 20:24:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv36-0003gp-LX; Thu, 07 Aug 2003 20:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kuYh-0002ma-UN for sipping@optimus.ietf.org; Thu, 07 Aug 2003 19:52:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08813 for ; Thu, 7 Aug 2003 19:52:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kuYg-0003l5-00 for sipping@ietf.org; Thu, 07 Aug 2003 19:52:38 -0400 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 19kuYf-0003ku-00 for sipping@ietf.org; Thu, 07 Aug 2003 19:52:37 -0400 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id h77Nm3CW020737; Thu, 7 Aug 2003 16:48:03 -0700 (PDT) Received: from convedia.com (egret.convedia.com [192.168.208.147]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18956; Thu, 7 Aug 2003 16:52:00 -0700 (PDT) Message-ID: <3F32E67B.2060109@convedia.com> Date: Thu, 07 Aug 2003 16:53:31 -0700 From: Tim Melanchuk User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishal Phirke CC: Chris Boulton , Garland Sharratt , sipping@ietf.org Subject: Re: [Sipping] draft-melanchuk-sipping-msml-00.txt 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 vishal, i hope the following explanation helps. please let me know if you still have any questions or comments. "dialog execution environment" is intended to be a generic term which represents a black box from the msml perspective. that is, msml creates media streams to and from the black box, and the behaviour in the black box is specified by the dialog language. moml allows an application to specify how (and when) primitives are wired together. when primitives are defined to execute sequentially, (i.e. are not in a group), then each primitive is connected to a media stream in turn. when one completes, the next is connected etc. when used with msml, the media stream is the "target" of the . when primitives are grouped for concurrent execution, then the primitives may be bridged to the "target" depending upon the topology as described in section 2.2 of moml for a one dimensional group. the dimension of a group defines the number of media streams which it supports. a dialog has one media stream. timm Vishal Phirke wrote: > > Hi Tim, > I have question regarding msml. > MSML defines three classes of media processing objects, viz., network > connection, conference and dialog execution context. Out of these first two > are physical entities within a media server whereas dialog execution > context is an abstract thing, and a dialog will be typically bound to a > network connection at the time of creation. The discription of the > element says that "A media stream is created between the > dialog execution environment and the connection or conference". I > understand the second endpoint but I am not sure what is the definition of > dialog execution environment. As per my understanding, assuming dialog is > made up of MOML constructs such as play and record, the typical requirement > will be to switch the stream between player and recorder. But I can't see > how a at dialog level can indicate which resource to connect to. Can > you elaborate more on the dialog execution environment? > -Vishal > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 8 00:29:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15447 for ; Fri, 8 Aug 2003 00:29:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kysJ-00040E-GW for sipping-archive@odin.ietf.org; Fri, 08 Aug 2003 00:29:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h784TBb8015386 for sipping-archive@odin.ietf.org; Fri, 8 Aug 2003 00:29:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kysJ-000405-BD for sipping-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 00:29:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15440 for ; Fri, 8 Aug 2003 00:29:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kysG-0005EG-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 00:29:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kysG-0005ED-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 00:29:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kys8-0003z3-Ua; Fri, 08 Aug 2003 00:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kyrx-0003yn-FD for sipping@optimus.ietf.org; Fri, 08 Aug 2003 00:28:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15434 for ; Fri, 8 Aug 2003 00:28:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kyru-0005E4-00 for sipping@ietf.org; Fri, 08 Aug 2003 00:28:46 -0400 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 19kyru-0005E1-00 for sipping@ietf.org; Fri, 08 Aug 2003 00:28:46 -0400 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id h784OGCW021196; Thu, 7 Aug 2003 21:24:16 -0700 (PDT) Received: from laptop33 ([192.168.209.5]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with SMTP id VAA08294; Thu, 7 Aug 2003 21:28:15 -0700 (PDT) From: "Garland Sharratt" To: "De Leo Walter" Cc: Subject: RE: [Sipping] draft-melanchuk-sipping-moml-00.txt Date: Thu, 7 Aug 2003 21:28:14 -0700 Keywords: ..NEW Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2800.1165 In-Reply-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cerbrus.convedia.com id h784OGCW021196 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for the encouragement. We are certainly favorable to this. We designed MSML/MOML to be a powerful and generic system for advanced contr= ol of media servers using SIP, and do hope that SIPPING takes on the drafts = as WG items at some point. Since the drafts were only released in late June= , though, I think they probably need a bit more time for review and concens= us before being formally advanced as WG items. We would certainly welcome a= ny comments you (or others) might have at this point. Garland -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of De Leo Walter Sent: Thursday, August 07, 2003 08:04 To: 'sipping@ietf.org' Subject: RE: [Sipping] draft-melanchuk-sipping-moml-00.txt I am interested in knowing if this drafat an msml draft will be proposed = as workgroup items. I think it should there are some proprietary solutions for ms cotnrol ove= r SIP. Regards > -----Mensaje original----- > De: Tim Melanchuk [SMTP:timm@convedia.com] > Enviado el: Mi=E9rcoles 6 de Agosto de 2003 21:46 > Para: Chris Boulton > CC: Garland Sharratt; sipping@ietf.org > Asunto: Re: [Sipping] draft-melanchuk-sipping-moml-00.txt > > thanks again for your feedback. answers to questions below. > > cheers, > timm > > > > > - Is there an alternative method for defining unlimited occurrences > > using the 'max' attribute =3D 0 (e.g. pattern element uses max within= DTMF > > > primitive). This seemed a little confusing. > > > i've had this comment from others. would extending the datatype > to include an explicit "unlimited" value be less confusing and/or > renaming "max" to "maxoccurs"? > > > > > - 4.5.1.1 The description of and needs to be made > > more explicit. > > > will do. > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 8 05:37:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05463 for ; Fri, 8 Aug 2003 05:37:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3gM-0003oX-IM for sipping-archive@odin.ietf.org; Fri, 08 Aug 2003 05:37:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h789bAsh014657 for sipping-archive@odin.ietf.org; Fri, 8 Aug 2003 05:37:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3gM-0003oC-Eh for sipping-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 05:37:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05451 for ; Fri, 8 Aug 2003 05:37:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l3gI-0007HB-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 05:37:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l3gI-0007H8-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 05:37:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3gE-0003ib-AP; Fri, 08 Aug 2003 05:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3fj-0003ga-P1 for sipping@optimus.ietf.org; Fri, 08 Aug 2003 05:36:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05388 for ; Fri, 8 Aug 2003 05:36:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l3fg-0007G1-00 for sipping@ietf.org; Fri, 08 Aug 2003 05:36:28 -0400 Received: from n197.nomadiclab.com ([131.160.193.197] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 19l3ff-0007FO-00 for sipping@ietf.org; Fri, 08 Aug 2003 05:36:27 -0400 Received: from piuha.net (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h789WriT003749; Fri, 8 Aug 2003 12:32:54 +0300 Message-ID: <3F336E45.7050901@piuha.net> Date: Fri, 08 Aug 2003 12:32:53 +0300 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: Jiri Kuthan , hgs@cs.columbia.edu, sipping@ietf.org Subject: Re: AW: AW: [Sipping] FYI: RADIUS & SIP References: <5.2.0.9.0.20030807180926.053e0eb8@mailhost.fokus.gmd.de> 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 Bernard Aboba wrote: > So the question is: > > "If a major protocol change were to be made to RADIUS to improve > reliability, would such a change be deployed on RADIUS clients and > servers and would it be acceptable for the SIP accounting specification > to depend on such a change?" Given that RADIUS and DIAMETER can work together for dial-in, I think we can make them work together in SIP. Folks who need a reliable & extensible protocol can already deploy DIAMETER. Therefore, my suggestion would be to provide the basic functionality in RADIUS, but NOT start any work on fundamental and possibly non-backwards compatible RADIUS enhancements. That is, lets publish Digest for RADIUS, SIP Accounting attributes for RADIUS*, corresponding versions for DIAMETER, allow these to work together, and let folks decide which protocols their particular situation needs. --Jari *) This one may have to be informational, as is RADIUS accounting base RFC. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 8 05:52:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06067 for ; Fri, 8 Aug 2003 05:52:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3ur-0004xw-2r for sipping-archive@odin.ietf.org; Fri, 08 Aug 2003 05:52:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h789q95k019082 for sipping-archive@odin.ietf.org; Fri, 8 Aug 2003 05:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3uq-0004xh-S2 for sipping-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 05:52:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06045 for ; Fri, 8 Aug 2003 05:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l3un-0007Q7-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 05:52:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l3um-0007Q4-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 05:52:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3uj-0004tp-HI; Fri, 08 Aug 2003 05:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3u1-0004oz-ER for sipping@optimus.ietf.org; Fri, 08 Aug 2003 05:51:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05990 for ; Fri, 8 Aug 2003 05:51:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l3tx-0007PG-00 for sipping@ietf.org; Fri, 08 Aug 2003 05:51:13 -0400 Received: from n197.nomadiclab.com ([131.160.193.197] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 19l3tw-0007OL-00 for sipping@ietf.org; Fri, 08 Aug 2003 05:51:12 -0400 Received: from piuha.net (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h789m6iT003769; Fri, 8 Aug 2003 12:48:07 +0300 Message-ID: <3F3371D6.3080700@piuha.net> Date: Fri, 08 Aug 2003 12:48:06 +0300 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich CC: john.loughney@nokia.com, aboba@internaut.com, sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP References: <0HJ900BOUCO54Y@dgismtp05.wcomnet.com> In-Reply-To: <0HJ900BOUCO54Y@dgismtp05.wcomnet.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 Henry Sinnreich wrote: > We have now four options to discuss in the SIP-AAA > I-D. Hmm.... again, I'm worried that we're spending too much time arguing about the different underlying options. We could easily end up in a lengthy beauty contest and leave everyone using expired I-Ds and vendor specific things in the meanwhile -- which is the current state of affairs. From what I can see, folks have required SIP auth and acct services for both RADIUS and DIAMETER. Lets give these to them, and ensure that they can work together so that folks who want high reliability, for instance, can upgrade to DIAMETER without breaking the possibility of talking to someone who only does RADIUS. --Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 8 10:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11267 for ; Fri, 8 Aug 2003 10:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7oe-0005v6-6Q for sipping-archive@odin.ietf.org; Fri, 08 Aug 2003 10:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78E20Hl022750 for sipping-archive@odin.ietf.org; Fri, 8 Aug 2003 10:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7oe-0005ur-0d for sipping-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 10:02:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11210 for ; Fri, 8 Aug 2003 10:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7ob-0000ty-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 10:01:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l7ob-0000tv-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 10:01:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7ni-0005X5-SJ; Fri, 08 Aug 2003 10:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7nT-0005VL-4d for sipping@optimus.ietf.org; Fri, 08 Aug 2003 10:00:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11105 for ; Fri, 8 Aug 2003 10:00:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7nR-0000st-00 for sipping@ietf.org; Fri, 08 Aug 2003 10:00:45 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19l7nP-0000sN-00 for sipping@ietf.org; Fri, 08 Aug 2003 10:00:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h78E08B10002; Fri, 8 Aug 2003 09:00:08 -0500 Subject: Re: [Sipping] Request for editorial input From: Robert Sparks To: Alan Hawrylyshen Cc: sipping@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1060351207.930.27.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 08 Aug 2003 09:00:07 -0500 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 On Thu, 2003-08-07 at 18:57, Alan Hawrylyshen wrote: > On Thursday, Aug 7, 2003, at 12:41 Canada/Mountain, Robert Sparks wrote: > > [snip] > > I propose making such breaks explicit as follows: > > [snip] > > Foo: areally > > bigtoken > > > > or > > > > Foo: areally > > big > > token > > > > > > I'm tempted to suggest something less intrusive like a single EOL > marker that indicates that the next line's leading WS is to be elided > from the example text. Something like '*' or '~'. > eg) > Foo: areally~ > big~ > token > > equivalent to: > > Foo: areallybigtoken > > Of course this means that the above (legal) SIP would be hard to > represent in the draft in literal form. > > Not that this is better, but is IS more readable (IMHO). Perhaps there > is a problem that I am overlooking with this, but it is certainly less > intrusive. :-) Thoughts? Adam suggested something similar (based on MIME conventions). My concern (fwiw) is that I don't expect it to be easy to find a single symbol that wouldn't be a legal character where it was breaking a line (it's not always a token that needs breaking). We could adopt a convention that anytime that appeared last on a line in the text of this document it has special meaning, but it brings us back to ambiguity. Arguably, this can suffer from the same deficiency, but it uses a high level of intrusiveness as a tool to help resolve the ambiguity in the intended way. An alternative would be to put in the examples something along the lines of: INVITE sip:a.example.com SIP/2.0 To: sip:b.example.com Call-ID: 23423423039480239840234 2390498u239759237947293 39457349539485739485739 20234802908u09823095480 CSeq: 83347 INVITE That said, I don't feel too strongly about how we add this extra hint as long as we add something. > > As for the appendix, are you proposing that the published draft would > contain the (potentially base 64) encoded compressed archive of example > messages -- completely unreadable by humans, but useful for extracting > the examples? Exactly. A few pages of 4799EA9280F923870CDD3988A... or the like. > > > Alan Hawrylyshen > Jasomi Networks Inc. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 8 10:25:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13171 for ; Fri, 8 Aug 2003 10:25:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8B3-00074K-3J for sipping-archive@odin.ietf.org; Fri, 08 Aug 2003 10:25:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78EP9Tv027172 for sipping-archive@odin.ietf.org; Fri, 8 Aug 2003 10:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8B2-00074B-FY for sipping-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 10:25:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13148 for ; Fri, 8 Aug 2003 10:25:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8B0-000179-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 10:25:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l8Az-000176-00 for sipping-web-archive@ietf.org; Fri, 08 Aug 2003 10:25:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8Aw-00071B-G5; Fri, 08 Aug 2003 10:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8A3-000706-4D for sipping@optimus.ietf.org; Fri, 08 Aug 2003 10:24:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13122 for ; Fri, 8 Aug 2003 10:24:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8A0-00016g-00 for sipping@ietf.org; Fri, 08 Aug 2003 10:24:04 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19l8A0-00016W-00 for sipping@ietf.org; Fri, 08 Aug 2003 10:24:04 -0400 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJB00CAN0ZRM7@firewall.wcom.com> for sipping@ietf.org; Fri, 08 Aug 2003 14:16:39 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJB00F010WDFJ@dgismtp01.wcomnet.com>; Fri, 08 Aug 2003 14:16:39 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.95]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJB00BR10Z8I1@dgismtp01.wcomnet.com>; Fri, 08 Aug 2003 14:16:21 +0000 (GMT) Date: Fri, 08 Aug 2003 09:16:21 -0500 From: Henry Sinnreich Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: <3F3371D6.3080700@piuha.net> To: jarkko@piuha.net Cc: john.loughney@nokia.com, aboba@internaut.com, sipping@ietf.org Message-id: <0HJB00BR20Z8I1@dgismtp01.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNdksIgnW6gpUlBTEOzhho73YD6wAAJGctA 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 > Hmm.... again, I'm worried that we're spending too much > time arguing about the different underlying options. The SIP-AAA WG has to find the best solution for SIP-AAA and is not a venue to promote DIAMETER. Certainly no decision should be made without evaluating all available options. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Jari Arkko > Sent: Friday, August 08, 2003 4:48 AM > To: Henry Sinnreich > Cc: john.loughney@nokia.com; aboba@internaut.com; sipping@ietf.org > Subject: Re: AW: [Sipping] FYI: RADIUS & SIP > > Henry Sinnreich wrote: > > > We have now four options to discuss in the SIP-AAA > > I-D. > > Hmm.... again, I'm worried that we're spending too much > time arguing about the different underlying options. > We could easily end up in a lengthy beauty contest and > leave everyone using expired I-Ds and vendor specific > things in the meanwhile -- which is the current state of > affairs. > > From what I can see, folks have required SIP auth and > acct services for both RADIUS and DIAMETER. Lets give > these to them, and ensure that they can work together > so that folks who want high reliability, for instance, > can upgrade to DIAMETER without breaking the possibility > of talking to someone who only does RADIUS. > > --Jari > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 8 14:54:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21085 for ; Fri, 8 Aug 2003 14:54:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCN7-00025F-7l for sipping-archive@odin.ietf.org; Fri, 08 Aug 2003 14:53:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78IrrNe008005 for sipping-archive@odin.ietf.org; Fri, 8 Aug 2003 14:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCN7-000252-4I for sipping-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 14:53:53 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21081 for ; Fri, 8 Aug 2003 14:53:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCMH-0001wD-JM; Fri, 08 Aug 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCM2-0001vp-El for sipping@optimus.ietf.org; Fri, 08 Aug 2003 14:52:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21060 for ; Fri, 8 Aug 2003 14:52:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lCLz-0002tk-00 for sipping@ietf.org; Fri, 08 Aug 2003 14:52:43 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19lCLy-0002tg-00 for sipping@ietf.org; Fri, 08 Aug 2003 14:52:42 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h78IqBRd022844; Fri, 8 Aug 2003 14:52:11 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 13:52:12 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862AC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , Alan Hawrylyshen Cc: sipping@ietf.org Subject: RE: [Sipping] Request for editorial input Date: Fri, 8 Aug 2003 13:52:10 -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: , Actually, my suggestion (although I didn't do a good job of conveying it) would be to encode *all* the examples using MIME Quoted-Printable encoding, thus removing all ambiguity (and providing testers with ready-built decoders). The downside of having all instances of "=" appear as "=3D" should, of course, be considered.... /a > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Friday, August 08, 2003 9:00 > To: Alan Hawrylyshen > Cc: sipping@ietf.org > Subject: Re: [Sipping] Request for editorial input > > > inline > On Thu, 2003-08-07 at 18:57, Alan Hawrylyshen wrote: > > On Thursday, Aug 7, 2003, at 12:41 Canada/Mountain, Robert > Sparks wrote: > > > [snip] > > > I propose making such breaks explicit as follows: > > > [snip] > > > Foo: areally > > > bigtoken > > > > > > or > > > > > > Foo: areally > > > big > > > token > > > > > > > > > > I'm tempted to suggest something less intrusive like a single EOL > > marker that indicates that the next line's leading WS is to > be elided > > from the example text. Something like '*' or '~'. > > eg) > > Foo: areally~ > > big~ > > token > > > > equivalent to: > > > > Foo: areallybigtoken > > > > Of course this means that the above (legal) SIP would be hard to > > represent in the draft in literal form. > > > > Not that this is better, but is IS more readable (IMHO). > Perhaps there > > is a problem that I am overlooking with this, but it is > certainly less > > intrusive. :-) Thoughts? > > Adam suggested something similar (based on MIME conventions). > > My concern (fwiw) is that I don't expect it to be easy to > find a single > symbol that wouldn't be a legal character where it was breaking a line > (it's not always a token that needs breaking). We could adopt a > convention that anytime that appeared last on a line in the text of > this document it has special meaning, but it brings us back to > ambiguity. Arguably, this can suffer from the same > deficiency, but it uses a high level of intrusiveness as a > tool to help > resolve the ambiguity in the intended way. > > An alternative would be to put in the examples something > along the lines > of: > > INVITE sip:a.example.com SIP/2.0 > To: sip:b.example.com > > Call-ID: 23423423039480239840234 > 2390498u239759237947293 > 39457349539485739485739 > 20234802908u09823095480 > > CSeq: 83347 INVITE > > That said, I don't feel too strongly about how we add this extra hint > as long as we add something. > > > > > As for the appendix, are you proposing that the published > draft would > > contain the (potentially base 64) encoded compressed > archive of example > > messages -- completely unreadable by humans, but useful for > extracting > > the examples? > > Exactly. A few pages of 4799EA9280F923870CDD3988A... or the like. > > > > > > > > Alan Hawrylyshen > > Jasomi Networks Inc. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Sun Aug 10 14:04:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12088 for ; Sun, 10 Aug 2003 14:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY9-0001U7-Of for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AI4DO1005695 for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY9-0001Tc-Ko for sipping-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12051 for ; Sun, 10 Aug 2003 14:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luY6-0000jH-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 14:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19luY5-0000j4-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY0-0001Ok-Vp; Sun, 10 Aug 2003 14:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luX9-0001MQ-Np for sipping@optimus.ietf.org; Sun, 10 Aug 2003 14:03:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11984 for ; Sun, 10 Aug 2003 14:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luX7-0000iL-00 for sipping@ietf.org; Sun, 10 Aug 2003 14:03:09 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19luX6-0000ho-01 for sipping@ietf.org; Sun, 10 Aug 2003 14:03:08 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2003 11:02:47 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7AI2gLJ022194; Sun, 10 Aug 2003 11:02:44 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47210; Sun, 10 Aug 2003 11:02:41 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Aug 2003 11:51:55 -0700 Subject: Re: [Sipping] DTMF: Why Not A New Method? From: Cullen Jennings To: sipping CC: Adam Roach Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86259@dyn-tx-exch-001.dynamicsoft.com> 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 There has been some discussion on the MESSAGE vs. NEW_METHOD for reporting the information from KPML. I don't think I have heard any strong argument for MESSAGE over NEW_METHOD but I have gotten a little lost on the whole argument. I think we might have consensus on NEW_METHOD but I'm not sure. I don't care but I think we need to make a decision on this and get on with it. Do we have consensus on this? Cullen On 7/24/03 13:56, "Adam Roach" wrote: > Oh, in that case... > > +------------------------------------------------------------+ > | You have received an IM of type "application/kpml+xml", | > | which is not a registered media type. | > | | > | [x] Save it as a file | > | [ ] Open it with application: ________________ | > | | > | [x] Always ask when handing type "application/kpml+xml" | > | | > | [OK] [Cancel] | > +------------------------------------------------------------+ > > /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 exim@www1.ietf.org Sun Aug 10 14:04:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12092 for ; Sun, 10 Aug 2003 14:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY9-0001TT-Gj for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AI4DQb005662 for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY9-0001TF-D0 for sipping-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12044 for ; Sun, 10 Aug 2003 14:04:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luY6-0000jF-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 14:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19luY5-0000j2-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luXz-0001O3-N3; Sun, 10 Aug 2003 14:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luX9-0001MK-1S for sipping@optimus.ietf.org; Sun, 10 Aug 2003 14:03:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11979 for ; Sun, 10 Aug 2003 14:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luX6-0000iB-00 for sipping@ietf.org; Sun, 10 Aug 2003 14:03:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19luX5-0000ho-01 for sipping@ietf.org; Sun, 10 Aug 2003 14:03:07 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2003 11:02:45 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7AI2gLH022194; Sun, 10 Aug 2003 11:02:42 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47207; Sun, 10 Aug 2003 11:02:40 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Aug 2003 11:37:56 -0700 Subject: Re: [Sipping] Request for editorial input From: Cullen Jennings To: Robert Sparks , Alan Hawrylyshen CC: Message-ID: In-Reply-To: <1060351207.930.27.camel@RjS.localdomain> 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 Some convention like this would be very helpful to me in the S/MIME example call flows. Just about anything would be fine with me. Does this need to be a IETF discussion? On 8/8/03 7:00, "Robert Sparks" wrote: > inline > On Thu, 2003-08-07 at 18:57, Alan Hawrylyshen wrote: >> On Thursday, Aug 7, 2003, at 12:41 Canada/Mountain, Robert Sparks wrote: >>> [snip] >>> I propose making such breaks explicit as follows: >>> [snip] >>> Foo: areally >>> bigtoken >>> >>> or >>> >>> Foo: areally >>> big >>> token >>> >>> >> >> I'm tempted to suggest something less intrusive like a single EOL >> marker that indicates that the next line's leading WS is to be elided >> from the example text. Something like '*' or '~'. >> eg) >> Foo: areally~ >> big~ >> token >> >> equivalent to: >> >> Foo: areallybigtoken >> >> Of course this means that the above (legal) SIP would be hard to >> represent in the draft in literal form. >> >> Not that this is better, but is IS more readable (IMHO). Perhaps there >> is a problem that I am overlooking with this, but it is certainly less >> intrusive. :-) Thoughts? > > Adam suggested something similar (based on MIME conventions). > > My concern (fwiw) is that I don't expect it to be easy to find a single > symbol that wouldn't be a legal character where it was breaking a line > (it's not always a token that needs breaking). We could adopt a > convention that anytime that appeared last on a line in the text of > this document it has special meaning, but it brings us back to > ambiguity. Arguably, this can suffer from the same > deficiency, but it uses a high level of intrusiveness as a tool to help > resolve the ambiguity in the intended way. > > An alternative would be to put in the examples something along the lines > of: > > INVITE sip:a.example.com SIP/2.0 > To: sip:b.example.com > > Call-ID: 23423423039480239840234 > 2390498u239759237947293 > 39457349539485739485739 > 20234802908u09823095480 > > CSeq: 83347 INVITE > > That said, I don't feel too strongly about how we add this extra hint > as long as we add something. > >> >> As for the appendix, are you proposing that the published draft would >> contain the (potentially base 64) encoded compressed archive of example >> messages -- completely unreadable by humans, but useful for extracting >> the examples? > > Exactly. A few pages of 4799EA9280F923870CDD3988A... or the like. > > >> >> >> Alan Hawrylyshen >> Jasomi Networks Inc. > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Sun Aug 10 14:04:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12119 for ; Sun, 10 Aug 2003 14:04:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY9-0001Tm-Ly for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AI4Dxt005678 for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY9-0001TV-IR for sipping-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12046 for ; Sun, 10 Aug 2003 14:04:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luY6-0000jB-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 14:04:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19luY5-0000j1-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY2-0001PQ-AL; Sun, 10 Aug 2003 14:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luXQ-0001Mq-2g for sipping@optimus.ietf.org; Sun, 10 Aug 2003 14:03:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11993 for ; Sun, 10 Aug 2003 14:03:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luXN-0000ia-00 for sipping@ietf.org; Sun, 10 Aug 2003 14:03:25 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19luXN-0000hy-00 for sipping@ietf.org; Sun, 10 Aug 2003 14:03:25 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7AI2epp027414; Sun, 10 Aug 2003 11:02:41 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47201; Sun, 10 Aug 2003 11:02:34 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Aug 2003 11:26:33 -0700 From: Cullen Jennings To: CC: Jiri Kuthan , Henning Schulzrinne , Bernard Aboba , Message-ID: In-Reply-To: <3F336E45.7050901@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] RADIUS & SIP & DIAMETER 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 Jari that we should be able to define extensions that are parallel definitions that carry the same semantics in Radius or DIAMETER and avoid many arguments about what the future will be. It should be the semantic information we want to transfer that is important to the SIPPING group, not the transport. I think we should keep the Authentication work somewhat separate in our minds from the Accounting work - they have little in common. I agree with the comment that no one is asking for Diameter - the requests I have heard have all been for Radius Accounting. I have not had requests for Diameter or really for Authentication / Authorization outside of 3GPP. I think it is worth doing, Cisco implemented an Authentication scheme for SIP over Radius a long time ago but I don't believe it has ever been used in a production network. A ton of people are using Radius for SIP billing in production networks - I think Accounting is a higher priority, but less interesting, issue than Authentication. I find the arguments of why Radius should not be used for Accounting somewhat compelling but until service providers request it, it is not likely to be real high priority. Because of this, I like Jari idea of getting the semantic information done for both in a way that allows Radius to work today for providers that use it but minimizes the changes to move to Diameter. Cullen On 8/8/03 2:32, "Jari Arkko" wrote: > Bernard Aboba wrote: > >> So the question is: >> >> "If a major protocol change were to be made to RADIUS to improve >> reliability, would such a change be deployed on RADIUS clients and >> servers and would it be acceptable for the SIP accounting specification >> to depend on such a change?" > > Given that RADIUS and DIAMETER can work together for dial-in, I > think we can make them work together in SIP. Folks who need a > reliable & extensible protocol can already deploy DIAMETER. > Therefore, my suggestion would be to provide the basic functionality > in RADIUS, but NOT start any work on fundamental and possibly > non-backwards compatible RADIUS enhancements. That is, lets > publish Digest for RADIUS, SIP Accounting attributes for RADIUS*, > corresponding versions for DIAMETER, allow these to work > together, and let folks decide which protocols their particular > situation needs. > > --Jari > > *) This one may have to be informational, as is RADIUS accounting > base RFC. > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Sun Aug 10 14:04:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12117 for ; Sun, 10 Aug 2003 14:04:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY9-0001UE-P9 for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7AI4Dtk005701 for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luY9-0001Tl-Ll for sipping-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 14:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12053 for ; Sun, 10 Aug 2003 14:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luY7-0000jK-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 14:04:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19luY5-0000j6-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 14:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luXy-0001NK-Sh; Sun, 10 Aug 2003 14:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19luX8-0001MF-IB for sipping@optimus.ietf.org; Sun, 10 Aug 2003 14:03:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11976 for ; Sun, 10 Aug 2003 14:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19luX6-0000i8-00 for sipping@ietf.org; Sun, 10 Aug 2003 14:03:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19luX5-0000ho-00 for sipping@ietf.org; Sun, 10 Aug 2003 14:03:07 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2003 11:02:38 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7AI2Z7F003525; Sun, 10 Aug 2003 11:02:35 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47200; Sun, 10 Aug 2003 11:02:33 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Aug 2003 11:03:16 -0700 Subject: Re: [Sipping] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt From: Cullen Jennings To: Eric Burger , Alan Johnston CC: Message-ID: In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F6551@zoe.office.snowshore.com> 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 One of the problems with end of call reporting is that it needs to have enough time based granularity information to be useful. For example .... Consider two calls. Call A. This is a 100 minute call with 1% packet loss distributed evenly. Call B. This had 0% packet loss for first 99 minutes then 100% packet loss for 1 minute then user hung up. Call A was a good call and the service provider is probably happy. Call B is a bad call and needs attention. The reporting needs to differentiate between these two cases. Cullen On 7/14/03 8:09, "Eric Burger" wrote: > Would any reporting system ever be interested in RTCP messages? I would > expect network operators (who I presume would be the interested third-parties) > to be interested in end-of-call summaries only. Otherwise, a service provider > of any significant size is signing up for a significant amount of RTCP > reporting (flooding?). > > Being NOTIFIED of end-of-call statistics is a sensible option. That way you > can use the existing SIP security, subscription, and message routing > infrastructure. > >> -----Original Message----- >> From: Alan Johnston [mailto:alan.johnston@mci.com] >> Sent: Fri, June 27, 2003 2:38 PM >> To: sipping@ietf.org >> Subject: [Sipping] FWD:I-D >> ACTION:draft-johnston-sipping-rtcp-summary-00.txt >> >> >> FYI - a new draft on the delivery of RTCP summary reports to >> third parties. >> >> Comments most welcome. >> >> Thanks, >> Alan Johnston >> MCI >> >> >> ---------- >> To: IETF-Announce: ; >> Subject: I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt >> From: Internet-Drafts@ietf.org >> Date: Tue, 24 Jun 2003 06:56:20 -0400 >> Reply-to: Internet-Drafts@ietf.org >> Sender: owner-ietf-announce@ietf.org >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> >> Title : RTCP Summary Report Delivery to >> SIP Third Parties >> Author(s) : A. Johnston, H. Sinnreich, A. Clark >> Filename : draft-johnston-sipping-rtcp-summary-00.txt >> Pages : 9 >> Date : 2003-6-23 >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Sun Aug 10 19:48:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19876 for ; Sun, 10 Aug 2003 19:48:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lzv8-0002ev-7t for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 19:48:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ANmIr8010215 for sipping-archive@odin.ietf.org; Sun, 10 Aug 2003 19:48:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lzv8-0002eg-3z for sipping-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 19:48:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19870 for ; Sun, 10 Aug 2003 19:48:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lzv6-0001qW-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 19:48:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lzv5-0001qT-00 for sipping-web-archive@ietf.org; Sun, 10 Aug 2003 19:48:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lzur-0002dh-03; Sun, 10 Aug 2003 19:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lzu3-0002dP-Ci for sipping@optimus.ietf.org; Sun, 10 Aug 2003 19:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19860 for ; Sun, 10 Aug 2003 19:47:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lzu1-0001qP-00 for sipping@ietf.org; Sun, 10 Aug 2003 19:47:09 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19lzu1-0001qC-00 for sipping@ietf.org; Sun, 10 Aug 2003 19:47:09 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJF00045GJU79@firewall.wcom.com> for sipping@ietf.org; Sun, 10 Aug 2003 23:43:06 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJF00M01GJU1T@pmismtp05.wcomnet.com>; Sun, 10 Aug 2003 23:43:06 +0000 (GMT) Received: from hsinnreich2 ([166.50.122.172]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJF00L1BGJSIW@pmismtp05.wcomnet.com>; Sun, 10 Aug 2003 23:43:06 +0000 (GMT) Date: Sun, 10 Aug 2003 18:43:04 -0500 From: Henry Sinnreich Subject: RE: [Sipping] FWD:I-DACTION:draft-johnston-sipping-rtcp-summary-00.txt In-reply-to: To: "'Cullen Jennings'" , "'Eric Burger'" , "'Alan Johnston'" Cc: sipping@ietf.org Message-id: <0HJF00L1CGJTIW@pmismtp05.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNfafE8yaz1ra3USBW94y3TxbV7oAALmYMg 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 Cullen, I agree that >The reporting needs to differentiate between > these two cases. Burst errors are treated very well I believe in http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt and this benefit extends to http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp-summary-00.t xt Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Cullen Jennings > Sent: Saturday, August 09, 2003 1:03 PM > To: Eric Burger; Alan Johnston > Cc: sipping@ietf.org > Subject: Re: [Sipping] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary- > 00.txt > > > One of the problems with end of call reporting is that it needs to have > enough time based granularity information to be useful. For example .... > Consider two calls. > > Call A. This is a 100 minute call with 1% packet loss distributed evenly. > > Call B. This had 0% packet loss for first 99 minutes then 100% packet loss > for 1 minute then user hung up. > > Call A was a good call and the service provider is probably happy. Call B > is > a bad call and needs attention. The reporting needs to differentiate > between > these two cases. > > Cullen > > > On 7/14/03 8:09, "Eric Burger" wrote: > > > Would any reporting system ever be interested in RTCP messages? I would > > expect network operators (who I presume would be the interested third- > parties) > > to be interested in end-of-call summaries only. Otherwise, a service > provider > > of any significant size is signing up for a significant amount of RTCP > > reporting (flooding?). > > > > Being NOTIFIED of end-of-call statistics is a sensible option. That way > you > > can use the existing SIP security, subscription, and message routing > > infrastructure. > > > >> -----Original Message----- > >> From: Alan Johnston [mailto:alan.johnston@mci.com] > >> Sent: Fri, June 27, 2003 2:38 PM > >> To: sipping@ietf.org > >> Subject: [Sipping] FWD:I-D > >> ACTION:draft-johnston-sipping-rtcp-summary-00.txt > >> > >> > >> FYI - a new draft on the delivery of RTCP summary reports to > >> third parties. > >> > >> Comments most welcome. > >> > >> Thanks, > >> Alan Johnston > >> MCI > >> > >> > >> ---------- > >> To: IETF-Announce: ; > >> Subject: I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt > >> From: Internet-Drafts@ietf.org > >> Date: Tue, 24 Jun 2003 06:56:20 -0400 > >> Reply-to: Internet-Drafts@ietf.org > >> Sender: owner-ietf-announce@ietf.org > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > >> > >> Title : RTCP Summary Report Delivery to > >> SIP Third Parties > >> Author(s) : A. Johnston, H. Sinnreich, A. Clark > >> Filename : draft-johnston-sipping-rtcp-summary-00.txt > >> Pages : 9 > >> Date : 2003-6-23 > >> > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 exim@www1.ietf.org Mon Aug 11 05:13:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10943 for ; Mon, 11 Aug 2003 05:13:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8jl-0003IR-3M for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 05:13:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B9D9WZ012665 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 05:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8jl-0003IC-0C for sipping-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 05:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10934 for ; Mon, 11 Aug 2003 05:13:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m8jh-00049f-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 05:13:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m8jh-00049c-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 05:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8jd-0003HH-V6; Mon, 11 Aug 2003 05:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8jY-0003Gu-LL for sipping@optimus.ietf.org; Mon, 11 Aug 2003 05:12:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10928 for ; Mon, 11 Aug 2003 05:12:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m8jV-00049N-00 for sipping@ietf.org; Mon, 11 Aug 2003 05:12:53 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19m8jU-00049K-00 for sipping@ietf.org; Mon, 11 Aug 2003 05:12:52 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 11 Aug 2003 10:15:37 +0100 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Request for editorial input Date: Mon, 11 Aug 2003 10:13:07 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE01E22CD6@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] Request for editorial input Thread-Index: AcNdtaeaK8F2eroUTFWVKjB1DRtgvACMwP1Q From: "Chris Boulton" To: "Robert Sparks" , "Alan Hawrylyshen" Cc: Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable inline >-----Original Message----- >From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: 08 August 2003 15:00 >To: Alan Hawrylyshen >Cc: sipping@ietf.org >Subject: Re: [Sipping] Request for editorial input > >inline >On Thu, 2003-08-07 at 18:57, Alan Hawrylyshen wrote: >> On Thursday, Aug 7, 2003, at 12:41 Canada/Mountain, Robert Sparks wrote: >> > [snip] >> > I propose making such breaks explicit as follows: >> > [snip] >> > Foo: areally >> > bigtoken >> > >> > or >> > >> > Foo: areally >> > big >> > token >> > >> > >> >> I'm tempted to suggest something less intrusive like a single EOL >> marker that indicates that the next line's leading WS is to be elided >> from the example text. Something like '*' or '~'. >> eg) >> Foo: areally~ >> big~ >> token >> >> equivalent to: >> >> Foo: areallybigtoken >> >> Of course this means that the above (legal) SIP would be hard to >> represent in the draft in literal form. >> >> Not that this is better, but is IS more readable (IMHO). Perhaps there >> is a problem that I am overlooking with this, but it is certainly less >> intrusive. :-) Thoughts? > >Adam suggested something similar (based on MIME conventions). > >My concern (fwiw) is that I don't expect it to be easy to find a single >symbol that wouldn't be a legal character where it was breaking a line >(it's not always a token that needs breaking). We could adopt a >convention that anytime that appeared last on a line in the text of >this document it has special meaning, but it brings us back to >ambiguity. Arguably, this can suffer from the same >deficiency, but it uses a high level of intrusiveness as a tool to help >resolve the ambiguity in the intended way. > >An alternative would be to put in the examples something along the lines >of: > > INVITE sip:a.example.com SIP/2.0 > To: sip:b.example.com > > Call-ID: 23423423039480239840234 > 2390498u239759237947293 > 39457349539485739485739 > 20234802908u09823095480 > > CSeq: 83347 INVITE > [Chris Boulton] Robert, This one looks fine to me. >That said, I don't feel too strongly about how we add this extra hint >as long as we add something. > >> >> As for the appendix, are you proposing that the published draft would >> contain the (potentially base 64) encoded compressed archive of example >> messages -- completely unreadable by humans, but useful for extracting >> the examples? > >Exactly. A few pages of 4799EA9280F923870CDD3988A... or the like. > > >> >> >> Alan Hawrylyshen >> Jasomi Networks Inc. > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the 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 exim@www1.ietf.org Mon Aug 11 05:19:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11044 for ; Mon, 11 Aug 2003 05:19:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8pZ-0003Z2-4U for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 05:19:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B9J9BU013698 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 05:19:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8pZ-0003Yr-1N for sipping-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 05:19:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11020 for ; Mon, 11 Aug 2003 05:19:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m8pV-0004BD-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 05:19:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m8pV-0004BA-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 05:19:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8pR-0003Ti-L8; Mon, 11 Aug 2003 05:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8p0-0003Sl-Sp for sipping@optimus.ietf.org; Mon, 11 Aug 2003 05:18:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11015 for ; Mon, 11 Aug 2003 05:18:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m8ox-0004Ax-00 for sipping@ietf.org; Mon, 11 Aug 2003 05:18:31 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19m8ow-0004Au-00 for sipping@ietf.org; Mon, 11 Aug 2003 05:18:30 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 11 Aug 2003 10:21:16 +0100 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Mon, 11 Aug 2003 10:18:46 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE01E22CD7@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] DTMF: Why Not A New Method? Thread-Index: AcNfadIU6Cu0pYuqQim0nR5s29t0OQAf4F2Q From: "Chris Boulton" To: "Cullen Jennings" , "sipping" Cc: "Adam Roach" Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable NEW_MTHOD gets my vote. Chris. >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: 09 August 2003 19:52 >To: sipping >Cc: Adam Roach >Subject: Re: [Sipping] DTMF: Why Not A New Method? > > >There has been some discussion on the MESSAGE vs. NEW_METHOD for reporting >the information from KPML. I don't think I have heard any strong argument >for MESSAGE over NEW_METHOD but I have gotten a little lost on the whole >argument. > >I think we might have consensus on NEW_METHOD but I'm not sure. I don't >care >but I think we need to make a decision on this and get on with it. Do we >have consensus on this? > >Cullen > > > >On 7/24/03 13:56, "Adam Roach" wrote: > >> Oh, in that case... >> >> +------------------------------------------------------------+ >> | You have received an IM of type "application/kpml+xml", | >> | which is not a registered media type. | >> | | >> | [x] Save it as a file | >> | [ ] Open it with application: ________________ | >> | | >> | [x] Always ask when handing type "application/kpml+xml" | >> | | >> | [OK] [Cancel] | >> +------------------------------------------------------------+ >> >> /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 exim@www1.ietf.org Mon Aug 11 06:44:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12500 for ; Mon, 11 Aug 2003 06:44:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mA9p-0006JU-M4 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 06:44:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BAi9fW024266 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 06:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mA9p-0006JJ-Fp for sipping-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 06:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12493 for ; Mon, 11 Aug 2003 06:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mA9l-0004bj-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 06:44:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mA9k-0004bg-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 06:44:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mA9h-0006GS-E2; Mon, 11 Aug 2003 06:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mA8q-0006G5-QV for sipping@optimus.ietf.org; Mon, 11 Aug 2003 06:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12477 for ; Mon, 11 Aug 2003 06:43:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mA8m-0004bI-00 for sipping@ietf.org; Mon, 11 Aug 2003 06:43:04 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19mA8l-0004ad-00 for sipping@ietf.org; Mon, 11 Aug 2003 06:43:03 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id LAA31848; Mon, 11 Aug 2003 11:42:34 +0100 (BST) Received: from ukwmxc01.vf-uk.internal.vodafone.com (ukwmxc01 [10.33.126.160]) by mailguard3 (4.9.5.10) with ESMTP id CA156AA1; Mon, 11 Aug 2003 11:43:48 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 11 Aug 2003 11:42:00 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 11 Aug 2003 11:41:59 +0100 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Mon, 11 Aug 2003 11:41:58 +0100 Message-ID: Thread-Topic: [Sipping] DTMF: Why Not A New Method? Thread-Index: AcNfaf9/+MFjsvF0TJO5d70lQSqXQgAifbqw From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Cullen Jennings" , "sipping" Cc: "Adam Roach" X-OriginalArrivalTime: 11 Aug 2003 10:41:59.0656 (UTC) FILETIME=[3160CE80:01C35FF5] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Cullen and others, I haven't been following the discussion too closely, but if we do decide = to have a new method, could we aim to make it reasonably generic? I = don't have a proposal really, but it seems there are a few problems = floating around already where people end up suggesting that MESSAGE can = be (ab)used to solve them. I guess we're talking about a way of passing = 'information' that, unlike INFO, is NOT necessarily related to an = ongoing session? Regards, Duncan -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: 09 August 2003 19:52 To: sipping Cc: Adam Roach Subject: Re: [Sipping] DTMF: Why Not A New Method? There has been some discussion on the MESSAGE vs. NEW_METHOD for = reporting the information from KPML. I don't think I have heard any strong = argument for MESSAGE over NEW_METHOD but I have gotten a little lost on the whole argument. I think we might have consensus on NEW_METHOD but I'm not sure. I don't = care but I think we need to make a decision on this and get on with it. Do we have consensus on this? Cullen =20 On 7/24/03 13:56, "Adam Roach" wrote: > Oh, in that case... >=20 > +------------------------------------------------------------+ > | You have received an IM of type "application/kpml+xml", | > | which is not a registered media type. | > | | > | [x] Save it as a file | > | [ ] Open it with application: ________________ | > | | > | [x] Always ask when handing type "application/kpml+xml" | > | | > | [OK] [Cancel] | > +------------------------------------------------------------+ >=20 > /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 exim@www1.ietf.org Mon Aug 11 12:17:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21625 for ; Mon, 11 Aug 2003 12:17:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mFM4-0001ie-FV for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 12:17:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BGH8WJ006604 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 12:17:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mFM4-0001iR-AS for sipping-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 12:17:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21592 for ; Mon, 11 Aug 2003 12:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mFM2-0006wK-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 12:17:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mFM2-0006wH-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 12:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mFLx-0001hS-4k; Mon, 11 Aug 2003 12:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mFLd-0001hD-U6 for sipping@optimus.ietf.org; Mon, 11 Aug 2003 12:16:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21585 for ; Mon, 11 Aug 2003 12:16:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mFLc-0006wB-00 for sipping@ietf.org; Mon, 11 Aug 2003 12:16:40 -0400 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 19mFLb-0006vy-00 for sipping@ietf.org; Mon, 11 Aug 2003 12:16:39 -0400 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id h7BGBlCW026427; Mon, 11 Aug 2003 09:11:47 -0700 (PDT) Received: from convedia.com (egret.convedia.com [192.168.208.147]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22389; Mon, 11 Aug 2003 09:15:52 -0700 (PDT) Message-ID: <3F37C19C.8050603@convedia.com> Date: Mon, 11 Aug 2003 09:17:32 -0700 From: Tim Melanchuk User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sipping , Adam Roach Subject: Re: [Sipping] DTMF: Why Not A New Method? 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 will NEW_METHOD also be able to satisfy the requirements for an app asynchronously pushing messages to a client (e.g. for pre-paid calling cards) as defined in REQ 4 & 7 of the app-interaction- framework-01. alternatively, what SIP message would be used here? the requirements and context from that draft are below. timm from draft-rosenberg-sipping-app-interaction-framework-01: In this case, there is no message already in transit that can be used as a vehicle for pushing a user interface component. This requires that applications can generate their own messages to push a new component to a UA: REQ 4: A UA application must be able to send a SIP message to the UA at the other end of the dialog, asking it to create a new interface component. However, synchronous updates are not sufficient for many applications. Frequently, the interface will need to be updated asynchronously by the application, without an explicit user action. A good example of this is, once again, the pre-paid calling card application. The application might like to update the user interface when the timer runs out on the call. This introduces several requirements: REQ 7: It must be possible for an application to asynchronously push an update to an existing user interface component, either in a message that was already in transit, or by generating a new message. Cullen Jennings wrote: > There has been some discussion on the MESSAGE vs. NEW_METHOD for reporting > the information from KPML. I don't think I have heard any strong argument > for MESSAGE over NEW_METHOD but I have gotten a little lost on the whole > argument. > > I think we might have consensus on NEW_METHOD but I'm not sure. I don't care > but I think we need to make a decision on this and get on with it. Do we > have consensus on 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 exim@www1.ietf.org Mon Aug 11 14:11:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26746 for ; Mon, 11 Aug 2003 14:11:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mH8S-0006rM-B5 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 14:11:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BIBCr7026365 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 14:11:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mH8R-0006rA-Oj for sipping-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 14:11:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26724 for ; Mon, 11 Aug 2003 14:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mH8P-0000Ei-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 14:11:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mH8O-0000Ee-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 14:11:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mH8I-0006qE-CV; Mon, 11 Aug 2003 14:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mH85-0006pt-Ii for sipping@optimus.ietf.org; Mon, 11 Aug 2003 14:10:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26703 for ; Mon, 11 Aug 2003 14:10:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mH83-0000EM-00 for sipping@ietf.org; Mon, 11 Aug 2003 14:10:47 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19mH82-0000EA-00 for sipping@ietf.org; Mon, 11 Aug 2003 14:10:46 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7BIA2Re006285; Mon, 11 Aug 2003 14:10:02 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 13:10:02 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862B4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Tim Melanchuk'" , Cullen Jennings Cc: sipping , Adam Roach Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Mon, 11 Aug 2003 13:10:02 -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: , > will NEW_METHOD also be able to... No! This is precisely what I'm trying to avoid happening. Methods have actual semantics associated with them. They should mean exactly one thing, not several. INVITE means you're starting a session. SUBSCRIBE means that you're subscribing to the state of a resource. MESSAGE means you're sending an instant message. The new method that we define for KPML should also mean precisely one thing: "I'm conveying requested stimulus from the user." If you need to define something else with different semantics than that, I would argue that there's a fair chance that a new method is indicated. Otherwise, the actual method names become meaningless. If that's the path we are going down, consistency would argue for deprecating all existing methods in favor of a single method (perhaps, "DO"), and inferring all semantics from some horribly complex combination of Content-Type, Content-Disposition, Accept, Supported, and similar header fields. /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 exim@www1.ietf.org Mon Aug 11 15:47:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01578 for ; Mon, 11 Aug 2003 15:47:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mIdL-0001I0-Bk for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 15:47:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BJlBx5004952 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 15:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mIdK-0001Hn-MO for sipping-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 15:47:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01528 for ; Mon, 11 Aug 2003 15:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mIdJ-000174-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 15:47:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mIdI-000171-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 15:47:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mIdB-0001G6-Mr; Mon, 11 Aug 2003 15:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mIcT-0001Dn-LT for sipping@optimus.ietf.org; Mon, 11 Aug 2003 15:46:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01324; Mon, 11 Aug 2003 15:46:11 -0400 (EDT) Message-Id: <200308111946.PAA01324@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: Mon, 11 Aug 2003 15:46:11 -0400 Subject: [Sipping] I-D ACTION:draft-stredicke-sipping-late-media-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 : Late Media in the Session Initiation Protocol Author(s) : C. Stredicke Filename : draft-stredicke-sipping-late-media-00.txt Pages : 7 Date : 2003-8-11 'Late Media' is presented after a dialog is disconnected or when the dialog is temporarily without media. The 'Late-Media' header indicates under which circumstances late media should be rendered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stredicke-sipping-late-media-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-stredicke-sipping-late-media-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-stredicke-sipping-late-media-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-8-11143244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stredicke-sipping-late-media-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-stredicke-sipping-late-media-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11143244.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 exim@www1.ietf.org Mon Aug 11 18:12:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08904 for ; Mon, 11 Aug 2003 18:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKtc-00076b-Bi for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 18:12:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BMC8pE027311 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 18:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKtc-00076Q-7U for sipping-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 18:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08854 for ; Mon, 11 Aug 2003 18:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mKtZ-0002oD-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 18:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mKtY-0002oA-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 18:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKtV-00075V-PJ; Mon, 11 Aug 2003 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKt1-000752-2E for sipping@optimus.ietf.org; Mon, 11 Aug 2003 18:11:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08797 for ; Mon, 11 Aug 2003 18:11:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mKsy-0002o3-00 for sipping@ietf.org; Mon, 11 Aug 2003 18:11:28 -0400 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 19mKsx-0002o0-00 for sipping@ietf.org; Mon, 11 Aug 2003 18:11:27 -0400 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id h7BM6ZCW027730; Mon, 11 Aug 2003 15:06:35 -0700 (PDT) Received: from convedia.com (egret.convedia.com [192.168.208.147]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20750; Mon, 11 Aug 2003 15:10:40 -0700 (PDT) Message-ID: <3F3814C4.9050609@convedia.com> Date: Mon, 11 Aug 2003 15:12:20 -0700 From: Tim Melanchuk User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Cullen Jennings , sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? References: <9BF66EBF6BEFD942915B4D4D45C051F3E862B4@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862B4@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 fine, i'm all for precisely defined semantics. the app-interaction-framework seems to me to identify a requirement for an application to asynchronously push an interface component. am i reading this correctly? if not, fine. if so, what method should be used there, and, if we need a new method for that as well, perhaps we should look at 2 new methods. one to "request" stimulus and one to "convey" the requested stimulus. note, i'm simply trying to understand how different proposals/drafts fit together. i'm not advocating violating sacrosanct principles of protocol design :-) timm Adam Roach wrote: >>will NEW_METHOD also be able to... > > > No! > [snip] > > The new method that we define for KPML should also mean precisely > one thing: "I'm conveying requested stimulus from the user." > > If you need to define something else with different semantics > than that, I would argue that there's a fair chance that a new > method is indicated. > [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 exim@www1.ietf.org Mon Aug 11 23:39:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15375 for ; Mon, 11 Aug 2003 23:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ05-0007vh-Rl for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 23:39:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C3d9wf030481 for sipping-archive@odin.ietf.org; Mon, 11 Aug 2003 23:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mQ05-0007vY-Lg for sipping-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 23:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15363 for ; Mon, 11 Aug 2003 23:39:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mQ03-0004Bq-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 23:39:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mQ03-0004Bn-00 for sipping-web-archive@ietf.org; Mon, 11 Aug 2003 23:39:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mPzx-0007uc-7q; Mon, 11 Aug 2003 23:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mPzJ-0007s6-4S for sipping@optimus.ietf.org; Mon, 11 Aug 2003 23:38:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15345 for ; Mon, 11 Aug 2003 23:38:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mPzH-0004BY-00 for sipping@ietf.org; Mon, 11 Aug 2003 23:38:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mPzG-0004BM-00 for sipping@ietf.org; Mon, 11 Aug 2003 23:38:18 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2003 20:37:49 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7C3bk7F019844; Mon, 11 Aug 2003 20:37:47 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-73.cisco.com [10.86.242.73]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABL46631; Mon, 11 Aug 2003 23:37:45 -0400 (EDT) Message-ID: <3F386109.3030005@cisco.com> Date: Mon, 11 Aug 2003 23:37:45 -0400 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: Cullen Jennings CC: sipping , Adam Roach Subject: Re: [Sipping] DTMF: Why Not A New Method? 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 will not stand in the way of concensus on this. A new method is acceptable to me. Paul Cullen Jennings wrote: > There has been some discussion on the MESSAGE vs. NEW_METHOD for reporting > the information from KPML. I don't think I have heard any strong argument > for MESSAGE over NEW_METHOD but I have gotten a little lost on the whole > argument. > > I think we might have consensus on NEW_METHOD but I'm not sure. I don't care > but I think we need to make a decision on this and get on with it. Do we > have consensus on this? > > Cullen > > > > On 7/24/03 13:56, "Adam Roach" wrote: > > >>Oh, in that case... >> >>+------------------------------------------------------------+ >>| You have received an IM of type "application/kpml+xml", | >>| which is not a registered media type. | >>| | >>| [x] Save it as a file | >>| [ ] Open it with application: ________________ | >>| | >>| [x] Always ask when handing type "application/kpml+xml" | >>| | >>| [OK] [Cancel] | >>+------------------------------------------------------------+ >> >>/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 exim@www1.ietf.org Tue Aug 12 04:06:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03983 for ; Tue, 12 Aug 2003 04:06:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUAe-00010L-UF for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 04:06:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C86KM3003861 for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 04:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUAe-00010C-Dw for sipping-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 04:06:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03939 for ; Tue, 12 Aug 2003 04:06:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mUAb-0005gG-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 04:06:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mUAa-0005g6-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 04:06:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUAM-0000yo-Vg; Tue, 12 Aug 2003 04:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mU9i-0000xC-Oi for sipping@optimus.ietf.org; Tue, 12 Aug 2003 04:05:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03910 for ; Tue, 12 Aug 2003 04:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mU9g-0005fA-00 for sipping@ietf.org; Tue, 12 Aug 2003 04:05:20 -0400 Received: from igate2.vodafone.co.uk ([194.62.232.66]) by ietf-mx with esmtp (Exim 4.12) id 19mU9b-0005e2-00 for sipping@ietf.org; Tue, 12 Aug 2003 04:05:16 -0400 Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id JAA13733; Tue, 12 Aug 2003 09:04:09 +0100 (BST) Received: from ukwmxc01.vf-uk.internal.vodafone.com (ukwmxc01 [10.33.126.160]) by mailguard3 (4.9.5.10) with ESMTP id X6f7aAAU; Tue, 12 Aug 2003 09:05:33 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Aug 2003 09:03:52 +0100 Received: from ukwmxm02.vf-uk.internal.vodafone.com ([10.33.126.242]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Aug 2003 09:03:51 +0100 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Tue, 12 Aug 2003 09:03:50 +0100 Message-ID: Thread-Topic: [Sipping] DTMF: Why Not A New Method? Thread-Index: AcNgVbJOVCW0L5INRcWHyzXPPDWQAwAUKQ2A From: "Mills, Duncan, D, CND Tech Dev, VF UK" To: "Tim Melanchuk" , "Adam Roach" Cc: "Cullen Jennings" , "sipping" X-OriginalArrivalTime: 12 Aug 2003 08:03:51.0960 (UTC) FILETIME=[44AF0980:01C360A8] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Tim, You appear to be coming from the same angle as me. If we are = considering having a new method for KPML, because MESSAGE is being = abused, then we may well find that we need other new methods to cover = other areas where MESSAGE could be abused. Pushing something from an = application server to an end-user is one area where people are already = wrongly proposing to use MESSAGE. I never really meant to say that we define a generic method with very = broad semantics. (Wrist slapped, mouth washed). My mail was probably = worded badly. I merely meant to say that there are probably a couple of = areas where a new method is perhaps needed, and maybe if we think about = it, we only need one method to meet the requirements of these areas? I guess any new method would be bi-directional anyway, so for instance, = if the new method was called "PUSH", then it could be used from an = end-user to an application to push key-presses and it could be used from = an application server to an end-point to push (e.g.) an interface = component. Rather than having a new method to solve the key press issue and a = second new method to solve the 'push' issue. Maybe this is obvious to = everyone? Cheers, Duncan -----Original Message----- From: Tim Melanchuk [mailto:timm@convedia.com] Sent: 11 August 2003 23:12 To: Adam Roach Cc: Cullen Jennings; sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? fine, i'm all for precisely defined semantics. the app-interaction-framework seems to me to identify a requirement for an application to asynchronously push an interface component. am i reading this correctly? if not, fine. if so, what method should be used there, and, if we need a new method for that as well, perhaps we should look at 2 new methods. one to "request" stimulus and one to "convey" the requested stimulus. note, i'm simply trying to understand how different proposals/drafts fit together. i'm not advocating violating sacrosanct principles of protocol design :-) timm Adam Roach wrote: >>will NEW_METHOD also be able to... >=20 >=20 > No! >=20 [snip] >=20 > The new method that we define for KPML should also mean precisely > one thing: "I'm conveying requested stimulus from the user." >=20 > If you need to define something else with different semantics > than that, I would argue that there's a fair chance that a new > method is indicated. >=20 [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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Tue Aug 12 16:19:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28219 for ; Tue, 12 Aug 2003 16:19:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfbk-0001P5-Pa for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 16:19:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CKJ4lf005389 for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 16:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfbk-0001Oq-LD for sipping-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 16:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28205 for ; Tue, 12 Aug 2003 16:18:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mfbi-0003m0-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 16:19:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mfbi-0003lw-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 16:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfbh-0001Nv-W0; Tue, 12 Aug 2003 16:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfap-0001Lt-Cv for sipping@optimus.ietf.org; Tue, 12 Aug 2003 16:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28189 for ; Tue, 12 Aug 2003 16:18:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mfan-0003lc-00 for sipping@ietf.org; Tue, 12 Aug 2003 16:18:05 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19mfam-0003lH-00 for sipping@ietf.org; Tue, 12 Aug 2003 16:18:04 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7CKHQDq012541; Tue, 12 Aug 2003 15:17:26 -0500 From: Dean Willis To: sipping@ietf.org Cc: rohan@cisco.com Content-Type: text/plain Message-Id: <1060719446.10296.44.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 12 Aug 2003 15:17:26 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Changes to drafts database for SIPPING 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've migrated the supplementary web page for SIPPING onto the same database as SIP. Follow the "Drafts" or "Morgue" links from: http://www.softarmor.com/sipping/ Of course, the detail information for the drafts isn't current -- it went stale just before the last IETF meetng -- but we're working on it. Right, Rohan and Gonzalo? -- 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 exim@www1.ietf.org Tue Aug 12 16:27:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28350 for ; Tue, 12 Aug 2003 16:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfjT-0001sE-Hb for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 16:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CKR3en007196 for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 16:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfjT-0001rz-DI for sipping-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 16:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28343 for ; Tue, 12 Aug 2003 16:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mfjR-0003oh-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 16:27:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mfjQ-0003oe-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 16:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfjR-0001r4-PJ; Tue, 12 Aug 2003 16:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mfit-0001pq-V2 for sipping@optimus.ietf.org; Tue, 12 Aug 2003 16:26:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28332 for ; Tue, 12 Aug 2003 16:26:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mfis-0003oV-00 for sipping@ietf.org; Tue, 12 Aug 2003 16:26:26 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19mfir-0003oO-00 for sipping@ietf.org; Tue, 12 Aug 2003 16:26:25 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7CKPrpp013373; Tue, 12 Aug 2003 13:25:54 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKH08316; Tue, 12 Aug 2003 13:18:58 -0700 (PDT) Date: Tue, 12 Aug 2003 13:28:40 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sipping@ietf.org To: Dean Willis From: Rohan Mahy In-Reply-To: <1060719446.10296.44.camel@bdsl.greycouncil.com> Message-Id: <8F4046C7-CD03-11D7-B11E-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Changes to drafts database for SIPPING 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 Tuesday, August 12, 2003, at 01:17 PM, Dean Willis wrote: > I've migrated the supplementary web page for SIPPING onto the same > database as SIP. > > Follow the "Drafts" or "Morgue" links from: > > http://www.softarmor.com/sipping/ > > Of course, the detail information for the drafts isn't current -- it > went stale just before the last IETF meetng -- but we're working on it. > Right, Rohan and Gonzalo? Correct. thx, -r > -- > 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 exim@www1.ietf.org Tue Aug 12 21:23:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05947 for ; Tue, 12 Aug 2003 21:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkM5-0003Gt-Fk for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 21:23:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D1NDGx012574 for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 21:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkM5-0003Gj-3J for sipping-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 21:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05927 for ; Tue, 12 Aug 2003 21:23:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mkM2-000582-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 21:23:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mkM1-00057y-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 21:23:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkLt-0003ET-HV; Tue, 12 Aug 2003 21:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkLa-0003Du-2j for sipping@optimus.ietf.org; Tue, 12 Aug 2003 21:22:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05896 for ; Tue, 12 Aug 2003 21:22:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mkLX-00057g-00 for sipping@ietf.org; Tue, 12 Aug 2003 21:22:39 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mkLW-00057b-00 for sipping@ietf.org; Tue, 12 Aug 2003 21:22:38 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2003 18:28:24 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7D1M67F017529; Tue, 12 Aug 2003 18:22:06 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKH43341; Tue, 12 Aug 2003 18:15:09 -0700 (PDT) Date: Tue, 12 Aug 2003 15:54:58 -0700 Subject: Re: [Sipping] Re: Comment on GRUU requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F27EEB5.80506@dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Wednesday, July 30, 2003, at 09:13 AM, Jonathan Rosenberg wrote: > > > Adam Roach wrote: > >> Alan Johnston [mailto:alan.johnston@mci.com] writes: >> > If we do not use a GRUU in a Contact, then it will not help solve >> the >> > attended transfer problem or the conferencing application - >> > both of these use the Contact URI. >> Admittedly I haven't given this a whole lot of thought >> yet, so it might not make perfect sense... but... can't >> we solve these cases by using a new header and making such >> applications GRUU aware? > > That was what I had in mind, yes. > > Attended transfer, it seems, already needs to be aware of how to get a > GRUU. The current draft has a whole slew of mechanisms for doing it, > the aim would be that the GRUU approach would replace those > mechanisms. To be fair, the current mechanism is try and pray. > Similarly in cc-conferencing, it already talks about using the > contact, so now it could talk about using the gruu in this other > header. > > I don't think we have so much of either of these deployed that this > cannot change. I disagree. Most of the SIP phones I see at SIPit support completing a transfer using a REFER with a Replaces header embedded in the Refer-To. The Refer-To URI is always set to the Contact URI of the appropriate UA. thanks, -rohan > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > 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 exim@www1.ietf.org Tue Aug 12 21:23:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05976 for ; Tue, 12 Aug 2003 21:23:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkM5-0003HF-Jp for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 21:23:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D1NDWx012589 for sipping-archive@odin.ietf.org; Tue, 12 Aug 2003 21:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkM5-0003Gr-E8 for sipping-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 21:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05928 for ; Tue, 12 Aug 2003 21:23:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mkM1-000585-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 21:23:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mkM1-00057z-00 for sipping-web-archive@ietf.org; Tue, 12 Aug 2003 21:23:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkLu-0003Ed-Cj; Tue, 12 Aug 2003 21:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkLk-0003EF-Cq for sipping@optimus.ietf.org; Tue, 12 Aug 2003 21:22:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05900 for ; Tue, 12 Aug 2003 21:22:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mkLh-00057l-00 for sipping@ietf.org; Tue, 12 Aug 2003 21:22:49 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mkLg-00057d-00 for sipping@ietf.org; Tue, 12 Aug 2003 21:22:48 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7D1M8LH016020; Tue, 12 Aug 2003 18:22:12 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKH43342; Tue, 12 Aug 2003 18:15:10 -0700 (PDT) Date: Tue, 12 Aug 2003 16:12:22 -0700 Subject: Re: [Sipping] Re: Update to 3pcc Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Jiri Kuthan'" , "'sipping@ietf.org'" To: David Schwartz From: Rohan Mahy In-Reply-To: Message-Id: <6DB1F720-CD1A-11D7-91B8-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 David, I think it is completely reasonable to build a pre-paid calling system using a proxy with AAA and session timer and optionally a cooperating UA (for IVR features). If a click-to-dial application sends a REFER to my phone which is using a pre-paid PSTN gateway service, there is no reason that the gateway service needs to use a B2BUA. Instead, a proxy can use the session timer extension when proxying the call for a portion of the user's available time. However, even if the PSTN gateway service decided to use a B2BUA for its prepaid service, this is no reason the click-to-dial application (possibly from a completely different organization) needs to use 3pcc. The two should be disconnected. thanks, -rohan On Tuesday, August 5, 2003, at 11:17 PM, David Schwartz wrote: > Hi Jiri. > > I was referring specifically to the call teardown issue associated > with most > pre-paid billing models. > > David > > -----Original Message----- > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > Sent: Tue, August 05, 2003 7:39 PM > To: David Schwartz; 'sipping@ietf.org' > Subject: Re: [Sipping] Re: Update to 3pcc > > > Hello David, > > I don't see how billing servers are related to method of > call initiation. > > Actually I believe that how a call is initiated (by manual > dialing a destination, by REFER-based click-to-dial, by b2bua-based > click-to-dial, CTI, etc.) is completely orthogonal to how the > call is charged for. Regardless what charging system you use > (if any), there will be different methods for initiating calls, > some will be better off than others. I maintain that a click-to-dial > b2bua is not a BCP. > > -jiri > > At 10:10 AM 7/30/2003, David Schwartz wrote: >> Hi Jiri >> >> REFER is good solution if you assume that either there are no billing >> issues, or alternatively, that the endpoint/s handle the billing >> issues. If >> this is not the case, for example, in an application where a >> centralized >> controller is setting up a call to two PSTN numbers, then you will >> need a >> centralized billing entity and REFER will not suffice. >> >> David >> >> -----Original Message----- >> From: sipping-request@ietf.org [mailto:sipping-request@ietf.org] >> Sent: Mon, July 28, 2003 7:00 PM >> To: sipping@ietf.org >> Subject: Sipping digest, Vol 1 #1144 - 2 msgs >> >> >> Send Sipping mailing list submissions to >> sipping@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www1.ietf.org/mailman/listinfo/sipping >> or, via email, send a message with subject or body 'help' to >> sipping-request@ietf.org >> >> You can reach the person managing the list at >> sipping-admin@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Sipping digest..." >> >> >> Today's Topics: >> >> 1. Re: Diversion header (Cullen Jennings) >> 2. Re: Update to 3pcc (Jiri Kuthan) >> >> --__--__-- >> >> Message: 1 >> Date: Sun, 27 Jul 2003 19:05:10 -0700 >> Subject: Re: [Sipping] Diversion header >> From: Cullen Jennings >> To: Romel Khan , >> >> >> I assume your question is there some way for for the final >> destination > that >> receives the call to know the who the 1st callee was that had some >> device > in >> the network redirect the call elsewhere. >> >> The answer is YES - there has been a lot of confusion over this so >> think >> about my answer carefully - it will seem counter intuitive at first. >> The >> answer is the "To" header but it will take me a second to explain why. >> >> Imagine case 1 where A send a call to proxy B, that sent to to C. >> Now C >> sent a 302 back B and B then forked the call to D. The To header in >> the >> message D receives will still have the To set to C. C is the element >> that >> sent the first 302. >> >> Now imagine a case (like your question) where there is not a recursive >> proxy. The 302 will go all the way back to A. Now A forms a new >> invite to >> but it can leave the To header set to the same thing it was in the >> original >> message (C in this case). When the message arrives at D, the To >> header will >> be set to C. >> >> If D was a voice mail system, it might be able to know to act on >> behalf of > C >> instead of some other entity. >> >> There are more complex things that relate to your request. Mary >> Barnes has >> been moving the history work along >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history- >> 04.txt >> >> There is some work on QSIG mappings with diversion >> http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip- >> diversion > - >> 00.txt >> >> There is a draft-levy-sip-diversion which I (and many others) believe >> has a >> pretty much zero chance of being accepted or becoming a RFC. This >> work has >> been superceded by the history work. Quite a few people do not >> support the >> history work and it is moving very slowly. Don't expect any of this to >> resolve quickly. >> >> Give some careful thought to if the "To" header meets your needs and >> if it >> does use - The To header is widely implemented :-) >> >> >> Cullen >> >> >> >> >> On 7/21/03 8:55, "Romel Khan" wrote: >> >>> Is there any SIP header defined in any SIP RFC or Internet Draft >>> that can >>> include the address of the 1st callee, who redirected the call using >>> 302, >> in >>> the 2nd outgoing INVITE? >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> >> >> >> --__--__-- >> >> Message: 2 >> Date: Mon, 28 Jul 2003 10:17:51 +0200 >> To: Jonathan Rosenberg , sipping > >> From: Jiri Kuthan >> Subject: Re: [Sipping] Update to 3pcc >> >> I'm actually not convinced that it is proper to show click-to-dial >> as a motivating example for use of b2bua and label it BCP. >> >> Use of REFER seems technically a superior solution worth being called >> BCP. Roots of the advantages are in a better application of e2e >> principle. >> REFER takes no middle-box b2bua -- it delegates signaling to >> end-points. >> Advantages include: >> - All the pitfalls with media are so straigforward, they don't even >> need to be described (like now in sessions 8 and 9). >> - It takes no media server to transmit ringing tone. >> - There are no SDP compatibility issues on controller's side. >> >> -jiri >> >> At 07:51 PM 7/8/2003, Jonathan Rosenberg wrote: >>> Folks, >>> >>> You may have noticed that I posted an update to the 3pcc spec: >>> >>> http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.txt >>> http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.html >>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.txt >>> >>> The update is based on comments received from IESG while reviewing >>> the >> draft. In particular, there were problems with the usage of 0.0.0.0 to >> imply that no media nor RTCP should be sent. This IP address is not >> meant >> for that purpose. Rather, the .invalid TLD is much better suited. So, >> I >> changed the draft to make use of .invalid in flows where the >> controller >> doesnt want media to be sent. >>> >>> Now, there are some concerns with that which folks need to be aware >>> of: >>> >>> 1. It is at odds with RFC 3264, which actually recommends 0.0.0.0. In > fact, >> the problem is really with RFC 3264, NOT 3pcc. However, 3264 is done, >> and >> this one isnt. I logged a bug against RFC 3264 on this, and we'll >> need to >> work on a way to transition folks towards using .invalid and not >> 0.0.0.0. >>> >>> 2. One the premises of 3pcc is that it should be compatible with any >>> UA >> that is RFC 3261 compliant. If a controller uses .invalid in the SDP, >> I am >> not sure what a SIP endpoint would do. I don't believe anything in >> RFC 3264 >> or in SIP talks about handling the case where there is an issue with a >> domain name in the SDP. As such, if you use .invalid, there could be > interop >> problems. The document mentions this. >>> >>> Comments or questions welcome. >>> >>> Thanks, >>> Jonathan R. >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Chief Technology Officer Parsippany, NJ 07054-2711 >>> dynamicsoft >>> 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 >> >> -- >> Jiri Kuthan http://iptel.org/~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 >> >> End of Sipping Digest >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 13 10:04:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19840 for ; Wed, 13 Aug 2003 10:04:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwEn-0008OO-Nb for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 10:04:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DE4T7c032256 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 10:04:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwEn-0008OB-KM for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 10:04:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19765 for ; Wed, 13 Aug 2003 10:04:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwEl-0001gS-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 10:04:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mwEk-0001gP-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 10:04:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwEL-0008N8-BW; Wed, 13 Aug 2003 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwDO-0008Ip-AV for sipping@optimus.ietf.org; Wed, 13 Aug 2003 10:03:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19600; Wed, 13 Aug 2003 10:02:56 -0400 (EDT) Message-Id: <200308131402.KAA19600@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, 13 Aug 2003 10:02:55 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-02.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 et al. Filename : draft-ietf-sipping-qsig2sip-02.txt Pages : 57 Date : 2003-8-13 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-02.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-02.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-02.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-8-13102145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-qsig2sip-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-qsig2sip-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-13102145.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 exim@www1.ietf.org Wed Aug 13 10:23:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21727 for ; Wed, 13 Aug 2003 10:23:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwWm-0000jL-JH for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 10:23:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DEN4Td002801 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 10:23:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwWm-0000j6-Du for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 10:23:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21710 for ; Wed, 13 Aug 2003 10:22:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwWk-0001yi-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 10:23:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mwWj-0001yf-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 10:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwWj-0000ht-Vf; Wed, 13 Aug 2003 10:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mwVo-0000hB-11 for sipping@optimus.ietf.org; Wed, 13 Aug 2003 10:22:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21613 for ; Wed, 13 Aug 2003 10:21:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwVl-0001xf-00 for sipping@ietf.org; Wed, 13 Aug 2003 10:22:01 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19mwVl-0001xU-00 for sipping@ietf.org; Wed, 13 Aug 2003 10:22:01 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 10C7D206609 for ; Wed, 13 Aug 2003 10:20:20 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19mwFx-0007JQ-Rz for ietf-announce-list@asgard.ietf.org; Wed, 13 Aug 2003 10:05:41 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19mwDM-0005wv-NN for all-ietf@asgard.ietf.org; Wed, 13 Aug 2003 10:03:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19600; Wed, 13 Aug 2003 10:02:56 -0400 (EDT) Message-Id: <200308131402.KAA19600@ietf.org> To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Wed, 13 Aug 2003 10:02:55 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+219613_9521271356181_57113941163" Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-02.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+219613_9521271356181_57113941163 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 et al. Filename : draft-ietf-sipping-qsig2sip-02.txt Pages : 57 Date : 2003-8-13 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-02.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-02.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-02.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. --MIMEStream=_0+219613_9521271356181_57113941163 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+144097_8712534892177_4407090204" --MIMEStream=_1+144097_8712534892177_4407090204 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-13102145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-qsig2sip-02.txt --MIMEStream=_1+144097_8712534892177_4407090204 Content-Type: Message/External-body; name="draft-ietf-sipping-qsig2sip-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-13102145.I-D@ietf.org> --MIMEStream=_1+144097_8712534892177_4407090204-- --MIMEStream=_0+219613_9521271356181_57113941163-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 13 11:08:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22800 for ; Wed, 13 Aug 2003 11:08:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxEV-0002gU-6q for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 11:08:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DF8Fbo010314 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 11:08:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxEV-0002gH-3X for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 11:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22773 for ; Wed, 13 Aug 2003 11:08:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mxES-0002E1-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 11:08:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mxER-0002Dy-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 11:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxEH-0002di-MH; Wed, 13 Aug 2003 11:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxDU-0002QV-IB for sipping@optimus.ietf.org; Wed, 13 Aug 2003 11:07:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22761 for ; Wed, 13 Aug 2003 11:07:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mxDR-0002Dg-00 for sipping@ietf.org; Wed, 13 Aug 2003 11:07:09 -0400 Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx with esmtp (Exim 4.12) id 19mxDQ-0002Dd-00 for sipping@ietf.org; Wed, 13 Aug 2003 11:07:08 -0400 Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.8/8.12.8) with ESMTP id h7DF69C2011238 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Aug 2003 10:06:09 -0500 Received: (from dwillis@localhost) by kevlar.softarmor.com (8.12.8/8.12.8/Submit) id h7DF68sK011236; Wed, 13 Aug 2003 10:06:08 -0500 X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Sipping] DTMF: Why Not A New Method? From: Dean Willis To: Tim Melanchuk Cc: Adam Roach , Cullen Jennings , sipping In-Reply-To: <3F3814C4.9050609@convedia.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3E862B4@dyn-tx-exch-001.dynamicsoft.com> <3F3814C4.9050609@convedia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1060787168.11152.9.camel@kevlar.softarmor.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 13 Aug 2003 10:06:08 -0500 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 Mon, 2003-08-11 at 17:12, Tim Melanchuk wrote: > fine, i'm all for precisely defined semantics. > > the app-interaction-framework seems to me to identify a requirement > for an application to asynchronously push an interface component. > am i reading this correctly? if not, fine. if so, what method should > be used there, and, if we need a new method for that as well, perhaps > we should look at 2 new methods. one to "request" stimulus and one > to "convey" the requested stimulus. > We already have an extensible mechanism for asynchronous non-dialog "push" type operations. I really don't yet understand why the UA that supports interface-component notification doesn't just SUBSCRIBE to the interface-component-notification event package and then get NOTIFYed with the new interface component. -- 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 exim@www1.ietf.org Wed Aug 13 11:15:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22949 for ; Wed, 13 Aug 2003 11:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxLA-00033e-1p for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 11:15:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DFF8EX011748 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 11:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxL9-00033P-Tu for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 11:15:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22938 for ; Wed, 13 Aug 2003 11:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mxL5-0002G4-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 11:15:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mxL4-0002G1-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 11:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxL4-0002y6-62; Wed, 13 Aug 2003 11:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxKo-0002xj-8p for sipping@optimus.ietf.org; Wed, 13 Aug 2003 11:14:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22934 for ; Wed, 13 Aug 2003 11:14:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mxKm-0002Fu-00 for sipping@ietf.org; Wed, 13 Aug 2003 11:14:44 -0400 Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx with esmtp (Exim 4.12) id 19mxKl-0002Fa-00 for sipping@ietf.org; Wed, 13 Aug 2003 11:14:43 -0400 Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.8/8.12.8) with ESMTP id h7DFDoC2011270 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Aug 2003 10:13:50 -0500 Received: (from dwillis@localhost) by kevlar.softarmor.com (8.12.8/8.12.8/Submit) id h7DFDnGw011267; Wed, 13 Aug 2003 10:13:49 -0500 X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Sipping] Re: Update to 3pcc From: Dean Willis To: Rohan Mahy Cc: David Schwartz , "'Jiri Kuthan'" , "'sipping@ietf.org'" In-Reply-To: <6DB1F720-CD1A-11D7-91B8-0003938AF740@cisco.com> References: <6DB1F720-CD1A-11D7-91B8-0003938AF740@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1060787628.11133.18.camel@kevlar.softarmor.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 13 Aug 2003 10:13:48 -0500 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 Rohan said: > I think it is completely reasonable to build a pre-paid calling system > using a proxy with AAA and session timer and optionally a cooperating > UA (for IVR features). Just as billing from session-timer is not a use case, neither is prepaid control using session timer appropriate. We designed session-timer to have a resolution on the order of minutes or hours, not seconds. It's for cleaning up state when stuff goes wrong -- basically, a soft-crash mechanism. One doesn't drive a car by manipulating its air-bags or discard the brakes because one's seat belt is buckled. It sounds to me like you're introducing a time-bounded variant of the authorization-token header. Something like that COULD be used by a cooperating UA (say, the PSTN gateway) with reasonable success. -- 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 exim@www1.ietf.org Wed Aug 13 11:47:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23854 for ; Wed, 13 Aug 2003 11:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxq6-0004nP-8F for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 11:47:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DFl61W018429 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 11:47:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxq6-0004nA-4W for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 11:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23832 for ; Wed, 13 Aug 2003 11:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mxq4-0002ZH-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 11:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mxq4-0002ZE-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 11:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxq2-0004mE-F1; Wed, 13 Aug 2003 11:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mxps-0004lw-3r for sipping@optimus.ietf.org; Wed, 13 Aug 2003 11:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23829 for ; Wed, 13 Aug 2003 11:46:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mxpr-0002Z9-00 for sipping@ietf.org; Wed, 13 Aug 2003 11:46:51 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mxpq-0002Z6-00 for sipping@ietf.org; Wed, 13 Aug 2003 11:46:50 -0400 Received: from dynamicsoft.com ([63.113.46.80]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DFkC3m003732; Wed, 13 Aug 2003 11:46:15 -0400 (EDT) Message-ID: <3F3A5D41.5040505@dynamicsoft.com> Date: Wed, 13 Aug 2003 11:46:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: john.loughney@nokia.com, sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP 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 Bernard Aboba wrote: >>This is one area in which RADIUS would need fixing. > > > The problem of course is that one cannot "fix" these problems without > upgrading deployed implementations. I suspect that, given the huge problems that have occurred with RADIUS, operators would be amenable to upgrading these boxes if vendors could provide fixes that were backwards compatible and gave them a path towards improving overall performance as other boxes were upgraded too. I also suspect RADIUS server vendors would welcome standardized ways to achieve those goals. It seems to me that exponential backoff in retransmits is certainly possible in a backwards compatible way. I'm not enough of a RADIUS expert to know whether the watchdog mechanism as described in rfc3539 is possible in a backwards compatible way. BTW, while on the subject of rfc3539, I am aware of many sip implementations which perform watchdog operations very similar to those described in section 3.4. I wonder if it would be useful to have a sipping specification that describes how to properly do this in sip? There are many ways to do this wrong, and we could leverage the thinking Bernard has put into the AAA document to write up a version for SIP that works well. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 12:10:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24579 for ; Wed, 13 Aug 2003 12:10:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myCZ-0006fi-FK for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 12:10:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DGAJmS025644 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 12:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myCZ-0006fX-CW for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 12:10:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24561 for ; Wed, 13 Aug 2003 12:10:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myCX-0002qx-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 12:10:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19myCX-0002qu-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 12:10:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myCH-0006cr-O3; Wed, 13 Aug 2003 12:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myBP-0006b4-Oc for sipping@optimus.ietf.org; Wed, 13 Aug 2003 12:09:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24523 for ; Wed, 13 Aug 2003 12:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myBO-0002qC-00 for sipping@ietf.org; Wed, 13 Aug 2003 12:09:06 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19myBN-0002q2-00 for sipping@ietf.org; Wed, 13 Aug 2003 12:09:05 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DG8T3m003745; Wed, 13 Aug 2003 12:08:31 -0400 (EDT) Message-ID: <3F3A627A.9080904@dynamicsoft.com> Date: Wed, 13 Aug 2003 12:08:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garland Sharratt CC: De Leo Walter , sipping@ietf.org Subject: Re: [Sipping] draft-melanchuk-sipping-moml-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id h7DG8T3m003745 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable I would think we would need to start with some requiremetns documents=20 first, no? -Jonathan R. Garland Sharratt wrote: > Thanks for the encouragement. We are certainly favorable to this. We > designed MSML/MOML to be a powerful and generic system for advanced con= trol > of media servers using SIP, and do hope that SIPPING takes on the draft= s as > WG items at some point. Since the drafts were only released in late Ju= ne, > though, I think they probably need a bit more time for review and conce= nsus > before being formally advanced as WG items. We would certainly welcome= any > comments you (or others) might have at this point. >=20 > Garland >=20 > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf O= f > De Leo Walter > Sent: Thursday, August 07, 2003 08:04 > To: 'sipping@ietf.org' > Subject: RE: [Sipping] draft-melanchuk-sipping-moml-00.txt >=20 >=20 > I am interested in knowing if this drafat an msml draft will be propose= d as > workgroup items. >=20 > I think it should there are some proprietary solutions for ms cotnrol o= ver > SIP. >=20 > Regards >=20 >=20 >>-----Mensaje original----- >>De: Tim Melanchuk [SMTP:timm@convedia.com] >>Enviado el: Mi=E9rcoles 6 de Agosto de 2003 21:46 >>Para: Chris Boulton >>CC: Garland Sharratt; sipping@ietf.org >>Asunto: Re: [Sipping] draft-melanchuk-sipping-moml-00.txt >> >>thanks again for your feedback. answers to questions below. >> >>cheers, >>timm >> >> >>>- Is there an alternative method for defining unlimited occurrences >>>using the 'max' attribute =3D 0 (e.g. pattern element uses max within = DTMF >> >>>primitive). This seemed a little confusing. >>> >> >>i've had this comment from others. would extending the datatype >>to include an explicit "unlimited" value be less confusing and/or >>renaming "max" to "maxoccurs"? >> >> >>>- 4.5.1.1 The description of and needs to be made >>>more explicit. >>> >> >>will do. >> >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 12:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25575 for ; Wed, 13 Aug 2003 12:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mykD-0000IG-SK for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 12:45:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DGj5AY001118 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 12:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mykD-0000Hx-P5 for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 12:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25559 for ; Wed, 13 Aug 2003 12:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mykA-00036p-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 12:45:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mykA-00036m-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 12:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mykA-0000Gv-Bu; Wed, 13 Aug 2003 12:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myjl-0000GY-Dc for sipping@optimus.ietf.org; Wed, 13 Aug 2003 12:44:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25552 for ; Wed, 13 Aug 2003 12:44:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myjj-00036Z-00 for sipping@ietf.org; Wed, 13 Aug 2003 12:44:35 -0400 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19myjj-000369-00 for sipping@ietf.org; Wed, 13 Aug 2003 12:44:35 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7DGde8k004535 for ; Wed, 13 Aug 2003 12:44:05 -0400 Received: from acclust02evs1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 3F2D32AA00226F28; Wed, 13 Aug 2003 12:43:04 -0400 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Wed, 13 Aug 2003 12:44:04 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A04A322DD@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sipping] DTMF: Why Not A New Method? Thread-Index: AcNhrTFlNd0vWOl2TF2IXMPyYpBElAADNQTQ From: "Roy, Radhika R, ALABS" To: "Dean Willis" Cc: "Adam Roach" , "sipping" Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Folks: Unless Adam would explain to us why MESSAGE is not good to transfer DTMF, we would probably not know precisely why we need to a new METHOD for DTMF reporting. Similarly, Jonathan also explained why INFO is a problem for DTMF reporting. The semantics of all other methods in SIP seem to be pretty clear how to use them, and no controversies appear how and when to use them to satisfy many needs. Can I request Adam and Jonathan to write the BCP drafts for both MESSAGE and INFO method, respectively, explaining the things how to use these methods as they have been explaining in the email threads? Best regards, Radhika R. Roy rrroy@att.com PS: Vendors are implementing many things using INFO and MESSAGE method, and let us minimize those non-interoperable implementations. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 13 12:52:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25754 for ; Wed, 13 Aug 2003 12:52:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myr1-0000Zu-D4 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 12:52:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DGq71N002218 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 12:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myqz-0000Zh-T8 for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 12:52:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25734 for ; Wed, 13 Aug 2003 12:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myqy-00039j-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 12:52:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19myqx-00039g-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 12:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myqv-0000Yh-Nh; Wed, 13 Aug 2003 12:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myqW-0000YN-8y for sipping@optimus.ietf.org; Wed, 13 Aug 2003 12:51:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25727 for ; Wed, 13 Aug 2003 12:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myqU-00039X-00 for sipping@ietf.org; Wed, 13 Aug 2003 12:51:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19myqT-00038q-00 for sipping@ietf.org; Wed, 13 Aug 2003 12:51:33 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DGon3m003757; Wed, 13 Aug 2003 12:50:51 -0400 (EDT) Message-ID: <3F3A6C66.3020001@dynamicsoft.com> Date: Wed, 13 Aug 2003 12:50:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stupka Jean-Marie CC: "'Rohan Mahy'" , "Poetzl, Joachim" , alan.johnston@mci.com, sipping@ietf.org Subject: Re: AW: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Eve nt P ackage and Automatic Callback References: <931A17FBB884D411B02B0008C70D9E2ABF132E@mchh243e.mchh.siemens.de> In-Reply-To: <931A17FBB884D411B02B0008C70D9E2ABF132E@mchh243e.mchh.siemens.de> 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 Jean-Marie, Myself, and many others on this list, appear to be confused as to why you believe what is currently specified will not work. You had previously made this comment: > The transaction being terminated, the data of the call attempt are > deleted and thus the data (including user B's number) are no more > available for a subsequent automatic callback request, right? If I > am wrong, could you please show me where it is said in RFC3261 that > a SIP user agent has to keep data of a transaction that is > terminated. Your assumption is that this data needs to exist for the service to work, but I dont see why. The caller has the original URI it used to call B. So, it subscribes to B. This gets routed to B's device once more. B accepts the subscription. Now, B reports information on whether or not it has any active dialogs. If its still in a call, it will, and the caller knows this. When B no longer has any active calls, the caller gets a notification and can now initiate a new INVITE. What doesn't work, in your mind? Perhaps you are concerned about authorization? i.e., how does B know whether to authorize the subscription? THe dialog package talks about this, and it says to provide summary information, identical to what a random caller would know if they simply sent INVITEs. Perhaps you are concerned about routing? i.e., that the SUBSCRIBE would somehow get routed to a different device? Thats possible. The GRUU work would resolve that. However, I would argue that an even better way to implement this service is to use PRESENCE. Instead of having the calling device subscribe to the dialog package on one device, it would subscribe to presence for the user. One problem with the dialog package (which Christian Stredicke has pointed out to me) is that if the phone is merely off-hook, and not in an actual call, the dialog package would report it as available. However, a presence indicator, being an application layer view on state, would indicate that the user is not available. Another benefit of presence is that it works well for multi-device situations. It can also cover cases where I'm not actually in a call, but busy for some other reason (i.e., in a meeting). -Jonathan R. Stupka Jean-Marie wrote: > The protocols imply procedures, the procedures imply data. If you > want to offer a network wide service you need the network elements > and the user equipments to work in a predictable manner with the > protocols, the procedures and the data. > > What is basically said in the previous mails is that standard > compliant equipment is nice, but to really work, it needs more. I > can easily understand that an operator can't accept this view. > > Regards, Jean-Marie > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 13:22:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26502 for ; Wed, 13 Aug 2003 13:22:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzK5-00024e-Dw for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 13:22:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DHM9iJ007971 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 13:22:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzK5-00024U-A4 for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 13:22:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26488 for ; Wed, 13 Aug 2003 13:22:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzK3-0003L0-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 13:22:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mzK2-0003Kx-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 13:22:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzJx-00023X-JU; Wed, 13 Aug 2003 13:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzJC-00022Z-3i for sipping@optimus.ietf.org; Wed, 13 Aug 2003 13:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26439 for ; Wed, 13 Aug 2003 13:21:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzJ5-0003K8-00 for sipping@ietf.org; Wed, 13 Aug 2003 13:21:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mzJ1-0003Jw-00 for sipping@ietf.org; Wed, 13 Aug 2003 13:21:05 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2003 10:26:59 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7DHKVuG029390; Wed, 13 Aug 2003 10:20:31 -0700 (PDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJY01609; Wed, 13 Aug 2003 10:20:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20030813130123.049f2080@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Aug 2003 13:20:29 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: AW: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Eve nt P ackage and Automatic Callback Cc: Stupka Jean-Marie , "'Rohan Mahy'" , "Poetzl, Joachim" , alan.johnston@mci.com, sipping@ietf.org In-Reply-To: <3F3A6C66.3020001@dynamicsoft.com> References: <931A17FBB884D411B02B0008C70D9E2ABF132E@mchh243e.mchh.siemens.de> <931A17FBB884D411B02B0008C70D9E2ABF132E@mchh243e.mchh.siemens.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_14231794==_.ALT" 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: , --=====================_14231794==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jonathan and Jean-Marie, There are 3 dialogs here: INVITE resulting in busy SUBSCRIPTION resulting in notify when free INVITE resulting in completion of call. Each of these can be independently interworked to the corresponding SS7 messages on the PSTN side. One question is which if any of these dialogs needs to be bound together in any way. I would contend that it is not necessary to relate the first two in any way. The common information element is the called party number which is known when the INVITE was sent. One could conceivably launch the subscription without the first INVITE ever having occurred and the interworking should be identical. A Subscription probe should translate to a CCBS probe, which is either accepted or rejected. I don't believe this causes any problems for the PSTN EO. (Someone please correct me if not true!) A second question is whether the indication of "party free" from CCBS interworked to a Notify should somehow provide some information (e.g. a token in a Contact address) that could be used in an INVITE interworked back to an IAM to distinguish the CCBS IAM from any other IAM. Question: Does that busy subscriber's EO upon notification of "subscriber free" to a camped-on subscriber block IAMs not containing the appropriate CCBS indicator? Otherwise, I am assuming that IAMs are treated first-come-first-served. Either way, there is no issue with this at the interworking point because such a Contact header with a CCBS indicator token is possible in the 200 OK SUBSCRIBE and Notify messages. As I understand it, the nature of the user-part of the user@domain address is completely up to the GW to fashion if the domain is that GW, and thus does not need standardization. That address could be used in the INVITE in the 3rd dialog and interworked to an IAM. If the SIP UAC doesn't use the contact, but instead just reuses the Called Party number, then a normal IAM will result and be treated accordingly. Mike At 12:50 PM 8/13/2003 -0400, Jonathan Rosenberg wrote: >Jean-Marie, > >Myself, and many others on this list, appear to be confused as to why >you believe what is currently specified will not work. You had >previously made this comment: > >>The transaction being terminated, the data of the call attempt are >>deleted and thus the data (including user B's number) are no more >>available for a subsequent automatic callback request, right? If I >>am wrong, could you please show me where it is said in RFC3261 that >>a SIP user agent has to keep data of a transaction that is >>terminated. > >Your assumption is that this data needs to exist for the service to work, >but I dont see why. The caller has the original URI it used to call B. So, >it subscribes to B. This gets routed to B's device once more. B accepts >the subscription. Now, B reports information on whether or not it has any >active dialogs. If its still in a call, it will, and the caller knows >this. When B no longer has any active calls, the caller gets a >notification and can now initiate a new INVITE. > >What doesn't work, in your mind? > >Perhaps you are concerned about authorization? i.e., how does B know >whether to authorize the subscription? THe dialog package talks about >this, and it says to provide summary information, identical to what a >random caller would know if they simply sent INVITEs. > >Perhaps you are concerned about routing? i.e., that the SUBSCRIBE would >somehow get routed to a different device? Thats possible. The GRUU work >would resolve that. However, I would argue that an even better way to >implement this service is to use PRESENCE. > >Instead of having the calling device subscribe to the dialog package on >one device, it would subscribe to presence for the user. One problem with >the dialog package (which Christian Stredicke has pointed out to me) is >that if the phone is merely off-hook, and not in an actual call, the >dialog package would report it as available. However, a presence >indicator, being an application layer view on state, would indicate that >the user is not available. > >Another benefit of presence is that it works well for multi-device >situations. It can also cover cases where I'm not actually in a call, but >busy for some other reason (i.e., in a meeting). > >-Jonathan R. > > >Stupka Jean-Marie wrote: > >>The protocols imply procedures, the procedures imply data. If you >>want to offer a network wide service you need the network elements >>and the user equipments to work in a predictable manner with the >>protocols, the procedures and the data. >>What is basically said in the previous mails is that standard >>compliant equipment is nice, but to really work, it needs more. I >>can easily understand that an operator can't accept this view. >>Regards, Jean-Marie > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >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 --=====================_14231794==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jonathan and Jean-Marie,

There are 3 dialogs here:
INVITE resulting in busy
SUBSCRIPTION resulting in notify when free
INVITE resulting in completion of call.

Each of these can be independently interworked to the corresponding SS7 messages on the PSTN side.

One question is which if any of these dialogs needs to be bound together in any way.  I would contend that it is not necessary to relate the first two in any way.  The common information element is the called party number which is known when the INVITE was sent.  One could conceivably launch the subscription without the first INVITE ever having occurred and the interworking should be identical.  A Subscription probe should translate to a CCBS probe, which is either accepted or rejected.  I don't believe this causes any problems for the PSTN EO.  (Someone please correct me if not true!)

A second question is whether the indication of "party free" from CCBS interworked to a Notify should somehow provide some information (e.g. a token in a Contact address) that could be used in an INVITE interworked back to an IAM to distinguish the CCBS IAM from any other IAM.

Question:  Does that busy subscriber's EO upon notification of "subscriber free" to a camped-on subscriber block IAMs not containing the appropriate CCBS indicator?  Otherwise, I am assuming that IAMs are treated first-come-first-served.

Either way, there is no issue with this at the interworking point because such a Contact header with a CCBS indicator token is possible in the 200 OK SUBSCRIBE and Notify messages.  As I understand it, the nature of the user-part of the user@domain address is completely up to the GW to fashion if the domain is that GW, and thus does not need standardization.  That address could be used in the INVITE in the 3rd dialog and interworked to an IAM.  If the SIP UAC doesn't use the contact, but instead just reuses the Called Party number, then a normal IAM will result and be treated accordingly.

Mike

At 12:50 PM 8/13/2003 -0400, Jonathan Rosenberg wrote:
Jean-Marie,

Myself, and many others on this list, appear to be confused as to why
you believe what is currently specified will not work. You had
previously made this comment:

The transaction being terminated, the data of the call attempt are
deleted and thus the data (including user B's number) are no more
available for a subsequent automatic callback request, right? If I
am wrong, could you please show me where it is said in RFC3261 that
a SIP user agent has to keep data of a transaction that is
terminated.

Your assumption is that this data needs to exist for the service to work, but I dont see why. The caller has the original URI it used to call B. So, it subscribes to B. This gets routed to B's device once more. B accepts the subscription. Now, B reports information on whether or not it has any active dialogs. If its still in a call, it will, and the caller knows this. When B no longer has any active calls, the caller gets a notification and can now initiate a new INVITE.

What doesn't work, in your mind?

Perhaps you are concerned about authorization? i.e., how does B know whether to authorize the subscription? THe dialog package talks about this, and it says to provide summary information, identical to what a random caller would know if they simply sent INVITEs.

Perhaps you are concerned about routing? i.e., that the SUBSCRIBE would somehow get routed to a different device? Thats possible. The GRUU work would resolve that. However, I would argue that an even better way to implement this service is to use PRESENCE.

Instead of having the calling device subscribe to the dialog package on one device, it would subscribe to presence for the user. One problem with the dialog package (which Christian Stredicke has pointed out to me) is that if the phone is merely off-hook, and not in an actual call, the dialog package would report it as available. However, a presence indicator, being an application layer view on state, would indicate that the user is not available.

Another benefit of presence is that it works well for multi-device situations. It can also cover cases where I'm not actually in a call, but busy for some other reason (i.e., in a meeting).

-Jonathan R.


Stupka Jean-Marie wrote:

The protocols imply procedures, the procedures imply data. If you
want to offer a network wide service you need the network elements
and the user equipments to work in a predictable manner with the
protocols, the procedures and the data.
What is basically said in the previous mails is that standard
compliant equipment is nice, but to really work, it needs more. I
can easily understand that an operator can't accept this view.
Regards, Jean-Marie

--
Jonathan D. Rosenberg, Ph.D.            = ;    600 Lanidex Plaza
Chief Technology Officer           &nb= sp;        Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com         = ;            FAX:   (973) 952-5050
http://www.jdrosen.net  = ;            &nb= sp;      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
--=====================_14231794==_.ALT-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 13 13:57:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27932 for ; Wed, 13 Aug 2003 13:57:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzrw-000409-Kt for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 13:57:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DHv8Dm015375 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 13:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzrw-0003zL-Fs for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 13:57:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27906 for ; Wed, 13 Aug 2003 13:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzrq-0003ae-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 13:57:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mzrq-0003ab-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 13:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzrq-0003ug-0u; Wed, 13 Aug 2003 13:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzrN-0003uL-Eb for sipping@optimus.ietf.org; Wed, 13 Aug 2003 13:56:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27896 for ; Wed, 13 Aug 2003 13:56:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzrL-0003aW-00 for sipping@ietf.org; Wed, 13 Aug 2003 13:56:31 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19mzrK-0003a6-00 for sipping@ietf.org; Wed, 13 Aug 2003 13:56:30 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7DHtmRe010997; Wed, 13 Aug 2003 13:55:48 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Aug 2003 12:55:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862D3@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , Jonathan Rosenberg Cc: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements Date: Wed, 13 Aug 2003 12:55:47 -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: , Rohan Mahy [mailto:rohan@cisco.com] writes: > Most of the SIP phones I see at SIPit support > completing a transfer using a REFER with a > Replaces header embedded in the Refer-To. > The Refer-To URI is always set to the Contact > URI of the appropriate UA. And this will continue to work as well as it does today. Newer, GRUU aware clients will simply exhibit an additional robustness. It seems a bit misguided to do things in a suboptimal way just to try to fix currently deployed clients. /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 exim@www1.ietf.org Wed Aug 13 14:00:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28038 for ; Wed, 13 Aug 2003 14:00:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzuo-0004DD-Jv for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 14:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DI06tX016185 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 14:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzuo-0004Cy-B5 for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 14:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28013 for ; Wed, 13 Aug 2003 14:00:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzul-0003cJ-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 14:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mzul-0003cG-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 14:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzuk-00049e-4z; Wed, 13 Aug 2003 14:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzu9-00048Y-5T for sipping@optimus.ietf.org; Wed, 13 Aug 2003 13:59:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27984 for ; Wed, 13 Aug 2003 13:59:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzu6-0003by-00 for sipping@ietf.org; Wed, 13 Aug 2003 13:59:22 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19mzu6-0003bj-00 for sipping@ietf.org; Wed, 13 Aug 2003 13:59:22 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DHwj3m003783; Wed, 13 Aug 2003 13:58:46 -0400 (EDT) Message-ID: <3F3A7C53.20008@dynamicsoft.com> Date: Wed, 13 Aug 2003 13:58:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: Comment on GRUU requirements 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 Rohan Mahy wrote: > >> I don't think we have so much of either of these deployed that this >> cannot change. > > > I disagree. Most of the SIP phones I see at SIPit support completing a > transfer using a REFER with a Replaces header embedded in the Refer-To. > The Refer-To URI is always set to the Contact URI of the appropriate UA. Well, we have here the standard problem here of having implementations of long-running drafts, and then deciding down the road that something needs to change. I think we want a non-GRUU in the Contact header (to avoid spirals through proxies, and needless load when the proxy doesnt intend to record-route), but we want a GRUU for attended-transfer. I would propose to use a separate header to identify GRUUs. Existing phones will work as they currently do, and when two phones both support GRUU, you get more reliable service. I recognize that putting the GRUU in the contact would mean only one of the phones needs to support it (clearly better), but the cost of this is a long-term situation that we don't want. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 14:29:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29429 for ; Wed, 13 Aug 2003 14:29:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0MP-0006B4-MU for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 14:28:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DISbXt023743 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 14:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0MP-0006As-Ir for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 14:28:37 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29355 for ; Wed, 13 Aug 2003 14:28:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0Lo-000620-Qa; Wed, 13 Aug 2003 14:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0Kr-0005zx-JA for sipping@optimus.ietf.org; Wed, 13 Aug 2003 14:27:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29240 for ; Wed, 13 Aug 2003 14:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0Kp-0003rY-00 for sipping@ietf.org; Wed, 13 Aug 2003 14:26:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n0Ko-0003qo-00 for sipping@ietf.org; Wed, 13 Aug 2003 14:26:58 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DIQU3m003797; Wed, 13 Aug 2003 14:26:30 -0400 (EDT) Message-ID: <3F3A82D2.3030107@dynamicsoft.com> Date: Wed, 13 Aug 2003 14:26:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: "Elwell, John" , "'sipping@ietf.org'" Subject: Re: [Sipping] Question on pick-up in service-examples-04 References: <5.2.1.1.0.20030710085538.01f1ced8@pop.mcit.com> In-Reply-To: <5.2.1.1.0.20030710085538.01f1ced8@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 Old email, and a sort-of-related point. It seems to me that the INVITE/Replaces really needs to be targeted at the GRUU for Alice's phone, no? Otherwise this service won't work in places where Carol is located in a different network. For example, if Carol takes here SIP phone to a hotel, she won't be able to directly reach the contact, and so the pickup will fail. I think we want pickup services to work independent of the physical locations of the two devices. In that case what is more useful in the dialog event package is the gruu, not just the contact. -Jonathan R. Alan Johnston wrote: > John, > > You are correct - the NOTIFY F5 does not show the Contact URI. It > should have been shown in a Remote Target tag. However, this tag is > listed as optional in the dialog package - I'm not sure why as it is > useful in a number of situations. > > I agree that it is important to use the Contact URI in this flow. > > Thanks, > Alan Johnston > MCI > > At 09:41 AM 7/10/2003 +0100, Elwell, John wrote: > >> Can anyone explain something to me in section 2.16 (call pick-up)? >> >> In F7, the Request-URI is the contact URI for Alice: >> alice@client.atlanta.example.com >> >> It is not clear how Carol's UA receives this contact address. F5 from >> Bob to Carol provides only the AoR: alice@atlanta.example.com. >> >> I believe it is important to use the contact URI in F7 to avoid the >> case where the INVITE request reaches the wrong UA at Alice. This is >> particularly true when Alice is in a legacy network - the contact >> address might help selection of the correct gateway. >> >> John (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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 15:07:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01531 for ; Wed, 13 Aug 2003 15:07:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0xh-0000bQ-DS for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 15:07:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DJ792v002310 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 15:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0xh-0000bB-93 for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 15:07:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01472 for ; Wed, 13 Aug 2003 15:07:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0xe-0004JW-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 15:07:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n0xd-0004JT-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 15:07:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0xZ-0000Zq-8A; Wed, 13 Aug 2003 15:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n0xB-0000Yu-JH for sipping@optimus.ietf.org; Wed, 13 Aug 2003 15:06:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01419 for ; Wed, 13 Aug 2003 15:06:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0x8-0004JP-00 for sipping@ietf.org; Wed, 13 Aug 2003 15:06:34 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n0x7-0004JG-00 for sipping@ietf.org; Wed, 13 Aug 2003 15:06:33 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DJ5f3m003823; Wed, 13 Aug 2003 15:05:43 -0400 (EDT) Message-ID: <3F3A8C01.7060003@dynamicsoft.com> Date: Wed, 13 Aug 2003 15:05:37 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: seancolson@yahoo.com, "'Peterson, Jon'" , "'sipping'" Subject: Re: [Sipping] Update to 3pcc References: <000801c345d6$a957fe60$6801a8c0@cranberry> <3F0BE0BC.8070403@dynamicsoft.com> <3F0EDD47.9050506@cisco.com> In-Reply-To: <3F0EDD47.9050506@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 the delay. Responses inline. Paul Kyzivat wrote: > I'm way behind in my mail and just discovered this discussion. Earlier I > had actually discovered the new draft and posted a question on this very > point without first finding this conversation. I apologize for that. > > Could this problem not be dealt with in a backward compatible manner by > using a domain name that actually exists in the public DNS and resolves > to the address 0.0.0.0? I'm not sure how this would work in practice. Who would own such a domain? Why would they agree to manage it in this way? I guess it would need to be some kind of public service, managed by IETF or something. I don't like the idea of tying the operation of the protocol to something like this. > > I don't see how Jonathan's alternative helps in practice. The .invalid > address often is needed in an initial offer, so there has as yet been no > opportunity to exchange option tags. So in this case it would require > starting with a Require of the option, which will result in the request > failing, and the need to retry with 0.0.0.0 in that case. So everybody > needs to support both ways, and for awhile we get lots of extra > messaging incurred when somebody tries to do the right thing. Anybody in > their right mind is just going to start out using 0.0.0.0, because it is > more likely to work on the first try. I agree this is a problem. I don't really have a better solution. All I can say is that the only flow which has an initial offer with SDP of 0.0.0.0 is flow II, which is not one of the recommended flows. As such, much of the usages of 0.0.0.0 will be for suspending streams post call setup, and those would not have this problem of extra RTT; the initial INVITE would indicated that .invalid is supported. So, I'd propose to still go ahead and revert back to 0.0.0.0 with some caveats, and then submit a separate I-D on using .invalid. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 15:20:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02675 for ; Wed, 13 Aug 2003 15:20:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1AK-0001aM-Bh for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 15:20:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DJKC3t006089 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 15:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1AK-0001ZN-1f for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 15:20:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02658 for ; Wed, 13 Aug 2003 15:20:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1AI-0004PU-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 15:20:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n1AI-0004PR-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 15:20:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1AA-0001Uh-CC; Wed, 13 Aug 2003 15:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n19A-0001TV-Gf for sipping@optimus.ietf.org; Wed, 13 Aug 2003 15:19:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02608 for ; Wed, 13 Aug 2003 15:18:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n199-0004Os-00 for sipping@ietf.org; Wed, 13 Aug 2003 15:18:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n197-0004Op-00 for sipping@ietf.org; Wed, 13 Aug 2003 15:18:58 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DJHv3m003827; Wed, 13 Aug 2003 15:18:02 -0400 (EDT) Message-ID: <3F3A8EE0.4000404@dynamicsoft.com> Date: Wed, 13 Aug 2003 15:17:52 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: David Schwartz , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: Update to 3pcc References: <5.2.0.9.0.20030805180020.033c5e80@mailhost.fokus.gmd.de> In-Reply-To: <5.2.0.9.0.20030805180020.033c5e80@mailhost.fokus.gmd.de> 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 weigh in here. To address the specific billing issue, the problem is that, in fact, there ARE cases where the call is charged for differently if it was initiated as a result of click-to-dial. The user that makes the initial INVITE may not be the one that needs to be charged. There may be ways around that for REFER by having the INVITE carry some kind of special billing tokens or something (such tokens being pushed to the user in the Refer-To), but these then require the c2d provider and the caller to utilize the same provider. The 3pcc mechanism does not have this constraint. However, in my mind, the real issue is one of control. 3pcc is useful in applications where the server needs to be in the signaling path in order to do or modify things. Thats not the case for all applications, but its true for many. Prepaid is one we have discussed as well. REFER just doesnt work there. I'd also point out that the 3pcc spec is not saying that the best practice for c2d is to use 3pcc; it saying that if you want to do third party call control, here is how you do it. I don't disagree that 3pcc for c2d can be complicated, and REFER does have a better story in terms of the media story. However, other work going on, namely the app interaction work, does address some of the big issues there in a pretty elegant way, I think. You do raise a valid concern about security. The story there could definitely be better. I've been considering, for some time, writing down some requirements for a standards-based 3pcc mechanism (as opposed to a practice for using current mechanisms) that would do a few things just a little differently to achieve much better properties overall. In particular, note how flow I has a nice property that the b2bua doesnt actually need to touch the SDP - it can, therefore, flow e2e even if its encrypted. Flow I has other problems that prevent it from being used generally. Some actual SIP extensions could be used to rectify that. However, this is our best current practice for doing 3pcc with what we have, and so we are constrained by 3261. -Jonathan R. Jiri Kuthan wrote: > Hello David, > > I don't see how billing servers are related to method of > call initiation. > > Actually I believe that how a call is initiated (by manual > dialing a destination, by REFER-based click-to-dial, by b2bua-based > click-to-dial, CTI, etc.) is completely orthogonal to how the > call is charged for. Regardless what charging system you use > (if any), there will be different methods for initiating calls, > some will be better off than others. I maintain that a click-to-dial > b2bua is not a BCP. > > -jiri > > At 10:10 AM 7/30/2003, David Schwartz wrote: > >>Hi Jiri >> >>REFER is good solution if you assume that either there are no billing >>issues, or alternatively, that the endpoint/s handle the billing issues. If >>this is not the case, for example, in an application where a centralized >>controller is setting up a call to two PSTN numbers, then you will need a >>centralized billing entity and REFER will not suffice. >> >>David >> >>-----Original Message----- >>From: sipping-request@ietf.org [mailto:sipping-request@ietf.org] >>Sent: Mon, July 28, 2003 7:00 PM >>To: sipping@ietf.org >>Subject: Sipping digest, Vol 1 #1144 - 2 msgs >> >> >>Send Sipping mailing list submissions to >> sipping@ietf.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://www1.ietf.org/mailman/listinfo/sipping >>or, via email, send a message with subject or body 'help' to >> sipping-request@ietf.org >> >>You can reach the person managing the list at >> sipping-admin@ietf.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of Sipping digest..." >> >> >>Today's Topics: >> >> 1. Re: Diversion header (Cullen Jennings) >> 2. Re: Update to 3pcc (Jiri Kuthan) >> >>--__--__-- >> >>Message: 1 >>Date: Sun, 27 Jul 2003 19:05:10 -0700 >>Subject: Re: [Sipping] Diversion header >>From: Cullen Jennings >>To: Romel Khan , >> >> >>I assume your question is there some way for for the final destination that >>receives the call to know the who the 1st callee was that had some device in >>the network redirect the call elsewhere. >> >>The answer is YES - there has been a lot of confusion over this so think >>about my answer carefully - it will seem counter intuitive at first. The >>answer is the "To" header but it will take me a second to explain why. >> >>Imagine case 1 where A send a call to proxy B, that sent to to C. Now C >>sent a 302 back B and B then forked the call to D. The To header in the >>message D receives will still have the To set to C. C is the element that >>sent the first 302. >> >>Now imagine a case (like your question) where there is not a recursive >>proxy. The 302 will go all the way back to A. Now A forms a new invite to >>but it can leave the To header set to the same thing it was in the original >>message (C in this case). When the message arrives at D, the To header will >>be set to C. >> >>If D was a voice mail system, it might be able to know to act on behalf of C >>instead of some other entity. >> >>There are more complex things that relate to your request. Mary Barnes has >>been moving the history work along >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-04.txt >> >>There is some work on QSIG mappings with diversion >>http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-diversion- >>00.txt >> >>There is a draft-levy-sip-diversion which I (and many others) believe has a >>pretty much zero chance of being accepted or becoming a RFC. This work has >>been superceded by the history work. Quite a few people do not support the >>history work and it is moving very slowly. Don't expect any of this to >>resolve quickly. >> >>Give some careful thought to if the "To" header meets your needs and if it >>does use - The To header is widely implemented :-) >> >> >>Cullen >> >> >> >> >>On 7/21/03 8:55, "Romel Khan" wrote: >> >> >>>Is there any SIP header defined in any SIP RFC or Internet Draft that can >>>include the address of the 1st callee, who redirected the call using 302, >> >>in >> >>>the 2nd outgoing INVITE? >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP >>> >> >> >> >>--__--__-- >> >>Message: 2 >>Date: Mon, 28 Jul 2003 10:17:51 +0200 >>To: Jonathan Rosenberg , sipping >>From: Jiri Kuthan >>Subject: Re: [Sipping] Update to 3pcc >> >>I'm actually not convinced that it is proper to show click-to-dial >>as a motivating example for use of b2bua and label it BCP. >> >>Use of REFER seems technically a superior solution worth being called >>BCP. Roots of the advantages are in a better application of e2e principle. >>REFER takes no middle-box b2bua -- it delegates signaling to end-points. >>Advantages include: >>- All the pitfalls with media are so straigforward, they don't even >> need to be described (like now in sessions 8 and 9). >>- It takes no media server to transmit ringing tone. >>- There are no SDP compatibility issues on controller's side. >> >>-jiri >> >>At 07:51 PM 7/8/2003, Jonathan Rosenberg wrote: >> >>>Folks, >>> >>>You may have noticed that I posted an update to the 3pcc spec: >>> >>>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.txt >>>http://www.jdrosen.net/papers/draft-ietf-sipping-3pcc-04.html >>>http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.txt >>> >>>The update is based on comments received from IESG while reviewing the >> >>draft. In particular, there were problems with the usage of 0.0.0.0 to >>imply that no media nor RTCP should be sent. This IP address is not meant >>for that purpose. Rather, the .invalid TLD is much better suited. So, I >>changed the draft to make use of .invalid in flows where the controller >>doesnt want media to be sent. >> >>>Now, there are some concerns with that which folks need to be aware of: >>> >>>1. It is at odds with RFC 3264, which actually recommends 0.0.0.0. In fact, >> >>the problem is really with RFC 3264, NOT 3pcc. However, 3264 is done, and >>this one isnt. I logged a bug against RFC 3264 on this, and we'll need to >>work on a way to transition folks towards using .invalid and not 0.0.0.0. >> >>>2. One the premises of 3pcc is that it should be compatible with any UA >> >>that is RFC 3261 compliant. If a controller uses .invalid in the SDP, I am >>not sure what a SIP endpoint would do. I don't believe anything in RFC 3264 >>or in SIP talks about handling the case where there is an issue with a >>domain name in the SDP. As such, if you use .invalid, there could be interop >>problems. The document mentions this. >> >>>Comments or questions welcome. >>> >>>Thanks, >>>Jonathan R. >>>-- >>>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>Chief Technology Officer Parsippany, NJ 07054-2711 >>>dynamicsoft >>>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 >> >>-- >>Jiri Kuthan http://iptel.org/~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 >> >>End of Sipping Digest >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 15:25:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02972 for ; Wed, 13 Aug 2003 15:25:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1F2-00027O-Bk for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 15:25:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DJP4Nq008136 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 15:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1F2-000279-6y for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 15:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02953 for ; Wed, 13 Aug 2003 15:24:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1F0-0004TE-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 15:25:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n1F0-0004TB-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 15:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1F0-00021t-6h; Wed, 13 Aug 2003 15:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n1EX-00020v-3Z for sipping@optimus.ietf.org; Wed, 13 Aug 2003 15:24:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02887 for ; Wed, 13 Aug 2003 15:24:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1EV-0004Sn-00 for sipping@ietf.org; Wed, 13 Aug 2003 15:24:31 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n1EV-0004SA-00 for sipping@ietf.org; Wed, 13 Aug 2003 15:24:31 -0400 Received: from dynamicsoft.com ([63.113.46.82]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DJO13m003834; Wed, 13 Aug 2003 15:24:04 -0400 (EDT) Message-ID: <3F3A904E.6090404@dynamicsoft.com> Date: Wed, 13 Aug 2003 15:23:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich CC: "'sipping'" Subject: Re: [Sipping] Re: Static and dynamic policies requirement References: <0HIW00M3N71DDD@dgismtp01.wcomnet.com> In-Reply-To: <0HIW00M3N71DDD@dgismtp01.wcomnet.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 Henry Sinnreich wrote: > > * The mechanism must provide the ability to inform the UA > >>about the set of session policies when the device starts up > > >>* The mechanism must provide a way to inform the client about >>changes in session policies when they occur > > > Would these lead to requirements for SIP telephony devices? Plus countelss > other.. Yes, this is one of many things which could be considered part of a device recommendation. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 17:09:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06045 for ; Wed, 13 Aug 2003 17:09:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2rt-0000Lg-58 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:09:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DL9HVI001334 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:09:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2rt-0000LR-1u for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 17:09:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06023 for ; Wed, 13 Aug 2003 17:09:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2rq-000569-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:09:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n2rq-000565-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:09:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2rd-0000Jw-QX; Wed, 13 Aug 2003 17:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2qr-0000JM-Rv for sipping@optimus.ietf.org; Wed, 13 Aug 2003 17:08:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06004 for ; Wed, 13 Aug 2003 17:08:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2qp-00055m-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:08:11 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n2qo-00055X-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:08:11 -0400 Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DL7X3m003873; Wed, 13 Aug 2003 17:07:33 -0400 (EDT) Message-ID: <3F3AA891.8090000@dynamicsoft.com> Date: Wed, 13 Aug 2003 17:07:29 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Tim Melanchuk'" , Cullen Jennings , sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? References: <9BF66EBF6BEFD942915B4D4D45C051F3E862B4@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862B4@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 Having had a chance to think about all of this some more, here are my thoughts. One - I give up on MESSAGE. You (Adam) are right, the semantics don't match. The method we want, I think, has a semantic of "here is the information you requested". In this case, it was requested with the deposit of the KPML script onto the device. As such, I believe we have such a method, and its called NOTIFY (well, I REALLY think its called HTTP POST, but I seem to be the only one in that boat...). Also note that this is NOT an implicit subscription. It is quite explicit. Its just not done with SUBSCRIBE. Given that, lets examine each of the concerns you raised about implicit subscriptions and see if they apply: Adam wrote: > - Duration of subscription. RFC 3265 includes an "expires" > parameter on the "Subscription-State" header field for each > NOTIFY. A major implication of this is that you can't > run a subscription for an indeterminate length of time > (such as the duration of an INVITE dialog). Subscription > duration has two sub-issues: The duration is exactly equal to the length of the validity of the KPML script. That lifetime is defined in the framework. It terminates when the dialog terminates. Otherwise, the application can "unsubscribe" by pushing a new App-Info header w/o a KPML script for that instance (Tim had asked how this is done - see my answer in a reply to his note). > > - If anything other than a SUBSCRIBE is used to put > the subscription in place, then the subscriber can't > even provide a suggested duration. The notifier must > provide one unilaterally. This is what REFER does. The duration is as defined above. > > - Once this value reaches 0, the subscriber must > resubscribe or the subscription will disappear. > In many cases, this requires an actual SUBSCRIBE > message, which tends to eliminate whatever slight > gain was expected by not having an explicit SUBSCRIBE > in the first place. Here, the subscription is bound to the lifetime of the dialog, and there is no need or possibility to extend it beyond that. > > - Correlation. In the general case, whatever mechanism > creates the implicit subscription must include sufficient > information to create a dialog. In the KPML case, it is > not clear how this would happen. For many calls, the > dialog between the calling endpoint and the server > receiving KPML feedback is not the same dialog as the > dialog between the calling and called parties. In all cases, its not the same dialog. Correlation is easy. The KPML script IS the subscription. The place to send the notify is implied from the URI in the KPML script. We would need to clarify in KPML that once that URI is used, subsequent notificatiosn to the same URI ought to go on the dialog established by the NOTIFY. But, this is a KPML issue. > > - Handling of multiple subscriptions in the same dialog. > It was asserted in the SIPPING meeting that this does > not apply to the KPML case. This assertion is *probably* > true, depending on how the "correlation" problem is solved. See above. > > - Filtering. Unless there is a way to add filtering to > the mechanism that creates the subscription, installation > of filters must be provisioned or performed via some > other out-of-band mechanism. With KMPL, it is arguable that > the script itself provides a filtering mechanism. Exactly. Because the KPML script is the subscription. The digit maps in the KPML are EXACTLY a filter. My argument against a new method, as a result, is the same as the general argument against two methods for doing the same thing. I can easily see applications later on where, in fact, a SUBSCRIBE gets used to get this information, instead of pushing a KPML script in App-Info. As a result of this, a NOTIFY would be sent. I think it would be bad if the server had to have support for two different methods even though they both contain the same information. Thanks, Jonathan R. Adam Roach wrote: >>will NEW_METHOD also be able to... > > > No! > > This is precisely what I'm trying to avoid happening. Methods > have actual semantics associated with them. They should mean > exactly one thing, not several. INVITE means you're starting > a session. SUBSCRIBE means that you're subscribing to the state > of a resource. MESSAGE means you're sending an instant message. > > The new method that we define for KPML should also mean precisely > one thing: "I'm conveying requested stimulus from the user." > > If you need to define something else with different semantics > than that, I would argue that there's a fair chance that a new > method is indicated. > > Otherwise, the actual method names become meaningless. If that's > the path we are going down, consistency would argue for deprecating > all existing methods in favor of a single method (perhaps, "DO"), > and inferring all semantics from some horribly complex combination > of Content-Type, Content-Disposition, Accept, Supported, and similar > header fields. > > /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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 17:15:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06134 for ; Wed, 13 Aug 2003 17:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2xZ-0000tg-QG for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:15:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLF9uB003446 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2xZ-0000tV-Kp for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 17:15:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06121 for ; Wed, 13 Aug 2003 17:15:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2xX-00058G-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:15:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n2xW-00058D-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:15:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2xS-0000oK-Cv; Wed, 13 Aug 2003 17:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2wy-0000ny-8U for sipping@optimus.ietf.org; Wed, 13 Aug 2003 17:14:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06118 for ; Wed, 13 Aug 2003 17:14:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2ww-00057x-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:14:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n2wv-00057s-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:14:29 -0400 Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DLDq3m003877; Wed, 13 Aug 2003 17:13:52 -0400 (EDT) Message-ID: <3F3AAA0D.2060007@dynamicsoft.com> Date: Wed, 13 Aug 2003 17:13:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Melanchuk CC: Adam Roach , Cullen Jennings , sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? References: <9BF66EBF6BEFD942915B4D4D45C051F3E862B4@dyn-tx-exch-001.dynamicsoft.com> <3F3814C4.9050609@convedia.com> In-Reply-To: <3F3814C4.9050609@convedia.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 Tim Melanchuk wrote: > fine, i'm all for precisely defined semantics. > > the app-interaction-framework seems to me to identify a requirement > for an application to asynchronously push an interface component. > am i reading this correctly? if not, fine. if so, what method should > be used there, and, if we need a new method for that as well, perhaps > we should look at 2 new methods. one to "request" stimulus and one > to "convey" the requested stimulus. The new scripts are pushed in App-Info headers. If the application is a UA application, it would presumably use a re-INVITE or INFO. If its a proxy that started the application, it can't initiate new messages, and therefore it needs to wait for something to fly by in which it can insert an App-Info header. An alternative, which we considered, was to have the application do a separate session just for the application interaction. So, it would generate an INVITE towards the UA. In that case, a "proxy" would be able to initiate pushes of new KPML scripts at any time by sending a re-INVITE on the separate dialog it just created, for which it is the UA. However, this quickly becomes complicated, with a lot more messages being exchanged. It also has the drawback of makign security harder. If you use sips, and you have scripts pushed in headers in in-dialog messages, you can get the property that only proxies on the call path (and the UAS) can send scripts to the UA. THats an important property. By allowing separate dialogs for this, you now need a different authorization tactic. You'd also need GRUUs to allow the server in the network to target a request to that device instance. I would go so far as to say that I wouldn't even mind eliminating the push requirement for new scripts. We don't have this in the web. I suspect most applications don't really need it - we seem to get by on the web without it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 13 17:32:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06770 for ; Wed, 13 Aug 2003 17:32:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3E0-0001n5-35 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:32:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLW7Nr006866 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Dz-0001ma-HF for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 17:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06759 for ; Wed, 13 Aug 2003 17:32:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3Dw-0005JT-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:32:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n3Dw-0005JP-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Dv-0001kd-5z; Wed, 13 Aug 2003 17:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Di-0001kG-9W for sipping@optimus.ietf.org; Wed, 13 Aug 2003 17:31:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06748 for ; Wed, 13 Aug 2003 17:31:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3Df-0005JB-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:31:48 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19n3Df-0005J1-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:31:47 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7DLUqRe011485; Wed, 13 Aug 2003 17:30:52 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Aug 2003 16:30:53 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862D7@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'Tim Melanchuk'" , Cullen Jennings , sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Wed, 13 Aug 2003 16:30:51 -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: , Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > Also note that this is NOT an implicit subscription. > It is quite explicit. Its just not done with SUBSCRIBE. You can't define the problem away by twisting commonly accepted terms in random directions. "Implicit Subscription" is the term that we, as a community, have historically used to mean "a subscription created by any means other than a SIP subscribe request, as described in RFC 3265." It's just shorter to say "implicit subscription." /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 exim@www1.ietf.org Wed Aug 13 17:32:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06771 for ; Wed, 13 Aug 2003 17:32:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3E0-0001n4-35 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:32:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLW7Xt006868 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Dz-0001mb-Hg for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 17:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06758 for ; Wed, 13 Aug 2003 17:32:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3Dw-0005JW-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:32:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n3Dw-0005JQ-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Dw-0001l4-BS; Wed, 13 Aug 2003 17:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Dp-0001kL-3m for sipping@optimus.ietf.org; Wed, 13 Aug 2003 17:31:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06751 for ; Wed, 13 Aug 2003 17:31:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3Dm-0005JG-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:31:54 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19n3Dm-0005J2-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:31:54 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7DLVDRe011488; Wed, 13 Aug 2003 17:31:13 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Aug 2003 16:31:14 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862D8@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'Tim Melanchuk'" , Cullen Jennings , sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Wed, 13 Aug 2003 16:31: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: , Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > The duration is exactly equal to the length of the validity of the > KPML script. That lifetime is defined in the framework. It terminates > when the dialog terminates. Otherwise, the application can > "unsubscribe" by pushing a new App-Info header w/o a KPML script for > that instance (Tim had asked how this is done - see my answer in a > reply to his note). You missed my point. I'll try to make it more obvious. Below, I've placed an example NOTIFY message. Find the "XXXXX" in it, and change it so that it makes syntactic and semantic sense. NOTIFY sip:appserver.example.com SIP/2.0 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bK4EPlfSFQK1 Max-Forwards: 70 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 997935769 NOTIFY Contact: Event: stimulus Subscription-State: active;expires=XXXXX Content-Type: application/kpml+xml Content-Length: 74 /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 exim@www1.ietf.org Wed Aug 13 17:41:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07339 for ; Wed, 13 Aug 2003 17:41:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Md-0002uI-SH for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLf3IK011168 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Md-0002u3-OB for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 17:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07325 for ; Wed, 13 Aug 2003 17:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3Mb-0005S0-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:41:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n3Ma-0005Rx-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:41:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Mb-0002qp-MY; Wed, 13 Aug 2003 17:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3M3-0002oC-P2 for sipping@optimus.ietf.org; Wed, 13 Aug 2003 17:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07294 for ; Wed, 13 Aug 2003 17:40:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3M1-0005RZ-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:40:25 -0400 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19n3M0-0005R0-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:40:24 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7DLYZ2T003663 for ; Wed, 13 Aug 2003 16:39:54 -0500 Received: from acclust02evs1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 3F2D32AA002398B6; Wed, 13 Aug 2003 17:38:52 -0400 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Re: Update to 3pcc Date: Wed, 13 Aug 2003 17:39:53 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A04A51865@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sipping] Re: Update to 3pcc Thread-Index: AcNh0TjpJXaOxQ8vQ1+YzqSv+OoQ1AAEbNrA From: "Roy, Radhika R, ALABS" To: "Jonathan Rosenberg" , "Jiri Kuthan" Cc: "David Schwartz" , Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Inline [RRR] ... I'd also point out that the 3pcc spec is not saying that the best=20 practice for c2d is to use 3pcc; it saying that if you want to do=20 third party call control, here is how you do it. [RRR] Right. The draft shows how to use the 3pcc, if one wants to do so. ... However, this is our best current practice for doing 3pcc with what we=20 have, and so we are constrained by 3261. [RRR] I agree. -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 exim@www1.ietf.org Wed Aug 13 17:44:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07417 for ; Wed, 13 Aug 2003 17:44:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3PW-00039E-PF for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLi290012094 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 17:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3PW-00038z-Lt for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 17:44:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07409 for ; Wed, 13 Aug 2003 17:43:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3PU-0005Td-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:44:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n3PT-0005Ta-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 17:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3PV-00037z-2H; Wed, 13 Aug 2003 17:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3Oz-00037h-R1 for sipping@optimus.ietf.org; Wed, 13 Aug 2003 17:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07401 for ; Wed, 13 Aug 2003 17:43:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3Ox-0005TR-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:43:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19n3Ow-0005TH-00 for sipping@ietf.org; Wed, 13 Aug 2003 17:43:26 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2003 14:42:57 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7DLgttp021551; Wed, 13 Aug 2003 14:42:55 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKI42482; Wed, 13 Aug 2003 14:35:50 -0700 (PDT) Date: Wed, 13 Aug 2003 14:45:41 -0700 Subject: Re: [Sipping] Re: Comment on GRUU requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jonathan Rosenberg , "'Alan Johnston'" , "'sipping@ietf.org'" To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862D3@dyn-tx-exch-001.dynamicsoft.com> Message-Id: <7BDAC0E8-CDD7-11D7-91B8-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Wednesday, August 13, 2003, at 10:55 AM, Adam Roach wrote: > Rohan Mahy [mailto:rohan@cisco.com] writes: >> Most of the SIP phones I see at SIPit support >> completing a transfer using a REFER with a >> Replaces header embedded in the Refer-To. >> The Refer-To URI is always set to the Contact >> URI of the appropriate UA. > > And this will continue to work as well as it does today. > Newer, GRUU aware clients will simply exhibit an additional > robustness. > > It seems a bit misguided to do things in a suboptimal way > just to try to fix currently deployed clients. and Jonathan wrote: >>> I don't think we have so much of either of these deployed that this >>> cannot change. >> I disagree. Most of the SIP phones I see at SIPit support completing >> a transfer using a REFER with a Replaces header embedded in the >> Refer-To. The Refer-To URI is always set to the Contact URI of the >> appropriate UA. > > Well, we have here the standard problem here of having implementations > of long-running drafts, and then deciding down the road that something > needs to change. > > I think we want a non-GRUU in the Contact header (to avoid spirals > through proxies, and needless load when the proxy doesnt intend to > record-route), but we want a GRUU for attended-transfer. I would > propose to use a separate header to identify GRUUs. Existing phones > will work as they currently do, and when two phones both support GRUU, > you get more reliable service. I recognize that putting the GRUU in > the contact would mean only one of the phones needs to support it > (clearly better), but the cost of this is a long-term situation that > we don't want. > > -Jonathan R. Hi, I think both of you are ignoring the "generality before efficiency" principle. Putting the GRUU in the Contact header always works, and in most deployments where it is needed (middlebox traversal), you WILL need to travel through the same set of proxies for nearly every request anyhow. With the increased deployment of TLS and SIPS we will increasingly have dialogs for which all or none of the requests are proxied. We are talking about interop with thousands of UAs which have implemented Proposed Standard level RFCs (SIP and Refer) and an long-lived, stable I-D that has completed WGLC and was submitted to the IESG (Replaces)`. We are not talking about random drafts that very few have implemented. To be convinced that it is worth adding a new GRUU header, I would at least like to see some plausible use cases that are common enough for us to be worrying about. Maybe the right way to look at this is to put the GRUU in the Contact, UNLESS you can tell that your peer understands the special significance of GRUUs. Also, where this extension is most needed, you need the right 2 out of 3 to support the extension. (This isn't just any two of three. If Bob supports the GRUU extension, but Carol does not, Alice still cannot cause a transfer to occur in the appropriate direction.) Starting with the classic Alice, Bob, and Carol actors. Alice and Bob have an existing dialog. Alice and Carol have an existing dialog. Alice wants Bob to talk to Carol, and will REFER Bob to INVITE Carol replacing the dialog between Alice and Carol. Carol needs a GRUU; if the GRUU is conveyed in a separate header Alice and Carol both need to support the GRUU extension for the Refer-To header to be set properly. 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 exim@www1.ietf.org Wed Aug 13 18:16:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09455 for ; Wed, 13 Aug 2003 18:16:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3uc-00052Q-TA for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 18:16:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DMGAKL019362 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 18:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3uc-00052D-OV for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 18:16:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09408 for ; Wed, 13 Aug 2003 18:16:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3uZ-0005gS-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 18:16:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n3uZ-0005gP-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 18:16:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3uU-00051I-1D; Wed, 13 Aug 2003 18:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3tX-00050k-8T for sipping@optimus.ietf.org; Wed, 13 Aug 2003 18:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09308 for ; Wed, 13 Aug 2003 18:14:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3tU-0005g6-00 for sipping@ietf.org; Wed, 13 Aug 2003 18:15:00 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19n3tT-0005g1-00 for sipping@ietf.org; Wed, 13 Aug 2003 18:14:59 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7DMEOuK006123; Wed, 13 Aug 2003 15:14:28 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKI47277; Wed, 13 Aug 2003 15:07:19 -0700 (PDT) Date: Wed, 13 Aug 2003 15:17:11 -0700 Subject: Re: [Sipping] Re: Update to 3pcc Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: David Schwartz , "'Jiri Kuthan'" , "'sipping@ietf.org'" To: Dean Willis From: Rohan Mahy In-Reply-To: <1060787628.11133.18.camel@kevlar.softarmor.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Wednesday, August 13, 2003, at 08:13 AM, Dean Willis wrote: > > Rohan said: >> I think it is completely reasonable to build a pre-paid calling system >> using a proxy with AAA and session timer and optionally a cooperating >> UA (for IVR features). > > Just as billing from session-timer is not a use case, neither is > prepaid > control using session timer appropriate. We designed session-timer to > have a resolution on the order of minutes or hours, not seconds. In many prepaid applications that is all that is required. For example: UA sends an INVITE with apropos credentials. Proxy does a AAA lookup, finds out there is enough credit for 2 hours, sets session timer at 15 minutes and proxies the request to a gateway with Require: timer. After 30 minutes the gateway reINVITEs (a timer refresh request). The Proxy again does a AAA lookup. At this point there is only enough credit for 10 minutes (the caller used the prepaid service to make a more expensive call). The proxy forwards the request with session timer set to 5 minutes. On the next timer refresh, the proxy forwards the request with a 3 minute timer. Finally the proxy uses a 2 minute timer. When the last timer refresh arrives, the Proxy sends a 403, and the gateway tears down the session. This mechanism works very well and is perfectly appropriate if either only one session is allowed at a time, or if you are willing to reserve resources for an existing session for a few minutes in the future. > It's for cleaning up state when stuff goes wrong -- basically, a > soft-crash > mechanism. I have no problem with that. But it is a perfectly reasonable solution for some prepaid applications (not all of them obviously), and requires no changes to the session timer spec. thanks, -rohan > One doesn't drive a car by manipulating its air-bags or > discard the brakes because one's seat belt is buckled. > > It sounds to me like you're introducing a time-bounded variant of the > authorization-token header. Something like that COULD be used by a > cooperating UA (say, the PSTN gateway) with reasonable success. > > -- > 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 exim@www1.ietf.org Wed Aug 13 18:33:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09927 for ; Wed, 13 Aug 2003 18:33:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4B0-0005ci-LC for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 18:33:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DMX6Ul021614 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 18:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4B0-0005cX-H6 for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 18:33:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09900 for ; Wed, 13 Aug 2003 18:32:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4Ax-0005lG-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 18:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n4Ax-0005lD-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 18:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4Aw-0005bc-DI; Wed, 13 Aug 2003 18:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4AY-0005aO-ML for sipping@optimus.ietf.org; Wed, 13 Aug 2003 18:32:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09888 for ; Wed, 13 Aug 2003 18:32:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4AV-0005l3-00 for sipping@ietf.org; Wed, 13 Aug 2003 18:32:35 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19n4AV-0005l0-00 for sipping@ietf.org; Wed, 13 Aug 2003 18:32:35 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7DMW5Re011588 for ; Wed, 13 Aug 2003 18:32:05 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Aug 2003 17:32:05 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862D9@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: sipping Date: Wed, 13 Aug 2003 17:32:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] App-Interaction: Considering models 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 considering Jonathan's contention that defining a new method for conveying stimulus is creating something that is similar in meaning to NOTIFY, I'm inclined to agree to some point. There are still subtle differences in meaning, so I'm not completely convinced that a new method is wrong, but I understand the point he's trying to make. After discussing it privately with others, I've concluded that there are three viable models worth considering. There are, of course, some minor variations that can be made to each. 1) Standard HTTP Handling UAC App Server UAS 1|-----INVITE---->| | 2| |-----INVITE---->| 3| |<-----200-------| 4|<-----200-------| | AS adds HTTP URL to 200 5|---HTTP GET---->| | UAC requests KPML script 6|<-----200-------| | AS replies with script 7|---HTTP POST--->| | UAC provides digits 8|<-----200-------| | AS acknowledges digits Of the three options presented here, I see this as the best solution. Basically, the app server includes an HTTP URL in the 200 response to the INVITE that it has proxied. The UAC then does a GET on the KPML script. Just like with HTML forms, the UAC does whatever local stuff is necessary to "fill out the form" (in this case, collect digits), and then posts the result back to the App Server. This is all plain-Jane unextended HTTP as it was intended to work. 2) Explicit Subscriptions (with GRUU) UAC App Server UAS 1|-----INVITE---->| | 2| |-----INVITE---->| AS extracts GRUU from INVITE 3| |<-----200-------| 4|<-----200-------| | 5|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script 6|------200------>| | 7|-----NOTIFY---->| | 8|<-----200-------| | 9|-----NOTIFY---->| | UAC provides digits A|<-----200-------| | AS acknowledges digits My second choice would be an explicit subscription to stimulus events. The only sticky part in this solution is the question of how the AS can route a SUBSCRIBE to the UAC. Once we have a GRUU solution in place, this is a no brainer: the AS can extract the GRUU from the INVITE, and use it as the target of its SUBSCRIBE. The KPML script is included in the SUBSCRIBE, and essentially serves as a filter. 3) Explicit Subscriptions (with REFER) UAC App Server UAS 1|-----INVITE---->| | 2| |-----INVITE---->| 3| |<-----200-------| 4|<-----200-------| | AS adds SIP URL to 200 5|-----REFER----->| | 6|<-----200-------| | 7|<----NOTIFY-----| | 8|------481------>| | 9|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script A|------200------>| | B|-----NOTIFY---->| | C|<-----200-------| | D|-----NOTIFY---->| | UAC provides digits E|<-----200-------| | AS acknowledges digits Although somewhat chattier than the previous solution, this gets around the GRUU issue by having the AS provide a SIP URI that routes to itself in the 200 response. The UAC then uses this URI to send a REFER to the AS. This REFER tells the AS to SUBSCRIBE to the UAC. The flow from that point forward is the same as for solution 2. /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 exim@www1.ietf.org Wed Aug 13 20:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12839 for ; Wed, 13 Aug 2003 20:34:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n649-0003vf-VH for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 20:34:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E0Y9SL015097 for sipping-archive@odin.ietf.org; Wed, 13 Aug 2003 20:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n649-0003vQ-Qj for sipping-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 20:34:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12814 for ; Wed, 13 Aug 2003 20:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n647-0006WA-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 20:34:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n647-0006W7-00 for sipping-web-archive@ietf.org; Wed, 13 Aug 2003 20:34:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n641-0003uQ-Os; Wed, 13 Aug 2003 20:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n63d-0003u3-CF for sipping@optimus.ietf.org; Wed, 13 Aug 2003 20:33:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12800 for ; Wed, 13 Aug 2003 20:33:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n63b-0006Vg-00 for sipping@ietf.org; Wed, 13 Aug 2003 20:33:35 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19n63a-0006VS-00 for sipping@ietf.org; Wed, 13 Aug 2003 20:33:34 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h7E0X2dS010237; Wed, 13 Aug 2003 18:33:02 -0600 (MDT) 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] FWD:I-DACTION:draft-johnston-sipping-rtcp-summary-00.txt Date: Wed, 13 Aug 2003 18:33:01 -0600 Message-ID: Thread-Topic: [Sipping] FWD:I-DACTION:draft-johnston-sipping-rtcp-summary-00.txt Thread-Index: AcNfafE8yaz1ra3USBW94y3TxbV7oAALmYMgAJgUKmA= From: "Jean-Francois Mule" To: "Alan Johnston" , , "Henry Sinnreich" Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alan & all, Here are some comments on the requirement section of ID draft-johnston-sipping-rtcp-summary-00.txt (see #jfm marks): > REQ-1: An authorized third party should be able to receive > selected RTCP reports on a near real time basis. #jfm Based on section 3, it seems that this requirement is for an authorized 3rd party to be also able to *request and/or* receive selected RTCP reports? > REQ-2: The client should not have to store large amounts of > information. #jfm This comment applies to the entire ID.=20 Is client =3D SIP UA? Or RTP host acting as receiver? Or the management agent storing managed objects for some kind of rtp mib objects? See comment on REQ-5 on "participant". A terminology section could help. > REQ-3: The client must be able to authenticate the third party. #jfm For e.g., the client here could be an snmpv3 agent or a sip entity or (why not) a netconf xml http client? I guess my point is that refining the requirement will help define the solution that meets your needs. > REQ-4: The RTCP report information must be able to be transferred > securely. #jfm Could you define precisely what you mean by "securely"? authentication, confidentiality? > REQ-5: Only one participant in the session need support the > mechanism - the participant will send both sent and received > summary reports. #jfm I find this requirement confusing, mostly because I'm not sure I understand what participant it. Does participant mean RTP/RTCP host or SIP UA client here?=20 I also wonder how relevant this requirement is. What if 2 SIP UAs using the same signaling proxy participate in a conferencing session and their respective RTP/RTCP hosts mix media streams coming=20 from distinct RTP/RTCP hosts? How does this requirement work in=20 conferencing?=20 > REQ-6: The reports will include or be associated with dialog > identifiers for correlation purposes. #jfm In this case, I think you mean the RTCPx reports delivered via the SIP dialog. Depending on how this draft evolves, these may be different from the RTCP reports. It may help to qualify "reports" then. To that extent and reading thru the email threads on this draft, there should be a requirement for a 3rd party to request specific RTCP reports (and we should not exclude SR, RR or BYE because some applications may actually be interested in those). Jean-Francois=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 01:56:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18099 for ; Thu, 14 Aug 2003 01:56:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nB5g-0007Ic-HC for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 01:56:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E5u4Ll028053 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 01:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nB5g-0007IO-Bx for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 01:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18083 for ; Thu, 14 Aug 2003 01:56:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nB5d-0007gN-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 01:56:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nB5c-0007gK-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 01:56:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nB5d-0007HK-QA; Thu, 14 Aug 2003 01:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nB4g-0007GS-TN for sipping@optimus.ietf.org; Thu, 14 Aug 2003 01:55:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18048 for ; Thu, 14 Aug 2003 01:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nB4d-0007fn-00 for sipping@ietf.org; Thu, 14 Aug 2003 01:54:59 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19nB4c-0007fX-00 for sipping@ietf.org; Thu, 14 Aug 2003 01:54:59 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7E5sMpp013309; Wed, 13 Aug 2003 22:54:22 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn1-238.cisco.com [10.21.96.238]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHB91717; Wed, 13 Aug 2003 22:54:17 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 13 Aug 2003 22:54:17 -0700 Subject: Re: [Sipping] App-Interaction: Considering models From: Cullen Jennings To: Adam Roach , sipping , Jonathan Rosenberg Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862D9@dyn-tx-exch-001.dynamicsoft.com> 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 I think all of these proposals are significantly more complex than using a MESSAGE/NEW_METHOD/NOTIFY. I will mention a few issues with the proposal inline but first let me a few other proposals... All of these have a call flow like > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| > 3| |<-----200-------| > 4|<-----200-------| | > 5|---SIP MESG---->| | > 6|<-----200-------| | The question for KMPL is, what method to use in msg 5. Proposal 1) Use MESSAGE. Many people think the semantics of message are display this IM to a user. Perhaps, but I send IM to applications and they send me back things like stock quotes all the time. I have no problem with semantics of MESSAGE being deliver this message to the addressed user or automaton. That's what we are doing here. Misrouted message will cause trivial problems, but this is a bogus issue - misrouted INVITE or MESSAGE will cause problems to - don't misroute things. Proposal 2) Use some new method like STIMULUS. The semantics of this are some user input stimulus is being sent - STIMULUS is to input what MESSAGE is to output. Proposal 3) Use NOTIFY. Semantics are, here is some information about some event that you requested to be informed about. The usual complaint on this one is that there was no Subscribe, or it was implicit, or it was explicit, or it violated some law of the SIP world. I think there was a subscribe, it was in the message that initiated the script. There is also a clear time it will end - when the script is terminated or when the dialog of the message that initiated the script ends. We all remember that implicit subscribes where bad (whatever an implicit subscribe is) but people seem to have a hard time remembering why this will be bad here. All 3 of these proposals have something in common - there is no concrete argument that any of them would not work. They send to a URI the AS provided so there are no forking issues. There is some grief on the semantics. Option 2 has the advantage of it lets us define the semantics however we want. I think that 2 is the best way to go but I don't care greatly. I do need convincing on what's wrong with these to move to something more complex. More comments inline On 8/13/03 3:32 PM, "Adam Roach" wrote: > After considering Jonathan's contention that defining > a new method for conveying stimulus is creating something > that is similar in meaning to NOTIFY, I'm inclined to > agree to some point. There are still subtle differences > in meaning, so I'm not completely convinced that a new > method is wrong, but I understand the point he's trying > to make. > > After discussing it privately with others, I've concluded > that there are three viable models worth considering. There > are, of course, some minor variations that can be made to > each. > > 1) Standard HTTP Handling > > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| > 3| |<-----200-------| > 4|<-----200-------| | AS adds HTTP URL to 200 > 5|---HTTP GET---->| | UAC requests KPML script > 6|<-----200-------| | AS replies with script > 7|---HTTP POST--->| | UAC provides digits > 8|<-----200-------| | AS acknowledges digits > > Of the three options presented here, I see this as the best > solution. Basically, the app server includes an HTTP URL > in the 200 response to the INVITE that it has proxied. The > UAC then does a GET on the KPML script. Just like with > HTML forms, the UAC does whatever local stuff is necessary > to "fill out the form" (in this case, collect digits), and > then posts the result back to the App Server. This is all > plain-Jane unextended HTTP as it was intended to work. > One of the difficult parts of this is security. This will get more complicated once you provide a way to send in message 4 the credentials that will allow 7. It may also make the App-Info header only really work with scripts that use HTTP to post instead of other things. Also, in the case of a financial institutions that have to log electronic communications, you will need to provide way to insert logging HTTP proxies and probably proxies for FW traversal too. Of course the AS or the UAC will need to figure out the network topology to know if the AS is inside or outside the FW. It's possible to configure all the domain and HTTP proxies rules into the device but it still hard to secure - particularly on devices that don't want to implement HTTPS due to not much memory. > 2) Explicit Subscriptions (with GRUU) > > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| AS extracts GRUU from INVITE > 3| |<-----200-------| > 4|<-----200-------| | > 5|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script > 6|------200------>| | > 7|-----NOTIFY---->| | > 8|<-----200-------| | > 9|-----NOTIFY---->| | UAC provides digits > A|<-----200-------| | AS acknowledges digits > > My second choice would be an explicit subscription to stimulus > events. The only sticky part in this solution is the question > of how the AS can route a SUBSCRIBE to the UAC. Once we have > a GRUU solution in place, this is a no brainer: the AS can > extract the GRUU from the INVITE, and use it as the target > of its SUBSCRIBE. The KPML script is included in the SUBSCRIBE, > and essentially serves as a filter. > I sort of see this one, but what if the App Server wanted to run an App on the UAS instead of the UAC. Would the 180 have the GRU? Would it be reliable? I seem to recall someone asking about the expire time on the subscription :-) I'd be keener on GRUU solutions if GRUU was a solved problem. > 3) Explicit Subscriptions (with REFER) > > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| > 3| |<-----200-------| > 4|<-----200-------| | AS adds SIP URL to 200 > 5|-----REFER----->| | > 6|<-----200-------| | > 7|<----NOTIFY-----| | > 8|------481------>| | > 9|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script > A|------200------>| | > B|-----NOTIFY---->| | > C|<-----200-------| | > D|-----NOTIFY---->| | UAC provides digits > E|<-----200-------| | AS acknowledges digits > > Although somewhat chattier than the previous solution, this gets around > the GRUU issue by having the AS provide a SIP URI that routes to itself > in the 200 response. The UAC then uses this URI to send a REFER to the > AS. This REFER tells the AS to SUBSCRIBE to the UAC. The flow from that > point forward is the same as for solution 2. > I got to admit, I had never considered anything like this. I think it is going to be hard to convince folks this is really easier and better than sending DTMF over INFO. Keep in mind that KPML is for little device that think 14k of memory is a lot. Real devices are just going to do VXML and HTML and ignore KPML. Cullen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 03:01:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01934 for ; Thu, 14 Aug 2003 03:01:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nC6g-0003Ue-FW for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 03:01:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E71A32013425 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 03:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nC6g-0003US-CT for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 03:01:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01918 for ; Thu, 14 Aug 2003 03:01:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nC6c-0000KK-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 03:01:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nC6b-0000KH-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 03:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nC6Y-0003TR-6g; Thu, 14 Aug 2003 03:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nC5m-0003QY-WA for sipping@optimus.ietf.org; Thu, 14 Aug 2003 03:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01901 for ; Thu, 14 Aug 2003 03:00:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nC5j-0000KC-00 for sipping@ietf.org; Thu, 14 Aug 2003 03:00:11 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19nC5i-0000Jx-00 for sipping@ietf.org; Thu, 14 Aug 2003 03:00:10 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HJL00F01KQ536@siemenscomms.co.uk> for sipping@ietf.org; Thu, 14 Aug 2003 07:58:53 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HJL00EBBKQ5V6@siemenscomms.co.uk> for sipping@ietf.org; Thu, 14 Aug 2003 07:58:53 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Aug 2003 07:59:40 +0100 Content-return: allowed Date: Thu, 14 Aug 2003 08:00:02 +0100 From: "Elwell, John" Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-02.txt To: sipping@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain 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 draft takes into account all comments from the reviewers. I believe it is ready to progress. John (john.elwell@siemens.com) -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 13 August 2003 15:03 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-02.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 et al. Filename : draft-ietf-sipping-qsig2sip-02.txt Pages : 57 Date : 2003-8-13 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-02.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-02.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-02.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 exim@www1.ietf.org Thu Aug 14 06:43:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05824 for ; Thu, 14 Aug 2003 06:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZU-0003hl-UV for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAh86A014237 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZU-0003hI-Pk for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 06:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05798 for ; Thu, 14 Aug 2003 06:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nFZQ-0001Oy-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nFZP-0001Os-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZS-0003eb-MQ; Thu, 14 Aug 2003 06:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lw1C-0004Rr-Sp for sipping@optimus.ietf.org; Sun, 10 Aug 2003 15:38:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14588 for ; Sun, 10 Aug 2003 15:38:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lw1B-00012l-00 for sipping@ietf.org; Sun, 10 Aug 2003 15:38:17 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19lw1A-00012h-00 for sipping@ietf.org; Sun, 10 Aug 2003 15:38:17 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7AJ8j921351 for ; Sun, 10 Aug 2003 12:08:46 -0700 Date: Sun, 10 Aug 2003 12:08:45 -0700 (PDT) From: Bernard Aboba To: sipping@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sipping] New RADIUS-related mailing list created 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 new mailing list has been created to discuss potential future IETF RADIUS-related work. To subscribe the list, send mail to majordomo@psg.com, with "subscribe radiusext" in the body of the message. To send mail to the list, address it to radiusext@ops.ietf.org. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 06:43:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05839 for ; Thu, 14 Aug 2003 06:43:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZZ-0003jl-1V for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAhDDq014361 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZY-0003jY-UJ for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 06:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05808 for ; Thu, 14 Aug 2003 06:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nFZU-0001PC-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nFZU-0001P6-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZU-0003hE-LM; Thu, 14 Aug 2003 06:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mzMZ-0002Il-JU for sipping@optimus.ietf.org; Wed, 13 Aug 2003 13:24:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26606 for ; Wed, 13 Aug 2003 13:24:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzMU-0003MK-00 for sipping@ietf.org; Wed, 13 Aug 2003 13:24:38 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19mzMT-0003MH-00 for sipping@ietf.org; Wed, 13 Aug 2003 13:24:37 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7DGskC28931; Wed, 13 Aug 2003 09:54:47 -0700 Date: Wed, 13 Aug 2003 09:54:46 -0700 (PDT) From: Bernard Aboba To: Jonathan Rosenberg cc: john.loughney@nokia.com, sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: <3F3A5D41.5040505@dynamicsoft.com> Message-ID: References: <3F3A5D41.5040505@dynamicsoft.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: , > It seems to me that exponential backoff in retransmits is certainly > possible in a backwards compatible way. Yes, this part of the issue can be handled in a backwards compatible way. Since only the RADIUS client retransmits, the RADIUS server code does not have to change. > I'm not enough of a RADIUS > expert to know whether the watchdog mechanism as described in rfc3539 > is possible in a backwards compatible way. For the watchdog, both the RADIUS client and server would have to change. The objective of a watchdog would be to get an immediate response from the next hop RADIUS proxy/server; no forwarding of the watchdog is permitted. This would imply a new command, since there is no existing command that cannot be forwarded. It's probably possible to do this in a backward compatible way. One possibility would be to run the new command on a new port. Since RADIUS has no capabilities negotiation, the RADIUS client can send the new command to a new port and conclude that the command is not supported if it receives an ICMP port unreachable. This is what is done with the dynamic authorization extensions, for example (RFC 3576). Not elegant (wouldn't want to do this with every new command!) but it would work. > BTW, while on the subject of rfc3539, I am aware of many sip > implementations which perform watchdog operations very similar to > those described in section 3.4. I wonder if it would be useful to have > a sipping specification that describes how to properly do this in sip? > There are many ways to do this wrong, and we could leverage the > thinking Bernard has put into the AAA document to write up a version > for SIP that works well. RFC 3539 sends a watchdog after a given elapsed time without evidence of liveness (no traffic). Somewhat better scalability can be obtained if you wait until there is traffic to be sent; establishing liveness without the need to actually make use of it is somewhat wasteful. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 06:43:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05854 for ; Thu, 14 Aug 2003 06:43:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZY-0003jV-9H for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAhCUY014333 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZY-0003j0-1q for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 06:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05788 for ; Thu, 14 Aug 2003 06:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nFZN-0001OZ-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nFZM-0001OU-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZN-0003af-Hu; Thu, 14 Aug 2003 06:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kp18-0004R1-E4 for sipping@optimus.ietf.org; Thu, 07 Aug 2003 13:57:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24347 for ; Thu, 7 Aug 2003 13:57:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kp16-0001De-00 for sipping@ietf.org; Thu, 07 Aug 2003 13:57:36 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19kp15-0001DI-00 for sipping@ietf.org; Thu, 07 Aug 2003 13:57:35 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h77HufDq031319; Thu, 7 Aug 2003 12:56:41 -0500 Subject: Re: AW: AW: [Sipping] FYI: RADIUS & SIP From: Dean Willis To: "Liess, Laura" Cc: jiri.kuthan@fokus.fraunhofer.de, hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, aboba@internaut.com, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" In-Reply-To: <43240544763FB8479F1529372F6197CF053CC910@G8PQC.blf01.telekom.de> References: <43240544763FB8479F1529372F6197CF053CC910@G8PQC.blf01.telekom.de> Content-Type: text/plain Message-Id: <1060279000.30487.5.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 07 Aug 2003 12:56:40 -0500 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 On Wed, 2003-08-06 at 03:17, Liess, Laura wrote: > What about the accounting draft draft-schulzrinne-accounting-sip-01.txt? Any reason for not working on it? > Laura Accounting over a non-reliable transport protocol is a Very Hard Problem. That's one of the reaons for DIAMETER. -- 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 exim@www1.ietf.org Thu Aug 14 06:43:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05855 for ; Thu, 14 Aug 2003 06:43:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZY-0003jU-96 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAhCra014331 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZY-0003j1-3P for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 06:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05790 for ; Thu, 14 Aug 2003 06:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nFZN-0001Og-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nFZM-0001OX-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZO-0003av-E5; Thu, 14 Aug 2003 06:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpAG-0004tK-AG for sipping@optimus.ietf.org; Thu, 07 Aug 2003 14:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24710 for ; Thu, 7 Aug 2003 14:06:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpAD-0001JA-00 for sipping@ietf.org; Thu, 07 Aug 2003 14:07:02 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19kpAD-0001J5-00 for sipping@ietf.org; Thu, 07 Aug 2003 14:07:01 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 1449F43DE; Thu, 7 Aug 2003 20:01:35 +0200 (CEST) Received: from jku07.fokus.fraunhofer.de (dhcp114.fokus.fraunhofer.de [195.37.78.114]) by fox.iptel.org (Postfix) with ESMTP id 9EF775A7; Thu, 7 Aug 2003 20:01:34 +0200 (CEST) Message-Id: <5.2.0.9.0.20030807200108.05436950@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 07 Aug 2003 20:02:54 +0200 To: Dean Willis , "Liess, Laura" From: Jiri Kuthan Subject: Re: AW: AW: [Sipping] FYI: RADIUS & SIP Cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, aboba@internaut.com, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" In-Reply-To: <1060279000.30487.5.camel@bdsl.greycouncil.com> References: <43240544763FB8479F1529372F6197CF053CC910@G8PQC.blf01.telekom.de> <43240544763FB8479F1529372F6197CF053CC910@G8PQC.blf01.telekom.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , At 07:56 PM 8/7/2003, Dean Willis wrote: >On Wed, 2003-08-06 at 03:17, Liess, Laura wrote: >> What about the accounting draft draft-schulzrinne-accounting-sip-01.txt? Any reason for not working on it? >> Laura > >Accounting over a non-reliable transport protocol is a Very Hard >Problem. That's one of the reaons for DIAMETER. Still less hard than accounting over a protocol which does not exist. We actually developed some DIAMETER code but the problem is it is not running anywhere. -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 exim@www1.ietf.org Thu Aug 14 06:43:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05873 for ; Thu, 14 Aug 2003 06:43:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZc-0003k3-2s for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAhGu3014379 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZb-0003jq-Vb for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 06:43:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05805 for ; Thu, 14 Aug 2003 06:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nFZU-0001P9-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nFZT-0001P5-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZT-0003go-LJ; Thu, 14 Aug 2003 06:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mraH-0006Rv-8C for sipping@optimus.ietf.org; Wed, 13 Aug 2003 05:06:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12940 for ; Wed, 13 Aug 2003 05:06:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mraE-0007jb-00 for sipping@ietf.org; Wed, 13 Aug 2003 05:06:18 -0400 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx with esmtp (Exim 4.12) id 19mraD-0007jQ-00 for sipping@ietf.org; Wed, 13 Aug 2003 05:06:17 -0400 Received: from conversion-daemon.tid.hi.inet by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) id <0HJJ00B01VFPJ3@tid.hi.inet> for sipping@ietf.org; Wed, 13 Aug 2003 11:05:47 +0200 (MEST) Received: from huracan.hi.inet (huracan.hi.inet [10.95.3.216]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with SMTP id <0HJJ00B7KVW8OA@tid.hi.inet>; Wed, 13 Aug 2003 11:04:56 +0200 (MEST) Received: from tid.es by huracan.hi.inet (SMI-8.6/SMI-SVR4) id LAA07192; Wed, 13 Aug 2003 11:07:44 +0200 Date: Wed, 13 Aug 2003 11:07:44 +0200 From: Luis Emilio Martin Subject: WG: [Sipping] WGLC for Q.SIP-SIP mapping draft To: thomas.stach@siemens.com, sipping@ietf.org Cc: jieying.li@clarent.com, jfmule@packetizer.com Message-id: <3F39FFDF.DEB7EE96@tid.es> Organization: Telefonica =?iso-8859-1?Q?Investigaci=F3n?= y Desarrollo MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.6 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: es-ES, en 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 Hello, > The QSIG SETUP message may optionally transport HLC and LLC Information elements which are not mentioned > in the draft. You might want to add something like into section 10: > >"The gateway SHOULD (or SHALL(?)) not include a Low layer compatibility in the QSIG SETUP message. The > gateway SHOULD not include a High layer compatibility information element in the QSIG SETUP message. > >NOTE: Inclusion of a HLC in the QSIG SETUP message might be useful, if the gateway knows prior to > sending the QSIG SETUP message that fax is being transmitted (e.g., because of a corresponding > SDP offer), it may include in the QSIG SETUP message a High layer compatibility information element > indicating group 3 fax." It is discussed the possibility to include HLC IE in the QSIG SETUP if an INVITE was received with fax transmission information (i.e. T38 only), so that fax detection at destination does not depend on processing audio data. It possibly is a matter of configuration in the gateway. Sorry I am not very used to T.38 procedures and Fax Group 2/3 methods but we are testing some gateways with T.38 and automatic fax detection capabilities based on DSPs and experiencing some strange behaviours in these gateways, so that SETUP messages including HLC produce INVITEs offering G.729 or G.711 and a bit later new INVITES offering t38. In reverse direction, can a SIP gateway, upon reception of a SETUP Message with Bearer Capability 3,1 kHz Audio and an HLC indicating Fax Group 2/3, to map the HLC field into an INVITE message with an SDP offering T.38 only (not any other audio codec). The example is taken from chapter 5.1.2 http://www.watersprings.org/pub/id/draft-mule-sip-t38callflows-02.txt : Content-Type: application/sdp Content-Length: 320 v=0 o=ifaxgw1 2890846527 2890846527 IN IP4 ifax.here.com s=Session SDP c=IN IP4 ifaxmg.here.com t=0 0 m=image 15002 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF It should be the most straightforward procedure to map fax but is my interpretation correct?... or the reception of a setUp with such IE values does not have enough information to include an SDP offering with T.38 only, so it is required to wait for CNG/V21 detection to pick all the information required, and a renegotiation is thus required after call is stablished? Thank you very much in advance Best Regards Luis Martin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 06:45:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05990 for ; Thu, 14 Aug 2003 06:45:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZq-00040o-Gd for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:44:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAhUpY015413 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZp-0003vJ-65 for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 06:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05794 for ; Thu, 14 Aug 2003 06:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nFZQ-0001Or-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nFZP-0001On-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZQ-0003dk-J7; Thu, 14 Aug 2003 06:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kxr3-0002C9-16 for sipping@optimus.ietf.org; Thu, 07 Aug 2003 23:23:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13760 for ; Thu, 7 Aug 2003 23:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kxr1-0004yc-00 for sipping@ietf.org; Thu, 07 Aug 2003 23:23:47 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19kxr0-0004yU-00 for sipping@ietf.org; Thu, 07 Aug 2003 23:23:46 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h783NCKw014364; Thu, 7 Aug 2003 23:23:12 -0400 Message-ID: <018f01c35d5c$6780e220$0401a8c0@packetizer.org> From: "Paul E. Jones" To: "Henry Sinnreich" , "'Rohan Mahy'" Cc: , , "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , "'Mike Spanner'" , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , "'Andrea Saks'" , "'Erik Lagerway'" References: <0HJ900I4JHRTGL@pmismtp05.wcomnet.com> Subject: Re: [Sipping] Re: items for vor voting in the BOF Date: Thu, 7 Aug 2003 23:23:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Henry, Apparently, the mail server is a bit back-logged... I just received this today. Anyway, the xten site seems to have only a softphone. Perhaps I overlooked the other stuff. I saw this site yesterday: www.sipphone.com That site has 2 physical SIP phones for $130. Not a bad price and they do have a small LCD display for Call ID. It does not support RFC 2793, but it claims to support SIMPLE. I'm not sure how useful SIMPLE would prove to be from the phone and am quite curious about the UI for entering text. Anybody know? Here's the product info: http://www.ovislink.com/newovislink/Products/IPPhones/BT100.pdf Paul ----- Original Message ----- From: "Henry Sinnreich" To: "'Paul E. Jones'" ; "'Henry Sinnreich'" ; "'Rohan Mahy'" Cc: ; ; "'Henry Sinnreich'" ; "'Gunnar Hellstrom'" ; "'Mike Spanner'" ; ; ; "'Rajesh Kumar'" ; ; ; "'James Hamlin'" ; ; ; ; ; ; ; "'Andrea Saks'" ; "'Erik Lagerway'" Sent: Thursday, August 07, 2003 2:23 PM Subject: RE: [Sipping] Re: items for vor voting in the BOF > > Paul, > > Go to http://xten.com and see what a low cost phone can do. It has display > and keyboard. > > Henry > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > > Paul E. Jones > > Sent: Tuesday, July 29, 2003 9:33 PM > > To: Henry Sinnreich; 'Rohan Mahy' > > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; 'Henry Sinnreich'; > > 'Gunnar Hellstrom'; 'Mike Spanner'; andreas.piirimets@omnitor.se; > > trefor@trefor.plus.com; 'Rajesh Kumar'; marcelo@envilogg.se; > > jorgen.bjorkner@hotsip.com; 'James Hamlin'; Erik.Zetterstrom@omnitor.se; > > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; mgarakan@cisco.com; > > oran@cisco.com; sipping@ietf.org; 'Andrea Saks' > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > Henry, > > > > The same would likely be said by a boss or busy secretary in many > > companies. > > Even so, the bulk of the phones in most enterprises are just little dumb > > phones with no real features (perhaps feature keys... not much else). I > > don't expect that to change substantially, even with the introduction of > > VoIP. After all, more and more capability can be moved onto the PC. Why > > add hundreds of dollars in value to an IP phone when all of the "cool" > > features that you want can be placed on the PC (and updated much more > > easily)? The address book, instant messaging, etc., can all be located on > > the PC. The PC can interface with the server and with your phone. The > > phone needs little functionality of its own, really. > > > > There are people who buy fancy phones for their homes. Even so, there > > will > > be a substantial number of people who just don't care and will buy the > > cheapest thing they can find. I'm sure that manufacturers will try to cut > > costs at every opportunity and screens are a target. Should we not plan > > on > > it? > > > > Paul > > > > ----- Original Message ----- > > From: "Henry Sinnreich" > > To: "'Paul E. Jones'" ; "'Rohan Mahy'" > > > > Cc: ; ; "'Henry Sinnreich'" > > ; "'Gunnar Hellstrom'" > > ; "'Mike Spanner'" > > ; > > ; ; "'Rajesh Kumar'" > > ; ; ; > > "'James Hamlin'" ; > > ; > > ; ; ; > > ; ; "'Andrea Saks'" > > Sent: Monday, July 28, 2003 10:18 PM > > Subject: RE: [Sipping] Re: items for vor voting in the BOF > > > > > > > Paul, finally, we disagree! > > > > > > We have 3-4 SIP phones in my house at all times and we are using all of > > them > > > in various rooms. We would not even dream touching a VoIP phone that > > does > > > not have a display and without its own web page where we can see the > > address > > > book and dial from the PC or from some another web absed personal call > > > manager. > > > > > > I would certainly not attempt to sell any friend or family member a SIP > > > phone withou display. Depressing thought. > > > > > > Nor would we ever by a mobile phone without display. > > > > > > Cheers :-) > > > > > > Henry > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > On Behalf Of Paul E. Jones > > > > Sent: Sunday, July 20, 2003 11:52 AM > > > > To: Rohan Mahy > > > > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; Henry > > > > Sinnreich; Gunnar Hellstrom; Mike Spanner; > > > > andreas.piirimets@omnitor.se; trefor@trefor.plus.com; 'Rajesh > > > > Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > James Hamlin; Erik.Zetterstrom@omnitor.se; > > > > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; > > > > mgarakan@cisco.com; oran@cisco.com; sipping@ietf.org; Andrea Saks > > > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > > > Rohan, > > > > > > > > I offered up a few questions to folks that I hoped people > > > > would have voted on. The questions I had was whether or not > > > > there should be a requirement to provide *some* interface to > > > > legacy TTY devices. Whether it's RJ-11 or 2.5mm makes no > > > > difference. However, I think it should be a requirement that > > > > pass-through work at the very least. If this was agreeable, > > > > I could certainly work to craft specific text for such a requirement. > > > > > > > > I do not have stats on how many phones do not have screens. > > > > However, note that requirement 1 also requires a keyboard, > > > > though that's never mentioned. > > > > One could say that text could be entered via some web > > > > interface, but doing so is a bit hard in a hotel room or at a > > > > gas station on the side of the road. Regardless, I've said > > > > before and I'll say it again: I do not expect that most of > > > > the IP phones that will go into mass production will have a > > > > suitable screen for text communication. Most of today's IP > > > > phones have screens, because it is a way to catch people's > > > > eyes. However, there are also many that do not. Would you > > > > consider Cisco's ATA, for example, an IP phone? I think it > > > > qualifies and there is no screen. There are a number of > > > > service providers deploying that and similar devices from > > > > other manufacturers. None of those have displays. > > > > > > > > I assert that in most enterprise environments, the display is > > > > of very little value. It's interesting at first, but it's > > > > not necessary to have a fancy > > > > screen: just something simple to control hold, transfer, > > > > conferencing, etc., is enough. In fact, I'd be happy with > > > > buttons that did that. > > > > > > > > At home, I think it's even less of a requirement to have a > > > > nice-size display. Recognizing that many phones today have a > > > > display for caller ID, etc., such displays are not suitable > > > > for text communication. Requirement 1 is asking for a nice > > > > display... and I think you'll find a much smaller percentage > > > > of those... especially as they become a commodity item. > > > > > > > > Paul > > > > > > > > ----- Original Message ----- > > > > From: "Rohan Mahy" > > > > To: "Paul E. Jones" > > > > Cc: ; ; "Henry Sinnreich" > > > > ; "Gunnar Hellstrom" > > > > ; "Mike Spanner" > > > > ; ; > > > > ; "'Rajesh Kumar'" > > > > ; ; > > > > ; "James Hamlin" > > > > ; ; > > > > ; ; > > > > ; ; ; > > > > "Andrea Saks" > > > > Sent: Saturday, July 19, 2003 11:14 PM > > > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > > > > Hi Paul, > > > > > > > > > > So it sounds like you wanted an additional requirement for > > > > pass-through > > > > > via a 2.5 mm jack for phones that do not support RFC2793? If I > > > > > understood this correctly, how would you word the requirement? > > > > > > > > > > Also, do you have any data on how many phones currently > > > > exist (number > > > > > or percentage) for which requirement 1 would not apply? I > > > > suspect that > > > > > the number of phones not covered by the first requirement > > > > is actually > > > > > quite small. > > > > > > > > > > thanks, > > > > > -rohan > > > > > > > > > > On Friday, July 18, 2003, at 05:04 PM, Paul E. Jones wrote: > > > > > > > > > > > Guido, > > > > > > > > > > > > I wish I could have attended, but I was attending a TDI conference > > > > > > here in > > > > > > the US. I couldn't be in both places at the same time, > > > > though I wish I > > > > > > could. I was disheartened that the questions were not > > > > presented as I > > > > > > proposed. You should know that, supposedly, work gets > > > > done over the > > > > > > e-mail > > > > > > reflector, not only in the meeting, so not being there > > > > should not have > > > > > > lessened my input on the matter. > > > > > > > > > > > > Looking at the results of the ad-hoc reported by Rohan, I see: > > > > > > 1) *If* an IP phone supports a display (and keyboard??), it > > > > > > must support RFC 2793 > > > > > > 2) IP phones *should* provide a way to input text > > > > > > 3) IP phones *may* provide an RJ-11 interface and *must* > > > > > > support pass-through. > > > > > > > > > > > > Now, my concerns are several. It appears that you have > > > > absolutely no > > > > > > requirement for the mass of products that do not sport a > > > > display to > > > > > > support > > > > > > text in either relay or pass-through mode. Further, there is no > > > > > > mention of > > > > > > a 2.5mm jack being an option. Question 3, as I > > > > mentioned, "pressured" > > > > > > folks > > > > > > more than it should. There should have been no reason to require > > > > > > support of > > > > > > pass-through, at the very least. > > > > > > > > > > > > I told you that my questions were to ensure that we at least get > > > > > > support for > > > > > > text on every phone in one way or another. It looks like > > > > you lost. > > > > > > Company > > > > > > X is now free to build an IP phone without any text > > > > support. I'm not > > > > > > really > > > > > > happy about that and I certainly don't see why you should be. > > > > > > > > > > > > Paul > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Guido Gybels" > > > > > > To: "Paul E. Jones" ; > > > > > > Cc: "Henry Sinnreich" ; "Gunnar > > > > Hellstrom" > > > > > > ; "Guido Gybels" > > > > > > ; > > > > > > "Mike Spanner" ; > > > > > > ; > > > > > > ; ; "'Rajesh Kumar'" > > > > > > ; ; > > > > > > ; > > > > > > "James Hamlin" ; > > > > > > ; > > > > > > ; ; > > > > > > ; > > > > > > ; ; > > > > > > Sent: Friday, July 18, 2003 2:31 AM > > > > > > Subject: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > > > > > > > > >> Paul, > > > > > >> > > > > > >> <> > > > > > >> > > > > > >> The discussion on the sipdev document took place > > > > yesterday, and if you > > > > > > wanted to make a point you were free to attend it. You'll see the > > > > > > results > > > > > > reflected in the next version of the document, and I can > > > > say that both > > > > > > Arnoud and myself believe this result to be extremely > > > > sensible as well > > > > > > as in > > > > > > the best interest of all stakeholders. > > > > > >> I also suggest this no longer belongs here on the > > > > mailing list until > > > > > >> a new > > > > > > issue would arise. I have stopped replying to your emails > > > > a while ago > > > > > > as I > > > > > > see no point in continuing the discussion (and swamping > > > > the list) with > > > > > > someone who, despite being a native English speaker, > > > > seems unable to > > > > > > understand what we are saying and more importantly deliberately > > > > > > misrepresents my statements or attributes words to my > > > > mouth that I did > > > > > > not > > > > > > speak. > > > > > >> > > > > > >> < > > > know you'd say > > > > > >> "no" > > > > > > to > > > > > >> it.>> > > > > > >> > > > > > >> This being a nice example of that. > > > > > >> > > > > > >> > > > > > >> I believe the IETF community has shown great wisdom and a true > > > > > > understanding of what is at stake here. We have now got a > > > > solid path > > > > > > to the > > > > > > future, with a clear strategy to get rid of obsolete and > > > > unsatisfactory > > > > > > solutions allowing a gradual move of deaf, hard of > > > > hearing and speech > > > > > > impaired people into mainstream technology. That will of > > > > course take > > > > > > time > > > > > > during which there will have to be legacy support and all the > > > > > > instruments > > > > > > are put in place to do exactly that. > > > > > >> > > > > > >> Guido > > > > > >> > > > > > >> Guido Gybels > > > > > >> Director of New Technologies > > > > > >> > > > > > >> RNID, 19-23 Featherstone Street > > > > > >> London EC1Y 8SL, UK > > > > > >> Tel +44(0)20-7294 3713 > > > > > >> Fax +44(0)20-7296 8069 > > > > > >> > > > > > >> _______________________________________________ > > > > > >> Sipping mailing list > > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > >> This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 06:45:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06019 for ; Thu, 14 Aug 2003 06:45:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZq-00040m-G8 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:44:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAhULY015412 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZp-0003v2-63 for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 06:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05789 for ; Thu, 14 Aug 2003 06:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nFZN-0001Oc-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nFZM-0001OV-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZP-0003bW-FL; Thu, 14 Aug 2003 06:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpV1-0005pc-Np for sipping@optimus.ietf.org; Thu, 07 Aug 2003 14:28:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25753 for ; Thu, 7 Aug 2003 14:28:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpUz-0001YB-00 for sipping@ietf.org; Thu, 07 Aug 2003 14:28:29 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19kpUy-0001Xq-00 for sipping@ietf.org; Thu, 07 Aug 2003 14:28:28 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJ900ALRHRWC8@firewall.wcom.com> for sipping@ietf.org; Thu, 07 Aug 2003 18:23:56 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJ900J01HRV73@pmismtp05.wcomnet.com>; Thu, 07 Aug 2003 18:23:56 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.95]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJ900I4IHRTGL@pmismtp05.wcomnet.com>; Thu, 07 Aug 2003 18:23:55 +0000 (GMT) Date: Thu, 07 Aug 2003 13:23:54 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: items for vor voting in the BOF In-reply-to: <023b01c35642$f2aa1950$0401a8c0@packetizer.org> To: "'Paul E. Jones'" , "'Henry Sinnreich'" , "'Rohan Mahy'" Cc: guido.gybels@rnid.org.uk, gv@trace.wisc.edu, "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , "'Mike Spanner'" , andreas.piirimets@omnitor.se, trefor@trefor.plus.com, "'Rajesh Kumar'" , marcelo@envilogg.se, jorgen.bjorkner@hotsip.com, "'James Hamlin'" , Erik.Zetterstrom@omnitor.se, hwildfeu@cisco.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, sipping@ietf.org, "'Andrea Saks'" , "'Erik Lagerway'" Message-id: <0HJ900I4JHRTGL@pmismtp05.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNdCqSnTt6uq+0rQimkFRpi+kMclgAAsYCg 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 Paul, Go to http://xten.com and see what a low cost phone can do. It has display and keyboard. Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Paul E. Jones > Sent: Tuesday, July 29, 2003 9:33 PM > To: Henry Sinnreich; 'Rohan Mahy' > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; 'Henry Sinnreich'; > 'Gunnar Hellstrom'; 'Mike Spanner'; andreas.piirimets@omnitor.se; > trefor@trefor.plus.com; 'Rajesh Kumar'; marcelo@envilogg.se; > jorgen.bjorkner@hotsip.com; 'James Hamlin'; Erik.Zetterstrom@omnitor.se; > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; mgarakan@cisco.com; > oran@cisco.com; sipping@ietf.org; 'Andrea Saks' > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > Henry, > > The same would likely be said by a boss or busy secretary in many > companies. > Even so, the bulk of the phones in most enterprises are just little dumb > phones with no real features (perhaps feature keys... not much else). I > don't expect that to change substantially, even with the introduction of > VoIP. After all, more and more capability can be moved onto the PC. Why > add hundreds of dollars in value to an IP phone when all of the "cool" > features that you want can be placed on the PC (and updated much more > easily)? The address book, instant messaging, etc., can all be located on > the PC. The PC can interface with the server and with your phone. The > phone needs little functionality of its own, really. > > There are people who buy fancy phones for their homes. Even so, there > will > be a substantial number of people who just don't care and will buy the > cheapest thing they can find. I'm sure that manufacturers will try to cut > costs at every opportunity and screens are a target. Should we not plan > on > it? > > Paul > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Paul E. Jones'" ; "'Rohan Mahy'" > > Cc: ; ; "'Henry Sinnreich'" > ; "'Gunnar Hellstrom'" > ; "'Mike Spanner'" > ; > ; ; "'Rajesh Kumar'" > ; ; ; > "'James Hamlin'" ; > ; > ; ; ; > ; ; "'Andrea Saks'" > Sent: Monday, July 28, 2003 10:18 PM > Subject: RE: [Sipping] Re: items for vor voting in the BOF > > > > Paul, finally, we disagree! > > > > We have 3-4 SIP phones in my house at all times and we are using all of > them > > in various rooms. We would not even dream touching a VoIP phone that > does > > not have a display and without its own web page where we can see the > address > > book and dial from the PC or from some another web absed personal call > > manager. > > > > I would certainly not attempt to sell any friend or family member a SIP > > phone withou display. Depressing thought. > > > > Nor would we ever by a mobile phone without display. > > > > Cheers :-) > > > > Henry > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of Paul E. Jones > > > Sent: Sunday, July 20, 2003 11:52 AM > > > To: Rohan Mahy > > > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; Henry > > > Sinnreich; Gunnar Hellstrom; Mike Spanner; > > > andreas.piirimets@omnitor.se; trefor@trefor.plus.com; 'Rajesh > > > Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > James Hamlin; Erik.Zetterstrom@omnitor.se; > > > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; > > > mgarakan@cisco.com; oran@cisco.com; sipping@ietf.org; Andrea Saks > > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > Rohan, > > > > > > I offered up a few questions to folks that I hoped people > > > would have voted on. The questions I had was whether or not > > > there should be a requirement to provide *some* interface to > > > legacy TTY devices. Whether it's RJ-11 or 2.5mm makes no > > > difference. However, I think it should be a requirement that > > > pass-through work at the very least. If this was agreeable, > > > I could certainly work to craft specific text for such a requirement. > > > > > > I do not have stats on how many phones do not have screens. > > > However, note that requirement 1 also requires a keyboard, > > > though that's never mentioned. > > > One could say that text could be entered via some web > > > interface, but doing so is a bit hard in a hotel room or at a > > > gas station on the side of the road. Regardless, I've said > > > before and I'll say it again: I do not expect that most of > > > the IP phones that will go into mass production will have a > > > suitable screen for text communication. Most of today's IP > > > phones have screens, because it is a way to catch people's > > > eyes. However, there are also many that do not. Would you > > > consider Cisco's ATA, for example, an IP phone? I think it > > > qualifies and there is no screen. There are a number of > > > service providers deploying that and similar devices from > > > other manufacturers. None of those have displays. > > > > > > I assert that in most enterprise environments, the display is > > > of very little value. It's interesting at first, but it's > > > not necessary to have a fancy > > > screen: just something simple to control hold, transfer, > > > conferencing, etc., is enough. In fact, I'd be happy with > > > buttons that did that. > > > > > > At home, I think it's even less of a requirement to have a > > > nice-size display. Recognizing that many phones today have a > > > display for caller ID, etc., such displays are not suitable > > > for text communication. Requirement 1 is asking for a nice > > > display... and I think you'll find a much smaller percentage > > > of those... especially as they become a commodity item. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Rohan Mahy" > > > To: "Paul E. Jones" > > > Cc: ; ; "Henry Sinnreich" > > > ; "Gunnar Hellstrom" > > > ; "Mike Spanner" > > > ; ; > > > ; "'Rajesh Kumar'" > > > ; ; > > > ; "James Hamlin" > > > ; ; > > > ; ; > > > ; ; ; > > > "Andrea Saks" > > > Sent: Saturday, July 19, 2003 11:14 PM > > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > Hi Paul, > > > > > > > > So it sounds like you wanted an additional requirement for > > > pass-through > > > > via a 2.5 mm jack for phones that do not support RFC2793? If I > > > > understood this correctly, how would you word the requirement? > > > > > > > > Also, do you have any data on how many phones currently > > > exist (number > > > > or percentage) for which requirement 1 would not apply? I > > > suspect that > > > > the number of phones not covered by the first requirement > > > is actually > > > > quite small. > > > > > > > > thanks, > > > > -rohan > > > > > > > > On Friday, July 18, 2003, at 05:04 PM, Paul E. Jones wrote: > > > > > > > > > Guido, > > > > > > > > > > I wish I could have attended, but I was attending a TDI conference > > > > > here in > > > > > the US. I couldn't be in both places at the same time, > > > though I wish I > > > > > could. I was disheartened that the questions were not > > > presented as I > > > > > proposed. You should know that, supposedly, work gets > > > done over the > > > > > e-mail > > > > > reflector, not only in the meeting, so not being there > > > should not have > > > > > lessened my input on the matter. > > > > > > > > > > Looking at the results of the ad-hoc reported by Rohan, I see: > > > > > 1) *If* an IP phone supports a display (and keyboard??), it > > > > > must support RFC 2793 > > > > > 2) IP phones *should* provide a way to input text > > > > > 3) IP phones *may* provide an RJ-11 interface and *must* > > > > > support pass-through. > > > > > > > > > > Now, my concerns are several. It appears that you have > > > absolutely no > > > > > requirement for the mass of products that do not sport a > > > display to > > > > > support > > > > > text in either relay or pass-through mode. Further, there is no > > > > > mention of > > > > > a 2.5mm jack being an option. Question 3, as I > > > mentioned, "pressured" > > > > > folks > > > > > more than it should. There should have been no reason to require > > > > > support of > > > > > pass-through, at the very least. > > > > > > > > > > I told you that my questions were to ensure that we at least get > > > > > support for > > > > > text on every phone in one way or another. It looks like > > > you lost. > > > > > Company > > > > > X is now free to build an IP phone without any text > > > support. I'm not > > > > > really > > > > > happy about that and I certainly don't see why you should be. > > > > > > > > > > Paul > > > > > > > > > > ----- Original Message ----- > > > > > From: "Guido Gybels" > > > > > To: "Paul E. Jones" ; > > > > > Cc: "Henry Sinnreich" ; "Gunnar > > > Hellstrom" > > > > > ; "Guido Gybels" > > > > > ; > > > > > "Mike Spanner" ; > > > > > ; > > > > > ; ; "'Rajesh Kumar'" > > > > > ; ; > > > > > ; > > > > > "James Hamlin" ; > > > > > ; > > > > > ; ; > > > > > ; > > > > > ; ; > > > > > Sent: Friday, July 18, 2003 2:31 AM > > > > > Subject: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > > > > > >> Paul, > > > > >> > > > > >> <> > > > > >> > > > > >> The discussion on the sipdev document took place > > > yesterday, and if you > > > > > wanted to make a point you were free to attend it. You'll see the > > > > > results > > > > > reflected in the next version of the document, and I can > > > say that both > > > > > Arnoud and myself believe this result to be extremely > > > sensible as well > > > > > as in > > > > > the best interest of all stakeholders. > > > > >> I also suggest this no longer belongs here on the > > > mailing list until > > > > >> a new > > > > > issue would arise. I have stopped replying to your emails > > > a while ago > > > > > as I > > > > > see no point in continuing the discussion (and swamping > > > the list) with > > > > > someone who, despite being a native English speaker, > > > seems unable to > > > > > understand what we are saying and more importantly deliberately > > > > > misrepresents my statements or attributes words to my > > > mouth that I did > > > > > not > > > > > speak. > > > > >> > > > > >> < > > know you'd say > > > > >> "no" > > > > > to > > > > >> it.>> > > > > >> > > > > >> This being a nice example of that. > > > > >> > > > > >> > > > > >> I believe the IETF community has shown great wisdom and a true > > > > > understanding of what is at stake here. We have now got a > > > solid path > > > > > to the > > > > > future, with a clear strategy to get rid of obsolete and > > > unsatisfactory > > > > > solutions allowing a gradual move of deaf, hard of > > > hearing and speech > > > > > impaired people into mainstream technology. That will of > > > course take > > > > > time > > > > > during which there will have to be legacy support and all the > > > > > instruments > > > > > are put in place to do exactly that. > > > > >> > > > > >> Guido > > > > >> > > > > >> Guido Gybels > > > > >> Director of New Technologies > > > > >> > > > > >> RNID, 19-23 Featherstone Street > > > > >> London EC1Y 8SL, UK > > > > >> Tel +44(0)20-7294 3713 > > > > >> Fax +44(0)20-7296 8069 > > > > >> > > > > >> _______________________________________________ > > > > >> Sipping mailing list > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > >> This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 07:38:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05989 for ; Thu, 14 Aug 2003 06:45:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZq-00040n-GV for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:44:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EAhUf9015414 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 06:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZp-0003vM-6I for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 06:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05797 for ; Thu, 14 Aug 2003 06:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nFZQ-0001Ov-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nFZP-0001Oo-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 06:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nFZR-0003eB-KT; Thu, 14 Aug 2003 06:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8A3-00070E-K7 for sipping@optimus.ietf.org; Fri, 08 Aug 2003 10:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13125 for ; Fri, 8 Aug 2003 10:24:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8A1-00016j-00 for sipping@ietf.org; Fri, 08 Aug 2003 10:24:05 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19l8A0-00016W-01 for sipping@ietf.org; Fri, 08 Aug 2003 10:24:04 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJB00DE81655K@firewall.wcom.com> for sipping@ietf.org; Fri, 08 Aug 2003 14:20:29 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJB00F01164UO@dgismtp06.wcomnet.com>; Fri, 08 Aug 2003 14:20:29 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.95]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJB00DQF162R5@dgismtp06.wcomnet.com>; Fri, 08 Aug 2003 14:20:28 +0000 (GMT) Date: Fri, 08 Aug 2003 09:20:26 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: items for vor voting in the BOF In-reply-to: <018f01c35d5c$6780e220$0401a8c0@packetizer.org> To: "'Paul E. Jones'" , "'Henry Sinnreich'" , "'Rohan Mahy'" Cc: guido.gybels@rnid.org.uk, gv@trace.wisc.edu, "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , "'Mike Spanner'" , andreas.piirimets@omnitor.se, trefor@trefor.plus.com, "'Rajesh Kumar'" , marcelo@envilogg.se, jorgen.bjorkner@hotsip.com, "'James Hamlin'" , Erik.Zetterstrom@omnitor.se, hwildfeu@cisco.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, sipping@ietf.org, "'Andrea Saks'" , "'Erik Lagerway'" Message-id: <0HJB00DQG162R5@dgismtp06.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNdXHzgRomaUWXyTR6Z6m7Nl/5rcwAW24Pw 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 a good opportunity to encourage all on the list to help register SIP phones and other products at the www.sipforum.org Thanks, Henry > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, August 07, 2003 10:23 PM > To: Henry Sinnreich; 'Rohan Mahy' > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; 'Henry Sinnreich'; > 'Gunnar Hellstrom'; 'Mike Spanner'; andreas.piirimets@omnitor.se; > trefor@trefor.plus.com; 'Rajesh Kumar'; marcelo@envilogg.se; > jorgen.bjorkner@hotsip.com; 'James Hamlin'; Erik.Zetterstrom@omnitor.se; > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; mgarakan@cisco.com; > oran@cisco.com; sipping@ietf.org; 'Andrea Saks'; 'Erik Lagerway' > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > Henry, > > Apparently, the mail server is a bit back-logged... I just received this > today. > > Anyway, the xten site seems to have only a softphone. Perhaps I > overlooked > the other stuff. > > I saw this site yesterday: www.sipphone.com > > That site has 2 physical SIP phones for $130. Not a bad price and they do > have a small LCD display for Call ID. It does not support RFC 2793, but > it > claims to support SIMPLE. I'm not sure how useful SIMPLE would prove to > be > from the phone and am quite curious about the UI for entering text. > Anybody > know? > > Here's the product info: > http://www.ovislink.com/newovislink/Products/IPPhones/BT100.pdf > > Paul > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Paul E. Jones'" ; "'Henry Sinnreich'" > ; "'Rohan Mahy'" > Cc: ; ; "'Henry Sinnreich'" > ; "'Gunnar Hellstrom'" > ; "'Mike Spanner'" > ; > ; ; "'Rajesh Kumar'" > ; ; ; > "'James Hamlin'" ; > ; > ; ; ; > ; ; "'Andrea Saks'" > ; > "'Erik Lagerway'" > Sent: Thursday, August 07, 2003 2:23 PM > Subject: RE: [Sipping] Re: items for vor voting in the BOF > > > > > > Paul, > > > > Go to http://xten.com and see what a low cost phone can do. It has > display > > and keyboard. > > > > Henry > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of > > > Paul E. Jones > > > Sent: Tuesday, July 29, 2003 9:33 PM > > > To: Henry Sinnreich; 'Rohan Mahy' > > > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; 'Henry Sinnreich'; > > > 'Gunnar Hellstrom'; 'Mike Spanner'; andreas.piirimets@omnitor.se; > > > trefor@trefor.plus.com; 'Rajesh Kumar'; marcelo@envilogg.se; > > > jorgen.bjorkner@hotsip.com; 'James Hamlin'; > Erik.Zetterstrom@omnitor.se; > > > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; mgarakan@cisco.com; > > > oran@cisco.com; sipping@ietf.org; 'Andrea Saks' > > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > Henry, > > > > > > The same would likely be said by a boss or busy secretary in many > > > companies. > > > Even so, the bulk of the phones in most enterprises are just little > dumb > > > phones with no real features (perhaps feature keys... not much else). > I > > > don't expect that to change substantially, even with the introduction > of > > > VoIP. After all, more and more capability can be moved onto the PC. > Why > > > add hundreds of dollars in value to an IP phone when all of the "cool" > > > features that you want can be placed on the PC (and updated much more > > > easily)? The address book, instant messaging, etc., can all be > located > on > > > the PC. The PC can interface with the server and with your phone. > The > > > phone needs little functionality of its own, really. > > > > > > There are people who buy fancy phones for their homes. Even so, there > > > will > > > be a substantial number of people who just don't care and will buy the > > > cheapest thing they can find. I'm sure that manufacturers will try to > cut > > > costs at every opportunity and screens are a target. Should we not > plan > > > on > > > it? > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Henry Sinnreich" > > > To: "'Paul E. Jones'" ; "'Rohan Mahy'" > > > > > > Cc: ; ; "'Henry > Sinnreich'" > > > ; "'Gunnar Hellstrom'" > > > ; "'Mike Spanner'" > > > ; > > > ; ; "'Rajesh > Kumar'" > > > ; ; > ; > > > "'James Hamlin'" ; > > > ; > > > ; ; > ; > > > ; ; "'Andrea Saks'" > > > > Sent: Monday, July 28, 2003 10:18 PM > > > Subject: RE: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > Paul, finally, we disagree! > > > > > > > > We have 3-4 SIP phones in my house at all times and we are using all > of > > > them > > > > in various rooms. We would not even dream touching a VoIP phone that > > > does > > > > not have a display and without its own web page where we can see the > > > address > > > > book and dial from the PC or from some another web absed personal > call > > > > manager. > > > > > > > > I would certainly not attempt to sell any friend or family member a > SIP > > > > phone withou display. Depressing thought. > > > > > > > > Nor would we ever by a mobile phone without display. > > > > > > > > Cheers :-) > > > > > > > > Henry > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > > On Behalf Of Paul E. Jones > > > > > Sent: Sunday, July 20, 2003 11:52 AM > > > > > To: Rohan Mahy > > > > > Cc: guido.gybels@rnid.org.uk; gv@trace.wisc.edu; Henry > > > > > Sinnreich; Gunnar Hellstrom; Mike Spanner; > > > > > andreas.piirimets@omnitor.se; trefor@trefor.plus.com; 'Rajesh > > > > > Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > > James Hamlin; Erik.Zetterstrom@omnitor.se; > > > > > hwildfeu@cisco.com; barry.dingle@bigfoot.com.au; > > > > > mgarakan@cisco.com; oran@cisco.com; sipping@ietf.org; Andrea Saks > > > > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > Rohan, > > > > > > > > > > I offered up a few questions to folks that I hoped people > > > > > would have voted on. The questions I had was whether or not > > > > > there should be a requirement to provide *some* interface to > > > > > legacy TTY devices. Whether it's RJ-11 or 2.5mm makes no > > > > > difference. However, I think it should be a requirement that > > > > > pass-through work at the very least. If this was agreeable, > > > > > I could certainly work to craft specific text for such a > requirement. > > > > > > > > > > I do not have stats on how many phones do not have screens. > > > > > However, note that requirement 1 also requires a keyboard, > > > > > though that's never mentioned. > > > > > One could say that text could be entered via some web > > > > > interface, but doing so is a bit hard in a hotel room or at a > > > > > gas station on the side of the road. Regardless, I've said > > > > > before and I'll say it again: I do not expect that most of > > > > > the IP phones that will go into mass production will have a > > > > > suitable screen for text communication. Most of today's IP > > > > > phones have screens, because it is a way to catch people's > > > > > eyes. However, there are also many that do not. Would you > > > > > consider Cisco's ATA, for example, an IP phone? I think it > > > > > qualifies and there is no screen. There are a number of > > > > > service providers deploying that and similar devices from > > > > > other manufacturers. None of those have displays. > > > > > > > > > > I assert that in most enterprise environments, the display is > > > > > of very little value. It's interesting at first, but it's > > > > > not necessary to have a fancy > > > > > screen: just something simple to control hold, transfer, > > > > > conferencing, etc., is enough. In fact, I'd be happy with > > > > > buttons that did that. > > > > > > > > > > At home, I think it's even less of a requirement to have a > > > > > nice-size display. Recognizing that many phones today have a > > > > > display for caller ID, etc., such displays are not suitable > > > > > for text communication. Requirement 1 is asking for a nice > > > > > display... and I think you'll find a much smaller percentage > > > > > of those... especially as they become a commodity item. > > > > > > > > > > Paul > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rohan Mahy" > > > > > To: "Paul E. Jones" > > > > > Cc: ; ; "Henry > Sinnreich" > > > > > ; "Gunnar Hellstrom" > > > > > ; "Mike Spanner" > > > > > ; ; > > > > > ; "'Rajesh Kumar'" > > > > > ; ; > > > > > ; "James Hamlin" > > > > > ; ; > > > > > ; ; > > > > > ; ; ; > > > > > "Andrea Saks" > > > > > Sent: Saturday, July 19, 2003 11:14 PM > > > > > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > > > > > > > Hi Paul, > > > > > > > > > > > > So it sounds like you wanted an additional requirement for > > > > > pass-through > > > > > > via a 2.5 mm jack for phones that do not support RFC2793? If I > > > > > > understood this correctly, how would you word the requirement? > > > > > > > > > > > > Also, do you have any data on how many phones currently > > > > > exist (number > > > > > > or percentage) for which requirement 1 would not apply? I > > > > > suspect that > > > > > > the number of phones not covered by the first requirement > > > > > is actually > > > > > > quite small. > > > > > > > > > > > > thanks, > > > > > > -rohan > > > > > > > > > > > > On Friday, July 18, 2003, at 05:04 PM, Paul E. Jones wrote: > > > > > > > > > > > > > Guido, > > > > > > > > > > > > > > I wish I could have attended, but I was attending a TDI > conference > > > > > > > here in > > > > > > > the US. I couldn't be in both places at the same time, > > > > > though I wish I > > > > > > > could. I was disheartened that the questions were not > > > > > presented as I > > > > > > > proposed. You should know that, supposedly, work gets > > > > > done over the > > > > > > > e-mail > > > > > > > reflector, not only in the meeting, so not being there > > > > > should not have > > > > > > > lessened my input on the matter. > > > > > > > > > > > > > > Looking at the results of the ad-hoc reported by Rohan, I see: > > > > > > > 1) *If* an IP phone supports a display (and keyboard??), it > > > > > > > must support RFC 2793 > > > > > > > 2) IP phones *should* provide a way to input text > > > > > > > 3) IP phones *may* provide an RJ-11 interface and *must* > > > > > > > support pass-through. > > > > > > > > > > > > > > Now, my concerns are several. It appears that you have > > > > > absolutely no > > > > > > > requirement for the mass of products that do not sport a > > > > > display to > > > > > > > support > > > > > > > text in either relay or pass-through mode. Further, there is > no > > > > > > > mention of > > > > > > > a 2.5mm jack being an option. Question 3, as I > > > > > mentioned, "pressured" > > > > > > > folks > > > > > > > more than it should. There should have been no reason to > require > > > > > > > support of > > > > > > > pass-through, at the very least. > > > > > > > > > > > > > > I told you that my questions were to ensure that we at least > get > > > > > > > support for > > > > > > > text on every phone in one way or another. It looks like > > > > > you lost. > > > > > > > Company > > > > > > > X is now free to build an IP phone without any text > > > > > support. I'm not > > > > > > > really > > > > > > > happy about that and I certainly don't see why you should be. > > > > > > > > > > > > > > Paul > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Guido Gybels" > > > > > > > To: "Paul E. Jones" ; > > > > > > > > Cc: "Henry Sinnreich" ; "Gunnar > > > > > Hellstrom" > > > > > > > ; "Guido Gybels" > > > > > > > ; > > > > > > > "Mike Spanner" ; > > > > > > > ; > > > > > > > ; ; "'Rajesh > Kumar'" > > > > > > > ; ; > > > > > > > ; > > > > > > > "James Hamlin" ; > > > > > > > ; > > > > > > > ; ; > > > > > > > ; > > > > > > > ; ; > > > > > > > Sent: Friday, July 18, 2003 2:31 AM > > > > > > > Subject: [Sipping] Re: items for vor voting in the BOF > > > > > > > > > > > > > > > > > > > > >> Paul, > > > > > > >> > > > > > > >> <> > > > > > > >> > > > > > > >> The discussion on the sipdev document took place > > > > > yesterday, and if you > > > > > > > wanted to make a point you were free to attend it. You'll see > the > > > > > > > results > > > > > > > reflected in the next version of the document, and I can > > > > > say that both > > > > > > > Arnoud and myself believe this result to be extremely > > > > > sensible as well > > > > > > > as in > > > > > > > the best interest of all stakeholders. > > > > > > >> I also suggest this no longer belongs here on the > > > > > mailing list until > > > > > > >> a new > > > > > > > issue would arise. I have stopped replying to your emails > > > > > a while ago > > > > > > > as I > > > > > > > see no point in continuing the discussion (and swamping > > > > > the list) with > > > > > > > someone who, despite being a native English speaker, > > > > > seems unable to > > > > > > > understand what we are saying and more importantly > deliberately > > > > > > > misrepresents my statements or attributes words to my > > > > > mouth that I did > > > > > > > not > > > > > > > speak. > > > > > > >> > > > > > > >> < > > > > know you'd say > > > > > > >> "no" > > > > > > > to > > > > > > >> it.>> > > > > > > >> > > > > > > >> This being a nice example of that. > > > > > > >> > > > > > > >> > > > > > > >> I believe the IETF community has shown great wisdom and a > true > > > > > > > understanding of what is at stake here. We have now got a > > > > > solid path > > > > > > > to the > > > > > > > future, with a clear strategy to get rid of obsolete and > > > > > unsatisfactory > > > > > > > solutions allowing a gradual move of deaf, hard of > > > > > hearing and speech > > > > > > > impaired people into mainstream technology. That will of > > > > > course take > > > > > > > time > > > > > > > during which there will have to be legacy support and all the > > > > > > > instruments > > > > > > > are put in place to do exactly that. > > > > > > >> > > > > > > >> Guido > > > > > > >> > > > > > > >> Guido Gybels > > > > > > >> Director of New Technologies > > > > > > >> > > > > > > >> RNID, 19-23 Featherstone Street > > > > > > >> London EC1Y 8SL, UK > > > > > > >> Tel +44(0)20-7294 3713 > > > > > > >> Fax +44(0)20-7296 8069 > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> Sipping mailing list > > > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > > >> This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 08:32:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07782 for ; Thu, 14 Aug 2003 08:32:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHH0-0008Tz-ON for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 08:32:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ECWAPw032607 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 08:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHH0-0008Tq-7D for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 08:32:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07775 for ; Thu, 14 Aug 2003 08:32:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nHGy-0001sp-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 08:32:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nHGy-0001sm-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 08:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHGs-0008TA-OJ; Thu, 14 Aug 2003 08:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHGE-0008SZ-Oz for sipping@optimus.ietf.org; Thu, 14 Aug 2003 08:31:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07772 for ; Thu, 14 Aug 2003 08:31:19 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nHGD-0001sd-00 for sipping@ietf.org; Thu, 14 Aug 2003 08:31:21 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19nHGC-0001sa-00 for sipping@ietf.org; Thu, 14 Aug 2003 08:31:20 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7ECVH414514 for ; Thu, 14 Aug 2003 15:31:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Aug 2003 15:31:17 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 14 Aug 2003 15:31:17 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 14 Aug 2003 15:31:17 +0300 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" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [Sipping] FYI: RADIUS & SIP Date: Thu, 14 Aug 2003 15:31:16 +0300 Message-ID: Thread-Topic: AW: AW: [Sipping] FYI: RADIUS & SIP Thread-Index: AcNiUQJS1qhENC5uTsS8/oFWvCIWfwADsTWQ To: Cc: X-OriginalArrivalTime: 14 Aug 2003 12:31:17.0159 (UTC) FILETIME=[F5319B70:01C3625F] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jiri, > >Accounting over a non-reliable transport protocol is a Very Hard > >Problem. That's one of the reaons for DIAMETER. >=20 > Still less hard than accounting over a protocol which does not exist. This may be a tupid comment, but as I understand, there is no = 'standard'=20 solution for this with RADIUS, so it seems that we are in the same boat, = no matter which protocol we choose. John _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 08:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08174 for ; Thu, 14 Aug 2003 08:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHUT-0000oV-Ft for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 08:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ECk5FQ003121 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 08:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHUS-0000oG-NV for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 08:46:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08162 for ; Thu, 14 Aug 2003 08:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nHUR-0001yS-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 08:46:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nHUQ-0001yP-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 08:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHUQ-0000nD-Gk; Thu, 14 Aug 2003 08:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHTy-0000mW-Cw for sipping@optimus.ietf.org; Thu, 14 Aug 2003 08:45:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08155 for ; Thu, 14 Aug 2003 08:45:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nHTx-0001yG-00 for sipping@ietf.org; Thu, 14 Aug 2003 08:45:33 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 19nHTw-0001yD-00 for sipping@ietf.org; Thu, 14 Aug 2003 08:45:32 -0400 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ACC056A902; Thu, 14 Aug 2003 15:45:21 +0300 (EEST) Message-ID: <3F3B83C6.6040802@piuha.net> Date: Thu, 14 Aug 2003 15:42:46 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com, jiri.kuthan@fokus.fraunhofer.de Cc: sipping@ietf.org Subject: Re: AW: AW: [Sipping] FYI: RADIUS & SIP 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 > This may be a tupid comment, but as I understand, there is no 'standard' > solution for this with RADIUS, so it seems that we are in the same boat, no > matter which protocol we choose. Some RADIUS improvements can be made without deployment barriers, e.g. exponential backoff for transport. Some others require more fundamental changes to the protocols, in which case you'd have to both develop the protocol and deploy the new servers/features. In the case of Diameter, the protocol work is done, but the deployment is mostly ahead. There's one open source project, by the way, look for it at sourceforge.net if you're interested. --Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 08:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08261 for ; Thu, 14 Aug 2003 08:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHZI-00016X-UP for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 08:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ECp4Si004243 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 08:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHZI-00016M-RN for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 08:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08249 for ; Thu, 14 Aug 2003 08:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nHZH-0001zg-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 08:51:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nHZG-0001zd-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 08:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHZG-00015R-IQ; Thu, 14 Aug 2003 08:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nHYk-00014z-1h for sipping@optimus.ietf.org; Thu, 14 Aug 2003 08:50:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08227 for ; Thu, 14 Aug 2003 08:50:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nHYi-0001za-00 for sipping@ietf.org; Thu, 14 Aug 2003 08:50:28 -0400 Received: from [217.18.33.25] (helo=excsrv.capcom) by ietf-mx with esmtp (Exim 4.12) id 19nHYg-0001zL-00 for sipping@ietf.org; Thu, 14 Aug 2003 08:50:26 -0400 content-class: urn:content-classes:message Subject: RE: [Sipping] WGLC for Q.SIP-SIP mapping draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Aug 2003 14:51:22 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sipping] WGLC for Q.SIP-SIP mapping draft Thread-Index: AcNiURPmwf57UqmbQ/+hXqj8GhprFAAD0H3Q From: "Juan Luis Esteban" To: "Luis Emilio Martin" , , Cc: , Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Luis, Most T.38 GW implementations rely on D.2.2.4/T.38 procedures (Voice and = facsimile connection), where an audio session is established and = switched over to T.38 on V.21 preamble fax seq detection by the = receiving GW. This scenario is described also in = 5.2.1/draft-mule-sip-t38callflows-02. A reINVITE is issued by the = receiving GW to modify the session SDP. IMHO 5.1.2 is limited to the case where IAFs are involved in the = transmission which is also described in D.2.2.3/T.38. Universal GWs = supporting voice and fax simultaneously will most likely implement voice = to fax switchover according to D.2.2.4/T.38, which seems to be obvious. Does anyone know about SIP GWs implementing D.2.2.3 procedures ?. regards, Juan Luis Esteban Capcom- -----Mensaje original----- De: Luis Emilio Martin [mailto:lemr@tid.es] Enviado el: mi=E9rcoles, 13 de agosto de 2003 11:08 Para: thomas.stach@siemens.com; sipping@ietf.org CC: jieying.li@clarent.com; jfmule@packetizer.com Asunto: WG: [Sipping] WGLC for Q.SIP-SIP mapping draft Hello, > The QSIG SETUP message may optionally transport HLC and LLC = Information elements which are not mentioned > in the draft. You might want to add something like into section 10: > >"The gateway SHOULD (or SHALL(?)) not include a Low layer compatibility = in the QSIG SETUP message. The=20 > gateway SHOULD not include a High layer compatibility information = element in the QSIG SETUP message. > >NOTE: Inclusion of a HLC in the QSIG SETUP message might be useful, if = the gateway knows prior to=20 > sending the QSIG SETUP message that fax is being transmitted (e.g., = because of a corresponding > SDP offer), it may include in the QSIG SETUP message a High layer = compatibility information element=20 > indicating group 3 fax." It is discussed the possibility to include HLC IE in the QSIG SETUP if an INVITE was received with fax transmission information (i.e. T38 only), so that fax detection at destination does not depend on processing audio data. It possibly is a matter of configuration in the gateway. Sorry I am not very used to T.38 procedures and Fax Group 2/3 methods but we are testing some gateways with T.38 and automatic fax detection capabilities based on DSPs and experiencing some strange=20 behaviours in these gateways, so that SETUP messages including HLC produce INVITEs offering G.729 or=20 G.711 and a bit later new INVITES offering t38. In reverse direction, can a SIP gateway, upon reception of a SETUP Message with Bearer Capability 3,1 kHz Audio and an HLC indicating Fax Group 2/3, to map the HLC field into an INVITE message with an SDP offering T.38 only (not any other audio codec). The example is taken from chapter 5.1.2 http://www.watersprings.org/pub/id/draft-mule-sip-t38callflows-02.txt : Content-Type: application/sdp Content-Length: 320 v=3D0 o=3Difaxgw1 2890846527 2890846527 IN IP4 ifax.here.com s=3DSession SDP c=3DIN IP4 ifaxmg.here.com t=3D0 0 m=3Dimage 15002 udptl t38 a=3DT38FaxVersion:0 a=3DT38MaxBitRate:14400 a=3DT38FaxFillBitRemoval:0 a=3DT38FaxTranscodingMMR:0 a=3DT38FaxTranscodingJBIG:0 a=3DT38FaxRateManagement:transferredTCF It should be the most straightforward procedure to map fax but is my interpretation correct?... or the reception of a setUp with such IE values does not have enough information to=20 include an SDP offering with T.38 only, so it is required to wait for CNG/V21 detection=20 to pick all the information required, and a renegotiation is thus required after call is stablished? Thank you very much in advance Best Regards Luis Martin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 09:56:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09885 for ; Thu, 14 Aug 2003 09:56:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nIaO-0003V1-Dc for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 09:56:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EDuGq5013451 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 09:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nIaO-0003Us-5G for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 09:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09848 for ; Thu, 14 Aug 2003 09:56:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nIaM-0002Os-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 09:56:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nIaL-0002Op-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 09:56:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nIa9-0003Qw-AT; Thu, 14 Aug 2003 09:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nIZG-0003PS-8Z for sipping@optimus.ietf.org; Thu, 14 Aug 2003 09:55:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09746 for ; Thu, 14 Aug 2003 09:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nIZE-0002MC-00 for sipping@ietf.org; Thu, 14 Aug 2003 09:55:04 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19nIZD-0002LB-00 for sipping@ietf.org; Thu, 14 Aug 2003 09:55:03 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJM00CGD3P0NZ@firewall.wcom.com> for sipping@ietf.org; Thu, 14 Aug 2003 13:48:36 +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 <0HJM00H013K2W8@pmismtp02.wcomnet.com>; Thu, 14 Aug 2003 13:48:36 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.105.76]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJM00GC23NQHG@pmismtp02.wcomnet.com>; Thu, 14 Aug 2003 13:47:52 +0000 (GMT) Date: Thu, 14 Aug 2003 08:47:49 -0500 From: Alan Johnston Subject: Re: [Sipping] App-Interaction: Considering models In-reply-to: X-Sender: Alan.Johnston@pop.mcit.com To: Cullen Jennings , Adam Roach , sipping , Jonathan Rosenberg Message-id: <5.2.1.1.0.20030814084222.025c4448@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <" <9BF66EBF6BEFD942915B4D4D45C051F3E862D9"@dyn-tx-exch-001.dynamicsoft.com> 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: , One short comment below. At 10:54 PM 8/13/2003 -0700, Cullen Jennings wrote: >I think all of these proposals are significantly more complex than using a >MESSAGE/NEW_METHOD/NOTIFY. I will mention a few issues with the proposal >inline but first let me a few other proposals... > >All of these have a call flow like > > > UAC App Server UAS > > 1|-----INVITE---->| | > > 2| |-----INVITE---->| > > 3| |<-----200-------| > > 4|<-----200-------| | > > 5|---SIP MESG---->| | > > 6|<-----200-------| | > >The question for KMPL is, what method to use in msg 5. > >Proposal 1) Use MESSAGE. Many people think the semantics of message are >display this IM to a user. Perhaps, but I send IM to applications and they >send me back things like stock quotes all the time. I have no problem with >semantics of MESSAGE being deliver this message to the addressed user or >automaton. That's what we are doing here. Misrouted message will cause >trivial problems, but this is a bogus issue - misrouted INVITE or MESSAGE >will cause problems to - don't misroute things. Here's the problem I have with this. Lets say I have a dumb SIP phone that has no display but does support KPML I also have a separate SIP IM client. My proxy has very simple logic - MESSAGE requests directed at my phone get redirected to my IM client. Using MESSAGE like this breaks this very simple (and potentially useful) logic. My proxy now has to take apart the MESSAGE request and determine if it is a IM MESSAGE, or an RPC MESSAGE (or whatever we will call this new use for MESSAGE. This is the type of MESSAGE routing problems I'm concerned about. Thanks, Alan Johnston MCI >Proposal 2) Use some new method like STIMULUS. The semantics of this are >some user input stimulus is being sent - STIMULUS is to input what MESSAGE >is to output. > >Proposal 3) Use NOTIFY. Semantics are, here is some information about some >event that you requested to be informed about. The usual complaint on this >one is that there was no Subscribe, or it was implicit, or it was explicit, >or it violated some law of the SIP world. I think there was a subscribe, it >was in the message that initiated the script. There is also a clear time it >will end - when the script is terminated or when the dialog of the message >that initiated the script ends. We all remember that implicit subscribes >where bad (whatever an implicit subscribe is) but people seem to have a hard >time remembering why this will be bad here. > >All 3 of these proposals have something in common - there is no concrete >argument that any of them would not work. They send to a URI the AS provided >so there are no forking issues. There is some grief on the semantics. Option >2 has the advantage of it lets us define the semantics however we want. I >think that 2 is the best way to go but I don't care greatly. I do need >convincing on what's wrong with these to move to something more complex. > >More comments inline > >On 8/13/03 3:32 PM, "Adam Roach" wrote: > > > After considering Jonathan's contention that defining > > a new method for conveying stimulus is creating something > > that is similar in meaning to NOTIFY, I'm inclined to > > agree to some point. There are still subtle differences > > in meaning, so I'm not completely convinced that a new > > method is wrong, but I understand the point he's trying > > to make. > > > > After discussing it privately with others, I've concluded > > that there are three viable models worth considering. There > > are, of course, some minor variations that can be made to > > each. > > > > 1) Standard HTTP Handling > > > > UAC App Server UAS > > 1|-----INVITE---->| | > > 2| |-----INVITE---->| > > 3| |<-----200-------| > > 4|<-----200-------| | AS adds HTTP URL to 200 > > 5|---HTTP GET---->| | UAC requests KPML script > > 6|<-----200-------| | AS replies with script > > 7|---HTTP POST--->| | UAC provides digits > > 8|<-----200-------| | AS acknowledges digits > > > > Of the three options presented here, I see this as the best > > solution. Basically, the app server includes an HTTP URL > > in the 200 response to the INVITE that it has proxied. The > > UAC then does a GET on the KPML script. Just like with > > HTML forms, the UAC does whatever local stuff is necessary > > to "fill out the form" (in this case, collect digits), and > > then posts the result back to the App Server. This is all > > plain-Jane unextended HTTP as it was intended to work. > > > >One of the difficult parts of this is security. > >This will get more complicated once you provide a way to send in message 4 >the credentials that will allow 7. It may also make the App-Info header only >really work with scripts that use HTTP to post instead of other things. >Also, in the case of a financial institutions that have to log electronic >communications, you will need to provide way to insert logging HTTP proxies >and probably proxies for FW traversal too. Of course the AS or the UAC will >need to figure out the network topology to know if the AS is inside or >outside the FW. It's possible to configure all the domain and HTTP proxies >rules into the device but it still hard to secure - particularly on devices >that don't want to implement HTTPS due to not much memory. > > > > 2) Explicit Subscriptions (with GRUU) > > > > UAC App Server UAS > > 1|-----INVITE---->| | > > 2| |-----INVITE---->| AS extracts GRUU from INVITE > > 3| |<-----200-------| > > 4|<-----200-------| | > > 5|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script > > 6|------200------>| | > > 7|-----NOTIFY---->| | > > 8|<-----200-------| | > > 9|-----NOTIFY---->| | UAC provides digits > > A|<-----200-------| | AS acknowledges digits > > > > My second choice would be an explicit subscription to stimulus > > events. The only sticky part in this solution is the question > > of how the AS can route a SUBSCRIBE to the UAC. Once we have > > a GRUU solution in place, this is a no brainer: the AS can > > extract the GRUU from the INVITE, and use it as the target > > of its SUBSCRIBE. The KPML script is included in the SUBSCRIBE, > > and essentially serves as a filter. > > > >I sort of see this one, but what if the App Server wanted to run an App on >the UAS instead of the UAC. Would the 180 have the GRU? Would it be >reliable? > >I seem to recall someone asking about the expire time on the subscription >:-) > >I'd be keener on GRUU solutions if GRUU was a solved problem. > > > 3) Explicit Subscriptions (with REFER) > > > > UAC App Server UAS > > 1|-----INVITE---->| | > > 2| |-----INVITE---->| > > 3| |<-----200-------| > > 4|<-----200-------| | AS adds SIP URL to 200 > > 5|-----REFER----->| | > > 6|<-----200-------| | > > 7|<----NOTIFY-----| | > > 8|------481------>| | > > 9|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script > > A|------200------>| | > > B|-----NOTIFY---->| | > > C|<-----200-------| | > > D|-----NOTIFY---->| | UAC provides digits > > E|<-----200-------| | AS acknowledges digits > > > > Although somewhat chattier than the previous solution, this gets around > > the GRUU issue by having the AS provide a SIP URI that routes to itself > > in the 200 response. The UAC then uses this URI to send a REFER to the > > AS. This REFER tells the AS to SUBSCRIBE to the UAC. The flow from that > > point forward is the same as for solution 2. > > > >I got to admit, I had never considered anything like this. I think it is >going to be hard to convince folks this is really easier and better than >sending DTMF over INFO. Keep in mind that KPML is for little device that >think 14k of memory is a lot. Real devices are just going to do VXML and >HTML and ignore KPML. > >Cullen > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 11:59:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16161 for ; Thu, 14 Aug 2003 11:59:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKVH-0001ef-Ef for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 11:59:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EFx7JG006355 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 11:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKVH-0001eQ-8W for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 11:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16147 for ; Thu, 14 Aug 2003 11:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKVG-0003i1-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 11:59:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nKVF-0003hy-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 11:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKVC-0001dQ-6G; Thu, 14 Aug 2003 11:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKUZ-0001af-84 for sipping@optimus.ietf.org; Thu, 14 Aug 2003 11:58:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16139 for ; Thu, 14 Aug 2003 11:58:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKUY-0003hu-00 for sipping@ietf.org; Thu, 14 Aug 2003 11:58:22 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nKUW-0003hk-00 for sipping@ietf.org; Thu, 14 Aug 2003 11:58:20 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2003 08:57:50 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7EFvkuI006094; Thu, 14 Aug 2003 08:57:48 -0700 (PDT) Received: from [128.107.170.114] ([128.107.170.114]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHC19938; Thu, 14 Aug 2003 08:57:45 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 14 Aug 2003 08:57:45 -0700 Subject: Re: [Sipping] App-Interaction: Considering models From: Cullen Jennings To: Alan Johnston , sipping CC: Adam Roach , Jonathan Rosenberg Message-ID: In-Reply-To: <5.2.1.1.0.20030814084222.025c4448@pop.mcit.com> 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 Ah, this is worth discussing - I don't think it is a problem. The proposal is to use MESSAGE not as the way to initiate the script on the UA but as the way for the UA to tell the App Server the results of the script. Lets say the AOR of the UAC was alice@atlanta, UAS was bob@bilboxi. The KPML script would contain the address of the app server. So say the script had bobs-apps@server1.example.com, the URI of message with the KPML result from the UA to the appserver would be sip:bobs-apps@server1.example.com. The proxy would just route normally to server1 and would not need to know anything special. A MESSAGE address to bob or alice would go to them. Cullen On 8/14/03 6:47 AM, "Alan Johnston" wrote: > One short comment below. > > At 10:54 PM 8/13/2003 -0700, Cullen Jennings wrote: > >> I think all of these proposals are significantly more complex than using a >> MESSAGE/NEW_METHOD/NOTIFY. I will mention a few issues with the proposal >> inline but first let me a few other proposals... >> >> All of these have a call flow like >> >>> UAC App Server UAS >>> 1|-----INVITE---->| | >>> 2| |-----INVITE---->| >>> 3| |<-----200-------| >>> 4|<-----200-------| | >>> 5|---SIP MESG---->| | >>> 6|<-----200-------| | >> >> The question for KMPL is, what method to use in msg 5. >> >> Proposal 1) Use MESSAGE. Many people think the semantics of message are >> display this IM to a user. Perhaps, but I send IM to applications and they >> send me back things like stock quotes all the time. I have no problem with >> semantics of MESSAGE being deliver this message to the addressed user or >> automaton. That's what we are doing here. Misrouted message will cause >> trivial problems, but this is a bogus issue - misrouted INVITE or MESSAGE >> will cause problems to - don't misroute things. > > Here's the problem I have with this. Lets say I have a dumb SIP phone that > has no display but does support KPML > I also have a separate SIP IM client. My proxy has very simple logic - > MESSAGE requests directed at my phone get redirected to my > IM client. Using MESSAGE like this breaks this very simple (and > potentially useful) logic. My proxy now has to take apart > the MESSAGE request and determine if it is a IM MESSAGE, or an RPC MESSAGE > (or whatever we will call this new use > for MESSAGE. > > This is the type of MESSAGE routing problems I'm concerned about. > > Thanks, > Alan Johnston > MCI > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 13:28:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18948 for ; Thu, 14 Aug 2003 13:28:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLtV-0006ba-LV for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 13:28:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EHSDQV025384 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 13:28:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLtV-0006bL-GM for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 13:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18924 for ; Thu, 14 Aug 2003 13:28:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nLtT-0004Rp-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 13:28:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nLtS-0004Rm-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 13:28:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLtJ-0006aO-8b; Thu, 14 Aug 2003 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLss-0006a8-Uc for sipping@optimus.ietf.org; Thu, 14 Aug 2003 13:27:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18919 for ; Thu, 14 Aug 2003 13:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nLsq-0004Ri-00 for sipping@ietf.org; Thu, 14 Aug 2003 13:27:32 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19nLsq-0004Rb-00 for sipping@ietf.org; Thu, 14 Aug 2003 13:27:32 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EHQrRe013705; Thu, 14 Aug 2003 13:26:53 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 12:26:54 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862E3@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach , sipping , Jonathan Rosenberg Subject: RE: [Sipping] App-Interaction: Considering models Date: Thu, 14 Aug 2003 12:26:46 -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: , Cullen Jennings [mailto:fluffy@cisco.com] writes: > I seem to recall someone asking about the expire time on the > subscription You appear to have misinterpreted what I said in the same way as Jonathan did. The issue I was attempting to raise is that subscriptions, as defined in 3265, always have a well-defined number of seconds before they expire. This amount of time can be expressed using an integer. If you start defining this period of time to be "until some other event happens, and we don't know when that will occur", you have to significantly modify RFC 3265 behavior. So, for the two SUBSCRIBE solutions I describe, the subscription would initially be for some arbitrary period of time (say, two hours). If the need for interaction lasts longer than that, you refresh. If the interaction is shorter, you unsubscribe. /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 exim@www1.ietf.org Thu Aug 14 13:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19080 for ; Thu, 14 Aug 2003 13:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLxE-0006so-4q for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 13:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EHW4A5026408 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 13:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLxD-0006rr-Vg for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 13:32:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19057 for ; Thu, 14 Aug 2003 13:32:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nLxB-0004UW-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 13:32:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nLxB-0004UT-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 13:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLxB-0006qw-Um; Thu, 14 Aug 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLwx-0006qg-Md for sipping@optimus.ietf.org; Thu, 14 Aug 2003 13:31:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19050 for ; Thu, 14 Aug 2003 13:31:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nLwv-0004UQ-00 for sipping@ietf.org; Thu, 14 Aug 2003 13:31:45 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19nLwu-0004UA-00 for sipping@ietf.org; Thu, 14 Aug 2003 13:31:44 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EHV3Re013715; Thu, 14 Aug 2003 13:31:03 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 12:31:04 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862E4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach , sipping , Jonathan Rosenberg Subject: RE: [Sipping] App-Interaction: Considering models Date: Thu, 14 Aug 2003 12:30:57 -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: , Cullen Jennings [mailto:fluffy@cisco.com] writes: > > 1) Standard HTTP Handling > > > > UAC App Server UAS > > 1|-----INVITE---->| | > > 2| |-----INVITE---->| > > 3| |<-----200-------| > > 4|<-----200-------| | AS adds HTTP URL to 200 > > 5|---HTTP GET---->| | UAC requests KPML script > > 6|<-----200-------| | AS replies with script > > 7|---HTTP POST--->| | UAC provides digits > > 8|<-----200-------| | AS acknowledges digits > > > > One of the difficult parts of this is security. > > This will get more complicated once you provide a way to send > in message 4 > the credentials that will allow 7. Red herring. The exact same issue applies to any of the cases you describe. In other words, for the following call flow, you need to get the UAC credentials for step 5: > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| > 3| |<-----200-------| > 4|<-----200-------| | > 5|---SIP MESG---->| | > 6|<-----200-------| | /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 exim@www1.ietf.org Thu Aug 14 13:34:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19200 for ; Thu, 14 Aug 2003 13:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLzA-0007A1-WC for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 13:34:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EHY4BO027519 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 13:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLzA-00079m-Rg for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 13:34:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19180 for ; Thu, 14 Aug 2003 13:34:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nLz8-0004Wf-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 13:34:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nLz8-0004Wc-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 13:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLz7-00074d-0u; Thu, 14 Aug 2003 13:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nLz0-00074A-Du for sipping@optimus.ietf.org; Thu, 14 Aug 2003 13:33:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19177 for ; Thu, 14 Aug 2003 13:33:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nLyy-0004WZ-00 for sipping@ietf.org; Thu, 14 Aug 2003 13:33:52 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19nLyx-0004WG-00 for sipping@ietf.org; Thu, 14 Aug 2003 13:33:51 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EHXERe013726; Thu, 14 Aug 2003 13:33:14 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 12:33:14 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862E5@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach , sipping , Jonathan Rosenberg Subject: RE: [Sipping] App-Interaction: Considering models Date: Thu, 14 Aug 2003 12:33: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: , Cullen Jennings writes: > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| > 3| |<-----200-------| > 4|<-----200-------| | > 5|---SIP MESG---->| | > 6|<-----200-------| | Are you proposing that the App Server would send the KPML script in the INVITE 200? Where? In the body? In an egregiously large header? /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 exim@www1.ietf.org Thu Aug 14 15:30:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23976 for ; Thu, 14 Aug 2003 15:30:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nNnY-00040M-IU for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 15:30:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EJUCXE015392 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 15:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nNnY-00040B-Ac for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 15:30:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23970 for ; Thu, 14 Aug 2003 15:30:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nNnW-0005LA-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 15:30:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nNnW-0005L7-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 15:30:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nNnO-0003x5-7r; Thu, 14 Aug 2003 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nNmr-0003wU-EJ for sipping@optimus.ietf.org; Thu, 14 Aug 2003 15:29:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23960 for ; Thu, 14 Aug 2003 15:29:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nNmq-0005Kz-00 for sipping@ietf.org; Thu, 14 Aug 2003 15:29:28 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nNmp-0005KR-00 for sipping@ietf.org; Thu, 14 Aug 2003 15:29:27 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 14 Aug 2003 12:35:37 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7EJStuG020360; Thu, 14 Aug 2003 12:28:56 -0700 (PDT) Received: from [128.107.170.114] ([128.107.170.114]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHC47843; Thu, 14 Aug 2003 12:28:54 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 14 Aug 2003 12:28:53 -0700 Subject: Re: [Sipping] App-Interaction: Considering models From: Cullen Jennings To: Adam Roach , sipping , Jonathan Rosenberg Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862E3@dyn-tx-exch-001.dynamicsoft.com> 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 On 8/14/03 10:26 AM, "Adam Roach" wrote: > Cullen Jennings [mailto:fluffy@cisco.com] writes: > >> I seem to recall someone asking about the expire time on the >> subscription > > You appear to have misinterpreted what I said in the same > way as Jonathan did. > > The issue I was attempting to raise is that subscriptions, > as defined in 3265, always have a well-defined number of > seconds before they expire. This amount of time can be > expressed using an integer. If you start defining this > period of time to be "until some other event happens, > and we don't know when that will occur", you have to > significantly modify RFC 3265 behavior. > > So, for the two SUBSCRIBE solutions I describe, the > subscription would initially be for some arbitrary period > of time (say, two hours). If the need for interaction > lasts longer than that, you refresh. If the interaction > is shorter, you unsubscribe. > > /a > > I had wondered about how to solve this - I think putting in a really large number is more or less what people had imagined. If you were running a session timer on the original dialog that time might be usable. If you sent a notify with 100 minutes, then 20 minutes later sent a new notify with 100 minutes (and there had been no subscribe in the meantime) would that violate 3265? What does the implicit subscribe in refer do? Anyways, I'm not really arguing for NOTIFY but this is one of the issues we need to figure out to use it. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 16:10:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25346 for ; Thu, 14 Aug 2003 16:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOQA-0006IL-IZ for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 16:10:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EKA67p024182 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 16:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOQA-0006Hm-DO for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 16:10:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25308 for ; Thu, 14 Aug 2003 16:10:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nOQ8-0005da-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 16:10:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nOQ8-0005dX-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 16:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOQ6-0006Fk-B2; Thu, 14 Aug 2003 16:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOPh-0006El-Vi for sipping@optimus.ietf.org; Thu, 14 Aug 2003 16:09:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25291 for ; Thu, 14 Aug 2003 16:09:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nOPg-0005dN-00 for sipping@ietf.org; Thu, 14 Aug 2003 16:09:36 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19nOPf-0005dF-00 for sipping@ietf.org; Thu, 14 Aug 2003 16:09:35 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EK8vRe014060; Thu, 14 Aug 2003 16:08:57 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 15:08:58 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862E8@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach , sipping , Jonathan Rosenberg Subject: RE: [Sipping] App-Interaction: Considering models Date: Thu, 14 Aug 2003 15:08:50 -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: , Cullen Jennings writes: > What does the implicit subscribe in refer do? To prevent expiration, it sends explicit SUBSCRIBE messages to refresh the subscription. /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 exim@www1.ietf.org Thu Aug 14 19:13:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01237 for ; Thu, 14 Aug 2003 19:13:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nRHG-0005Ls-VJ for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 19:13:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7END6S6020568 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 19:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nRHG-0005Lf-Rk for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 19:13:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01215 for ; Thu, 14 Aug 2003 19:13:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nRHF-0006pA-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 19:13:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nRHE-0006p6-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 19:13:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nRH9-0005Kz-Ot; Thu, 14 Aug 2003 19:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nRH0-0005Jm-Hn for sipping@optimus.ietf.org; Thu, 14 Aug 2003 19:12:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01209 for ; Thu, 14 Aug 2003 19:12:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nRGz-0006p1-00 for sipping@ietf.org; Thu, 14 Aug 2003 19:12:49 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19nRGy-0006oo-00 for sipping@ietf.org; Thu, 14 Aug 2003 19:12:48 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7ENBgRe014416; Thu, 14 Aug 2003 19:11:42 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 18:11:42 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862EF@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach , sipping , Jonathan Rosenberg Subject: RE: [Sipping] App-Interaction: Considering models Date: Thu, 14 Aug 2003 18:11:33 -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: , Cullen Jennings [mailto:fluffy@cisco.com] writes: > Proposal 3) Use NOTIFY. Semantics are, here is some > information about some event that you requested to > be informed about. The usual complaint on this one > is that there was no Subscribe, or it was implicit, > or it was explicit, or it violated some law of the > SIP world. I think there was a subscribe, it was in > the message that initiated the script. There is also > a clear time it will end - when the script is terminated > or when the dialog of the message that initiated the > script ends. We all remember that implicit subscribes > where bad (whatever an implicit subscribe is) but people > seem to have a hard time remembering why this will be > bad here. It's not simple dogma; there are real problems here. I've cited a few of them (and, as I point out in another message, Jonathan's rebuttal is somewhat lacking in the area of duration; also, I still plan to respond on the correlation issue, because I think his rebuttal glosses over the details). Can these problems be fixed? Probably. REFER provides an existence proof that implicit subscriptions[1] can be made to work with enough crafting. After it's said and done, do we regret choosing that path? I do. Robert does. Do we want to learn from our mistakes? Your phrasing above knocked loose in my mind another reason that implicit subscriptions[1] are ill-advised: you are using a single transaction to perform two operations. Conveying partial success (e.g. the call completed, but the subscription failed) is problematic. We have made efforts to avoid this type of situation in the past. /a [1] To be clear, I mean "subscriptions put in place via some other mechanism than that described in RFC 3265." _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 14 19:21:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01400 for ; Thu, 14 Aug 2003 19:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nROx-0005ZT-FL for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 19:21:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ENL3Mi021409 for sipping-archive@odin.ietf.org; Thu, 14 Aug 2003 19:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nROx-0005ZE-C3 for sipping-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 19:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01395 for ; Thu, 14 Aug 2003 19:20:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nROv-0006sG-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 19:21:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nROv-0006sD-00 for sipping-web-archive@ietf.org; Thu, 14 Aug 2003 19:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nROv-0005YY-Ci; Thu, 14 Aug 2003 19:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nROV-0005YA-1G for sipping@optimus.ietf.org; Thu, 14 Aug 2003 19:20:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01391 for ; Thu, 14 Aug 2003 19:20:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nROT-0006s7-00 for sipping@ietf.org; Thu, 14 Aug 2003 19:20:33 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19nROS-0006rd-00 for sipping@ietf.org; Thu, 14 Aug 2003 19:20:32 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7ENJMRe014432; Thu, 14 Aug 2003 19:19:43 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 18:19:23 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862F0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'Tim Melanchuk'" , Cullen Jennings , sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Thu, 14 Aug 2003 18:19: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: , Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > Correlation is easy. The KPML script IS the subscription. The > place to send the notify is implied from the URI in the KPML > script. We would need to clarify in KPML that once that URI is > used, subsequent notificatiosn to the same URI ought to go on > the dialog established by the NOTIFY. But, this is a KPML issue. I mean dialog correlation. Let's say you're an app server. Client A sends an INVITE through you. You add something to the 200 response that ultimately results in Client A getting the following KPML script: Client A sends another INVITE through you. You add something to the 200 response that ultimately results in Client A getting the following KPML script: Finally, you get a NOTIFY request from the user. How do you know to which session it pertains? /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 exim@www1.ietf.org Fri Aug 15 04:47:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21901 for ; Fri, 15 Aug 2003 04:47:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19naEs-0000Iu-5r for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 04:47:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7F8lEcu001169 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 04:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19naEr-0000Im-Uq for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 04:47:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21881 for ; Fri, 15 Aug 2003 04:47:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19naEo-0001D5-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 04:47:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19naEo-0001D2-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 04:47:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19naEf-0000HM-Vn; Fri, 15 Aug 2003 04:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19naEW-0000Gh-3x for sipping@optimus.ietf.org; Fri, 15 Aug 2003 04:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21863 for ; Fri, 15 Aug 2003 04:46:47 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19naET-0001CV-00 for sipping@ietf.org; Fri, 15 Aug 2003 04:46:49 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19naES-0001CS-00 for sipping@ietf.org; Fri, 15 Aug 2003 04:46:48 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7F8kl402768 for ; Fri, 15 Aug 2003 11:46:48 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Aug 2003 11:46:47 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 15 Aug 2003 11:46:46 +0300 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] App-Interaction: Considering models Date: Fri, 15 Aug 2003 11:46:45 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796FB0@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] App-Interaction: Considering models Thread-Index: AcNjAGk/UQ/QfAMtRLWT9Zu9nwPmDQACGLtg To: , , , X-OriginalArrivalTime: 15 Aug 2003 08:46:46.0125 (UTC) FILETIME=[C23EB1D0:01C36309] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable I tend to strongly agree with Adam; unless we plan to write an RFC that = contains the top 10 tests for implicit subscriptions, we need to forbid = it. I personally don't see any problem with sending a SUBSCRIBE explicitly. = An extra round trip delay, so what? My other favourite is a new method similar to NOTIFY, like REPORT. We = have done this in the past were a method semantics are not quite right = for one thing and we create a new method. Take for example REGISTER and = PUBLISH. Regards, Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Friday, August 15, 2003 2:12 AM > To: 'Cullen Jennings'; Adam Roach; sipping; Jonathan Rosenberg > Subject: RE: [Sipping] App-Interaction: Considering models >=20 >=20 > Cullen Jennings [mailto:fluffy@cisco.com] writes: >=20 > > Proposal 3) Use NOTIFY. Semantics are, here is some=20 > > information about some event that you requested to > > be informed about. The usual complaint on this one > > is that there was no Subscribe, or it was implicit, > > or it was explicit, or it violated some law of the > > SIP world. I think there was a subscribe, it was in > > the message that initiated the script. There is also > > a clear time it will end - when the script is terminated > > or when the dialog of the message that initiated the > > script ends. We all remember that implicit subscribes > > where bad (whatever an implicit subscribe is) but people > > seem to have a hard time remembering why this will be > > bad here. >=20 > It's not simple dogma; there are real problems here. I've > cited a few of them (and, as I point out in another message, > Jonathan's rebuttal is somewhat lacking in the area of > duration; also, I still plan to respond on the correlation > issue, because I think his rebuttal glosses over the > details). >=20 > Can these problems be fixed? Probably. REFER provides an > existence proof that implicit subscriptions[1] can be made > to work with enough crafting. After it's said and done, > do we regret choosing that path? I do. Robert does. Do we > want to learn from our mistakes? >=20 > Your phrasing above knocked loose in my mind another reason > that implicit subscriptions[1] are ill-advised: you are using > a single transaction to perform two operations. Conveying > partial success (e.g. the call completed, but the subscription > failed) is problematic. We have made efforts to avoid this > type of situation in the past. >=20 > /a >=20 > [1] To be clear, I mean "subscriptions put in place via some > other mechanism than that described in RFC 3265." >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 15 10:07:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27935 for ; Fri, 15 Aug 2003 10:07:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfEW-0004CR-ST for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 10:07:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FE7Cin016139 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 10:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfEW-0004CE-OS for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 10:07:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27879 for ; Fri, 15 Aug 2003 10:07:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nfEU-0002jx-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 10:07:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nfET-0002ju-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 10:07:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfEL-00047U-My; Fri, 15 Aug 2003 10:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nfDZ-00046A-Q4 for sipping@optimus.ietf.org; Fri, 15 Aug 2003 10:06:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27791 for ; Fri, 15 Aug 2003 10:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nfDX-0002jq-00 for sipping@ietf.org; Fri, 15 Aug 2003 10:06:11 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19nfDW-0002jm-00 for sipping@ietf.org; Fri, 15 Aug 2003 10:06:10 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7FE5NUg000521; Fri, 15 Aug 2003 10:05:26 -0400 (EDT) Message-ID: <3F3CD7E6.9020102@dynamicsoft.com> Date: Fri, 15 Aug 2003 08:53:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: Comment on GRUU requirements References: <7BDAC0E8-CDD7-11D7-91B8-0003938AF740@cisco.com> In-Reply-To: <7BDAC0E8-CDD7-11D7-91B8-0003938AF740@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 inline. Rohan Mahy wrote: > > On Wednesday, August 13, 2003, at 10:55 AM, Adam Roach wrote: > >> Rohan Mahy [mailto:rohan@cisco.com] writes: >> >>> Most of the SIP phones I see at SIPit support >>> completing a transfer using a REFER with a >>> Replaces header embedded in the Refer-To. >>> The Refer-To URI is always set to the Contact >>> URI of the appropriate UA. >> >> >> And this will continue to work as well as it does today. >> Newer, GRUU aware clients will simply exhibit an additional >> robustness. >> >> It seems a bit misguided to do things in a suboptimal way >> just to try to fix currently deployed clients. > > > and Jonathan wrote: > >>>> I don't think we have so much of either of these deployed that this >>>> cannot change. >>> >>> I disagree. Most of the SIP phones I see at SIPit support completing >>> a transfer using a REFER with a Replaces header embedded in the >>> Refer-To. The Refer-To URI is always set to the Contact URI of the >>> appropriate UA. >> >> >> Well, we have here the standard problem here of having implementations >> of long-running drafts, and then deciding down the road that something >> needs to change. >> >> I think we want a non-GRUU in the Contact header (to avoid spirals >> through proxies, and needless load when the proxy doesnt intend to >> record-route), but we want a GRUU for attended-transfer. I would >> propose to use a separate header to identify GRUUs. Existing phones >> will work as they currently do, and when two phones both support GRUU, >> you get more reliable service. I recognize that putting the GRUU in >> the contact would mean only one of the phones needs to support it >> (clearly better), but the cost of this is a long-term situation that >> we don't want. >> >> -Jonathan R. > > > Hi, > > I think both of you are ignoring the "generality before efficiency" > principle. I don't think that is the tradeoff here. Given a clean slate, it is clear that a new header would be used. The argument for contact header is just to facilitate introduction of GRUU. Thus, its more of the "backwards compatible vs. right thing" kind of debate. > Putting the GRUU in the Contact header always works, and in > most deployments where it is needed (middlebox traversal), you WILL need > to travel through the same set of proxies for nearly every request > anyhow. With the increased deployment of TLS and SIPS we will > increasingly have dialogs for which all or none of the requests are > proxied. A few responses here. Firstly, your comments above would seem to imply that a UA wouldn't always put the GRUU in the Contact header - that it would do so only in situations where it was needed. The problem is, the UA can't know when its needed. It would be needed if someone else wants to transfer a call to it, or subscribe to its dialog package. Since the UA can't know that ahead of time, for it to work, we need to specify that all UAs should always use GRUUs all the time. If the GRUU is placed in the Contact header, this would mean the end of e2e sip signaling, PERIOD. Even if you assume a proxy needs to be on the path, a proxy then is faced with an impossible decision. When it receives a request, does the proxy need to record route (if the downstream UA is using a GRUU) or not (if it isn't). It doesn't know what the downstream UA can do at this point. So, it can't make a correct decision. Existing proxies wouldn't even know about this decision. The result would be that, where proxies record-route and the downstream UA uses a GRUU, requests will spiral or take extra hops on every call. This results in decreased overall performance in the network and increased call setup times. > > We are talking about interop with thousands of UAs which have > implemented Proposed Standard level RFCs (SIP and Refer) and an > long-lived, stable I-D that has completed WGLC and was submitted to the > IESG (Replaces)`. We are not talking about random drafts that very few > have implemented. These drafts are standardized, yes, but their usage for assisted call transfer (which is what we are talking about here) has clearly been changing and is still an I-D. Nothing in the specs you mention tells people to extract the Refer-To URI from the Contact header of the peer. > To be convinced that it is worth adding a new GRUU > header, I would at least like to see some plausible use cases that are > common enough for us to be worrying about. Maybe the right way to look > at this is to put the GRUU in the Contact, UNLESS you can tell that your > peer understands the special significance of GRUUs. Hopefully my explanation above describes the problems with putting GRUU in contacts. Even if you knew that all of your peers supported Contact headers, putting one in would have the problems described above. IMHO, the GRUU is a lot like the Reply-To URI. Its a URI that provides an additional means of communication in the future, outside of the current dialog. Just as the Reply-To URI is indicated with a header, so to is the GRUU indicated with a header. > > Also, where this extension is most needed, you need the right 2 out of 3 > to support the extension. (This isn't just any two of three. If Bob > supports the GRUU extension, but Carol does not, Alice still cannot > cause a transfer to occur in the appropriate direction.) > > Starting with the classic Alice, Bob, and Carol actors. > > Alice and Bob have an existing dialog. > Alice and Carol have an existing dialog. > Alice wants Bob to talk to Carol, and will REFER Bob to INVITE Carol > replacing the dialog between Alice and Carol. > > Carol needs a GRUU; if the GRUU is conveyed in a separate header Alice > and Carol both need to support the GRUU extension for the Refer-To > header to be set properly. Yes, I agree with this. I agree its not optimal. With what I am proposing, things will work as well as they do today, no worse, no better, if Alice and Bob don't support GRUUs. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Fri Aug 15 11:18:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00372 for ; Fri, 15 Aug 2003 11:18:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngLA-0007Uj-RF for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FFI8tT028805 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngLA-0007UV-Ni for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 11:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00362 for ; Fri, 15 Aug 2003 11:18:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngL8-00038B-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:18:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ngL7-000388-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngL3-0007R7-8j; Fri, 15 Aug 2003 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngKJ-0007Pm-1f for sipping@optimus.ietf.org; Fri, 15 Aug 2003 11:17:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00353 for ; Fri, 15 Aug 2003 11:17:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngKI-00037y-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:17:14 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngKH-00037W-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:17:13 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJO00L0D25BH0@firewall.wcom.com> for sipping@ietf.org; Fri, 15 Aug 2003 15:10: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 <0HJO00E012531Z@pmismtp02.wcomnet.com>; Fri, 15 Aug 2003 15:10:23 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.152.24]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJO00DAR258I1@pmismtp02.wcomnet.com>; Fri, 15 Aug 2003 15:10:22 +0000 (GMT) Date: Fri, 15 Aug 2003 10:10:10 -0500 From: Alan Johnston Subject: Re: [Sipping] Re: Comment on GRUU requirements In-reply-to: <3F3A7C53.20008@dynamicsoft.com> X-Sender: Alan.Johnston@pop.mcit.com To: Jonathan Rosenberg , Rohan Mahy Cc: Adam Roach , "'sipping@ietf.org'" Message-id: <5.2.1.1.0.20030814090258.02627e80@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: 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: , At 01:58 PM 8/13/2003 -0400, Jonathan Rosenberg wrote: >Rohan Mahy wrote: > > >>>I don't think we have so much of either of these deployed that this >>>cannot change. >> >>I disagree. Most of the SIP phones I see at SIPit support completing a >>transfer using a REFER with a Replaces header embedded in the >>Refer-To. The Refer-To URI is always set to the Contact URI of the >>appropriate UA. > >Well, we have here the standard problem here of having implementations of >long-running drafts, and then deciding down the road that something needs >to change. > >I think we want a non-GRUU in the Contact header (to avoid spirals through >proxies, and needless load when the proxy doesnt intend to record-route), I think you are making an assumption that every GRUU must route through a proxy. Why is that? I have argued all along that most UAs already have a GRUU - it is their Contact URI. Only in cases where a NAT/Firewall or some proxy screening logic is in the way does a GRUU need to route through a proxy. Also, I don't think spirals are an issue since when the proxy first receives the GRUU, recognizes it as its own and perform the algorithm to extract the Contact, then send it there. As for needless load, if the proxy doesn't record route then it obviously doesn't need to be there in the GRUU - the Contact must work just fine in reaching the UA or the existing dialog is broken. Thanks, Alan Johnston MCI > but we want a GRUU for attended-transfer. I would propose to use a > separate header to identify GRUUs. Existing phones will work as they > currently do, and when two phones both support GRUU, you get more > reliable service. I recognize that putting the GRUU in the contact would > mean only one of the phones needs to support it (clearly better), but the > cost of this is a long-term situation that we don't want. > >-Jonathan R. > > > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >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 exim@www1.ietf.org Fri Aug 15 11:40:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00898 for ; Fri, 15 Aug 2003 11:40:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nggP-0000H3-4a for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:40:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FFe5Be001039 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nggO-0000Gf-UN for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 11:40:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00895 for ; Fri, 15 Aug 2003 11:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nggN-0003G5-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:40:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nggN-0003G2-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nggM-0000Fa-FO; Fri, 15 Aug 2003 11:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngfS-0000EZ-4C for sipping@optimus.ietf.org; Fri, 15 Aug 2003 11:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00854 for ; Fri, 15 Aug 2003 11:39:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngfR-0003Fh-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:39:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ngfQ-0003FR-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:39:04 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7FFcKUg001076; Fri, 15 Aug 2003 11:38:21 -0400 (EDT) Message-ID: <3F3CFE6A.3090007@dynamicsoft.com> Date: Fri, 15 Aug 2003 11:38:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Tim Melanchuk'" , Cullen Jennings , sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? References: <9BF66EBF6BEFD942915B4D4D45C051F3E862D7@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862D7@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 Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > > Also note that this is NOT an implicit subscription. > > It is quite explicit. Its just not done with SUBSCRIBE. > > You can't define the problem away by twisting commonly accepted > terms in random directions. "Implicit Subscription" is the term > that we, as a community, have historically used to mean "a > subscription created by any means other than a SIP subscribe > request, as described in RFC 3265." It's just shorter to say > "implicit subscription." My point was that the problem with "implicit" was that a lot of the information in a normal subscribe was not present, and a lot of the things you can do with a normal subscribe (like refresh) were not possible. Many of those problems go away when we have a mechanism like the app-info header and kpml, where we can get similar functionality. I'd welcome your thoughts on my responses to the specific issues you raised. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Fri Aug 15 11:45:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01096 for ; Fri, 15 Aug 2003 11:45:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nglD-0000jI-AJ for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:45:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FFj38Y002798 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nglD-0000j3-65 for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 11:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01037 for ; Fri, 15 Aug 2003 11:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nglC-0003JS-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:45:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nglB-0003JP-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nglB-0000hM-Jd; Fri, 15 Aug 2003 11:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngkH-0000XG-TM for sipping@optimus.ietf.org; Fri, 15 Aug 2003 11:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01020 for ; Fri, 15 Aug 2003 11:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngkG-0003Is-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:44:04 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ngkG-0003IL-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:44:04 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7FFhOUg001079; Fri, 15 Aug 2003 11:43:24 -0400 (EDT) Message-ID: <3F3CFF9A.6030709@dynamicsoft.com> Date: Fri, 15 Aug 2003 11:43:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Tim Melanchuk'" , Cullen Jennings , sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? References: <9BF66EBF6BEFD942915B4D4D45C051F3E862D8@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862D8@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 Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > > The duration is exactly equal to the length of the validity of the > > KPML script. That lifetime is defined in the framework. It terminates > > when the dialog terminates. Otherwise, the application can > > "unsubscribe" by pushing a new App-Info header w/o a KPML script for > > that instance (Tim had asked how this is done - see my answer in a > > reply to his note). > > You missed my point. I'll try to make it more obvious. > Below, I've placed an example NOTIFY message. Find the > "XXXXX" in it, and change it so that it makes syntactic > and semantic sense. The situation is identical to the normal subscription (i.e., explicit with a SUBSCRIBE) case where you don't really want to refresh at all, since the resource has a natural termination tiem which is relatively short. In such a case, the SUBSCRIBE would basically have a very long subscription duration, as does the NOTIFY in response, and when the subscription termiantes a NOTIFY is sent with a state of termianted and a reason of noresource. So, the same here. The KPML/App-Info imply no refreshes, so a long duration. Thus the NOTIFY has something long - say a week - as the duration. That would be XXXX=604800. When the dialog expires the UA would send a NOTIFY with xxxx=0 and a reason of noresource. -Jonathan R. > > NOTIFY sip:appserver.example.com SIP/2.0 > Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bK4EPlfSFQK1 > Max-Forwards: 70 > From: ;tag=zpNctbZq > To: ;tag=ie4hbb8t > Call-ID: cdB34qLToC@terminal.example.com > CSeq: 997935769 NOTIFY > Contact: > Event: stimulus > Subscription-State: active;expires=XXXXX > Content-Type: application/kpml+xml > Content-Length: 74 > > > > > > > /a > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Fri Aug 15 11:46:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01187 for ; Fri, 15 Aug 2003 11:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngmB-00014K-2p for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FFk3df004103 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngmA-000146-UF for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 11:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01132 for ; Fri, 15 Aug 2003 11:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngm9-0003Ks-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:46:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ngm8-0003Kp-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngm8-00012f-Ui; Fri, 15 Aug 2003 11:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nglH-0000mj-Vg for sipping@optimus.ietf.org; Fri, 15 Aug 2003 11:45:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01041 for ; Fri, 15 Aug 2003 11:45:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nglG-0003Jc-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:45:06 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19nglF-0003JD-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:45:06 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7FFiPUg001082; Fri, 15 Aug 2003 11:44:25 -0400 (EDT) Message-ID: <3F3CFFD7.1090004@dynamicsoft.com> Date: Fri, 15 Aug 2003 11:44:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Tim Melanchuk'" , Cullen Jennings , sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? References: <9BF66EBF6BEFD942915B4D4D45C051F3E862F0@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862F0@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 Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > > Correlation is easy. The KPML script IS the subscription. The > > place to send the notify is implied from the URI in the KPML > > script. We would need to clarify in KPML that once that URI is > > used, subsequent notificatiosn to the same URI ought to go on > > the dialog established by the NOTIFY. But, this is a KPML issue. > > I mean dialog correlation. > > Let's say you're an app server. Client A sends an INVITE > through you. You add something to the 200 response that > ultimately results in Client A getting the following KPML > script: > > > > > > > > > > > Client A sends another INVITE through you. You add something to > the 200 response that ultimately results in Client A getting > the following KPML script: > > > > > > > > > > > Finally, you get a NOTIFY request from the user. How do you > know to which session it pertains? You wouldnt send the KPML you have described. Each would have a different URI in the href. The URI provides the correlation. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Fri Aug 15 11:52:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01375 for ; Fri, 15 Aug 2003 11:52:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngry-0001PU-S3 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:52:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FFq2re005414 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 11:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngry-0001PF-On for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 11:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01372 for ; Fri, 15 Aug 2003 11:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngrx-0003PV-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:52:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ngrw-0003PS-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 11:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngrw-0001OJ-Ln; Fri, 15 Aug 2003 11:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ngrC-0001O2-R1 for sipping@optimus.ietf.org; Fri, 15 Aug 2003 11:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01354 for ; Fri, 15 Aug 2003 11:51:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ngrB-0003PP-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:51:13 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ngrA-0003Oc-00 for sipping@ietf.org; Fri, 15 Aug 2003 11:51:12 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7FFoCUg001089; Fri, 15 Aug 2003 11:50:13 -0400 (EDT) Message-ID: <3F3D0132.5020904@dynamicsoft.com> Date: Fri, 15 Aug 2003 11:50:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Dean Willis , David Schwartz , "'Jiri Kuthan'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: Update to 3pcc 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 I agree with Dean that this is not at all what session timer was meant for. The spec is pretty explicit about its usage as a cleanup mechanism. You'll have serious problems if the refreshing side is not trusted. Session timer allows either side to refresh. So, if this is a PC to phone case and PC is refreshing this won't work. Even when its the gateway refreshing, 403 doesnt cause the gateway to terminate the call - at least it shouldnt, I dont think. Nothing in the spec says to tear down the call if you get a 403 to an INVITE. -Jonathan R. Rohan Mahy wrote: > > On Wednesday, August 13, 2003, at 08:13 AM, Dean Willis wrote: > >> >> Rohan said: >> >>> I think it is completely reasonable to build a pre-paid calling system >>> using a proxy with AAA and session timer and optionally a cooperating >>> UA (for IVR features). >> >> >> Just as billing from session-timer is not a use case, neither is prepaid >> control using session timer appropriate. We designed session-timer to >> have a resolution on the order of minutes or hours, not seconds. > > > In many prepaid applications that is all that is required. For example: > > UA sends an INVITE with apropos credentials. > Proxy does a AAA lookup, finds out there is enough credit for 2 hours, > sets session timer at 15 minutes and proxies the request to a gateway > with Require: timer. > After 30 minutes the gateway reINVITEs (a timer refresh request). The > Proxy again does a AAA lookup. At this point there is only enough > credit for 10 minutes (the caller used the prepaid service to make a > more expensive call). The proxy forwards the request with session timer > set to 5 minutes. > On the next timer refresh, the proxy forwards the request with a 3 > minute timer. Finally the proxy uses a 2 minute timer. When the last > timer refresh arrives, the Proxy sends a 403, and the gateway tears down > the session. > > This mechanism works very well and is perfectly appropriate if either > only one session is allowed at a time, or if you are willing to reserve > resources for an existing session for a few minutes in the future. > >> It's for cleaning up state when stuff goes wrong -- basically, a >> soft-crash >> mechanism. > > > I have no problem with that. But it is a perfectly reasonable solution > for some prepaid applications (not all of them obviously), and requires > no changes to the session timer spec. > > thanks, > -rohan > > >> One doesn't drive a car by manipulating its air-bags or >> discard the brakes because one's seat belt is buckled. >> >> It sounds to me like you're introducing a time-bounded variant of the >> authorization-token header. Something like that COULD be used by a >> cooperating UA (say, the PSTN gateway) with reasonable success. >> >> -- >> 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Fri Aug 15 12:14:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02017 for ; Fri, 15 Aug 2003 12:14:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhDK-0003D8-Ez for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 12:14:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FGE6tH012336 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 12:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhDK-0003Ct-Br for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 12:14:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01960 for ; Fri, 15 Aug 2003 12:14:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nhDI-0003ZC-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 12:14:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nhDI-0003Z9-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 12:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhDE-0003B5-TW; Fri, 15 Aug 2003 12:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nhCf-00035p-V8 for sipping@optimus.ietf.org; Fri, 15 Aug 2003 12:13:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01934 for ; Fri, 15 Aug 2003 12:13:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nhCe-0003YP-00 for sipping@ietf.org; Fri, 15 Aug 2003 12:13:24 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nhCd-0003Xy-00 for sipping@ietf.org; Fri, 15 Aug 2003 12:13:24 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2003 09:19:51 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7FGCotp001807; Fri, 15 Aug 2003 09:12:50 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-21.cisco.com [10.86.242.21]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABO46460; Fri, 15 Aug 2003 12:12:47 -0400 (EDT) Message-ID: <3F3D067F.3040509@cisco.com> Date: Fri, 15 Aug 2003 12:12:47 -0400 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: Rohan Mahy , Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: Comment on GRUU requirements References: <7BDAC0E8-CDD7-11D7-91B8-0003938AF740@cisco.com> <3F3CD7E6.9020102@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: > > IMHO, the GRUU is a lot like the Reply-To URI. Its a URI that provides > an additional means of communication in the future, outside of the > current dialog. Just as the Reply-To URI is indicated with a header, so > to is the GRUU indicated with a header. This is an interesting analogy, and perhaps a good one. But Reply-To suffers from underspecification - AFAIK the circumstances under which a UA should extract the value from a Refer-To and insert them in some other request are entirely unspecified. As a result, the Refer-To header is currently pretty much unusable. If we are to go with a separate header for GRUUs, then we need to do a much better job of defining when it should be used. 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 exim@www1.ietf.org Fri Aug 15 13:09:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04577 for ; Fri, 15 Aug 2003 13:09:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ni4r-0005ty-AM for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 13:09:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FH9PnR022681 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 13:09:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ni4p-0005tk-PO for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:09:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04507 for ; Fri, 15 Aug 2003 13:09:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ni4n-00046z-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 13:09:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ni4m-00046v-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 13:09:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ni4T-0005sJ-AU; Fri, 15 Aug 2003 13:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ni3x-0005s2-FC for sipping@optimus.ietf.org; Fri, 15 Aug 2003 13:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04453 for ; Fri, 15 Aug 2003 13:08:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ni3v-000463-00 for sipping@ietf.org; Fri, 15 Aug 2003 13:08:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ni3u-000438-00 for sipping@ietf.org; Fri, 15 Aug 2003 13:08:26 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7FH7qUg001146; Fri, 15 Aug 2003 13:07:52 -0400 (EDT) Message-ID: <3F3D1366.4090900@dynamicsoft.com> Date: Fri, 15 Aug 2003 13:07:50 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: sipping Subject: Re: [Sipping] App-Interaction: Considering models References: <9BF66EBF6BEFD942915B4D4D45C051F3E862D9@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862D9@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 Thoughts inline. Adam Roach wrote: > After considering Jonathan's contention that defining > a new method for conveying stimulus is creating something > that is similar in meaning to NOTIFY, I'm inclined to > agree to some point. There are still subtle differences > in meaning, so I'm not completely convinced that a new > method is wrong, but I understand the point he's trying > to make. > > After discussing it privately with others, I've concluded > that there are three viable models worth considering. There > are, of course, some minor variations that can be made to > each. > > 1) Standard HTTP Handling > > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| > 3| |<-----200-------| > 4|<-----200-------| | AS adds HTTP URL to 200 > 5|---HTTP GET---->| | UAC requests KPML script > 6|<-----200-------| | AS replies with script > 7|---HTTP POST--->| | UAC provides digits > 8|<-----200-------| | AS acknowledges digits > > Of the three options presented here, I see this as the best > solution. Basically, the app server includes an HTTP URL > in the 200 response to the INVITE that it has proxied. The > UAC then does a GET on the KPML script. Just like with > HTML forms, the UAC does whatever local stuff is necessary > to "fill out the form" (in this case, collect digits), and > then posts the result back to the App Server. This is all > plain-Jane unextended HTTP as it was intended to work. This is also my favorite, and always has been. However, I had believed I was the only one who liked this. Cullen raised some concerns about it: > One of the difficult parts of this is security. > > This will get more complicated once you provide a way to send in message 4 > the credentials that will allow 7. This is only a problem when there is no direct trust relationship already between the caller and the application server. If there is such a trust relationship, then you can use digest with the same credentials used to authenticate the INVITE. If there is not, it is more complex. The case when there is not (which we discussed in the design team meetings) was when, for example, I call Cullen. This lands in a Cisco proxy, which runs an app that asks me to choose which "fluffy" I want, as there are miraculously two at Cisco (probably not true but bear with me). Now, the Cisco proxy doesn't know me at all. But, it wants to make sure that the entity which does the POST is the one that made the call. I would argue that there is an easy solution to this, which is just sips + https. If the call is over sips, the proxy can send the UA a random URI in the APp-Info header. No one else can see this header but the caller and intervening proxies. Then, the caller does https to the proxy, and sends the URI it was handed. I believe this provides a reasonably secure correlation. Note that sips is needed in all cases for any security for app-info headers. > It may also make the App-Info header only > really work with scripts that use HTTP to post instead of other things. That would be the proposal here, since its HTTP with the other script types (HTML, VoiceXML). > Also, in the case of a financial institutions that have to log electronic > communications, you will need to provide way to insert logging HTTP proxies > and probably proxies for FW traversal too. All of these exist, no? The only real argument for HTTP is that this basically IS a web application of sorts, just one on a really dumb device. > Of course the AS or the UAC will > need to figure out the network topology to know if the AS is inside or > outside the FW. I don't follow that. > It's possible to configure all the domain and HTTP proxies > rules into the device but it still hard to secure - particularly on devices > that don't want to implement HTTPS due to not much memory. Well - thats the rub - if https isnt possible, yes, its a problem. But then you can't argue that sips would be OK, in which case you have no security anyway. > > 2) Explicit Subscriptions (with GRUU) > > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| AS extracts GRUU from INVITE > 3| |<-----200-------| > 4|<-----200-------| | > 5|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script > 6|------200------>| | > 7|-----NOTIFY---->| | > 8|<-----200-------| | > 9|-----NOTIFY---->| | UAC provides digits > A|<-----200-------| | AS acknowledges digits > > My second choice would be an explicit subscription to stimulus > events. The only sticky part in this solution is the question > of how the AS can route a SUBSCRIBE to the UAC. Once we have > a GRUU solution in place, this is a no brainer: the AS can > extract the GRUU from the INVITE, and use it as the target > of its SUBSCRIBE. The KPML script is included in the SUBSCRIBE, > and essentially serves as a filter. This was one of the solutions I outlined in my initial email, yes. GRUU is not the only problem. There is also the correlation problem - how does the UA know that the SUBSCRIBE comes from an entity along the call path? AUthorizing the subscribe as above would be really hard. > > 3) Explicit Subscriptions (with REFER) > > UAC App Server UAS > 1|-----INVITE---->| | > 2| |-----INVITE---->| > 3| |<-----200-------| > 4|<-----200-------| | AS adds SIP URL to 200 > 5|-----REFER----->| | > 6|<-----200-------| | > 7|<----NOTIFY-----| | > 8|------481------>| | > 9|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script > A|------200------>| | > B|-----NOTIFY---->| | > C|<-----200-------| | > D|-----NOTIFY---->| | UAC provides digits > E|<-----200-------| | AS acknowledges digits > > Although somewhat chattier than the previous solution, this gets around > the GRUU issue by having the AS provide a SIP URI that routes to itself > in the 200 response. How does that solve the GRUU problem? It still needs to get a GRUU to hand out in the Refer-To. This just adds another layer of indirection. Adam later wrote: > Your phrasing above knocked loose in my mind another reason > that implicit subscriptions[1] are ill-advised: you are using > a single transaction to perform two operations. Conveying > partial success (e.g. the call completed, but the subscription > failed) is problematic. We have made efforts to avoid this > type of situation in the past. What two operations are being performed by which transaction? The NOTIFY? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Fri Aug 15 13:42:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06190 for ; Fri, 15 Aug 2003 13:42:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niaV-0007hs-PW for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 13:42:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHg7eR029618 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 13:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niaV-0007hd-L0 for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:42:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06186 for ; Fri, 15 Aug 2003 13:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niaT-0004au-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 13:42:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19niaS-0004ar-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 13:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niaP-0007gR-RD; Fri, 15 Aug 2003 13:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niZf-0007fy-Ru for sipping@optimus.ietf.org; Fri, 15 Aug 2003 13:41:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06180 for ; Fri, 15 Aug 2003 13:41:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niZd-0004ai-00 for sipping@ietf.org; Fri, 15 Aug 2003 13:41:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19niZb-0004aZ-00 for sipping@ietf.org; Fri, 15 Aug 2003 13:41:11 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7FHedtp006846; Fri, 15 Aug 2003 10:40:39 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKK52080; Fri, 15 Aug 2003 10:33:18 -0700 (PDT) Date: Fri, 15 Aug 2003 10:43:25 -0700 Subject: Re: [Sipping] Re: Comment on GRUU requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F3CD7E6.9020102@dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Friday, August 15, 2003, at 05:53 AM, Jonathan Rosenberg wrote: > inline. > > Rohan Mahy wrote: > >> On Wednesday, August 13, 2003, at 10:55 AM, Adam Roach wrote: >>> Rohan Mahy [mailto:rohan@cisco.com] writes: >>> >>>> Most of the SIP phones I see at SIPit support >>>> completing a transfer using a REFER with a >>>> Replaces header embedded in the Refer-To. >>>> The Refer-To URI is always set to the Contact >>>> URI of the appropriate UA. >>> >>> >>> And this will continue to work as well as it does today. >>> Newer, GRUU aware clients will simply exhibit an additional >>> robustness. >>> >>> It seems a bit misguided to do things in a suboptimal way >>> just to try to fix currently deployed clients. >> and Jonathan wrote: >>>>> I don't think we have so much of either of these deployed that >>>>> this cannot change. >>>> >>>> I disagree. Most of the SIP phones I see at SIPit support >>>> completing a transfer using a REFER with a Replaces header embedded >>>> in the Refer-To. The Refer-To URI is always set to the Contact URI >>>> of the appropriate UA. >>> >>> >>> Well, we have here the standard problem here of having >>> implementations of long-running drafts, and then deciding down the >>> road that something needs to change. >>> >>> I think we want a non-GRUU in the Contact header (to avoid spirals >>> through proxies, and needless load when the proxy doesnt intend to >>> record-route), but we want a GRUU for attended-transfer. I would >>> propose to use a separate header to identify GRUUs. Existing phones >>> will work as they currently do, and when two phones both support >>> GRUU, you get more reliable service. I recognize that putting the >>> GRUU in the contact would mean only one of the phones needs to >>> support it (clearly better), but the cost of this is a long-term >>> situation that we don't want. >>> >>> -Jonathan R. >> Hi, >> I think both of you are ignoring the "generality before efficiency" >> principle. > > I don't think that is the tradeoff here. Given a clean slate, it is > clear that a new header would be used. The argument for contact header > is just to facilitate introduction of GRUU. Thus, its more of the > "backwards compatible vs. right thing" kind of debate. > >> Putting the GRUU in the Contact header always works, and in most >> deployments where it is needed (middlebox traversal), you WILL need >> to travel through the same set of proxies for nearly every request >> anyhow. With the increased deployment of TLS and SIPS we will >> increasingly have dialogs for which all or none of the requests are >> proxied. > > A few responses here. Firstly, your comments above would seem to imply > that a UA wouldn't always put the GRUU in the Contact header - that it > would do so only in situations where it was needed. The problem is, > the UA can't know when its needed. It would be needed if someone else > wants to transfer a call to it, or subscribe to its dialog package. > Since the UA can't know that ahead of time, for it to work, we need to > specify that all UAs should always use GRUUs all the time. If the GRUU > is placed in the Contact header, this would mean the end of e2e sip > signaling, PERIOD. AFAIK, there are two cases only. You either a) can self-generate GRUUs (no server leasing) in which case you use these as your Contact addresses, or b) you need to lease GRUUs and put them somewhere. Clearly, e2e signaling still works just fine in case a). My position is that e2e signaling is only rarely used in practice in case b), and that with TLS/SIPS that this will become even less of an option. IMO this is just modeling the real partition that is occurring among IP hosts. There are full-fledged Internet hosts which can make use of the e2e principle (case a) and all the other IP hosts which are stuck behind middleboxes with "fogged up windows" (case b). I believe my comments merely reflect that (unfortunate) reality. > Even if you assume a proxy needs to be on the path, a proxy then is > faced with an impossible decision. When it receives a request, does > the proxy need to record route (if the downstream UA is using a GRUU) > or not (if it isn't). It doesn't know what the downstream UA can do at > this point. So, it can't make a correct decision. Existing proxies > wouldn't even know about this decision. The result would be that, > where proxies record-route and the downstream UA uses a GRUU, requests > will spiral or take extra hops on every call. This results in > decreased overall performance in the network and increased call setup > times. In practice, this is not very complicated. If the proxy needs to record route for application purposes then it will record route according to that policy (no change). If the proxy is configured to record route for middlebox traversal purposes then it is trivial for it to check if the request-URI "host is me" before adding record route. This has always been a good idea, we just have an additional motivation for that check now. >> We are talking about interop with thousands of UAs which have >> implemented Proposed Standard level RFCs (SIP and Refer) and an >> long-lived, stable I-D that has completed WGLC and was submitted to >> the IESG (Replaces)`. We are not talking about random drafts that >> very few have implemented. > > These drafts are standardized, yes, but their usage for assisted call > transfer (which is what we are talking about here) has clearly been > changing and is still an I-D. Nothing in the specs you mention tells > people to extract the Refer-To URI from the Contact header of the > peer. This usage has not significantly changed in almost the last two years. (The caller preferences solution was abandoned almost immediately because it had much worse backward compatibility problems.) If you want any sort of useful distributed call control (not just transfer, but all the services you could build conferencing, replaces, join, and the dialog package) you need to have a URI that reaches the same SIP UA for all dialogs which are related to the target dialog. If you use the rigid definition of Contact as only valid in a dialog, then the Contact header is effectively useless (it can't stand alone without the route set) except where the Contact URI happens to be a GRUU of the style in case a). In fact we already have a precedent (in the REGISTER method) that a Contact should be valid for more than one dialog. So why don't we formalize this convention and state that what you place in the Contact header for a dialog MUST be a GRUU and how you get one is up to you. >> To be convinced that it is worth adding a new GRUU header, I would at >> least like to see some plausible use cases that are common enough for >> us to be worrying about. Maybe the right way to look at this is to >> put the GRUU in the Contact, UNLESS you can tell that your peer >> understands the special significance of GRUUs. > > Hopefully my explanation above describes the problems with putting > GRUU in contacts. Even if you knew that all of your peers supported > Contact headers, putting one in would have the problems described > above. again, you haven't described a "problem" that is any different from best current practice. most implementations *already* use the URI from the Contact in the Refer-To header (and in other places outside of a single dialog). > IMHO, the GRUU is a lot like the Reply-To URI. Its a URI that provides > an additional means of communication in the future, outside of the > current dialog. Just as the Reply-To URI is indicated with a header, > so to is the GRUU indicated with a header. Then what is the use of having a Contact header? By redefining the Contact header clearly we do not cause any harm. Implementations which do not put GRUUs in Contacts will be just as broken as they are today but no more so, and a bunch of things will just work nicely that didn't before. >> Also, where this extension is most needed, you need the right 2 out >> of 3 to support the extension. (This isn't just any two of three. >> If Bob supports the GRUU extension, but Carol does not, Alice still >> cannot cause a transfer to occur in the appropriate direction.) >> Starting with the classic Alice, Bob, and Carol actors. >> Alice and Bob have an existing dialog. >> Alice and Carol have an existing dialog. >> Alice wants Bob to talk to Carol, and will REFER Bob to INVITE Carol >> replacing the dialog between Alice and Carol. >> Carol needs a GRUU; if the GRUU is conveyed in a separate header >> Alice and Carol both need to support the GRUU extension for the >> Refer-To header to be set properly. > > Yes, I agree with this. I agree its not optimal. With what I am > proposing, things will work as well as they do today, no worse, no > better, if Alice and Bob don't support GRUUs. Right, and with what I am proposing they will sometimes work even better than that. thanks, -rohan > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > 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 exim@www1.ietf.org Fri Aug 15 13:52:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06590 for ; Fri, 15 Aug 2003 13:52:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nik7-0008TE-1s for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 13:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHq3Ao032554 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 13:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nik6-0008Sz-V5 for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06580 for ; Fri, 15 Aug 2003 13:51:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nik4-0004iK-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 13:52:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nik4-0004iH-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 13:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nik5-0008S3-5t; Fri, 15 Aug 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nijl-0008Rm-FA for sipping@optimus.ietf.org; Fri, 15 Aug 2003 13:51:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06565 for ; Fri, 15 Aug 2003 13:51:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nijj-0004hw-00 for sipping@ietf.org; Fri, 15 Aug 2003 13:51:39 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19niji-0004hf-00 for sipping@ietf.org; Fri, 15 Aug 2003 13:51:38 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7FHokpp022536; Fri, 15 Aug 2003 10:50:47 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKK53506; Fri, 15 Aug 2003 10:43:26 -0700 (PDT) Date: Fri, 15 Aug 2003 10:53:32 -0700 Subject: Re: [Sipping] Re: Update to 3pcc Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Dean Willis , David Schwartz , "'Jiri Kuthan'" , "'sipping@ietf.org'" To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F3D0132.5020904@dynamicsoft.com> Message-Id: <62A9F91C-CF49-11D7-91B8-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Friday, August 15, 2003, at 08:50 AM, Jonathan Rosenberg wrote: > I agree with Dean that this is not at all what session timer was meant > for. The spec is pretty explicit about its usage as a cleanup > mechanism. if it works without changes to the existing mechanism, then what is the problem? > You'll have serious problems if the refreshing side is not trusted. > Session timer allows either side to refresh. So, if this is a PC to > phone case and PC is refreshing this won't work. the gateway is the refresher, and is trusted. the example i gave nicely fits a business model where the provider accounts for PSTN usage, but does not charge/account for arbitrary SIP sessions. Easy things should be easy, contrived things will be hard and will require a B2BUA. > Even when its the gateway refreshing, 403 doesnt cause the gateway to > terminate the call - at least it shouldnt, I dont think. Nothing in > the spec says to tear down the call if you get a 403 to an INVITE. you are correct, but the call will be torn down after the session expires. since the session is not refreshed when the proxy responds with a 403, the session will expire and the gateway will send a BYE. thanks, -rohan > > -Jonathan R. > > Rohan Mahy wrote: > >> On Wednesday, August 13, 2003, at 08:13 AM, Dean Willis wrote: >>> >>> Rohan said: >>> >>>> I think it is completely reasonable to build a pre-paid calling >>>> system >>>> using a proxy with AAA and session timer and optionally a >>>> cooperating >>>> UA (for IVR features). >>> >>> >>> Just as billing from session-timer is not a use case, neither is >>> prepaid >>> control using session timer appropriate. We designed session-timer to >>> have a resolution on the order of minutes or hours, not seconds. >> In many prepaid applications that is all that is required. For >> example: >> UA sends an INVITE with apropos credentials. >> Proxy does a AAA lookup, finds out there is enough credit for 2 >> hours, sets session timer at 15 minutes and proxies the request to a >> gateway with Require: timer. >> After 30 minutes the gateway reINVITEs (a timer refresh request). >> The Proxy again does a AAA lookup. At this point there is only >> enough credit for 10 minutes (the caller used the prepaid service to >> make a more expensive call). The proxy forwards the request with >> session timer set to 5 minutes. >> On the next timer refresh, the proxy forwards the request with a 3 >> minute timer. Finally the proxy uses a 2 minute timer. When the >> last timer refresh arrives, the Proxy sends a 403, and the gateway >> tears down the session. >> This mechanism works very well and is perfectly appropriate if either >> only one session is allowed at a time, or if you are willing to >> reserve resources for an existing session for a few minutes in the >> future. >>> It's for cleaning up state when stuff goes wrong -- basically, a >>> soft-crash >>> mechanism. >> I have no problem with that. But it is a perfectly reasonable >> solution for some prepaid applications (not all of them obviously), >> and requires no changes to the session timer spec. >> thanks, >> -rohan >>> One doesn't drive a car by manipulating its air-bags or >>> discard the brakes because one's seat belt is buckled. >>> >>> It sounds to me like you're introducing a time-bounded variant of the >>> authorization-token header. Something like that COULD be used by a >>> cooperating UA (say, the PSTN gateway) with reasonable success. >>> >>> -- >>> 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 > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > 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 exim@www1.ietf.org Fri Aug 15 16:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11923 for ; Fri, 15 Aug 2003 16:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl0T-0000GA-VP for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 16:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKH5Ds000992 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 16:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl0T-0000Fv-S6 for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:17:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11917 for ; Fri, 15 Aug 2003 16:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl0S-0005gV-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 16:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nl0R-0005gS-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 16:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl0P-0000Ea-88; Fri, 15 Aug 2003 16:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkzi-0000Dn-JO for sipping@optimus.ietf.org; Fri, 15 Aug 2003 16:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11879 for ; Fri, 15 Aug 2003 16:16:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkzg-0005g7-00 for sipping@ietf.org; Fri, 15 Aug 2003 16:16:16 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19nkzf-0005fn-00 for sipping@ietf.org; Fri, 15 Aug 2003 16:16:16 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7FKFbpp017971; Fri, 15 Aug 2003 13:15:38 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKK72013; Fri, 15 Aug 2003 13:08:16 -0700 (PDT) Date: Fri, 15 Aug 2003 13:18:26 -0700 Subject: Re: [Sipping] Request for editorial input Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sipping@ietf.org To: Robert Sparks From: Rohan Mahy In-Reply-To: <1060281712.932.16.camel@RjS.localdomain> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Robert, The issue that you raise is also a problem for SMIME examples. We need a way to display binary non-ASCII data. We can display this using textual conventions like you suggest for short sections, but for longer sections of non-text formatted data, perhaps we need to use a hexdump format like the compression folks use (see the SIP static compression dictionary). thanks, -rohan On Thursday, August 7, 2003, at 11:41 AM, Robert Sparks wrote: > As noted at IETF57, I'm picking up editorship of the torture-test > document. > > One of the things I want to do is disambiguate the printed text > examples. There are cases now where the torture consists of having very > long text fields. For example: > > CSeq: > 239sdfadfnm34r5u09sdfawetrq3o4t5nodifnaoihesfoiw34foisdfeijjnaosdfj4ios > dfnaehnaasoo34ijdfn5kl3neasdfvnazs > > which gets broken into a format that is not valid for SIP when you try > to render withing the 72 column limit of internet drafts. (Its probably > also broken badly in this message by many mail readers). > > I propose making such breaks explicit as follows: > > If I needed to break the following (short for clarity) header field: > > Foo: areallybigtoken > > I'll render it as > > Foo: areally > bigtoken > > or > > Foo: areally > big > token > > > Objections? Alternative suggestions? > > Additionally, I'm considering including an appendix with an > ascii-armored container (a zip-file or compressed tarball > perhaps) with each message (so that we can include some > torturous whitespace and non-ASCII range UTF8 tests. > > RjS > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 15 17:19:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14522 for ; Fri, 15 Aug 2003 17:19:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlyl-0004py-FQ for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 17:19:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FLJNtJ018590 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 17:19:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlyl-0004pf-82 for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 17:19:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14413 for ; Fri, 15 Aug 2003 17:19:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlyi-0006Jc-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 17:19:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nlyX-0006Ir-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 17:19:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlyS-0004lb-Vs; Fri, 15 Aug 2003 17:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlyG-0004go-FS for sipping@optimus.ietf.org; Fri, 15 Aug 2003 17:18:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14321 for ; Fri, 15 Aug 2003 17:18:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlyD-0006HR-00 for sipping@ietf.org; Fri, 15 Aug 2003 17:18:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nlyD-0006HN-00 for sipping@ietf.org; Fri, 15 Aug 2003 17:18:49 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2003 14:25:21 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7FLIHLH015252; Fri, 15 Aug 2003 14:18:17 -0700 (PDT) Received: from [128.107.170.114] ([128.107.170.114]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHD59704; Fri, 15 Aug 2003 14:18:09 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Aug 2003 14:18:08 -0700 Subject: Re: [Sipping] DTMF: Why Not A New Method? From: Cullen Jennings To: Adam Roach CC: sipping Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862F0@dyn-tx-exch-001.dynamicsoft.com> 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 I think the href in the VXML would provide the correlation information so it might be something like Href="sip:application_23_user_55_instance_2345@appserver.example.com" Cullen On 8/14/03 4:19 PM, "Adam Roach" wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > >> Correlation is easy. The KPML script IS the subscription. The >> place to send the notify is implied from the URI in the KPML >> script. We would need to clarify in KPML that once that URI is >> used, subsequent notificatiosn to the same URI ought to go on >> the dialog established by the NOTIFY. But, this is a KPML issue. > > I mean dialog correlation. > > Let's say you're an app server. Client A sends an INVITE > through you. You add something to the 200 response that > ultimately results in Client A getting the following KPML > script: > > > > > > > > > > > Client A sends another INVITE through you. You add something to > the 200 response that ultimately results in Client A getting > the following KPML script: > > > > > > > > > > > Finally, you get a NOTIFY request from the user. How do you > know to which session it pertains? > > /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 exim@www1.ietf.org Fri Aug 15 17:21:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14577 for ; Fri, 15 Aug 2003 17:21:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlzv-00059p-4p for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 17:20:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FLKZ5R019819 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 17:20:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlzu-00059a-FH for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 17:20:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14554 for ; Fri, 15 Aug 2003 17:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlzP-0004yP-Fd; Fri, 15 Aug 2003 17:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlyu-0004qe-55 for sipping@optimus.ietf.org; Fri, 15 Aug 2003 17:19:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14450 for ; Fri, 15 Aug 2003 17:19:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlyr-0006KY-00 for sipping@ietf.org; Fri, 15 Aug 2003 17:19:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nlyr-0006HW-00 for sipping@ietf.org; Fri, 15 Aug 2003 17:19:29 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2003 14:26:00 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7FLIvLH015584; Fri, 15 Aug 2003 14:18:58 -0700 (PDT) Received: from [128.107.170.114] ([128.107.170.114]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHD59807; Fri, 15 Aug 2003 14:18:57 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Aug 2003 14:18:56 -0700 Subject: Re: [Sipping] App-Interaction: Considering models From: Cullen Jennings To: Adam Roach , sipping , Jonathan Rosenberg Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862E5@dyn-tx-exch-001.dynamicsoft.com> 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 On 8/14/03 10:33 AM, "Adam Roach" wrote: > Cullen Jennings writes: > >> UAC App Server UAS >> 1|-----INVITE---->| | >> 2| |-----INVITE---->| >> 3| |<-----200-------| >> 4|<-----200-------| | >> 5|---SIP MESG---->| | >> 6|<-----200-------| | > > Are you proposing that the App Server would send the KPML script > in the INVITE 200? Where? In the body? In an egregiously large > header? > > The App-Info allows the script to be fetched with HTTP or be in a body and use a cid URL to get it out of the body. I probably should have included the HTTP get between message 4 and 5 to be fair. Cullen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 15 17:29:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14785 for ; Fri, 15 Aug 2003 17:29:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nm8a-0005RM-OR for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 17:29:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FLTWOu020906 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 17:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nm8a-0005R7-LV for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 17:29:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14778 for ; Fri, 15 Aug 2003 17:29:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nm85-0005Ip-97; Fri, 15 Aug 2003 17:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nm7K-0005HB-18 for sipping@optimus.ietf.org; Fri, 15 Aug 2003 17:28:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14758 for ; Fri, 15 Aug 2003 17:28:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nm7H-0006Nk-00 for sipping@ietf.org; Fri, 15 Aug 2003 17:28:11 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nm7G-0006Nb-00 for sipping@ietf.org; Fri, 15 Aug 2003 17:28:11 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2003 14:27:40 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7FLRZtr017402; Fri, 15 Aug 2003 14:27:39 -0700 (PDT) Received: from [128.107.170.114] ([128.107.170.114]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHD60714; Fri, 15 Aug 2003 14:27:34 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Aug 2003 14:27:34 -0700 Subject: Re: [Sipping] App-Interaction: Considering models From: Cullen Jennings To: Adam Roach , sipping , Jonathan Rosenberg Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862EF@dyn-tx-exch-001.dynamicsoft.com> 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 Fair enough, I am not really arguing for NOTIFY, I sort of like the NEW_METHOD approach because it lets us get past all the semantics arguments by defining the semantics to be exactly what we want. I forgot on my list, PUBLISH may be an option to use to depending on what people believe the semantics of it are. On the topic of reporting that there was some error in dealing with the script referenced in the App-Info header, we use the (cough) web model of error reporting, which is to say we don't do it at all. Thought this seems lame at first glance, after much discussion, we came to the conclusion that any useful application you wanted to build with this needed to deal with never receiving any stimulus from the script and that web model was quite reasonable and the right thing for this. I think this decision makes the problem of multiple error report on implicit subscribes a non issue here. Cullen On 8/14/03 4:11 PM, "Adam Roach" wrote: > Cullen Jennings [mailto:fluffy@cisco.com] writes: > >> Proposal 3) Use NOTIFY. Semantics are, here is some >> information about some event that you requested to >> be informed about. The usual complaint on this one >> is that there was no Subscribe, or it was implicit, >> or it was explicit, or it violated some law of the >> SIP world. I think there was a subscribe, it was in >> the message that initiated the script. There is also >> a clear time it will end - when the script is terminated >> or when the dialog of the message that initiated the >> script ends. We all remember that implicit subscribes >> where bad (whatever an implicit subscribe is) but people >> seem to have a hard time remembering why this will be >> bad here. > > It's not simple dogma; there are real problems here. I've > cited a few of them (and, as I point out in another message, > Jonathan's rebuttal is somewhat lacking in the area of > duration; also, I still plan to respond on the correlation > issue, because I think his rebuttal glosses over the > details). > > Can these problems be fixed? Probably. REFER provides an > existence proof that implicit subscriptions[1] can be made > to work with enough crafting. After it's said and done, > do we regret choosing that path? I do. Robert does. Do we > want to learn from our mistakes? > > Your phrasing above knocked loose in my mind another reason > that implicit subscriptions[1] are ill-advised: you are using > a single transaction to perform two operations. Conveying > partial success (e.g. the call completed, but the subscription > failed) is problematic. We have made efforts to avoid this > type of situation in the past. > > /a > > [1] To be clear, I mean "subscriptions put in place via some > other mechanism than that described in RFC 3265." > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 15 18:37:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16839 for ; Fri, 15 Aug 2003 18:37:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnC5-0008VQ-6o for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 18:37:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FMbDF1032692 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 18:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnC5-0008VD-2N for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 18:37:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16815 for ; Fri, 15 Aug 2003 18:37:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nnC2-0006c1-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 18:37:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nnC1-0006by-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 18:37:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnBt-0008Pw-AY; Fri, 15 Aug 2003 18:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnBJ-0008O1-MG for sipping@optimus.ietf.org; Fri, 15 Aug 2003 18:36:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16752 for ; Fri, 15 Aug 2003 18:36:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nnBG-0006bH-00 for sipping@ietf.org; Fri, 15 Aug 2003 18:36:22 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nnBG-0006aQ-00 for sipping@ietf.org; Fri, 15 Aug 2003 18:36:22 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Aug 2003 15:42:55 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7FMZoLH001421; Fri, 15 Aug 2003 15:35:51 -0700 (PDT) Received: from [128.107.170.114] ([128.107.170.114]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHD67926; Fri, 15 Aug 2003 15:35:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Aug 2003 15:35:49 -0700 Subject: Re: [Sipping] App-Interaction: Considering models From: Cullen Jennings To: Jonathan Rosenberg , Adam Roach CC: sipping Message-ID: In-Reply-To: <3F3D1366.4090900@dynamicsoft.com> 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 Let me propose a realistic scenario that is a little more difficult with http. It is probably possible to solve, just complicated. I will admit that much of the reason many people don't want to use HTTP is because they think sending it in SIP will be less work - they may or may not be right but the "less work" on low end devices is what has driven us to a fairly messy situation in handling DTMF today. I want to come up this something that is appealing enough to the people doing evil things today that they stop doing evil things. That said, let me describe a scenario that does occur and is difficult with HTTP. A residential phone user, called A, has a UA that they can use to make PSTN calls. This UA connects to a voice service provider, called Provider B that claims to terminate the calls to the PSTN. This provider does not directly terminate them but actually pass them to provider C. Provider C runs the call through a H.323 translator and terminates then sends the call to a 323 GW. The 323 GW does not support RFC 2833. The user A UA is likely to be behind a NAT and the final GW might be behind a NAT depending on the country of termination. B does not wish A to learn the identify of C because A might get a better price and cut B out of the loop. C does not wish B to learn too much about their network topology, since C might actually be passing traffic to provider D. Provider B and C and both run transparent B2BUA, broken proxies, and firewalls to make this all possible. The 323 translator wants to receive DTMF in the signaling so that it can pass it to the GW. In a variant of the scenario, provider B is a prepaid service and wants to be able to intercept long #. If the phone sent DTMF over INFO, the people with this problem would be happy. The development effort to send DTMF over INFO is very low. It would be possible to solve this example with 2833 to the 323 translator. The IETF suggested this was the right way to go - I am unaware of anyone who did that. Everyone decided some weird variant of sending it over SIP looked like a much better idea even though it was not interoperable. Perhaps they were all insane but people buying equipment convinced vendors to build it. If we want to standardize something that is going to be widely implemented, I think we need to keep what is deployed today and why it happened in mind. It is probably possible to have provider B write a HTTP proxy like thing that takes posts from A and then relays them on to C and change it's call control software to rewrite the KPML scripts as they pass through the signaling proxy/b2bua. But this leads to the the NAT ALG like behavior that we are trying to avoid. Cullen Another scenario similar to this happens when the PSTN GW is a SIP GW that may support 2833 but it is doing overlap dialing and uses KPML to tell the UA to keep sending it more digits before media is set up. I don't claim to fully understand this one so don't ask me too many questions on it :-) On 8/15/03 10:07 AM, "Jonathan Rosenberg" wrote: > Thoughts inline. > > Adam Roach wrote: > >> 1) Standard HTTP Handling >> >> UAC App Server UAS >> 1|-----INVITE---->| | >> 2| |-----INVITE---->| >> 3| |<-----200-------| >> 4|<-----200-------| | AS adds HTTP URL to 200 >> 5|---HTTP GET---->| | UAC requests KPML script >> 6|<-----200-------| | AS replies with script >> 7|---HTTP POST--->| | UAC provides digits >> 8|<-----200-------| | AS acknowledges digits >> >> Of the three options presented here, I see this as the best >> solution. Basically, the app server includes an HTTP URL >> in the 200 response to the INVITE that it has proxied. The >> UAC then does a GET on the KPML script. Just like with >> HTML forms, the UAC does whatever local stuff is necessary >> to "fill out the form" (in this case, collect digits), and >> then posts the result back to the App Server. This is all >> plain-Jane unextended HTTP as it was intended to work. > > This is also my favorite, and always has been. However, I had believed > I was the only one who liked this. > > Cullen raised some concerns about it: > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 15 18:51:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17126 for ; Fri, 15 Aug 2003 18:51:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnPW-0000zm-LI for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 18:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FMp6Q1003820 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 18:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnPW-0000yy-Gx for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 18:51:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17090 for ; Fri, 15 Aug 2003 18:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nnPT-0006fq-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 18:51:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nnPS-0006fn-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 18:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnPS-0000we-GN; Fri, 15 Aug 2003 18:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nnOc-0000oo-KS for sipping@optimus.ietf.org; Fri, 15 Aug 2003 18:50:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17070 for ; Fri, 15 Aug 2003 18:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nnOZ-0006fa-00 for sipping@ietf.org; Fri, 15 Aug 2003 18:50:07 -0400 Received: from web41509.mail.yahoo.com ([66.218.93.92]) by ietf-mx with smtp (Exim 4.12) id 19nnOY-0006fS-00 for sipping@ietf.org; Fri, 15 Aug 2003 18:50:06 -0400 Message-ID: <20030815224936.17823.qmail@web41509.mail.yahoo.com> Received: from [131.107.3.72] by web41509.mail.yahoo.com via HTTP; Fri, 15 Aug 2003 15:49:36 PDT Date: Fri, 15 Aug 2003 15:49:36 -0700 (PDT) From: Sean Olson Subject: Re: [Sipping] Re: Comment on GRUU requirements To: Rohan Mahy , Jonathan Rosenberg Cc: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" In-Reply-To: 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: , I have to agree with Rohan. I don't understand the purpose of NOT placing the GRUU in the Contact: header if possible. Whether or not this GRUU ties into a proxy is up for debate, but in practice I believe it will be the rule rather than the exception. Similar (but not identical) to the fact that a registrar is not absolutely necessary to use SIP but it sure makes things easier in practice. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.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 exim@www1.ietf.org Fri Aug 15 20:00:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18292 for ; Fri, 15 Aug 2003 20:00:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19noUK-0003i5-4k for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 20:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7G0087r014255 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 20:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19noUJ-0003hq-RX for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 20:00:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18275 for ; Fri, 15 Aug 2003 20:00:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19noUH-0006zP-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 20:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19noUH-0006zL-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 20:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19noUD-0003gK-9B; Fri, 15 Aug 2003 20:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19noTE-0003cQ-OW for sipping@optimus.ietf.org; Fri, 15 Aug 2003 19:59:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18232 for ; Fri, 15 Aug 2003 19:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19noTC-0006yl-00 for sipping@ietf.org; Fri, 15 Aug 2003 19:58:58 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19noTC-0006ya-00 for sipping@ietf.org; Fri, 15 Aug 2003 19:58:58 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7FNwSlt000826 for ; Fri, 15 Aug 2003 19:58:28 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Aug 2003 18:58:28 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862F9@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: sipping Subject: RE: [Sipping] App-Interaction: Considering models Date: Fri, 15 Aug 2003 18:58: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: , Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > 2) Explicit Subscriptions (with GRUU) > > This was one of the solutions I outlined in my initial email, yes. > GRUU is not the only problem. There is also the correlation problem - > how does the UA know that the SUBSCRIBE comes from an entity > along the > call path? AUthorizing the subscribe as above would be really hard. The SUBSCRIBE itself will need to contain information about the dialog for which it is requesting information anyway, right? Getting this information requires you to be in a position that would allow you to intercept the digits themselves. If you want to keep this information even more securely under wraps, use sips: to set up the call; the dialog information is revealed only to people in the call path, and only they would be able to subscribe to keypad events. /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 exim@www1.ietf.org Fri Aug 15 20:14:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18623 for ; Fri, 15 Aug 2003 20:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nohn-0004bC-8n for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 20:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7G0E3UJ017672 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 20:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nohn-0004ax-4I for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 20:14:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18614 for ; Fri, 15 Aug 2003 20:13:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nohl-00075N-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 20:14:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nohk-00075K-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 20:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nohl-0004Yb-4f; Fri, 15 Aug 2003 20:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19noh3-0004UG-T4 for sipping@optimus.ietf.org; Fri, 15 Aug 2003 20:13:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18592 for ; Fri, 15 Aug 2003 20:13:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19noh1-00075D-00 for sipping@ietf.org; Fri, 15 Aug 2003 20:13:15 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19noh1-00074z-00 for sipping@ietf.org; Fri, 15 Aug 2003 20:13:15 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7G0Cclt000849; Fri, 15 Aug 2003 20:12:38 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Aug 2003 19:12:37 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862FB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Jonathan Rosenberg , Adam Roach Cc: sipping Date: Fri, 15 Aug 2003 19:12:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Overlap Dialing 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: , fluffy writes: > Another scenario similar to this happens when the PSTN GW is > a SIP GW that may support 2833 but it is doing overlap dialing > and uses KPML to tell the UA to keep sending it more digits > before media is set up. *cringe* That reminds me: the overlap dialing specification should be popping out as an RFC any moment now. We just finished auth48. /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 exim@www1.ietf.org Fri Aug 15 20:36:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19053 for ; Fri, 15 Aug 2003 20:36:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19np3A-0005L0-6K for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 20:36:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7G0a8iE020516 for sipping-archive@odin.ietf.org; Fri, 15 Aug 2003 20:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19np3A-0005Kp-3C for sipping-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 20:36:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19045 for ; Fri, 15 Aug 2003 20:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19np37-0007Cl-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 20:36:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19np37-0007Ci-00 for sipping-web-archive@ietf.org; Fri, 15 Aug 2003 20:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19np34-0005I0-Lg; Fri, 15 Aug 2003 20:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19np2w-0005H3-5z for sipping@optimus.ietf.org; Fri, 15 Aug 2003 20:35:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19024 for ; Fri, 15 Aug 2003 20:35:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19np2t-0007CN-00 for sipping@ietf.org; Fri, 15 Aug 2003 20:35:51 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19np2t-0007CE-00 for sipping@ietf.org; Fri, 15 Aug 2003 20:35:51 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7G0Z1q27477; Fri, 15 Aug 2003 19:35:02 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Aug 2003 17:35:01 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20A47D3F4@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Cullen Jennings'" , "'Jonathan Rosenberg'" , "'Adam Roach'" Cc: "'sipping'" Subject: RE: [Sipping] App-Interaction: Considering models Date: Fri, 15 Aug 2003 17:34:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3638E.34FC54E6" 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_01C3638E.34FC54E6 Content-Type: text/plain Cullen Jennings wrote: > If the phone sent DTMF over INFO, the people with this > problem would be happy. The development effort to send DTMF > over INFO is very low. It would be possible to solve this > example with 2833 to the 323 translator. The IETF suggested > this was the right way to go - I am unaware of anyone who did > that. Everyone decided some weird variant of sending it over > SIP looked like a much better idea even though it was not > interoperable. Perhaps they were all insane but people buying > equipment convinced vendors to build it. If we want to > standardize something that is going to be widely implemented, > I think we need to keep what is deployed today and why it > happened in mind. The RFC2833 to H.323 translator idea is hightly dubious to me and I really don't see where that translater would sit to be able to perform this task. It would seem to have to sit at the media termination, which would imply that the endpoint supports RFC2833 in the first place. Certainly, support for RFC2833 is included in H.323 starting with version 4. So it would probably be much easier to support that than the translator idea. > Another scenario similar to this happens when the PSTN GW is > a SIP GW that may support 2833 but it is doing overlap > dialing and uses KPML to tell the UA to keep sending it more > digits before media is set up. I don't claim to fully > understand this one so don't ask me too many questions on it :-) This is kind of a weird scenario. Wouldn't you just do the digit collection at the UA, then make the call (en-bloc) to the PSTN gateway? And then it's up to the PSTN GW to do overlap sending if it pleases. If the UA can't do the digit collection and insists on doing overlap (because it is itself a PSTN gateway for example), then the normal overlap sending procedures should apply (with the sequential INVITEs). I don't think we should use KPLM for dialling. ------_=_NextPart_001_01C3638E.34FC54E6 Content-Type: text/html RE: [Sipping] App-Interaction: Considering models

Cullen Jennings wrote:
> If the phone sent DTMF over INFO, the people with this
> problem would be happy. The development effort to send DTMF
> over INFO is very low. It would be possible to solve this
> example with 2833 to the 323 translator. The IETF suggested
> this was the right way to go - I am unaware of anyone who did
> that. Everyone decided some weird variant of sending it over
> SIP looked like a much better idea even though it was not
> interoperable. Perhaps they were all insane but people buying
> equipment convinced vendors to build it. If we want to
> standardize something that is going to be widely implemented,
> I think we need to keep what is deployed today and why it
> happened in mind.

The RFC2833 to H.323 translator idea is hightly dubious to me
and I really don't see where that translater would sit to be able
to perform this task. It would seem to have to sit at the media
termination, which would imply that the endpoint supports RFC2833
in the first place.

Certainly, support for RFC2833 is included in H.323 starting with
version 4. So it would probably be much easier to support that than
the translator idea.

> Another scenario similar to this happens when the PSTN GW is
> a SIP GW that may support 2833 but it is doing overlap
> dialing and uses KPML to tell the UA to keep sending it more
> digits before media is set up. I don't claim to fully
> understand this one so don't ask me too many questions on it :-)

This is kind of a weird scenario. Wouldn't you just do the digit collection
at the UA, then make the call (en-bloc) to the PSTN gateway? And then it's up
to the PSTN GW to do overlap sending if it pleases.

If the UA can't do the digit collection and insists on doing overlap (because
it is itself a PSTN gateway for example), then the normal overlap sending
procedures should apply (with the sequential INVITEs).

I don't think we should use KPLM for dialling.

------_=_NextPart_001_01C3638E.34FC54E6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Mon Aug 18 08:04:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17013 for ; Mon, 18 Aug 2003 08:04:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oikA-00034G-Ke for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 08:04:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IC4E1L011788 for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 08:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oikA-000343-Hr for sipping-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 08:04:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17002 for ; Mon, 18 Aug 2003 08:04:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oik9-0006km-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 08:04:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oik8-0006kf-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 08:04:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oijx-00032h-Jn; Mon, 18 Aug 2003 08:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oijG-00031f-VA for sipping@optimus.ietf.org; Mon, 18 Aug 2003 08:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16938 for ; Mon, 18 Aug 2003 08:03:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oijG-0006jg-00 for sipping@ietf.org; Mon, 18 Aug 2003 08:03:18 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19oijF-0006jc-00 for sipping@ietf.org; Mon, 18 Aug 2003 08:03:17 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7IC347W010891; Mon, 18 Aug 2003 14:03:04 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 18 Aug 2003 14:03:27 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Sean Olson'" , Rohan Mahy , Jonathan Rosenberg Cc: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements Date: Mon, 18 Aug 2003 14:02:50 +0200 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, I don't know if this has been discussed, but how about putting the GRUU in the Contact header, AND define a "gruu" header/uri parameter. Now, existing nodes will, as Rohan put it, be as broken as they are today, but they will still work, and nodes supporting GRUU will use the gruu parameter to indicate/detect that the uri in the Contact header is a GRUU. But, no new header needs to be defined (I think we already have too many headers carrying URIs, many of which we don't use - or even don't know how or when to use), and there would be no backward compability issues, and no need to redefine existing headers/functionality. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: 16. elokuuta 2003 1:50 > To: Rohan Mahy; Jonathan Rosenberg > Cc: Adam Roach; 'Alan Johnston'; 'sipping@ietf.org' > Subject: Re: [Sipping] Re: Comment on GRUU requirements > > > I have to agree with Rohan. I don't understand the > purpose of NOT placing the GRUU in the Contact: header > if possible. Whether or not this GRUU ties into a > proxy is up for debate, but in practice I believe it > will be the rule rather than the exception. Similar > (but not identical) to the fact that a registrar is > not absolutely necessary to use SIP but it sure makes > things easier in practice. > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.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 exim@www1.ietf.org Mon Aug 18 11:51:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24404 for ; Mon, 18 Aug 2003 11:51:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omHp-0002FA-FL for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 11:51:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IFpDsn008618 for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 11:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omHp-0002Ev-1l for sipping-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 11:51:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24381 for ; Mon, 18 Aug 2003 11:51:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19omHn-0000WX-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 11:51:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19omHn-0000WU-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 11:51:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omHe-0002Dx-Nm; Mon, 18 Aug 2003 11:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19omHK-0002DN-3t for sipping@optimus.ietf.org; Mon, 18 Aug 2003 11:50:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24371 for ; Mon, 18 Aug 2003 11:50:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19omHI-0000WP-00 for sipping@ietf.org; Mon, 18 Aug 2003 11:50:40 -0400 Received: from web41507.mail.yahoo.com ([66.218.93.90]) by ietf-mx with smtp (Exim 4.12) id 19omHH-0000VI-00 for sipping@ietf.org; Mon, 18 Aug 2003 11:50:39 -0400 Message-ID: <20030818155006.27660.qmail@web41507.mail.yahoo.com> Received: from [207.46.225.252] by web41507.mail.yahoo.com via HTTP; Mon, 18 Aug 2003 08:50:06 PDT Date: Mon, 18 Aug 2003 08:50:06 -0700 (PDT) From: Sean Olson Subject: RE: [Sipping] Re: Comment on GRUU requirements To: "Christer Holmberg \(JO/LMF\)" , Rohan Mahy , Jonathan Rosenberg Cc: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" In-Reply-To: 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: , I believe this was Adam's original suggestion. Works for me. --- "Christer Holmberg (JO/LMF)" wrote: > > Hi, > > I don't know if this has been discussed, but how > about putting the GRUU in the Contact header, AND > define a "gruu" header/uri parameter. Now, existing > nodes will, as Rohan put it, be as broken as they > are today, but they will still work, and nodes > supporting GRUU will use the gruu parameter to > indicate/detect that the uri in the Contact header > is a GRUU. But, no new header needs to be defined (I > think we already have too many headers carrying > URIs, many of which we don't use - or even don't > know how or when to use), and there would be no > backward compability issues, and no need to redefine > existing headers/functionality. > > Regards, > > Christer Holmberg > Ericsson Finland > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: 16. elokuuta 2003 1:50 > > To: Rohan Mahy; Jonathan Rosenberg > > Cc: Adam Roach; 'Alan Johnston'; > 'sipping@ietf.org' > > Subject: Re: [Sipping] Re: Comment on GRUU > requirements > > > > > > I have to agree with Rohan. I don't understand the > > purpose of NOT placing the GRUU in the Contact: > header > > if possible. Whether or not this GRUU ties into a > > proxy is up for debate, but in practice I believe > it > > will be the rule rather than the exception. > Similar > > (but not identical) to the fact that a registrar > is > > not absolutely necessary to use SIP but it sure > makes > > things easier in practice. > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > > http://sitebuilder.yahoo.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 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.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 exim@www1.ietf.org Mon Aug 18 13:24:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26528 for ; Mon, 18 Aug 2003 13:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onji-0005X3-SR for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 13:24:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IHO6mq021259 for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 13:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onji-0005Wo-OQ for sipping-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 13:24:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26514 for ; Mon, 18 Aug 2003 13:24:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19onjg-00012e-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 13:24:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19onjg-00012b-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 13:24:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onjd-0005Vp-AD; Mon, 18 Aug 2003 13:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onir-0005UB-GH for sipping@optimus.ietf.org; Mon, 18 Aug 2003 13:23:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26493 for ; Mon, 18 Aug 2003 13:23:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19onip-00012K-00 for sipping@ietf.org; Mon, 18 Aug 2003 13:23:11 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19onio-000125-00 for sipping@ietf.org; Mon, 18 Aug 2003 13:23:10 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7IHMSlt006182; Mon, 18 Aug 2003 13:22:28 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Aug 2003 12:22:28 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86307@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , Jonathan Rosenberg Cc: Adam Roach , "'Alan Johnston'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements Date: Mon, 18 Aug 2003 12:22:27 -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: , Rohan Mahy [mailto:rohan@cisco.com] writes: > In fact we already have a precedent (in the REGISTER method) > that a Contact should be valid for more than one dialog. This is one of those perfect-hindsight problems, but the issue here is that "Contact" in REGISTER is wildly different in meaning than "Contact" in any other context (except, arguably, 300-class responses). These uses really should have employed a different header than "Contact". Citing them as precedent is shaky at best. /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 exim@www1.ietf.org Mon Aug 18 14:46:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29211 for ; Mon, 18 Aug 2003 14:46:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19op17-0000hE-Ro for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 14:46:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IIk9qW002670 for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 14:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19op17-0000gz-NN for sipping-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 14:46:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29192 for ; Mon, 18 Aug 2003 14:46:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19op14-0001gN-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 14:46:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19op14-0001gK-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 14:46:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19op0z-0000g0-Ql; Mon, 18 Aug 2003 14:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19op0P-0000f9-PJ for sipping@optimus.ietf.org; Mon, 18 Aug 2003 14:45:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29179 for ; Mon, 18 Aug 2003 14:45:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19op0N-0001g5-00 for sipping@ietf.org; Mon, 18 Aug 2003 14:45:23 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19op0M-0001fu-00 for sipping@ietf.org; Mon, 18 Aug 2003 14:45:22 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7IIiolt006321 for ; Mon, 18 Aug 2003 14:44:51 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Aug 2003 13:44:50 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86309@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements Date: Mon, 18 Aug 2003 13:44:42 -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: , Yes, this was my original proposal; however, I appreciate the concern that this approach requires all requests -- even those in a dialog -- to go through a GRUU server. After considerable thought, I believe that this approach coupled with Alan's suggestion that non-firewalled clients can generate their own GRUUs seems to allay those concerns. So, as long as "colocating a GRUU server with a UAS" is explicitly supported, I'm happy to see this as a solution. /a > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Monday, August 18, 2003 10:50 > To: Christer Holmberg (JO/LMF); Rohan Mahy; Jonathan Rosenberg > Cc: Adam Roach; 'Alan Johnston'; 'sipping@ietf.org' > Subject: RE: [Sipping] Re: Comment on GRUU requirements > > > I believe this was Adam's original suggestion. Works > for me. > > --- "Christer Holmberg (JO/LMF)" > wrote: > > > > Hi, > > > > I don't know if this has been discussed, but how > > about putting the GRUU in the Contact header, AND > > define a "gruu" header/uri parameter. Now, existing > > nodes will, as Rohan put it, be as broken as they > > are today, but they will still work, and nodes > > supporting GRUU will use the gruu parameter to > > indicate/detect that the uri in the Contact header > > is a GRUU. But, no new header needs to be defined (I > > think we already have too many headers carrying > > URIs, many of which we don't use - or even don't > > know how or when to use), and there would be no > > backward compability issues, and no need to redefine > > existing headers/functionality. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > -----Original Message----- > > > From: Sean Olson [mailto:seancolson@yahoo.com] > > > Sent: 16. elokuuta 2003 1:50 > > > To: Rohan Mahy; Jonathan Rosenberg > > > Cc: Adam Roach; 'Alan Johnston'; > > 'sipping@ietf.org' > > > Subject: Re: [Sipping] Re: Comment on GRUU > > requirements > > > > > > > > > I have to agree with Rohan. I don't understand the > > > purpose of NOT placing the GRUU in the Contact: > > header > > > if possible. Whether or not this GRUU ties into a > > > proxy is up for debate, but in practice I believe > > it > > > will be the rule rather than the exception. > > Similar > > > (but not identical) to the fact that a registrar > > is > > > not absolutely necessary to use SIP but it sure > > makes > > > things easier in practice. > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! SiteBuilder - Free, easy-to-use web site > > design software > > > http://sitebuilder.yahoo.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 > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.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 exim@www1.ietf.org Mon Aug 18 18:49:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08327 for ; Mon, 18 Aug 2003 18:49:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19osoG-0000ag-U2 for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 18:49:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IMn8YS002266 for sipping-archive@odin.ietf.org; Mon, 18 Aug 2003 18:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19osoG-0000aT-Oo for sipping-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 18:49:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08309 for ; Mon, 18 Aug 2003 18:49:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19osoD-0003Bw-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 18:49:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19osoD-0003Bt-00 for sipping-web-archive@ietf.org; Mon, 18 Aug 2003 18:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oso9-0000ZW-Ga; Mon, 18 Aug 2003 18:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19osnI-0000Ye-DO for sipping@optimus.ietf.org; Mon, 18 Aug 2003 18:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08295; Mon, 18 Aug 2003 18:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19osnF-0003Bg-00; Mon, 18 Aug 2003 18:48:05 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19osnE-0003Bd-00; Mon, 18 Aug 2003 18:48:04 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h7IMm4J05291; Mon, 18 Aug 2003 15:48:04 -0700 (PDT) Message-Id: <200308182248.h7IMm4J05291@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sipping@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 18 Aug 2003 15:48:04 -0700 Subject: [Sipping] RFC 3578 on Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) 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 Request for Comments is now available in online RFC libraries. RFC 3578 Title: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) Author(s): G. Camarillo, A. B. Roach, J. Peterson, L. Ong Status: Standards Track Date: August 2003 Mailbox: Gonzalo.Camarillo@ericsson.com, adam@dynamicsoft.com, jon.peterson@neustar.biz, lyong@ciena.com Pages: 13 Characters: 26667 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-overlap-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3578.txt This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030818154630.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3578 --OtherAccess Content-Type: Message/External-body; name="rfc3578.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030818154630.RFC@RFC-EDITOR.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 exim@www1.ietf.org Tue Aug 19 09:57:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10837 for ; Tue, 19 Aug 2003 09:57:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p6zB-0005xB-CR for sipping-archive@odin.ietf.org; Tue, 19 Aug 2003 09:57:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JDvLtX022881 for sipping-archive@odin.ietf.org; Tue, 19 Aug 2003 09:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p6zB-0005wy-8C for sipping-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 09:57:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10790 for ; Tue, 19 Aug 2003 09:57:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p6z2-0000Qw-00 for sipping-web-archive@ietf.org; Tue, 19 Aug 2003 09:57:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p6z2-0000Qs-00 for sipping-web-archive@ietf.org; Tue, 19 Aug 2003 09:57:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p6ys-0005rE-Dp; Tue, 19 Aug 2003 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJnl-0007NM-Bl for sipping@optimus.ietf.org; Thu, 14 Aug 2003 11:14:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14512 for ; Thu, 14 Aug 2003 11:14:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJnk-0003IS-00 for sipping@ietf.org; Thu, 14 Aug 2003 11:14:08 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJnj-0003I7-00 for sipping@ietf.org; Thu, 14 Aug 2003 11:14:07 -0400 Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJM00IEC7GTIZ@firewall.wcom.com> for sipping@ietf.org; Thu, 14 Aug 2003 15:10:05 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJM005017GNHR@pmismtp06.wcomnet.com>; Thu, 14 Aug 2003 15:10:05 +0000 (GMT) Received: from hsinnreich2 ([166.50.136.152]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJM005167GPE7@pmismtp06.wcomnet.com>; Thu, 14 Aug 2003 15:10:04 +0000 (GMT) Date: Thu, 14 Aug 2003 10:10:01 -0500 From: Henry Sinnreich Subject: RE: AW: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: <5.2.0.9.0.20030807200108.05436950@mailhost.fokus.gmd.de> To: "'Jiri Kuthan'" , "'Dean Willis'" , "'Liess, Laura'" Cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, aboba@internaut.com, sipping@ietf.org, "'Dumler, Alexander'" , "'Wolff, Christian'" Message-id: <0HJM005197GQE7@pmismtp06.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNiURYmoHrpxx0ARAWAvHbYY+j4fgAIiJNg 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 > Still less hard than accounting over a protocol which does not exist. I agree. Also, I will keep reminding folks there are web services out there. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Jiri Kuthan > Sent: Thursday, August 07, 2003 1:03 PM > To: Dean Willis; Liess, Laura > Cc: hgs@cs.columbia.edu; jdrosen@dynamicsoft.com; aboba@internaut.com; > sipping@ietf.org; Dumler, Alexander; Wolff, Christian > Subject: Re: AW: AW: [Sipping] FYI: RADIUS & SIP > > At 07:56 PM 8/7/2003, Dean Willis wrote: > >On Wed, 2003-08-06 at 03:17, Liess, Laura wrote: > >> What about the accounting draft draft-schulzrinne-accounting-sip- > 01.txt? Any reason for not working on it? > >> Laura > > > >Accounting over a non-reliable transport protocol is a Very Hard > >Problem. That's one of the reaons for DIAMETER. > > Still less hard than accounting over a protocol which does not exist. > We actually developed some DIAMETER code but the problem is it is > not running anywhere. > > -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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Tue Aug 19 15:56:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05831 for ; Tue, 19 Aug 2003 15:56:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCaM-0007Zy-0B for sipping-archive@odin.ietf.org; Tue, 19 Aug 2003 15:56:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JJu5Gc029130 for sipping-archive@odin.ietf.org; Tue, 19 Aug 2003 15:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCaL-0007Zl-Ta for sipping-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 15:56:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05773 for ; Tue, 19 Aug 2003 15:56:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCaK-00073n-00 for sipping-web-archive@ietf.org; Tue, 19 Aug 2003 15:56:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pCaJ-00073k-00 for sipping-web-archive@ietf.org; Tue, 19 Aug 2003 15:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCaJ-0007YT-4r; Tue, 19 Aug 2003 15:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCa9-0007Xb-Mw for sipping@optimus.ietf.org; Tue, 19 Aug 2003 15:55:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05734 for ; Tue, 19 Aug 2003 15:55:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCa7-00072k-00 for sipping@ietf.org; Tue, 19 Aug 2003 15:55:52 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19pCa7-00071K-00 for sipping@ietf.org; Tue, 19 Aug 2003 15:55:51 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Aug 2003 12:55:21 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7JJtIPk005100; Tue, 19 Aug 2003 12:55:19 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKN86184; Tue, 19 Aug 2003 12:47:23 -0700 (PDT) Date: Tue, 19 Aug 2003 12:58:15 -0700 Subject: Re: [Sipping] Re: Comment on GRUU requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jonathan Rosenberg , "'Alan Johnston'" , "'sipping@ietf.org'" To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86307@dyn-tx-exch-001.dynamicsoft.com> Message-Id: <78543E8F-D27F-11D7-B410-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Monday, August 18, 2003, at 10:22 AM, Adam Roach wrote: > Rohan Mahy [mailto:rohan@cisco.com] writes: > >> In fact we already have a precedent (in the REGISTER method) >> that a Contact should be valid for more than one dialog. > > This is one of those perfect-hindsight problems, but > the issue here is that "Contact" in REGISTER is wildly > different in meaning than "Contact" in any other context > (except, arguably, 300-class responses). I completely disagree; and I believe that this is the core of the semantic problem we are having. I take "Contact" to mean a URI where a particular user or service can be reached. This makes a Contact in a REGISTER no different from a Contact in an INVITE or a in the dialog package. I believe that any other definition of Contact is completely contrived. thanks, -rohan > These uses really should have employed a different header > than "Contact". Citing them as precedent is shaky > at best. > > /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 exim@www1.ietf.org Tue Aug 19 17:31:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10045 for ; Tue, 19 Aug 2003 17:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pE4K-0004Ar-LT for sipping-archive@odin.ietf.org; Tue, 19 Aug 2003 17:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JLV8g1016039 for sipping-archive@odin.ietf.org; Tue, 19 Aug 2003 17:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pE4K-0004Ac-HB for sipping-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 17:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10030 for ; Tue, 19 Aug 2003 17:31:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pE4I-0000RT-00 for sipping-web-archive@ietf.org; Tue, 19 Aug 2003 17:31:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pE4H-0000RP-00 for sipping-web-archive@ietf.org; Tue, 19 Aug 2003 17:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pE4E-00049M-Fd; Tue, 19 Aug 2003 17:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pE47-00048S-Av for sipping@optimus.ietf.org; Tue, 19 Aug 2003 17:30:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10002 for ; Tue, 19 Aug 2003 17:30:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pE44-0000Qx-00 for sipping@ietf.org; Tue, 19 Aug 2003 17:30:53 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19pE44-0000Ps-00 for sipping@ietf.org; Tue, 19 Aug 2003 17:30:52 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7JLU7lt009991; Tue, 19 Aug 2003 17:30:07 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Aug 2003 16:30:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86325@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , Adam Roach Cc: Jonathan Rosenberg , "'Alan Johnston'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements Date: Tue, 19 Aug 2003 16:30:06 -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: , Rohan Mahy [mailto:rohan@cisco.com] writes: > I take "Contact" to mean a URI where a particular user or > service can be reached. This makes a Contact in a REGISTER > no different from a Contact in an INVITE or a in > the dialog package. I believe that any other definition of > Contact is completely contrived. Contrived, perhaps -- but practical and necessary. Without the context provided by a route set, many of the applications of contact you describe don't necessarily resolve from the Internet. In an ideal world, your characterization of Contact would be spot on; the real world, however, isn't always so cooperative. /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 exim@www1.ietf.org Wed Aug 20 10:40:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11795 for ; Wed, 20 Aug 2003 10:40:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pU8E-0007TM-PZ for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 10:40:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KEeEPI028720 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 10:40:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pU8E-0007T9-Lo for sipping-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 10:40:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11788 for ; Wed, 20 Aug 2003 10:40:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pU8C-0001QH-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 10:40:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pU8B-0001QE-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 10:40:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pU82-0007RU-7C; Wed, 20 Aug 2003 10:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pU7D-0007QL-5f for sipping@optimus.ietf.org; Wed, 20 Aug 2003 10:39:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11748 for ; Wed, 20 Aug 2003 10:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pU79-0001PG-00 for sipping@ietf.org; Wed, 20 Aug 2003 10:39:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19pU78-0001Os-00 for sipping@ietf.org; Wed, 20 Aug 2003 10:39:06 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2003 07:38:37 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7KEcYPl008070; Wed, 20 Aug 2003 07:38:34 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKO68291; Wed, 20 Aug 2003 07:30:31 -0700 (PDT) Date: Tue, 19 Aug 2003 23:09:50 -0700 Subject: Re: [Sipping] Question on pick-up in service-examples-04 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alan Johnston , "Elwell, John" , "'sipping@ietf.org'" To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F3A82D2.3030107@dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Wednesday, August 13, 2003, at 11:26 AM, Jonathan Rosenberg wrote: > Old email, and a sort-of-related point. > > It seems to me that the INVITE/Replaces really needs to be targeted at > the GRUU for Alice's phone, no? Otherwise this service won't work in > places where Carol is located in a different network. For example, if > Carol takes here SIP phone to a hotel, she won't be able to directly > reach the contact, and so the pickup will fail. I think we want pickup > services to work independent of the physical locations of the two > devices. > > In that case what is more useful in the dialog event package is the > gruu, not just the contact. Or this can be seen as yet another motivation to always put a GRUU in the Contact header.... thx, -r > > -Jonathan R. > > Alan Johnston wrote: > >> John, >> You are correct - the NOTIFY F5 does not show the Contact URI. It >> should have been shown in a Remote Target tag. However, this tag is >> listed as optional in the dialog package - I'm not sure why as it is >> useful in a number of situations. >> I agree that it is important to use the Contact URI in this flow. >> Thanks, >> Alan Johnston >> MCI >> At 09:41 AM 7/10/2003 +0100, Elwell, John wrote: >>> Can anyone explain something to me in section 2.16 (call pick-up)? >>> >>> In F7, the Request-URI is the contact URI for Alice: >>> alice@client.atlanta.example.com >>> >>> It is not clear how Carol's UA receives this contact address. F5 >>> from Bob to Carol provides only the AoR: alice@atlanta.example.com. >>> >>> I believe it is important to use the contact URI in F7 to avoid the >>> case where the INVITE request reaches the wrong UA at Alice. This is >>> particularly true when Alice is in a legacy network - the contact >>> address might help selection of the correct gateway. >>> >>> John (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 > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > 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 exim@www1.ietf.org Wed Aug 20 13:58:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25809 for ; Wed, 20 Aug 2003 13:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXDj-0001Q5-2u for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 13:58:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KHw76Q005456 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 13:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXDi-0001Pv-Vg for sipping-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 13:58:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25773 for ; Wed, 20 Aug 2003 13:58:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXDg-0004bt-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 13:58:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pXDg-0004bq-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 13:58:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXDd-0001Oo-HI; Wed, 20 Aug 2003 13:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXCy-0001Nb-TK for sipping@optimus.ietf.org; Wed, 20 Aug 2003 13:57:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25713 for ; Wed, 20 Aug 2003 13:57:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXCw-0004ap-00 for sipping@ietf.org; Wed, 20 Aug 2003 13:57:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19pXCv-0004Zb-00 for sipping@ietf.org; Wed, 20 Aug 2003 13:57:17 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2003 10:56:47 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7KHuji1021815; Wed, 20 Aug 2003 10:56:45 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKO93096; Wed, 20 Aug 2003 10:48:42 -0700 (PDT) Date: Wed, 20 Aug 2003 10:59:45 -0700 Subject: Re: [Sipping] App-Interaction: Considering models Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Adam Roach , sipping , Jonathan Rosenberg To: Cullen Jennings From: Rohan Mahy In-Reply-To: Message-Id: <14F433FE-D338-11D7-B410-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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.... On Wednesday, August 13, 2003, at 10:54 PM, Cullen Jennings wrote: > I think all of these proposals are significantly more complex than > using a > MESSAGE/NEW_METHOD/NOTIFY. I will mention a few issues with the > proposal > inline but first let me a few other proposals... > > All of these have a call flow like > >> UAC App Server UAS >> 1|-----INVITE---->| | >> 2| |-----INVITE---->| >> 3| |<-----200-------| >> 4|<-----200-------| | >> 5|---SIP MESG---->| | >> 6|<-----200-------| | > > The question for KMPL is, what method to use in msg 5. > > Proposal 1) Use MESSAGE. Many people think the semantics of message are > display this IM to a user. Perhaps, but I send IM to applications and > they > send me back things like stock quotes all the time. I have no problem > with > semantics of MESSAGE being deliver this message to the addressed user > or > automaton. That's what we are doing here. Misrouted message will cause > trivial problems, but this is a bogus issue - misrouted INVITE or > MESSAGE > will cause problems to - don't misroute things. Adam has already given good/likely concrete examples where "bad things" can happen. Unless you can prove that these won't actually happen, then I suggest we discard this option and move on. > Proposal 2) Use some new method like STIMULUS. The semantics of this > are > some user input stimulus is being sent - STIMULUS is to input what > MESSAGE > is to output. I'm fine with this option. It will work. Should this NEWMETHOD be used for responses and new markup or just responses? as long as you are sending them to the app server and not the UAS in your picture, this should be on a new dialog. > Proposal 3) Use NOTIFY. Semantics are, here is some information about > some > event that you requested to be informed about. The usual complaint on > this > one is that there was no Subscribe, or it was implicit, or it was > explicit, > or it violated some law of the SIP world. I think there was a > subscribe, it > was in the message that initiated the script. There is also a clear > time it > will end - when the script is terminated or when the dialog of the > message > that initiated the script ends. How long in seconds exactly is that again? ;-) Ah, you don't know unless you are using session timer you say. Well, unless you are requiring session timer, I object on the grounds that my UA can never recover lost state with this "implicit subscription" mechanism. > We all remember that implicit subscribes > where bad (whatever an implicit subscribe is) but people seem to have > a hard > time remembering why this will be bad here. also, if you plan to use implicit subscriptions, this will require an initial NOTIFY after the initial INVITE. this has been a remarkable PAI for REFER. also, since this is going to a different UA than the UAS (if you sent it anyway you would screw up the CSeqs) it needs to be on a different dialog, but then you need a way to initiate this dialog which gets pretty ugly, since there is no SUBSCRIBE. You would need to send a NOTIFY with one tag only, and then complete the dialog in the response to the NOTIFY. I think implicit subs are bad in this case because: a) the dialog identifiers for the subscription are in a (currently) illegal combination of SIP messages b) the state of the associated dialog is completely decoupled from the state of subscription, which makes the Subscription-State header (which is supposed to convey BOTH) fairly useless. c) experience has shown that implicit subs for REFER where a pain to implement and only now folks are starting to get it right; this use is even more complicated d) you need a different GRUU for each "subscription" e) even if you use a GRUU for each "subscription", you have a dialog correlation problem in the example I give below. UA1 App Proxy UA2 UA3 | | | | | |INVITE------->| | | | | |INVITE------>| | | | |App-Info: * |INVITE------->| | | | |App-Info: * | | | | |<---------180-| | | |<----------------NOTIFY-----| | | |-----------------200--------| | | | | | | | | |INVITE---------------------->| | | |App-Info: * | | | | |<------------------------180-| | |<---------------------NOTIFY---------------| | |----------------------200------------------| | | | | | if the header is App-Info: sip:unique-instance23988413@appserver, then the appserver still receives requests from multiple UAs. The NOTIFYs are on completely separate new dialogs. I don't think there is any way to correlate the first notify with the first INVITE fork, and the second notify with the second INVITE fork. f) timers are not explicit ... g) there is no technical reason given why a new method would not work. the only objections have been philosophical !!!FOR GODS SAKE DONT USE IMPLICIT SUBSCRIPTIONS!!!! > All 3 of these proposals have something in common - there is no > concrete > argument that any of them would not work. I think I have provided ample bad reasons why not to do 1 and 3. > They send to a URI the AS provided > so there are no forking issues. There is some grief on the semantics. > Option > 2 has the advantage of it lets us define the semantics however we > want. I > think that 2 is the best way to go but I don't care greatly. I do need > convincing on what's wrong with these to move to something more > complex. > > More comments inline likewise... > On 8/13/03 3:32 PM, "Adam Roach" wrote: > >> After considering Jonathan's contention that defining >> a new method for conveying stimulus is creating something >> that is similar in meaning to NOTIFY, I'm inclined to >> agree to some point. There are still subtle differences >> in meaning, so I'm not completely convinced that a new >> method is wrong, but I understand the point he's trying >> to make. >> >> After discussing it privately with others, I've concluded >> that there are three viable models worth considering. There >> are, of course, some minor variations that can be made to >> each. >> >> 1) Standard HTTP Handling >> >> UAC App Server UAS >> 1|-----INVITE---->| | >> 2| |-----INVITE---->| >> 3| |<-----200-------| >> 4|<-----200-------| | AS adds HTTP URL to 200 >> 5|---HTTP GET---->| | UAC requests KPML script >> 6|<-----200-------| | AS replies with script >> 7|---HTTP POST--->| | UAC provides digits >> 8|<-----200-------| | AS acknowledges digits >> >> Of the three options presented here, I see this as the best >> solution. Basically, the app server includes an HTTP URL >> in the 200 response to the INVITE that it has proxied. The >> UAC then does a GET on the KPML script. Just like with >> HTML forms, the UAC does whatever local stuff is necessary >> to "fill out the form" (in this case, collect digits), and >> then posts the result back to the App Server. This is all >> plain-Jane unextended HTTP as it was intended to work. >> > > One of the difficult parts of this is security. agreed. this also potentially has the same dialog correlation problem that I described above. > This will get more complicated once you provide a way to send in > message 4 > the credentials that will allow 7. It may also make the App-Info > header only > really work with scripts that use HTTP to post instead of other things. > Also, in the case of a financial institutions that have to log > electronic > communications, you will need to provide way to insert logging HTTP > proxies > and probably proxies for FW traversal too. Of course the AS or the UAC > will > need to figure out the network topology to know if the AS is inside or > outside the FW. It's possible to configure all the domain and HTTP > proxies > rules into the device but it still hard to secure - particularly on > devices > that don't want to implement HTTPS due to not much memory. > > >> 2) Explicit Subscriptions (with GRUU) >> >> UAC App Server UAS >> 1|-----INVITE---->| | >> 2| |-----INVITE---->| AS extracts GRUU from INVITE >> 3| |<-----200-------| >> 4|<-----200-------| | >> 5|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script >> 6|------200------>| | >> 7|-----NOTIFY---->| | >> 8|<-----200-------| | >> 9|-----NOTIFY---->| | UAC provides digits >> A|<-----200-------| | AS acknowledges digits >> >> My second choice would be an explicit subscription to stimulus >> events. The only sticky part in this solution is the question >> of how the AS can route a SUBSCRIBE to the UAC. Once we have >> a GRUU solution in place, this is a no brainer: the AS can >> extract the GRUU from the INVITE, and use it as the target >> of its SUBSCRIBE. The KPML script is included in the SUBSCRIBE, >> and essentially serves as a filter. I don't see how Adam plans to correlate the SUBSCRIBE with the INVITE-initiated dialog. You can't send the SUBSCRIBE on the existing dialog, because you will screw up the CSeq space. btw: If an event package is defined for this, will we allow PUBLISH as well? > I sort of see this one, but what if the App Server wanted to run an > App on > the UAS instead of the UAC. Would the 180 have the GRU? Would it be > reliable? > > I seem to recall someone asking about the expire time on the > subscription > :-) > > I'd be keener on GRUU solutions if GRUU was a solved problem. we need to solve this problem anyway if you want transfer to work, so I'm not especially concerned. >> 3) Explicit Subscriptions (with REFER) >> >> UAC App Server UAS >> 1|-----INVITE---->| | >> 2| |-----INVITE---->| >> 3| |<-----200-------| >> 4|<-----200-------| | AS adds SIP URL to 200 >> 5|-----REFER----->| | >> 6|<-----200-------| | >> 7|<----NOTIFY-----| | >> 8|------481------>| | >> 9|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script >> A|------200------>| | >> B|-----NOTIFY---->| | >> C|<-----200-------| | >> D|-----NOTIFY---->| | UAC provides digits >> E|<-----200-------| | AS acknowledges digits >> >> Although somewhat chattier than the previous solution, this gets >> around >> the GRUU issue by having the AS provide a SIP URI that routes to >> itself >> in the 200 response. The UAC then uses this URI to send a REFER to the >> AS. This REFER tells the AS to SUBSCRIBE to the UAC. The flow from >> that >> point forward is the same as for solution 2. > > I got to admit, I had never considered anything like this. I think it > is > going to be hard to convince folks this is really easier and better > than > sending DTMF over INFO. Keep in mind that KPML is for little device > that > think 14k of memory is a lot. Real devices are just going to do VXML > and > HTML and ignore KPML. I don't understand how Adam can correlate the REFER (which has to be using a different dialog than the original INVITE) with the dialog for which you are interested in collecting digits. thanks, -rohan > Cullen > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 20 14:01:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26049 for ; Wed, 20 Aug 2003 14:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXGZ-0001id-Jn for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 14:01:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KI13oN006590 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 14:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXGZ-0001hh-Gi for sipping-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 14:01:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26016 for ; Wed, 20 Aug 2003 14:00:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXGX-0004fi-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 14:01:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pXGW-0004ff-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 14:01:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXGX-0001d4-Lb; Wed, 20 Aug 2003 14:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXGL-0001cS-9M for sipping@optimus.ietf.org; Wed, 20 Aug 2003 14:00:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25993 for ; Wed, 20 Aug 2003 14:00:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXGI-0004fH-00 for sipping@ietf.org; Wed, 20 Aug 2003 14:00:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19pXGI-0004en-00 for sipping@ietf.org; Wed, 20 Aug 2003 14:00:46 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2003 11:00:16 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7KI0E8s000136; Wed, 20 Aug 2003 11:00:14 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKO93601; Wed, 20 Aug 2003 10:52:07 -0700 (PDT) Date: Wed, 20 Aug 2003 11:02:38 -0700 Subject: Re: [Sipping] App-Interaction: Considering models Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jonathan Rosenberg , sipping To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E862F9@dyn-tx-exch-001.dynamicsoft.com> Message-Id: <7C5D03F1-D338-11D7-B410-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Friday, August 15, 2003, at 04:58 PM, Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > >>> 2) Explicit Subscriptions (with GRUU) >> >> This was one of the solutions I outlined in my initial email, yes. >> GRUU is not the only problem. There is also the correlation problem - >> how does the UA know that the SUBSCRIBE comes from an entity >> along the >> call path? AUthorizing the subscribe as above would be really hard. > > The SUBSCRIBE itself will need to contain information about the > dialog for which it is requesting information anyway, right? > Getting this information requires you to be in a position that > would allow you to intercept the digits themselves. > > If you want to keep this information even more securely under > wraps, use sips: to set up the call; the dialog information > is revealed only to people in the call path, and only they would > be able to subscribe to keypad events. I wanted to clarify something about dialog usage in this example. A long running assumption that many seem to be making (not necessarily Jonathan or Adam) is that the stimulus from UA1 running the KPML script needs to travel over the same dialog that UA1 has with UA2, even though nobody wants the stimulus to go to UA2, it needs to go to some intermediary, or another UA somewhere. We no longer have a dialog, we have a "trialog". This trialog thing is an abomination which fortunately does not exist. Handling multiple dialogs resulting in the same set of dialogs (resulting from a forked request), and reference counting invites and subscriptions to determine when a dialog is finally terminated is already a huge pain. Trialogs simply don't work because each side of a dialog needs to manage their own CSeq space. 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 exim@www1.ietf.org Wed Aug 20 16:16:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07740 for ; Wed, 20 Aug 2003 16:16:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZNJ-0002dR-E3 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 16:16:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KKG9h4010129 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 16:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZNJ-0002dI-8s for sipping-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 16:16:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07716 for ; Wed, 20 Aug 2003 16:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pZNH-0007A5-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 16:16:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pZNG-0007A2-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 16:16:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZNC-0002bv-Bq; Wed, 20 Aug 2003 16:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZMV-0002b1-02 for sipping@optimus.ietf.org; Wed, 20 Aug 2003 16:15:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07662 for ; Wed, 20 Aug 2003 16:15:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pZMT-00079E-00 for sipping@ietf.org; Wed, 20 Aug 2003 16:15:17 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19pZMS-00078S-00 for sipping@ietf.org; Wed, 20 Aug 2003 16:15:16 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7KKETlt014899; Wed, 20 Aug 2003 16:14:29 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Aug 2003 15:14:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8633A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , Cullen Jennings Cc: Adam Roach , sipping , Jonathan Rosenberg Subject: RE: [Sipping] App-Interaction: Considering models Date: Wed, 20 Aug 2003 15:14:28 -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: , Rohan Mahy [mailto:rohan@cisco.com] writes: >> 1) Standard HTTP Handling > > this also potentially has the same dialog > correlation problem that I described above. You're right; it does. My enthusiasm for this solution is consequently waning. I will add that the "just use a new method" approach suffers from precisely the same relic. In fact, the only thing proposed to date which does not is... >> 2) Explicit Subscriptions (with GRUU) >> >> UAC App Server UAS >> 1|-----INVITE---->| | >> 2| |-----INVITE---->| AS extracts GRUU from INVITE >> 3| |<-----200-------| >> 4|<-----200-------| | >> 5|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script >> 6|------200------>| | >> 7|-----NOTIFY---->| | >> 8|<-----200-------| | >> 9|-----NOTIFY---->| | UAC provides digits >> A|<-----200-------| | AS acknowledges digits > I don't see how Adam plans to correlate the SUBSCRIBE with the > INVITE-initiated dialog. You can't send the SUBSCRIBE on the > existing dialog, because you will screw up the CSeq space. Of *course* you don't re-use the dialog. Steps 1 through 4 are in one dialog (between the UAC and the UAS); steps 5 through A are in a second dialog (between the App Server and the UAC). To answer the implied question about how to perform correlation, I suggest wholesale copying of section 3.2 from draft-ietf-sipping-dialog-package-02. > > I'd be keener on GRUU solutions if GRUU was a solved problem. > > we need to solve this problem anyway if you want transfer to work, so > I'm not especially concerned. Yes, I forgot to address this. Given the relative maturity of each, I imagine that App-Interaction will hit the finish line about the same time as the GRUU work. If you additionally consider complexity, GRUU should finish first. /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 exim@www1.ietf.org Wed Aug 20 17:10:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11543 for ; Wed, 20 Aug 2003 17:10:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19paDU-0005zh-CA for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 17:10:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KLA4xC023035 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 17:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19paDU-0005zS-8v for sipping-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 17:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11527 for ; Wed, 20 Aug 2003 17:09:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19paDS-0000Dn-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 17:10:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19paDR-0000Di-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 17:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19paDS-0005yB-1D; Wed, 20 Aug 2003 17:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19paD5-0005xa-1o for sipping@optimus.ietf.org; Wed, 20 Aug 2003 17:09:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11480 for ; Wed, 20 Aug 2003 17:09:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19paD2-0000DE-00 for sipping@ietf.org; Wed, 20 Aug 2003 17:09:36 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19paD2-0000D7-00 for sipping@ietf.org; Wed, 20 Aug 2003 17:09:36 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7KL947b025171; Wed, 20 Aug 2003 14:09:04 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKP20601; Wed, 20 Aug 2003 14:01:00 -0700 (PDT) Date: Wed, 20 Aug 2003 14:11:59 -0700 Subject: Re: [Sipping] App-Interaction: Considering models Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Cullen Jennings , sipping , Jonathan Rosenberg To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E8633A@dyn-tx-exch-001.dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Wednesday, August 20, 2003, at 01:14 PM, Adam Roach wrote: > Rohan Mahy [mailto:rohan@cisco.com] writes: > >>> 1) Standard HTTP Handling >> >> this also potentially has the same dialog >> correlation problem that I described above. > > You're right; it does. My enthusiasm for this solution > is consequently waning. > > I will add that the "just use a new method" approach > suffers from precisely the same relic. using a new method does not actually suffer from the dialog correlation problem. You are sending a feedback or stimulus body in the new method, which just needs to contain a session-id or dialog-information to describe the dialog for which the feedback/stimulus is associated. You can use the same URI (as long as it has GRUU properties) for ALL your feedback for the same service/application if you'd like (imagine a prepaid application that can use the same URI for a T3 gateway worth of sessions). I think this is a nice property. > In fact, the > only thing proposed to date which does not is... > >>> 2) Explicit Subscriptions (with GRUU) >>> >>> UAC App Server UAS >>> 1|-----INVITE---->| | >>> 2| |-----INVITE---->| AS extracts GRUU from INVITE >>> 3| |<-----200-------| >>> 4|<-----200-------| | >>> 5|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script >>> 6|------200------>| | >>> 7|-----NOTIFY---->| | >>> 8|<-----200-------| | >>> 9|-----NOTIFY---->| | UAC provides digits >>> A|<-----200-------| | AS acknowledges digits > >> I don't see how Adam plans to correlate the SUBSCRIBE with the >> INVITE-initiated dialog. You can't send the SUBSCRIBE on the >> existing dialog, because you will screw up the CSeq space. > > Of *course* you don't re-use the dialog. Steps 1 through 4 are > in one dialog (between the UAC and the UAS); steps 5 through A > are in a second dialog (between the App Server and the UAC). > > To answer the implied question about how to perform correlation, > I suggest wholesale copying of section 3.2 from > draft-ietf-sipping-dialog-package-02. ok, that would work fine. however, you require a subscription per dialog, unless you write a subscription filter body. >>> I'd be keener on GRUU solutions if GRUU was a solved problem. >> >> we need to solve this problem anyway if you want transfer to work, so >> I'm not especially concerned. > > Yes, I forgot to address this. Given the relative maturity > of each, I imagine that App-Interaction will hit the finish > line about the same time as the GRUU work. If you additionally > consider complexity, GRUU should finish first. > > /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 exim@www1.ietf.org Wed Aug 20 18:04:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14386 for ; Wed, 20 Aug 2003 18:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pb3x-00084S-PX for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 18:04:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KM4H9V031018 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 18:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pb3x-00084D-ML for sipping-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 18:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14299 for ; Wed, 20 Aug 2003 18:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pb3u-0000rC-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 18:04:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pb3u-0000r8-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 18:04:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pb3h-00082U-Bi; Wed, 20 Aug 2003 18:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pb3J-00081s-QI for sipping@optimus.ietf.org; Wed, 20 Aug 2003 18:03:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14192 for ; Wed, 20 Aug 2003 18:03:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pb3G-0000qD-00 for sipping@ietf.org; Wed, 20 Aug 2003 18:03:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19pb3G-0000pq-00 for sipping@ietf.org; Wed, 20 Aug 2003 18:03:34 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2003 15:03:05 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7KM328s021272; Wed, 20 Aug 2003 15:03:02 -0700 (PDT) Received: from [128.107.171.79] ([128.107.171.79]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHH45003; Wed, 20 Aug 2003 15:02:59 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 20 Aug 2003 15:02:57 -0700 Subject: Re: [Sipping] App-Interaction: Considering models From: Cullen Jennings To: Adam Roach , "'Rohan Mahy'" CC: sipping , Jonathan Rosenberg Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E8633A@dyn-tx-exch-001.dynamicsoft.com> 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 On 8/20/03 13:14, "Adam Roach" wrote: >> >> this also potentially has the same dialog >> correlation problem that I described above. .. Snip ... > In fact, the > only thing proposed to date which does not is... > >>> 2) Explicit Subscriptions (with GRUU) >>> >>> UAC App Server UAS >>> 1|-----INVITE---->| | >>> 2| |-----INVITE---->| AS extracts GRUU from INVITE >>> 3| |<-----200-------| >>> 4|<-----200-------| | >>> 5|<---SUBSCRIBE---| | AS SUBSCRIBEs with KPML script >>> 6|------200------>| | >>> 7|-----NOTIFY---->| | >>> 8|<-----200-------| | >>> 9|-----NOTIFY---->| | UAC provides digits >>> A|<-----200-------| | AS acknowledges digits > .. Snip... > >>> I'd be keener on GRUU solutions if GRUU was a solved problem. >> >> we need to solve this problem anyway if you want transfer to work, so >> I'm not especially concerned. > > Yes, I forgot to address this. Given the relative maturity > of each, I imagine that App-Interaction will hit the finish > line about the same time as the GRUU work. If you additionally > consider complexity, GRUU should finish first. > > /a > Yes, I agree with this logic. So are we coming to the conclusion that the GRUU/SUB/NOT is the right way to go? I can try and flesh out some details on this if we are. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 20 18:41:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17013 for ; Wed, 20 Aug 2003 18:41:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pbdZ-0001b4-5g for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 18:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KMf5Zp006132 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 18:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pbdZ-0001ap-1K for sipping-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 18:41:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16984 for ; Wed, 20 Aug 2003 18:40:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pbdV-0001Er-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 18:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pbdV-0001Eo-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 18:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pbdV-0001Ze-BZ; Wed, 20 Aug 2003 18:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pbcf-0001YN-MA for sipping@optimus.ietf.org; Wed, 20 Aug 2003 18:40:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16897 for ; Wed, 20 Aug 2003 18:40:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pbcc-0001DD-00 for sipping@ietf.org; Wed, 20 Aug 2003 18:40:06 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19pbcb-0001Co-00 for sipping@ietf.org; Wed, 20 Aug 2003 18:40:05 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7KMdClt015904; Wed, 20 Aug 2003 18:39:12 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Aug 2003 17:39:13 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8634A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , Adam Roach Cc: Cullen Jennings , sipping , Jonathan Rosenberg Subject: RE: [Sipping] App-Interaction: Considering models Date: Wed, 20 Aug 2003 17:39:12 -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: , Rohan Mahy [mailto:rohan@cisco.com] writes: > using a new method does not actually suffer from the dialog > correlation problem. You are sending a feedback or stimulus > body in the new method, which just needs to contain a session-id > or dialog-information to describe the dialog for which the > feedback/stimulus is associated. You are correct. Ignore my previous objection. /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 exim@www1.ietf.org Wed Aug 20 19:14:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18254 for ; Wed, 20 Aug 2003 19:14:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pc9V-00032h-2X for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 19:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KNE5SK011689 for sipping-archive@odin.ietf.org; Wed, 20 Aug 2003 19:14:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pc9U-00032S-Ua for sipping-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 19:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18222 for ; Wed, 20 Aug 2003 19:14:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pc9T-0001Z0-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 19:14:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pc9S-0001Yx-00 for sipping-web-archive@ietf.org; Wed, 20 Aug 2003 19:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pc9R-00031H-3d; Wed, 20 Aug 2003 19:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pc8h-0002vG-HO for sipping@optimus.ietf.org; Wed, 20 Aug 2003 19:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18184 for ; Wed, 20 Aug 2003 19:13:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pc8g-0001YR-00 for sipping@ietf.org; Wed, 20 Aug 2003 19:13:14 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19pc8f-0001Xr-00 for sipping@ietf.org; Wed, 20 Aug 2003 19:13:13 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7KNCVlt016100; Wed, 20 Aug 2003 19:12:31 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Aug 2003 18:12:32 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8634F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach , "'Rohan Mahy'" Cc: sipping , Jonathan Rosenberg Subject: RE: [Sipping] App-Interaction: Considering models Date: Wed, 20 Aug 2003 18:12:31 -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: , Cullen Jennings [mailto:fluffy@cisco.com] writes: > So are we coming to the conclusion that the > GRUU/SUB/NOT is the right way to go? I can try > and flesh out some details on this if we are. Personally, I now favor this method, since I consider the http correlation issue that we've discussed to be a non-starter. I don't think it's unsolvable; I just am wary of solutions that obviously need hacks, even when viewed at the mile-high level. However, my arguments for preferring explicit use of SUBSCRIBE over a new method are, at this point, largely philosophical, not technical. I'm not certain that discussion has played out completely yet. /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 exim@www1.ietf.org Thu Aug 21 21:27:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13111 for ; Thu, 21 Aug 2003 21:27:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q0hu-0003dY-1L for sipping-archive@odin.ietf.org; Thu, 21 Aug 2003 21:27:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M1REW5013976 for sipping-archive@odin.ietf.org; Thu, 21 Aug 2003 21:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q0ht-0003dL-Uf for sipping-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 21:27:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13095 for ; Thu, 21 Aug 2003 21:27:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q0hr-0004b5-00 for sipping-web-archive@ietf.org; Thu, 21 Aug 2003 21:27:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q0hq-0004b1-00 for sipping-web-archive@ietf.org; Thu, 21 Aug 2003 21:27:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q0gj-0003YW-Hi; Thu, 21 Aug 2003 21:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q0ft-0003Xi-Qf for sipping@optimus.ietf.org; Thu, 21 Aug 2003 21:25:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13020 for ; Thu, 21 Aug 2003 21:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q0fr-0004a8-00 for sipping@ietf.org; Thu, 21 Aug 2003 21:25:07 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19q0fq-0004a1-00 for sipping@ietf.org; Thu, 21 Aug 2003 21:25:06 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id A7367591A1; Fri, 22 Aug 2003 03:18:02 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-170-129.reverse.qdsl-home.de [212.202.170.129]) by fox.iptel.org (Postfix) with ESMTP id E661B591A0; Fri, 22 Aug 2003 03:18:01 +0200 (CEST) Message-Id: <5.2.0.9.0.20030822031252.038d6e10@mailhost.fokus.fhg.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 22 Aug 2003 03:21:39 +0200 To: Rohan Mahy , Jonathan Rosenberg From: Jiri Kuthan Subject: Re: [Sipping] Re: Update to 3pcc Cc: Dean Willis , David Schwartz , "'sipping@ietf.org'" In-Reply-To: <62A9F91C-CF49-11D7-91B8-0003938AF740@cisco.com> References: <3F3D0132.5020904@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.1 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , That's it, thanks Rohan. If there is an element in the scenario (gateway), which provides a valuable service (P$S$T$N), then it implements session timer to protect itself (to cut-off a call). Elements that don't provide a service may not support timer, who cares. -jiri At 07:53 PM 8/15/2003, Rohan Mahy wrote: >On Friday, August 15, 2003, at 08:50 AM, Jonathan Rosenberg wrote: > >>I agree with Dean that this is not at all what session timer was meant for. The spec is pretty explicit about its usage as a cleanup mechanism. > >if it works without changes to the existing mechanism, then what is the problem? > >>You'll have serious problems if the refreshing side is not trusted. Session timer allows either side to refresh. So, if this is a PC to phone case and PC is refreshing this won't work. > >the gateway is the refresher, and is trusted. the example i gave nicely fits a business model where the provider accounts for PSTN usage, but does not charge/account for arbitrary SIP sessions. Easy things should be easy, contrived things will be hard and will require a B2BUA. > >>Even when its the gateway refreshing, 403 doesnt cause the gateway to terminate the call - at least it shouldnt, I dont think. Nothing in the spec says to tear down the call if you get a 403 to an INVITE. > >you are correct, but the call will be torn down after the session expires. since the session is not refreshed when the proxy responds with a 403, the session will expire and the gateway will send a BYE. > >thanks, -- Jiri Kuthan http://iptel.org/~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 exim@www1.ietf.org Thu Aug 21 22:28:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15240 for ; Thu, 21 Aug 2003 22:28:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q1ep-00060I-Ud for sipping-archive@odin.ietf.org; Thu, 21 Aug 2003 22:28:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M2S7lu023072 for sipping-archive@odin.ietf.org; Thu, 21 Aug 2003 22:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q1ep-000603-Qq for sipping-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 22:28:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15207 for ; Thu, 21 Aug 2003 22:28:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q1em-000591-00 for sipping-web-archive@ietf.org; Thu, 21 Aug 2003 22:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q1em-00058y-00 for sipping-web-archive@ietf.org; Thu, 21 Aug 2003 22:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q1ej-0005yh-Oo; Thu, 21 Aug 2003 22:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q1e0-0005yE-VI for sipping@optimus.ietf.org; Thu, 21 Aug 2003 22:27:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15172 for ; Thu, 21 Aug 2003 22:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q1dx-00058i-00 for sipping@ietf.org; Thu, 21 Aug 2003 22:27:13 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19q1dw-00058f-00 for sipping@ietf.org; Thu, 21 Aug 2003 22:27:12 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 8F0B0591A1; Fri, 22 Aug 2003 04:20:13 +0200 (CEST) Received: from jku07.fokus.fraunhofer.de (port-212-202-170-129.reverse.qdsl-home.de [212.202.170.129]) by fox.iptel.org (Postfix) with ESMTP id BF237591A0; Fri, 22 Aug 2003 04:20:12 +0200 (CEST) Message-Id: <5.2.0.9.0.20030822032918.037243f8@mailhost.fokus.fhg.de> X-Sender: jku@mailhost.fokus.fhg.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 22 Aug 2003 04:22:21 +0200 To: Jonathan Rosenberg From: Jiri Kuthan Subject: Re: [Sipping] Re: Update to 3pcc Cc: David Schwartz , "'sipping@ietf.org'" In-Reply-To: <3F3A8EE0.4000404@dynamicsoft.com> References: <5.2.0.9.0.20030805180020.033c5e80@mailhost.fokus.gmd.de> <5.2.0.9.0.20030805180020.033c5e80@mailhost.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.1 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , At 09:17 PM 8/13/2003, Jonathan Rosenberg wrote: >Sorry for taking so long to weigh in here. >To address the specific billing issue, the problem is that, in fact, there ARE cases where the call is charged for differently if it was initiated as a result of click-to-dial. The user that makes the initial INVITE may not be the one that needs to be charged. There may be ways around that for REFER by having the INVITE carry some kind of special billing tokens or something (such tokens being pushed to the user in the Refer-To), but these then require the c2d provider and the caller to utilize the same provider. The 3pcc mechanism does not have this constraint. I would prefer focusing on a common case. I really do not think 3-rd party billing for click-to-dial is something very usual. If you think so, then that's the example which should come in the 3pcc draft. >However, in my mind, the real issue is one of control. 3pcc is useful in applications where the server needs to be in the signaling path in order to do or modify things. Thats not the case for all applications, but its true for many. Prepaid is one we have discussed as well. REFER just doesnt work there. I almost agree, but that's a different topic than I raised. >I'd also point out that the 3pcc spec is not saying that the best practice for c2d is to use 3pcc; it saying that if you want to do third party call control, here is how you do it. Sometimes, BCP for a technology is not to use it. I don't think IETF should document "BCP for 3pcc" on examples which are better implemented with another technology. If you are enthusiastic about HTTP, publish "BCP for Use of HTTP" and show examples of using HTTP to control media gateways, some people will not be happy either (unless it was April 1st). >I don't disagree that 3pcc for c2d can be complicated, and REFER does have a better story in terms of the media story. However, other work going on, namely the app interaction work, does address some of the big issues there in a pretty elegant way, I think. I really prefer keeping simple things simple. One could of course build click-to-dial even using VoiceXML-driven MGCP-enabled Softswitch, but that's not the goal. REFER is simple and its purpose perfectly fits the c-t-d app. -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 exim@www1.ietf.org Fri Aug 22 13:37:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09247 for ; Fri, 22 Aug 2003 13:37:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFqA-0005hp-5X for sipping-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHajbS021923 for sipping-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFq9-0005gW-Nb for sipping-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 13:36:45 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09075 for ; Fri, 22 Aug 2003 13:36:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFpR-0005Fd-GY; Fri, 22 Aug 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qEro-0003Bk-Gm for sipping@optimus.ietf.org; Fri, 22 Aug 2003 12:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05938 for ; Fri, 22 Aug 2003 12:34:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qErm-0006iL-00 for sipping@ietf.org; Fri, 22 Aug 2003 12:34:23 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19qErm-0006i1-00 for sipping@ietf.org; Fri, 22 Aug 2003 12:34:22 -0400 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HK100C864G5ZM@firewall.wcom.com> for sipping@ietf.org; Fri, 22 Aug 2003 16:28:53 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HK1007014G3U0@dgismtp05.wcomnet.com>; Fri, 22 Aug 2003 16:28:53 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.95]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HK1006DU4G35J@dgismtp05.wcomnet.com>; Fri, 22 Aug 2003 16:28:52 +0000 (GMT) Date: Fri, 22 Aug 2003 11:28:52 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: Update to 3pcc In-reply-to: <5.2.0.9.0.20030822032918.037243f8@mailhost.fokus.fhg.de> To: "'Jiri Kuthan'" , "'Jonathan Rosenberg'" Cc: "'David Schwartz'" , sipping@ietf.org Message-id: <0HK1006DX4G45J@dgismtp05.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNoVRKYgfoIJiYuS8Sauz3QWZMsSwAdK9vQ 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 Where are the service providers in this discussion on billing? ;-) Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Jiri Kuthan > Sent: Thursday, August 21, 2003 9:22 PM > To: Jonathan Rosenberg > Cc: David Schwartz; 'sipping@ietf.org' > Subject: Re: [Sipping] Re: Update to 3pcc > > At 09:17 PM 8/13/2003, Jonathan Rosenberg wrote: > >Sorry for taking so long to weigh in here. > >To address the specific billing issue, the problem is that, in fact, > there ARE cases where the call is charged for differently if it was > initiated as a result of click-to-dial. The user that makes the initial > INVITE may not be the one that needs to be charged. There may be ways > around that for REFER by having the INVITE carry some kind of special > billing tokens or something (such tokens being pushed to the user in the > Refer-To), but these then require the c2d provider and the caller to > utilize the same provider. The 3pcc mechanism does not have this > constraint. > > I would prefer focusing on a common case. I really do not think 3-rd party > billing > for click-to-dial is something very usual. If you think so, then that's > the example which > should come in the 3pcc draft. > > >However, in my mind, the real issue is one of control. 3pcc is useful in > applications where the server needs to be in the signaling path in order > to do or modify things. Thats not the case for all applications, but its > true for many. Prepaid is one we have discussed as well. REFER just doesnt > work there. > > I almost agree, but that's a different topic than I raised. > > >I'd also point out that the 3pcc spec is not saying that the best > practice for c2d is to use 3pcc; it saying that if you want to do third > party call control, here is how you do it. > > Sometimes, BCP for a technology is not to use it. I don't think IETF > should document > "BCP for 3pcc" on examples which are better implemented with another > technology. > If you are enthusiastic about HTTP, publish "BCP for Use of HTTP" and show > examples > of using HTTP to control media gateways, some people will not be happy > either (unless > it was April 1st). > > > >I don't disagree that 3pcc for c2d can be complicated, and REFER does > have a better story in terms of the media story. However, other work going > on, namely the app interaction work, does address some of the big issues > there in a pretty elegant way, I think. > > I really prefer keeping simple things simple. One could of course build > click-to-dial > even using VoiceXML-driven MGCP-enabled Softswitch, but that's not the > goal. REFER > is simple and its purpose perfectly fits the c-t-d app. > > -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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 27 02:35:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26463 for ; Wed, 27 Aug 2003 02:35:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rtQo-0000Y7-1o for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 02:05:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R65JID002097 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 02:05:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rpnV-0005dR-1M for sipping-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 22:12:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05731 for ; Tue, 26 Aug 2003 22:12:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rpnR-0000pb-00 for sipping-web-archive@ietf.org; Tue, 26 Aug 2003 22:12:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rpnQ-0000pY-00 for sipping-web-archive@ietf.org; Tue, 26 Aug 2003 22:12:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rp9H-0003bx-0Y; Tue, 26 Aug 2003 21:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rik8-0002xm-9b for sipping@optimus.ietf.org; Tue, 26 Aug 2003 14:40:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20532 for ; Tue, 26 Aug 2003 14:40:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rik5-0005ZF-00 for sipping@ietf.org; Tue, 26 Aug 2003 14:40:33 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19rik4-0005Yp-00 for sipping@ietf.org; Tue, 26 Aug 2003 14:40:32 -0400 Received: from rshockeybox.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h7QIieE27294; Tue, 26 Aug 2003 11:44:40 -0700 Message-Id: <5.2.0.9.2.20030826143509.0370c5a8@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Aug 2003 14:39:11 -0400 To: "Christian Stredicke" , "'sipping'" From: Richard Shockey Subject: Re: [Sipping] Kill Overlap Dialling In-Reply-To: <006e01c36b94$117b2200$6901a8c0@sip> References: <9BF66EBF6BEFD942915B4D4D45C051F3E862FB@dyn-tx-exch-001.dynamicsoft.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: , At 11:06 AM 8/26/2003 +0530, Christian Stredicke wrote: >Hi All, Christian I think this should end the issue. The "out of box" experience with SIP phones does not have to replicate that of the land line service ..the most compelling argument for a Dial button on SIP phones is D. >the feedback which I received so far on overlap dialling was pretty >clear: There will be no overlap dialling support for SIP. > >Arguments: > >A. ENUM does not support overlap dialling. There are security concerns >on who will own the nodes of incomplete numbers and it was also reported >that the overhead for the node lookup is too much. Right we had this argument at the ENUM WG in Vienna. >B. Countries with fixed-length numbers (like USA) can have a dial plan >on the phone. Other countries always need to press the dial button >except for cases where extension numbers are dialled. People calling >from the US have to press a dial key (or #) after dialling a non-US >number. That is accepted by the customers. > >C. The lack of support of 484 responses on PSTN gateways makes overlap >dialling unusable anyway. A SIP extension would be necessary, but does >not exist at this time and the probability that we reach consensus on >such an extension in time is minimal. > >D. "Grandma" is not in the customer focus any more. "Grandchildren" are >used to cell phones and press the dial button after making up their >minds on which person to call. > >E. Phones without display will not be sold in large numbers any more. If >vendors should decide to make SIP phones without display, they must >include a dial button (timeout of 5 seconds to start dialling is not >feasible as this makes printed telephone book lookup impossible). LED's are cheep.. >Am I right? I this is so, we would like to stop efforts on implementing >this in out endpoints. > Please... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 27 03:43:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02200 for ; Wed, 27 Aug 2003 03:43:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rtus-00048F-CL for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 02:36:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6aNkF015860 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 02:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rtBn-0008Aw-Fm for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 01:49:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25679 for ; Wed, 27 Aug 2003 01:49:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rtBk-0005nE-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 01:49:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rtBj-0005nB-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 01:49:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rp9E-0003bO-SP; Tue, 26 Aug 2003 21:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rheU-0000bN-BB for sipping@optimus.ietf.org; Tue, 26 Aug 2003 13:30:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16246 for ; Tue, 26 Aug 2003 13:30:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rheS-0003mo-00 for sipping@ietf.org; Tue, 26 Aug 2003 13:30:40 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19rheR-0003mK-00 for sipping@ietf.org; Tue, 26 Aug 2003 13:30:39 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7QHU9d8017727; Tue, 26 Aug 2003 13:30:09 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 12:30:09 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863C7@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Christian Stredicke'" , "'sipping'" Subject: RE: [Sipping] Kill Overlap Dialling Date: Tue, 26 Aug 2003 12:30:07 -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: , Christian Stredicke writes: > C. The lack of support of 484 responses on PSTN gateways makes overlap > dialling unusable anyway. A SIP extension would be necessary, but does > not exist at this time So.... RFC 3578 is a figment of my imagination? /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 exim@www1.ietf.org Wed Aug 27 03:43:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02330 for ; Wed, 27 Aug 2003 03:43:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rtvb-0004E6-2n for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 02:37:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6b7Ca016223 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 02:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rt8M-00083Y-D4 for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 01:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25392 for ; Wed, 27 Aug 2003 01:46:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rt8J-0005hp-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 01:46:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rt8I-0005hm-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 01:46:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rp9F-0003bg-T8; Tue, 26 Aug 2003 21:30:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rhvK-00019r-S7 for sipping@optimus.ietf.org; Tue, 26 Aug 2003 13:48:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16921 for ; Tue, 26 Aug 2003 13:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rhvI-0003zl-00 for sipping@ietf.org; Tue, 26 Aug 2003 13:48:04 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19rhvH-0003zA-00 for sipping@ietf.org; Tue, 26 Aug 2003 13:48:04 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7QHkmVt010712; Tue, 26 Aug 2003 10:46:48 -0700 (PDT) Received: from [10.32.138.117] ([10.32.138.117]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHL99888; Tue, 26 Aug 2003 10:46:47 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 26 Aug 2003 10:46:48 -0700 Subject: Re: [Sipping] Kill Overlap Dialling From: Cullen Jennings To: Christian Stredicke , "'sipping'" Message-ID: In-Reply-To: <006e01c36b94$117b2200$6901a8c0@sip> 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 Well there is RFC 3578. On 8/25/03 22:36, "Christian Stredicke" wrote: > Hi All, > > the feedback which I received so far on overlap dialling was pretty > clear: There will be no overlap dialling support for SIP. > > Arguments: > > A. ENUM does not support overlap dialling. There are security concerns > on who will own the nodes of incomplete numbers and it was also reported > that the overhead for the node lookup is too much. > > B. Countries with fixed-length numbers (like USA) can have a dial plan > on the phone. Other countries always need to press the dial button > except for cases where extension numbers are dialled. People calling > from the US have to press a dial key (or #) after dialling a non-US > number. That is accepted by the customers. > > C. The lack of support of 484 responses on PSTN gateways makes overlap > dialling unusable anyway. A SIP extension would be necessary, but does > not exist at this time and the probability that we reach consensus on > such an extension in time is minimal. > > D. "Grandma" is not in the customer focus any more. "Grandchildren" are > used to cell phones and press the dial button after making up their > minds on which person to call. > > E. Phones without display will not be sold in large numbers any more. If > vendors should decide to make SIP phones without display, they must > include a dial button (timeout of 5 seconds to start dialling is not > feasible as this makes printed telephone book lookup impossible). > > > Am I right? I this is so, we would like to stop efforts on implementing > this in out endpoints. > > Best, > > > Christian > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 27 18:12:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13309 for ; Wed, 27 Aug 2003 18:12:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4DK-00069U-Kn for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 13:36:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RHa9RQ023636 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 13:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2zQ-0000nS-6E for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 12:17:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12666 for ; Wed, 27 Aug 2003 12:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2zO-0001qc-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 12:17:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s2zO-0001qZ-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 12:17:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2sz-0000Si-EZ; Wed, 27 Aug 2003 12:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rOu5-00022N-T0 for sipping@optimus.ietf.org; Mon, 25 Aug 2003 17:29:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17069 for ; Mon, 25 Aug 2003 17:29:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rOu3-0007cR-00 for sipping@ietf.org; Mon, 25 Aug 2003 17:29:31 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19rOu2-0007cG-00 for sipping@ietf.org; Mon, 25 Aug 2003 17:29:30 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7PLSod8014246; Mon, 25 Aug 2003 17:28:50 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 16:28:50 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863B5@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'Cullen Jennings'" , "'Rohan Mahy'" , sipping Subject: RE: [Sipping] App-Interaction: Considering models Date: Mon, 25 Aug 2003 16:28: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: , Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] wrote: > I would argue that the App-Info header is what is actually creating > the state, and the state of this thing exists for the duration of the > dialog. The results of the user input are the state, but they aren't > normally sent anywhere. Rather, they are monitored through an > explicit subscription from the application server. I thought I had mentioned it earlier (it was always in the back of my mind), but the intention, in using explicit subscriptions, was to not have an "App-Info" header. The SUBSCRIBE itself carries the KPML script (which, upon close examination, is really more of a filter than a script, so this usage seems appropriate). So, I would argue that the INVITE exchange is what actually creates this state. In other words, it makes just as much sense to subscribe to this state as it does to subscribe to the state of a dialog. > In this model, I suppose an explicit subscription makes > sense, but the whole thing seems convoluted. Why bother to > explicitly subscribe to something when you created the state > in the first place, and you are the only one who is interested > in finding out about it? Ah, but what if you *aren't* the only one interested in finding out about it? What if I go through some proxy that is doing some sort of prepaid service [1] with two-stage dialing. If I want to end my current call and start a new one, I send a long pound. On the other hand, the thing that I've ended up calling has a proxy that wants my keypresses also, because it's some sort of call center that needs me to type in my account number. It sure seems that it would be much, much simpler to consider them as subscribing to the same state (keypad events) with different filters, than to consider the two different "App-Info" headers in the INVITE 200 response as creating two separate pieces of state associated with (n.b. *not* "sent in") the dialog. What is *really* nice about this is that one can envision future systems where parties not on the call path (but still rendered to the user through some other means) can tap this state without additional specification; all they need is some mechanism to get the dialog identifiers. /a [1] Don't get hung up on the fact that I said something that has billing implications. The point is that there might be two proxies wanting to know about keypresses, and this is an easily grasped system with which many people are already familiar. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 27 21:35:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28599 for ; Wed, 27 Aug 2003 21:35:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBcu-0005p4-0x for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 21:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1V43g022381 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 21:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBTc-0005CK-VC for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 21:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27125 for ; Wed, 27 Aug 2003 21:21:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sBTa-0005Ic-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 21:21:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sBTZ-0005IZ-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 21:21:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4xI-0001Ip-GA; Wed, 27 Aug 2003 14:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rOaY-0001b7-Ip for sipping@optimus.ietf.org; Mon, 25 Aug 2003 17:09:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16225 for ; Mon, 25 Aug 2003 17:09:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rOaW-0007Nv-00 for sipping@ietf.org; Mon, 25 Aug 2003 17:09:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19rOaV-0007Nj-00 for sipping@ietf.org; Mon, 25 Aug 2003 17:09:19 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7PL8gUg005180; Mon, 25 Aug 2003 17:08:42 -0400 (EDT) Message-ID: <3F4A7AD6.50606@dynamicsoft.com> Date: Mon, 25 Aug 2003 17:08:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , sipping Subject: Re: [Sipping] App-Interaction: Considering models 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 inline. Cullen Jennings wrote: > Let me propose a realistic scenario that is a little more difficult with > http. It is probably possible to solve, just complicated. I will admit that > much of the reason many people don't want to use HTTP is because they think > sending it in SIP will be less work - they may or may not be right but the > "less work" on low end devices is what has driven us to a fairly messy > situation in handling DTMF today. I want to come up this something that is > appealing enough to the people doing evil things today that they stop doing > evil things. That said, let me describe a scenario that does occur and is > difficult with HTTP. Do these people find KPML objectionable too? No doubt the easiest thing is to send INFO within the same dialog. However that is frought with real problems. Once you've gotten to the point where its something out of dialog, and something that requires you to fetch (with http presumably) or look at an embedded script, is http for pushing the results worse? > > A residential phone user, called A, has a UA that they can use to make PSTN > calls. This UA connects to a voice service provider, called Provider B that > claims to terminate the calls to the PSTN. This provider does not directly > terminate them but actually pass them to provider C. Provider C runs the > call through a H.323 translator and terminates then sends the call to a 323 > GW. The 323 GW does not support RFC 2833. The user A UA is likely to be > behind a NAT and the final GW might be behind a NAT depending on the country > of termination. B does not wish A to learn the identify of C because A might > get a better price and cut B out of the loop. C does not wish B to learn too > much about their network topology, since C might actually be passing traffic > to provider D. Provider B and C and both run transparent B2BUA, broken > proxies, and firewalls to make this all possible. The 323 translator wants > to receive DTMF in the signaling so that it can pass it to the GW. In a > variant of the scenario, provider B is a prepaid service and wants to be > able to intercept long #. > > If the phone sent DTMF over INFO, the people with this problem would be > happy. The development effort to send DTMF over INFO is very low. Well, hang on. Its "easy" if its any method within the existing dialog. Once its outside of the dialog, whether its SIP or HTTP, this seems to be more or less equially "problematic". It would > be possible to solve this example with 2833 to the 323 translator. The IETF > suggested this was the right way to go - I am unaware of anyone who did > that. Everyone decided some weird variant of sending it over SIP looked like > a much better idea even though it was not interoperable. Perhaps they were > all insane but people buying equipment convinced vendors to build it. If we > want to standardize something that is going to be widely implemented, I > think we need to keep what is deployed today and why it happened in mind. > > It is probably possible to have provider B write a HTTP proxy like thing > that takes posts from A and then relays them on to C and change it's call > control software to rewrite the KPML scripts as they pass through the > signaling proxy/b2bua. But this leads to the the NAT ALG like behavior that > we are trying to avoid. And how would doing this with SIP solve that? Seems like you would still need to modify the KPML scripts. However, instead of receiving POSTS and relaying thme to C, you would take SIP NEW-METHODS and relay them on to C. Indeed, if these NEW-METHOD requests have the dialog identifiers in the body, those need to be rewritten by the server at B. So, what is the difference? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Wed Aug 27 23:11:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07584 for ; Wed, 27 Aug 2003 23:11:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8Ia-0002xx-6f for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 17:57:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RLvqgu011397 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 17:57:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s43w-00053c-Hs for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 13:26:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19918 for ; Wed, 27 Aug 2003 13:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s43t-0003vu-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 13:26:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s43s-0003vr-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 13:26:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2vk-0000cH-1G; Wed, 27 Aug 2003 12:13:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rp1v-0003U8-5B for sipping@optimus.ietf.org; Tue, 26 Aug 2003 21:23:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00956 for ; Tue, 26 Aug 2003 21:23:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rp1s-0007EA-00 for sipping@ietf.org; Tue, 26 Aug 2003 21:23:20 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19rp1r-0007E7-00 for sipping@ietf.org; Tue, 26 Aug 2003 21:23:19 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h7R1N11R013401; Wed, 27 Aug 2003 10:23:01 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h7R1N18E014681; Wed, 27 Aug 2003 10:23:01 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h7R1N0eH017792; Wed, 27 Aug 2003 10:23:00 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id KAA29243; Wed, 27 Aug 2003 10:23:00 +0900 (JST) Received: from Annika.lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id KAA09912; Wed, 27 Aug 2003 10:22:59 +0900 (JST) Message-Id: <5.1.1.9.2.20030827101621.04f62be8@img.m.ecl.ntt.co.jp> X-Sender: ko011@img.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Wed, 27 Aug 2003 10:22:31 +0900 To: Henry Sinnreich , "'Jiri Kuthan'" , "'Jonathan Rosenberg'" From: Kumiko Ono Subject: RE: [Sipping] Re: Update to 3pcc Cc: "'David Schwartz'" , sipping@ietf.org In-Reply-To: <0HK1006DX4G45J@dgismtp05.wcomnet.com> References: <5.2.0.9.0.20030822032918.037243f8@mailhost.fokus.fhg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" 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 think that click-to-dial service providers are usually different from PSTN gateway provider. The settlement between these providers is usually done monthly. In this case, click-to-dial provider that also provides pre-paid calling service might want to take the initiative in disconnect procedure like sending BYE request. Thanks, Kumiko Ono At 11:28 03/08/22 -0500, Henry Sinnreich wrote: >Where are the service providers in this discussion on billing? ;-) > >Thanks, Henry > >> -----Original Message----- >> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of >> Jiri Kuthan >> Sent: Thursday, August 21, 2003 9:22 PM >> To: Jonathan Rosenberg >> Cc: David Schwartz; 'sipping@ietf.org' >> Subject: Re: [Sipping] Re: Update to 3pcc >> >> At 09:17 PM 8/13/2003, Jonathan Rosenberg wrote: >> >Sorry for taking so long to weigh in here. >> >To address the specific billing issue, the problem is that, in fact, >> there ARE cases where the call is charged for differently if it was >> initiated as a result of click-to-dial. The user that makes the initial >> INVITE may not be the one that needs to be charged. There may be ways >> around that for REFER by having the INVITE carry some kind of special >> billing tokens or something (such tokens being pushed to the user in the >> Refer-To), but these then require the c2d provider and the caller to >> utilize the same provider. The 3pcc mechanism does not have this >> constraint. >> >> I would prefer focusing on a common case. I really do not think 3-rd party >> billing >> for click-to-dial is something very usual. If you think so, then that's >> the example which >> should come in the 3pcc draft. >> >> >However, in my mind, the real issue is one of control. 3pcc is useful in >> applications where the server needs to be in the signaling path in order >> to do or modify things. Thats not the case for all applications, but its >> true for many. Prepaid is one we have discussed as well. REFER just doesnt >> work there. >> >> I almost agree, but that's a different topic than I raised. >> >> >I'd also point out that the 3pcc spec is not saying that the best >> practice for c2d is to use 3pcc; it saying that if you want to do third >> party call control, here is how you do it. >> >> Sometimes, BCP for a technology is not to use it. I don't think IETF >> should document >> "BCP for 3pcc" on examples which are better implemented with another >> technology. >> If you are enthusiastic about HTTP, publish "BCP for Use of HTTP" and show >> examples >> of using HTTP to control media gateways, some people will not be happy >> either (unless >> it was April 1st). >> >> >> >I don't disagree that 3pcc for c2d can be complicated, and REFER does >> have a better story in terms of the media story. However, other work going >> on, namely the app interaction work, does address some of the big issues >> there in a pretty elegant way, I think. >> >> I really prefer keeping simple things simple. One could of course build >> click-to-dial >> even using VoiceXML-driven MGCP-enabled Softswitch, but that's not the >> goal. REFER >> is simple and its purpose perfectly fits the c-t-d app. >> >> -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 > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the 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 exim@www1.ietf.org Wed Aug 27 23:28:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09288 for ; Wed, 27 Aug 2003 23:28:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9aO-0006dY-FZ for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 19:20:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RNKK61025508 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 19:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4N7-0006wS-Bt for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 13:46:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21693 for ; Wed, 27 Aug 2003 13:46:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s4N5-0004SG-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 13:46:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s4N4-0004SD-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 13:46:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2sd-0000Oq-5Y; Wed, 27 Aug 2003 12:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rcoc-0001pl-Rx for sipping@optimus.ietf.org; Tue, 26 Aug 2003 08:20:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01086 for ; Tue, 26 Aug 2003 08:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rcob-000083-00 for sipping@ietf.org; Tue, 26 Aug 2003 08:20:49 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19rcob-00007i-00 for sipping@ietf.org; Tue, 26 Aug 2003 08:20:49 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h7QCKIAP010281; Tue, 26 Aug 2003 07:20:18 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.129]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id QXXV0HNP; Tue, 26 Aug 2003 07:19:57 -0500 Message-ID: <3F4B507E.7000803@ericsson.com> Date: Tue, 26 Aug 2003 15:20:14 +0300 X-Sybari-Trust: ace98dba 0f2b92c8 7860309c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke CC: "'sipping'" Subject: Re: [Sipping] Kill Overlap Dialling References: <006e01c36b94$117b2200$6901a8c0@sip> In-Reply-To: <006e01c36b94$117b2200$6901a8c0@sip> 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 Christian, what you are saying is in line with the recently published RFC 3578. That RFC recommends that gateways tranforms everything to en-bloc, and that the overlap procedures defined in the document should be used only as a last resort. That is, only if the gateway *must* meet some particular requirements that would be impossible to meet without using them. Gonzalo Christian Stredicke wrote: > Hi All, > > the feedback which I received so far on overlap dialling was pretty > clear: There will be no overlap dialling support for SIP. > > Arguments: > > A. ENUM does not support overlap dialling. There are security concerns > on who will own the nodes of incomplete numbers and it was also reported > that the overhead for the node lookup is too much. > > B. Countries with fixed-length numbers (like USA) can have a dial plan > on the phone. Other countries always need to press the dial button > except for cases where extension numbers are dialled. People calling > from the US have to press a dial key (or #) after dialling a non-US > number. That is accepted by the customers. > > C. The lack of support of 484 responses on PSTN gateways makes overlap > dialling unusable anyway. A SIP extension would be necessary, but does > not exist at this time and the probability that we reach consensus on > such an extension in time is minimal. > > D. "Grandma" is not in the customer focus any more. "Grandchildren" are > used to cell phones and press the dial button after making up their > minds on which person to call. > > E. Phones without display will not be sold in large numbers any more. If > vendors should decide to make SIP phones without display, they must > include a dial button (timeout of 5 seconds to start dialling is not > feasible as this makes printed telephone book lookup impossible). > > > Am I right? I this is so, we would like to stop efforts on implementing > this in out endpoints. > > Best, > > > Christian > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 From exim@www1.ietf.org Wed Aug 27 23:49:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11392 for ; Wed, 27 Aug 2003 23:49:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBEl-0003wA-ON for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 21:06:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S167s3015128 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 21:06:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s55y-0001aW-On for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 14:32:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24663 for ; Wed, 27 Aug 2003 14:32:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s55w-0005CG-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 14:32:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s55v-0005CD-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 14:32:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s49L-0005vj-DN; Wed, 27 Aug 2003 13:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rOVi-0001Hf-5q for sipping@optimus.ietf.org; Mon, 25 Aug 2003 17:04:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16111 for ; Mon, 25 Aug 2003 17:04:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rOVg-0007MX-00 for sipping@ietf.org; Mon, 25 Aug 2003 17:04:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19rOVf-0007MJ-00 for sipping@ietf.org; Mon, 25 Aug 2003 17:04:19 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7PL3fUg005176; Mon, 25 Aug 2003 17:03:41 -0400 (EDT) Message-ID: <3F4A79A9.1030005@dynamicsoft.com> Date: Mon, 25 Aug 2003 17:03:37 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Cullen Jennings'" , "'Rohan Mahy'" , sipping Subject: Re: [Sipping] App-Interaction: Considering models References: <9BF66EBF6BEFD942915B4D4D45C051F3E8634F@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E8634F@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 Adam Roach wrote: > Cullen Jennings [mailto:fluffy@cisco.com] writes: > > > So are we coming to the conclusion that the > > GRUU/SUB/NOT is the right way to go? I can try > > and flesh out some details on this if we are. > > Personally, I now favor this method, since I consider > the http correlation issue that we've discussed to > be a non-starter. I don't think it's unsolvable; I > just am wary of solutions that obviously need hacks, > even when viewed at the mile-high level. Well, the correlation would work identically to the SIP case. The HTTP request would need to carry some kind of dialog identifier, whether its in the body or as part of the R-URI. > > However, my arguments for preferring explicit > use of SUBSCRIBE over a new method are, at this point, > largely philosophical, not technical. I'm not > certain that discussion has played out completely > yet. Well, let me tease this out a bit. The purpose of SUBSCRIBE is to ask about the state of something that exists already in the network. The SUBSCRIBE message itself does not create an instance of the thing being monitored, nor does the lifetime of the subscription guide the lifetime of the state being monitored. Indeed, I recall that Eric had objected to an explicit SUBSCRIBE for carrying the KPML, since it doesnt make sense to have SUBSCRIBE create the state being monitored. I would argue that the App-Info header is what is actually creating the state, and the state of this thing exists for the duration of the dialog. The results of the user input are the state, but they aren't normally sent anywhere. Rather, they are monitored through an explicit subscription from the application server. In this model, I suppose an explicit subscription makes sense, but the whole thing seems convoluted. Why bother to explicitly subscribe to something when you created the state in the first place, and you are the only one who is interested in finding out about it? Why bother managing the state of the subscription AND the user input state separately? The overall system, to me, feels a lot more like form input on the web. A server in the network provides a script that gives context for the user to provide input. This input is then sent back to the source of the script in the first place, which then returns (possibly) another script to execute. As such, I have more or less talked myself out of implicit subscriptions, but also explicit subscriptions at the same time. I would say that this is either a new method or HTTP, which still remains my favorite.. I'll respond to Cullen's note on this separately. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 exim@www1.ietf.org Thu Aug 28 01:08:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17826 for ; Thu, 28 Aug 2003 01:08:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBke-0006mq-2q for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 21:39:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1d41t026079 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 21:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBXt-0005NJ-1B for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 21:25:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27512 for ; Wed, 27 Aug 2003 21:25:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sBXo-0005NW-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 21:25:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sBXn-0005NT-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 21:25:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4vw-00018e-GV; Wed, 27 Aug 2003 14:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rt9F-00085q-Ij for sipping@optimus.ietf.org; Wed, 27 Aug 2003 01:47:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25433 for ; Wed, 27 Aug 2003 01:47:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rt9C-0005j4-00 for sipping@ietf.org; Wed, 27 Aug 2003 01:47:10 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19rt9B-0005h5-00 for sipping@ietf.org; Wed, 27 Aug 2003 01:47:09 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h7R5jZo11299; Wed, 27 Aug 2003 05:45:35 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 00:48:24 -0500 Message-ID: From: "Peterson, Jon" To: "'Cullen Jennings'" , Christian Stredicke , "'sipping'" Subject: RE: [Sipping] Kill Overlap Dialling Date: Wed, 27 Aug 2003 00:46:06 -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: , RFC3578: Therefore, the preferred solution for a gateway handling PSTN overlap signalling and SIP is to convert the PSTN overlap signalling into SIP en-bloc signalling using number analysis and timers. The gateway waits until all the signalling messages carrying parts of the callee's number arrive, and only then, it generates a SIP INVITE request. Section 2 describes how to convert ISUP overlap signalling into en-bloc SIP this way. RFC3578 does not endorse the use of overlap dialing for SIP - it endorses the conversion of overlap to en-bloc as necessary. The mechanism for overlap mapping described in the document is restricted to quite a limited applicability, and has a number of drawbacks. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, August 26, 2003 10:47 AM > To: Christian Stredicke; 'sipping' > Subject: Re: [Sipping] Kill Overlap Dialling > > > > Well there is RFC 3578. > > > On 8/25/03 22:36, "Christian Stredicke" wrote: > > > Hi All, > > > > the feedback which I received so far on overlap dialling was pretty > > clear: There will be no overlap dialling support for SIP. > > > > Arguments: > > > > A. ENUM does not support overlap dialling. There are > security concerns > > on who will own the nodes of incomplete numbers and it was > also reported > > that the overhead for the node lookup is too much. > > > > B. Countries with fixed-length numbers (like USA) can have > a dial plan > > on the phone. Other countries always need to press the dial button > > except for cases where extension numbers are dialled. People calling > > from the US have to press a dial key (or #) after dialling a non-US > > number. That is accepted by the customers. > > > > C. The lack of support of 484 responses on PSTN gateways > makes overlap > > dialling unusable anyway. A SIP extension would be > necessary, but does > > not exist at this time and the probability that we reach > consensus on > > such an extension in time is minimal. > > > > D. "Grandma" is not in the customer focus any more. > "Grandchildren" are > > used to cell phones and press the dial button after making up their > > minds on which person to call. > > > > E. Phones without display will not be sold in large numbers > any more. If > > vendors should decide to make SIP phones without display, they must > > include a dial button (timeout of 5 seconds to start dialling is not > > feasible as this makes printed telephone book lookup impossible). > > > > > > Am I right? I this is so, we would like to stop efforts on > implementing > > this in out endpoints. > > > > Best, > > > > > > Christian > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 28 01:13:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18290 for ; Thu, 28 Aug 2003 01:13:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBtA-00079u-Jx for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 21:47:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1lqII027508 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 21:47:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5GF-0002DO-04 for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 14:43:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25501 for ; Wed, 27 Aug 2003 14:43:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5GC-0005Lb-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 14:43:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s5GB-0005LY-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 14:43:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s48f-0005tj-Rp; Wed, 27 Aug 2003 13:31:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rOex-0001kl-1m for sipping@optimus.ietf.org; Mon, 25 Aug 2003 17:13:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16461 for ; Mon, 25 Aug 2003 17:13:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rOeu-0007SB-00 for sipping@ietf.org; Mon, 25 Aug 2003 17:13:52 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19rOet-0007Rn-00 for sipping@ietf.org; Mon, 25 Aug 2003 17:13:51 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7PLDKd8014177 for ; Mon, 25 Aug 2003 17:13:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 16:13:20 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863B4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'sipping'" Subject: RE: [Sipping] App-Interaction: Considering models Date: Mon, 25 Aug 2003 16:13:12 -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, this thread appears to have stalled. I think everyone has pretty much laid all the cards they have on the table. To summarize: 1) Implicit [1] subscription: - Has correlation problems in the forking case - Has technical problems inherent in implicit [1] subscriptions - Is fewer messages than an explicit [2] subscription - Requires additional mechanism (e.g. HTTP) to retrieve KPML scripts. - Changes normal protocol machinery by setting up a virgin dialog using NOTIFY message 2) MESSAGE: - Has correlation problems in the forking case - Arguably has significantly different semantics than is needed for app-interaction - Can have detrimental, user-visible effects - Requires additional mechanism (e.g. HTTP) to retrieve KPML scripts. 3) HTTP GET/POST: - Has correlation problems in the forking case - May interact poorly with firewalls and NATs 4) NEW_METHOD: - No technical objections raised - Semantically, has some overlap with NOTIFY - Requires additional mechanism (e.g. HTTP) to retrieve KPML scripts. 5) Explicit [2] subscription: - No technical objections raised - Is more complicated than NEW_METHOD - Relies on GRUU solution (which should finish before app-interaction) Have I left anything off? /a [1] By "implicit", I mean "subscriptions put in place via some other mechanism than those described in RFC 3265." [2] By "explicit", I mean "subscriptions put in place via the mechanisms described in RFC 3265." _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 28 02:33:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07276 for ; Thu, 28 Aug 2003 02:33:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCUz-0001Fc-6V for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 22:26:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2QvrW004802 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 22:26:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s95D-0005HO-V7 for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 18:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15783 for ; Wed, 27 Aug 2003 18:48:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s95A-0002EX-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 18:48:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s95A-0002EU-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 18:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4YK-0007ae-V6; Wed, 27 Aug 2003 13:57:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2vD-0000YW-5f for sipping@optimus.ietf.org; Wed, 27 Aug 2003 12:13:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12393 for ; Wed, 27 Aug 2003 12:13:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2vB-0001m3-00 for sipping@ietf.org; Wed, 27 Aug 2003 12:13:21 -0400 Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx with esmtp (Exim 4.12) id 19s2vA-0001lr-00 for sipping@ietf.org; Wed, 27 Aug 2003 12:13:20 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7RGCYW23953; Wed, 27 Aug 2003 18:12:35 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 17:12:35 +0100 Message-ID: From: "Mark Watson" To: "'Christian Stredicke'" , "'sipping'" Subject: RE: [Sipping] Kill Overlap Dialling Date: Wed, 27 Aug 2003 17:12:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36CB6.048B380A" 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_01C36CB6.048B380A Content-Type: text/plain Pleeeeeease don't start this again ... I don't think the reasons for overlap dialling, which we discussed for a looooooong time, very painfully, have changed significantly. As for end-of-dialling keys on SIP phones, I'd be surprised if anyone on this list had not seen sipphone.com. You can try selling this kind of thing in Europe without overlap, but expect reviewers to complain about connection times. They will not always realise that most of it is the inter-digit timer. You can certainly change user behaviour if you explain to them that it works differently from an old-style phone & if there is something in it for the user as well. But if it 'looks and feels' just like a phone there will always be people who expect it to work just like a phone. Service providers & the market, not IETF, should decide how important those people are. ...Mark -----Original Message----- From: Christian Stredicke [mailto:stredicke@snom.de] Sent: 26 August 2003 06:37 To: 'sipping' Subject: [Sipping] Kill Overlap Dialling Hi All, the feedback which I received so far on overlap dialling was pretty clear: There will be no overlap dialling support for SIP. Arguments: A. ENUM does not support overlap dialling. There are security concerns on who will own the nodes of incomplete numbers and it was also reported that the overhead for the node lookup is too much. B. Countries with fixed-length numbers (like USA) can have a dial plan on the phone. Other countries always need to press the dial button except for cases where extension numbers are dialled. People calling from the US have to press a dial key (or #) after dialling a non-US number. That is accepted by the customers. C. The lack of support of 484 responses on PSTN gateways makes overlap dialling unusable anyway. A SIP extension would be necessary, but does not exist at this time and the probability that we reach consensus on such an extension in time is minimal. D. "Grandma" is not in the customer focus any more. "Grandchildren" are used to cell phones and press the dial button after making up their minds on which person to call. E. Phones without display will not be sold in large numbers any more. If vendors should decide to make SIP phones without display, they must include a dial button (timeout of 5 seconds to start dialling is not feasible as this makes printed telephone book lookup impossible). Am I right? I this is so, we would like to stop efforts on implementing this in out endpoints. Best, Christian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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_01C36CB6.048B380A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] Kill Overlap Dialling

Pleeeeeease don't start this again ...

I don't think the reasons for overlap dialling, which = we discussed for a looooooong time, very painfully, have changed = significantly.

As for end-of-dialling keys on SIP phones, I'd be = surprised if anyone on this list had not seen sipphone.com. You can try = selling this kind of thing in Europe without overlap, but expect = reviewers to complain about connection times. They will not always = realise that most of it is the inter-digit timer.

You can certainly change user behaviour if you = explain to them that it works differently from an old-style phone & = if there is something in it for the user as well. But if it 'looks and = feels' just like a phone there will always be people who expect it to = work just like a phone. Service providers & the market, not IETF, = should decide how important those people are.

...Mark

-----Original Message-----
From: Christian Stredicke [mailto:stredicke@snom.de]
Sent: 26 August 2003 06:37
To: 'sipping'
Subject: [Sipping] Kill Overlap Dialling


Hi All,

the feedback which I received so far on overlap = dialling was pretty
clear: There will be no overlap dialling support for = SIP.

Arguments:

A. ENUM does not support overlap dialling. There are = security concerns on who will own the nodes of incomplete numbers and = it was also reported that the overhead for the node lookup is too = much.

B. Countries with fixed-length numbers (like USA) can = have a dial plan on the phone. Other countries always need to press the = dial button except for cases where extension numbers are dialled. = People calling from the US have to press a dial key (or #) after = dialling a non-US number. That is accepted by the customers.

C. The lack of support of 484 responses on PSTN = gateways makes overlap dialling unusable anyway. A SIP extension would = be necessary, but does not exist at this time and the probability that = we reach consensus on such an extension in time is minimal.

D. "Grandma" is not in the customer focus = any more. "Grandchildren" are used to cell phones and press = the dial button after making up their minds on which person to = call.

E. Phones without display will not be sold in large = numbers any more. If vendors should decide to make SIP phones without = display, they must include a dial button (timeout of 5 seconds to start = dialling is not feasible as this makes printed telephone book lookup = impossible).


Am I right? I this is so, we would like to stop = efforts on implementing this in out endpoints.

Best,


Christian


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the 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_01C36CB6.048B380A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 28 03:09:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10025 for ; Thu, 28 Aug 2003 03:09:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDe3-0007e9-Rv for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 23:40:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3eNnM029383 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 23:40:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s7U0-0008OU-9L for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 17:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08512 for ; Wed, 27 Aug 2003 17:05:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s7Ty-0000WD-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 17:05:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s7Tx-0000WA-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 17:05:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4sH-0000Q1-8g; Wed, 27 Aug 2003 14:18:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rw2I-0002Pf-5Y for sipping@optimus.ietf.org; Wed, 27 Aug 2003 04:52:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07750 for ; Wed, 27 Aug 2003 04:52:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rw2F-0001Ub-00 for sipping@ietf.org; Wed, 27 Aug 2003 04:52:11 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19rw2E-0001Tw-00 for sipping@ietf.org; Wed, 27 Aug 2003 04:52:10 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 27 Aug 2003 10:51:33 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 10:51:33 +0200 Message-Id: <953B9B08F98DD61183F8000347AE660102862B93@G8PPV.blf01.telekom.de> From: "Jesske, R" To: stredicke@snom.de, sipping@ietf.org Subject: AW: [Sipping] Kill Overlap Dialling Date: Wed, 27 Aug 2003 10:51:32 +0200 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: , > > B. Countries with fixed-length numbers (like USA) can have a dial plan > on the phone. Other countries always need to press the dial button > except for cases where extension numbers are dialled. People calling > from the US have to press a dial key (or #) after dialling a non-US > number. That is accepted by the customers. > > Hi, As you surly know there are several countries that are not using fixed-length numbers (like Germany) and there is also no chance to change it. Also we have no dial button! Therefore there is the need for Overlap. As Adam and Cullen mentioned there is RFC3578. And also ITU-T defined the interworking of overlap dialling of SIP with ISUP/BICC networks (Q.1912.SIP). Best Regards Roland Jesske Deutsche Telekom AG T Com Zentrale Roland Jesske, T38-12 Section T38; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 email: r.jesske@telekom.de _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 28 03:30:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11676 for ; Thu, 28 Aug 2003 03:30:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sChZ-0002ao-SF for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 22:39:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2dvwJ009953 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 22:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s7NX-00085f-54 for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 16:58:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08066 for ; Wed, 27 Aug 2003 16:58:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s7NU-0000PI-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 16:58:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s7NU-0000PE-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 16:58:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s46U-0005Je-EP; Wed, 27 Aug 2003 13:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rzVN-0001VL-Ma for sipping@optimus.ietf.org; Wed, 27 Aug 2003 08:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21880 for ; Wed, 27 Aug 2003 08:34:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rzVM-0004fV-00 for sipping@ietf.org; Wed, 27 Aug 2003 08:34:28 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19rzVM-0004fE-00 for sipping@ietf.org; Wed, 27 Aug 2003 08:34:28 -0400 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HKA007L42N6PD@firewall.wcom.com> for sipping@ietf.org; Wed, 27 Aug 2003 12:28:18 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HKA008012N5UY@dgismtp03.wcomnet.com>; Wed, 27 Aug 2003 12:28:17 +0000 (GMT) Received: from hsinnreich2 ([166.50.152.240]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HKA0077J2N45L@dgismtp03.wcomnet.com>; Wed, 27 Aug 2003 12:28:17 +0000 (GMT) Date: Wed, 27 Aug 2003 07:28:17 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Kill Overlap Dialling In-reply-to: <9BF66EBF6BEFD942915B4D4D45C051F3E863C7@dyn-tx-exch-001.dynamicsoft.com> To: "'Adam Roach'" , "'Christian Stredicke'" , "'sipping'" Message-id: <0HKA0077K2N45L@dgismtp03.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcNsXxZm37KUVfpdToCFKP7u5CDuQAANvGlA 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 > So.... RFC 3578 is a figment of my imagination? The fact that people took care of mapping ISDN ISUP overlap signaling to SIP does not mean ISUP is the right role model. Or we would not develop SIP in the first place and just keep using ISUP... Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Adam Roach > Sent: Tuesday, August 26, 2003 12:30 PM > To: 'Christian Stredicke'; 'sipping' > Subject: RE: [Sipping] Kill Overlap Dialling > > Christian Stredicke writes: > > > C. The lack of support of 484 responses on PSTN gateways makes overlap > > dialling unusable anyway. A SIP extension would be necessary, but does > > not exist at this time > > So.... RFC 3578 is a figment of my imagination? > > /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 exim@www1.ietf.org Thu Aug 28 04:06:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14604 for ; Thu, 28 Aug 2003 04:06:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDZZ-0006yc-K9 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 23:35:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3ZjUC026810 for sipping-archive@odin.ietf.org; Wed, 27 Aug 2003 23:35:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s7kq-0000vC-1r for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 17:23:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09659 for ; Wed, 27 Aug 2003 17:22:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s7kn-0000o1-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 17:22:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s7km-0000ny-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 17:22:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qk-0002ZC-0r; Wed, 27 Aug 2003 14:54:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2EX-0007Sd-13 for sipping@optimus.ietf.org; Wed, 27 Aug 2003 11:29:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09027 for ; Wed, 27 Aug 2003 11:29:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2EW-000136-00 for sipping@ietf.org; Wed, 27 Aug 2003 11:29:16 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19s2EV-00012O-00 for sipping@ietf.org; Wed, 27 Aug 2003 11:29:15 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7RFSb97007607; Wed, 27 Aug 2003 10:28:37 -0500 Subject: RE: [Sipping] Kill Overlap Dialling From: Dean Willis To: Adam Roach Cc: "'Christian Stredicke'" , "'sipping'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E863C7@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3E863C7@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1061998117.7350.24.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 27 Aug 2003 10:28:37 -0500 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 On Tue, 2003-08-26 at 12:30, Adam Roach wrote: > Christian Stredicke writes: > > > C. The lack of support of 484 responses on PSTN gateways makes overlap > > dialling unusable anyway. A SIP extension would be necessary, but does > > not exist at this time > > So.... RFC 3578 is a figment of my imagination? Good point, Adam. Can you tell us how many implementations of RFC 3578 were exercised at the last SIPit? -- 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 exim@www1.ietf.org Thu Aug 28 04:55:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18803 for ; Thu, 28 Aug 2003 04:55:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sG0Y-0007VN-Ku for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 02:11:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S6Bk0s028837 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 02:11:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCL6-0000QE-40 for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 22:16:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02097 for ; Wed, 27 Aug 2003 22:16:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sCL2-0006e6-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 22:16:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sCL2-0006e3-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 22:16:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8mj-0004SE-Qq; Wed, 27 Aug 2003 18:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qd-0002WY-5v for sipping@optimus.ietf.org; Wed, 27 Aug 2003 14:53:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26440 for ; Wed, 27 Aug 2003 14:53:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5Qa-0005bZ-00 for sipping@ietf.org; Wed, 27 Aug 2003 14:53:56 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19s5QZ-0005a0-00 for sipping@ietf.org; Wed, 27 Aug 2003 14:53:55 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7RIrHd8022840 for ; Wed, 27 Aug 2003 14:53:17 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 13:53:17 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863D1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'sipping'" Subject: RE: [Sipping] App-Interaction: Considering models Date: Wed, 27 Aug 2003 13:53:16 -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 wrote: > Okay, this thread appears to have stalled. n.b.: I sent this on Monday, when the thread had, indeed, appeared to have stalled. I guess this particular message got caught in a mailspool somewhere... /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 exim@www1.ietf.org Thu Aug 28 07:24:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02556 for ; Thu, 28 Aug 2003 07:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sI8J-0007Th-EO for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 04:27:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S8Rt2q028742 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 04:27:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCtK-0003hm-VY for sipping-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 22:52:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05585 for ; Wed, 27 Aug 2003 22:52:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sCtH-0007e5-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 22:52:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sCtG-0007e2-00 for sipping-web-archive@ietf.org; Wed, 27 Aug 2003 22:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8Ho-0002xB-U7; Wed, 27 Aug 2003 17:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s451-00058v-7Z for sipping@optimus.ietf.org; Wed, 27 Aug 2003 13:27:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20029 for ; Wed, 27 Aug 2003 13:27:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s44z-0003xz-00 for sipping@ietf.org; Wed, 27 Aug 2003 13:27:33 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19s44y-0003x8-00 for sipping@ietf.org; Wed, 27 Aug 2003 13:27:32 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7RHQrd8022551; Wed, 27 Aug 2003 13:26:53 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 12:26:53 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E863CE@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Dean Willis'" , Adam Roach Cc: "'Christian Stredicke'" , "'sipping'" Subject: RE: [Sipping] Kill Overlap Dialling Date: Wed, 27 Aug 2003 12:26:50 -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: , Dean Willis [mailto:dean.willis@softarmor.com] writes: > Good point, Adam. Can you tell us how many implementations of RFC 3578 > were exercised at the last SIPit? That's more of a Robert question; I wasn't there. /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 exim@www1.ietf.org Thu Aug 28 09:35:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13987 for ; Thu, 28 Aug 2003 09:35:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sL1e-00039C-70 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 07:33:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SBXERR012092 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 07:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJKw-0002Zw-NJ for sipping-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 05:45:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22409 for ; Thu, 28 Aug 2003 05:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sJKs-000116-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 05:44:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sJKr-000112-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 05:44:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sGu5-00036x-81; Thu, 28 Aug 2003 03:09:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFBp-0003xp-9m for sipping@optimus.ietf.org; Thu, 28 Aug 2003 01:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18653 for ; Thu, 28 Aug 2003 01:19:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sFBm-0003Ib-00 for sipping@ietf.org; Thu, 28 Aug 2003 01:19:18 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19sFBl-0003I7-00 for sipping@ietf.org; Thu, 28 Aug 2003 01:19:17 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7S5IkCb015520; Wed, 27 Aug 2003 22:18:46 -0700 (PDT) Received: from [10.0.1.2] (tokyo-vpn-user269.cisco.com [10.70.83.13]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHN85759; Wed, 27 Aug 2003 22:18:39 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 27 Aug 2003 20:54:03 -0700 Subject: Re: AW: [Sipping] Kill Overlap Dialing From: Cullen Jennings To: "Jesske, R" , , Message-ID: In-Reply-To: <953B9B08F98DD61183F8000347AE660102862B93@G8PPV.blf01.telekom.de> 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 I've been trying to restrain from adding to the never ending overlap dialing conversation but .... On 8/27/03 1:51, "Jesske, R" wrote: > Also we have > no dial button! I keep seeing variants of this but I would like to point out 1) I have yet to see a phone without a # button 2) somehow or other people from the US PSTN can call Germany on the PSTN. I'm sure that's impossible reading all the threads on this but oddly it seems to works. Yay, Yah I know that this is less than an ideal solution - please don't explain why this is an awful solution - I know. If there was an ideal solution to overlap dialing IETF would have made it an RFC long ago. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 28 16:38:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16740 for ; Thu, 28 Aug 2003 16:38:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQof-0003vJ-2L for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 13:44:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SHiCAD015073 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 13:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sMyI-0001Pv-VY for sipping-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 09:37:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14252 for ; Thu, 28 Aug 2003 09:37:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sMyH-00076y-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 09:37:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sMyG-00076v-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 09:37:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKxZ-0002tk-Fq; Thu, 28 Aug 2003 07:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sHhg-0005qA-PO for sipping@optimus.ietf.org; Thu, 28 Aug 2003 04:00:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14077 for ; Thu, 28 Aug 2003 04:00:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sHhe-0006kG-00 for sipping@ietf.org; Thu, 28 Aug 2003 04:00:22 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19sHhd-0006jX-00 for sipping@ietf.org; Thu, 28 Aug 2003 04:00:21 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7S7xnC28670 for ; Thu, 28 Aug 2003 02:59:50 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 08:59:48 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB009993515@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Christian Stredicke , "'sipping'" Subject: RE: [Sipping] Kill Overlap Dialling Date: Thu, 28 Aug 2003 08:59:46 +0100 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: , The conclusion everyone has always reached on this issue in the past is that you can only eliminate overlap dialling when you have control over whether the terminal can overlap dial or not. Therefore the GSM people eliminated overlap dialling from the handset, and therefore in the network, by insisting that all GSM phones had the user entering the number and then hitting a SEND key. They have not eliminated overlap dialling in the core network, in so far as incomplete numbers can still be received from other networks, which have to be resolved into terminal identifiers before they can be declared to be complete. Likewise, you can insist on the SIP phone dialling complete, but if you want to interwork with the PSTN, then the problem will be there. regards Keith > -----Original Message----- > From: Christian Stredicke [mailto:stredicke@snom.de] > Sent: 26 August 2003 06:37 > To: 'sipping' > Subject: [Sipping] Kill Overlap Dialling > > > Hi All, > > the feedback which I received so far on overlap dialling was pretty > clear: There will be no overlap dialling support for SIP. > > Arguments: > > A. ENUM does not support overlap dialling. There are security concerns > on who will own the nodes of incomplete numbers and it was > also reported > that the overhead for the node lookup is too much. > > B. Countries with fixed-length numbers (like USA) can have a dial plan > on the phone. Other countries always need to press the dial button > except for cases where extension numbers are dialled. People calling > from the US have to press a dial key (or #) after dialling a non-US > number. That is accepted by the customers. > > C. The lack of support of 484 responses on PSTN gateways makes overlap > dialling unusable anyway. A SIP extension would be necessary, but does > not exist at this time and the probability that we reach consensus on > such an extension in time is minimal. > > D. "Grandma" is not in the customer focus any more. > "Grandchildren" are > used to cell phones and press the dial button after making up their > minds on which person to call. > > E. Phones without display will not be sold in large numbers > any more. If > vendors should decide to make SIP phones without display, they must > include a dial button (timeout of 5 seconds to start dialling is not > feasible as this makes printed telephone book lookup impossible). > > > Am I right? I this is so, we would like to stop efforts on > implementing > this in out endpoints. > > Best, > > > Christian > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 28 23:02:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16329 for ; Thu, 28 Aug 2003 23:02:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sX7u-0005VK-PT for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 20:28:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T0SUfh021152 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 20:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sUBK-00061B-4O for sipping-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 17:19:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19979 for ; Thu, 28 Aug 2003 17:19:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sUBG-0007Je-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 17:19:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sUBF-0007Jb-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 17:19:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQvM-0004XB-2p; Thu, 28 Aug 2003 13:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sNqR-0003mG-B9 for sipping@optimus.ietf.org; Thu, 28 Aug 2003 10:33:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19933 for ; Thu, 28 Aug 2003 10:33:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sNqN-0000PG-00 for sipping@ietf.org; Thu, 28 Aug 2003 10:33:47 -0400 Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx with esmtp (Exim 4.12) id 19sNqH-0000Om-00 for sipping@ietf.org; Thu, 28 Aug 2003 10:33:41 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7SEX3K18578; Thu, 28 Aug 2003 16:33:04 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 15:33:04 +0100 Message-ID: From: "Mark Watson" To: "'Henry Sinnreich'" , "'Christian Stredicke'" , "'sipping'" Subject: RE: [Sipping] Kill Overlap Dialling Date: Thu, 28 Aug 2003 15:32:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36D71.45A11042" 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_01C36D71.45A11042 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by zctfs063.nortelnetworks.com id h7SEX3K18578 Content-Transfer-Encoding: quoted-printable Henry, Of course, if it looks and feels like a mobile phone, there may indeed be people who expect it to work like a mobile phone. And with mobile phones there is a big pay-off for the user (mobility) which mitigates various negative performance aspects (e.g. connection time, voice quality). But if it looks and feels like a good old-fashioned phone then (some) peo= ple may expect it to behave like a good old fashioned phone. My point is that it is not for us to decide how important these people ar= e but just to provide the technology which allows such potential requiremen= ts to be met if there is market demand. You say these people are not important, or can be re-educated, but there = are Service Providers who feel (i) these people are important and (ii) the technical barrier is lower/less important than the re-education barrier. ...Mark -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com]=20 Sent: 28 August 2003 14:25 To: Watson, Mark [MOP:EP10:EXCH]; 'Christian Stredicke'; 'sipping' Subject: RE: [Sipping] Kill Overlap Dialling >You can try selling this kind of thing in Europe >without overlap, but expect reviewers to complain about connection times. Are they buying mobile phones nevertheless? Henry ________________________________________ From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Mark Watson Sent: Wednesday, August 27, 2003 11:13 AM To: 'Christian Stredicke'; 'sipping' Subject: RE: [Sipping] Kill Overlap Dialling Pleeeeeease don't start this again ...=20 I don't think the reasons for overlap dialling, which we discussed for a looooooong time, very painfully, have changed significantly. As for end-of-dialling keys on SIP phones, I'd be surprised if anyone on this li= st had not seen sipphone.com. You can try selling this kind of thing in Euro= pe without overlap, but expect reviewers to complain about connection times. They will not always realise that most of it is the inter-digit timer. Yo= u can certainly change user behaviour if you explain to them that it works differently from an old-style phone & if there is something in it for the user as well. But if it 'looks and feels' just like a phone there will always be people who expect it to work just like a phone. Service provide= rs & the market, not IETF, should decide how important those people are. ...Mark=20 -----Original Message-----=20 From: Christian Stredicke [mailto:stredicke@snom.de]=20 Sent: 26 August 2003 06:37=20 To: 'sipping'=20 Subject: [Sipping] Kill Overlap Dialling=20 Hi All,=20 the feedback which I received so far on overlap dialling was pretty=20 clear: There will be no overlap dialling support for SIP.=20 Arguments:=20 A. ENUM does not support overlap dialling. There are security concerns on who will own the nodes of incomplete numbers and it was also reported tha= t the overhead for the node lookup is too much. B. Countries with fixed-len= gth numbers (like USA) can have a dial plan on the phone. Other countries alw= ays need to press the dial button except for cases where extension numbers ar= e dialled. People calling from the US have to press a dial key (or #) after dialling a non-US number. That is accepted by the customers. C. The lack = of support of 484 responses on PSTN gateways makes overlap dialling unusable anyway. A SIP extension would be necessary, but does not exist at this ti= me and the probability that we reach consensus on such an extension in time = is minimal.=20 D. "Grandma" is not in the customer focus any more. "Grandchildren" are u= sed to cell phones and press the dial button after making up their minds on which person to call. E. Phones without display will not be sold in large numbers any more. If vendors should decide to make SIP phones without display, they must include a dial button (timeout of 5 seconds to start dialling is not feasible as this makes printed telephone book lookup impossible). Am I right? I this is so, we would like to stop efforts on implementing t= his in out endpoints.=20 Best,=20 Christian=20 _______________________________________________=20 Sipping mailing list=A0 https://www1.ietf.org/mailman/listinfo/sipping=20 This list is for NEW development of the application of SIP=20 Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP=20 ------_=_NextPart_001_01C36D71.45A11042 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Kill Overlap Dialling

Henry,

Of course, if it looks and feels like a mobile phone, = there may indeed be people who expect it to work like a mobile phone. = And with mobile phones there is a big pay-off for the user (mobility) = which mitigates various negative performance aspects (e.g. connection = time, voice quality).

But if it looks and feels like a good old-fashioned = phone then (some) people may expect it to behave like a good old = fashioned phone.

My point is that it is not for us to decide how = important these people are but just to provide the technology which = allows such potential requirements to be met if there is market = demand.

You say these people are not important, or can be = re-educated, but there are Service Providers who feel (i) these people = are important and (ii) the technical barrier is lower/less important = than the re-education barrier.

...Mark

-----Original Message-----
From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com]
Sent: 28 August 2003 14:25
To: Watson, Mark [MOP:EP10:EXCH]; 'Christian = Stredicke'; 'sipping'
Subject: RE: [Sipping] Kill Overlap Dialling


>You can try selling this kind of thing in = Europe
>without overlap, but expect reviewers to = complain about connection times.

Are they buying mobile phones nevertheless?

Henry

________________________________________
From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org= ] On Behalf Of Mark Watson
Sent: Wednesday, August 27, 2003 11:13 AM
To: 'Christian Stredicke'; 'sipping'
Subject: RE: [Sipping] Kill Overlap Dialling

Pleeeeeease don't start this again ...
I don't think the reasons for overlap dialling, = which we discussed for a looooooong time, very painfully, have changed = significantly. As for end-of-dialling keys on SIP phones, I'd be = surprised if anyone on this list had not seen sipphone.com. You can try = selling this kind of thing in Europe without overlap, but expect = reviewers to complain about connection times. They will not always = realise that most of it is the inter-digit timer. You can certainly = change user behaviour if you explain to them that it works differently = from an old-style phone & if there is something in it for the user = as well. But if it 'looks and feels' just like a phone there will = always be people who expect it to work just like a phone. Service = providers & the market, not IETF, should decide how important those = people are. ...Mark

-----Original Message-----
From: Christian Stredicke [mailto:stredicke@snom.de]
Sent: 26 August 2003 06:37
To: 'sipping'
Subject: [Sipping] Kill Overlap Dialling

Hi All,
the feedback which I received so far on overlap = dialling was pretty
clear: There will be no overlap dialling support for = SIP.
Arguments:
A. ENUM does not support overlap dialling. There are = security concerns on who will own the nodes of incomplete numbers and = it was also reported that the overhead for the node lookup is too much. = B. Countries with fixed-length numbers (like USA) can have a dial plan = on the phone. Other countries always need to press the dial button = except for cases where extension numbers are dialled. People calling = from the US have to press a dial key (or #) after dialling a non-US = number. That is accepted by the customers. C. The lack of support of = 484 responses on PSTN gateways makes overlap dialling unusable anyway. = A SIP extension would be necessary, but does not exist at this time and = the probability that we reach consensus on such an extension in time is = minimal.

D. "Grandma" is not in the customer focus = any more. "Grandchildren" are used to cell phones and press = the dial button after making up their minds on which person to call. E. = Phones without display will not be sold in large numbers any more. If = vendors should decide to make SIP phones without display, they must = include a dial button (timeout of 5 seconds to start dialling is not = feasible as this makes printed telephone book lookup = impossible).

Am I right? I this is so, we would like to stop = efforts on implementing this in out endpoints.
Best,

Christian

_______________________________________________ =
Sipping mailing list=A0 https://www1.ietf.org/mailman/listinfo/sipping =
This list is for NEW development of the 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_01C36D71.45A11042-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 28 23:30:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18736 for ; Thu, 28 Aug 2003 23:30:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sXQs-0006rB-HD for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 20:48:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T0m6FJ026347 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 20:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sTNM-0003VL-Aq for sipping-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 16:28:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15952 for ; Thu, 28 Aug 2003 16:28:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sTNK-0006O2-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 16:28:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sTNJ-0006Ny-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 16:28:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQmY-0003b7-5F; Thu, 28 Aug 2003 13:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sMoL-0000af-7S for sipping@optimus.ietf.org; Thu, 28 Aug 2003 09:27:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13270 for ; Thu, 28 Aug 2003 09:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sMoI-0006oi-00 for sipping@ietf.org; Thu, 28 Aug 2003 09:27:35 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19sMoI-0006nr-00 for sipping@ietf.org; Thu, 28 Aug 2003 09:27:34 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HKB00FEBZX794@firewall.wcom.com> for sipping@ietf.org; Thu, 28 Aug 2003 13:24:43 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HKB00B01ZX5VD@dgismtp04.wcomnet.com>; Thu, 28 Aug 2003 13:24:43 +0000 (GMT) Received: from hsinnreich2 ([166.50.136.36]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HKB00B82ZX2FU@dgismtp04.wcomnet.com>; Thu, 28 Aug 2003 13:24:42 +0000 (GMT) Date: Thu, 28 Aug 2003 08:24:39 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Kill Overlap Dialling In-reply-to: To: "'Mark Watson'" , "'Christian Stredicke'" , "'sipping'" Message-id: <0HKB00B86ZX5FU@dgismtp04.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcNs7TF/3SkvqPrpR+qCSWl7N1tUTQAef9tg Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable >You can try selling this kind of thing in Europe=20 >without overlap, but expect reviewers to complain about connection = times. Are they buying mobile phones nevertheless? Henry ________________________________________ From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of Mark Watson Sent: Wednesday, August 27, 2003 11:13 AM To: 'Christian Stredicke'; 'sipping' Subject: RE: [Sipping] Kill Overlap Dialling Pleeeeeease don't start this again ...=20 I don't think the reasons for overlap dialling, which we discussed for a looooooong time, very painfully, have changed significantly. As for end-of-dialling keys on SIP phones, I'd be surprised if anyone on this list had not seen sipphone.com. You can try selling this kind of = thing in Europe without overlap, but expect reviewers to complain about = connection times. They will not always realise that most of it is the inter-digit timer. You can certainly change user behaviour if you explain to them that it = works differently from an old-style phone & if there is something in it for = the user as well. But if it 'looks and feels' just like a phone there will always be people who expect it to work just like a phone. Service = providers & the market, not IETF, should decide how important those people are. ...Mark=20 -----Original Message-----=20 From: Christian Stredicke [mailto:stredicke@snom.de]=20 Sent: 26 August 2003 06:37=20 To: 'sipping'=20 Subject: [Sipping] Kill Overlap Dialling=20 Hi All,=20 the feedback which I received so far on overlap dialling was pretty=20 clear: There will be no overlap dialling support for SIP.=20 Arguments:=20 A. ENUM does not support overlap dialling. There are security concerns = on who will own the nodes of incomplete numbers and it was also reported = that the overhead for the node lookup is too much. B. Countries with fixed-length numbers (like USA) can have a dial plan = on the phone. Other countries always need to press the dial button except = for cases where extension numbers are dialled. People calling from the US = have to press a dial key (or #) after dialling a non-US number. That is = accepted by the customers. C. The lack of support of 484 responses on PSTN gateways makes overlap dialling unusable anyway. A SIP extension would be necessary, but does = not exist at this time and the probability that we reach consensus on such = an extension in time is minimal.=20 D. "Grandma" is not in the customer focus any more. "Grandchildren" are = used to cell phones and press the dial button after making up their minds on which person to call. E. Phones without display will not be sold in large numbers any more. If vendors should decide to make SIP phones without display, they must = include a dial button (timeout of 5 seconds to start dialling is not feasible as this makes printed telephone book lookup impossible). Am I right? I this is so, we would like to stop efforts on implementing = this in out endpoints.=20 Best,=20 Christian=20 _______________________________________________=20 Sipping mailing list=A0 https://www1.ietf.org/mailman/listinfo/sipping=20 This list is for NEW development of the application of SIP=20 Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Thu Aug 28 23:46:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20543 for ; Thu, 28 Aug 2003 23:46:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sXw2-0000Ch-44 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 21:20:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T1KIbA000773 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 21:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sUDF-0006DA-QA for sipping-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 17:21:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20182 for ; Thu, 28 Aug 2003 17:21:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sUDD-0007Mo-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 17:21:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sUDC-0007Ml-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 17:21:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQg6-00034E-P5; Thu, 28 Aug 2003 13:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sOHO-0004he-Hw for sipping@optimus.ietf.org; Thu, 28 Aug 2003 11:01:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22065 for ; Thu, 28 Aug 2003 11:01:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sOHL-0000rv-00 for sipping@ietf.org; Thu, 28 Aug 2003 11:01:39 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19sOHL-0000r5-00 for sipping@ietf.org; Thu, 28 Aug 2003 11:01:39 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HKC00EHP48JVK@firewall.wcom.com> for sipping@ietf.org; Thu, 28 Aug 2003 14:57:55 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HKC005013ZGC1@dgismtp04.wcomnet.com>; Thu, 28 Aug 2003 14:57:55 +0000 (GMT) Received: from hsinnreich2 ([166.50.136.36]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HKC005A0488IT@dgismtp04.wcomnet.com>; Thu, 28 Aug 2003 14:57:45 +0000 (GMT) Date: Thu, 28 Aug 2003 09:57:45 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Kill Overlap Dialling In-reply-to: To: "'Mark Watson'" , "'Henry Sinnreich'" , "'Christian Stredicke'" , "'sipping'" Message-id: <0HKC005A1488IT@dgismtp04.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcNtcU720NxCqXzXTyahgviPQB4H0AAAmkmQ Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable I am not sure why we have to keep the "good old fashioned phone" as a business target or technological icon. Instead of driving by looking in = the rear view mirror, we should rather address all those users gobbling up mobile phones and integrated enterprise communications and applications, such as in Microsoft Office 2003 or Siemens Openscape. Using overlap dialing from the PC/laptop/PDA/smart-phone/mobile phone? = Would you? Excuse me for mentioning a few commercial products... Henry ________________________________________ From: Mark Watson [mailto:mwatson@nortelnetworks.com]=20 Sent: Thursday, August 28, 2003 9:33 AM To: 'Henry Sinnreich'; 'Christian Stredicke'; 'sipping' Subject: RE: [Sipping] Kill Overlap Dialling Henry,=20 Of course, if it looks and feels like a mobile phone, there may indeed = be people who expect it to work like a mobile phone. And with mobile phones there is a big pay-off for the user (mobility) which mitigates various negative performance aspects (e.g. connection time, voice quality). But if it looks and feels like a good old-fashioned phone then (some) = people may expect it to behave like a good old fashioned phone. My point is that it is not for us to decide how important these people = are but just to provide the technology which allows such potential = requirements to be met if there is market demand. You say these people are not important, or can be re-educated, but there = are Service Providers who feel (i) these people are important and (ii) the technical barrier is lower/less important than the re-education barrier. ...Mark=20 -----Original Message-----=20 From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com]=20 Sent: 28 August 2003 14:25=20 To: Watson, Mark [MOP:EP10:EXCH]; 'Christian Stredicke'; 'sipping'=20 Subject: RE: [Sipping] Kill Overlap Dialling=20 >You can try selling this kind of thing in Europe=20 >without overlap, but expect reviewers to complain about connection = times.=20 Are they buying mobile phones nevertheless?=20 Henry=20 ________________________________________=20 From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of Mark Watson=20 Sent: Wednesday, August 27, 2003 11:13 AM=20 To: 'Christian Stredicke'; 'sipping'=20 Subject: RE: [Sipping] Kill Overlap Dialling=20 Pleeeeeease don't start this again ...=20 I don't think the reasons for overlap dialling, which we discussed for a looooooong time, very painfully, have changed significantly. As for end-of-dialling keys on SIP phones, I'd be surprised if anyone on this = list had not seen sipphone.com. You can try selling this kind of thing in = Europe without overlap, but expect reviewers to complain about connection = times. They will not always realise that most of it is the inter-digit timer. = You can certainly change user behaviour if you explain to them that it works differently from an old-style phone & if there is something in it for = the user as well. But if it 'looks and feels' just like a phone there will always be people who expect it to work just like a phone. Service = providers & the market, not IETF, should decide how important those people are. ...Mark=20 -----Original Message-----=20 From: Christian Stredicke [mailto:stredicke@snom.de]=20 Sent: 26 August 2003 06:37=20 To: 'sipping'=20 Subject: [Sipping] Kill Overlap Dialling=20 Hi All,=20 the feedback which I received so far on overlap dialling was pretty=20 clear: There will be no overlap dialling support for SIP.=20 Arguments:=20 A. ENUM does not support overlap dialling. There are security concerns = on who will own the nodes of incomplete numbers and it was also reported = that the overhead for the node lookup is too much. B. Countries with = fixed-length numbers (like USA) can have a dial plan on the phone. Other countries = always need to press the dial button except for cases where extension numbers = are dialled. People calling from the US have to press a dial key (or #) = after dialling a non-US number. That is accepted by the customers. C. The lack = of support of 484 responses on PSTN gateways makes overlap dialling = unusable anyway. A SIP extension would be necessary, but does not exist at this = time and the probability that we reach consensus on such an extension in time = is minimal.=20 D. "Grandma" is not in the customer focus any more. "Grandchildren" are = used to cell phones and press the dial button after making up their minds on which person to call. E. Phones without display will not be sold in = large numbers any more. If vendors should decide to make SIP phones without display, they must include a dial button (timeout of 5 seconds to start dialling is not feasible as this makes printed telephone book lookup impossible). Am I right? I this is so, we would like to stop efforts on implementing = this in out endpoints.=20 Best,=20 Christian=20 _______________________________________________=20 Sipping mailing list=A0 https://www1.ietf.org/mailman/listinfo/sipping=20 This list is for NEW development of the application of SIP=20 Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 29 02:29:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16700 for ; Fri, 29 Aug 2003 02:29:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19saEc-0007JO-04 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 23:47:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T3lbk5028098 for sipping-archive@odin.ietf.org; Thu, 28 Aug 2003 23:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sXrb-0008Up-1O for sipping-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 21:15:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08416 for ; Thu, 28 Aug 2003 21:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sXrY-0003Uq-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 21:15:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sXrX-0003Un-00 for sipping-web-archive@ietf.org; Thu, 28 Aug 2003 21:15:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sU9a-0005zA-6r; Thu, 28 Aug 2003 17:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sRC6-0005VQ-OI for sipping@optimus.ietf.org; Thu, 28 Aug 2003 14:08:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05706 for ; Thu, 28 Aug 2003 14:08:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sRC4-0004EJ-00 for sipping@ietf.org; Thu, 28 Aug 2003 14:08:24 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19sRC3-0004Da-00 for sipping@ietf.org; Thu, 28 Aug 2003 14:08:23 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7SI7r97019142; Thu, 28 Aug 2003 13:07:53 -0500 Subject: RE: [Sipping] Kill Overlap Dialling From: Dean Willis To: "Drage, Keith (Keith)" Cc: Christian Stredicke , "'sipping'" In-Reply-To: <475FF955A05DD411980D00508B6D5FB009993515@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB009993515@en0033exch001u.uk.lucent.com> Content-Type: text/plain Message-Id: <1062094073.18183.42.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 28 Aug 2003 13:07:53 -0500 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 On Thu, 2003-08-28 at 02:59, Drage, Keith (Keith) wrote: > The conclusion everyone has always reached on this issue in the past is that you can only eliminate overlap dialling when you have control over whether the terminal can overlap dial or not. > > Therefore the GSM people eliminated overlap dialling from the handset, and therefore in the network, by insisting that all GSM phones had the user entering the number and then hitting a SEND key. They have not eliminated overlap dialling in the core network, in so far as incomplete numbers can still be received from other networks, which have to be resolved into terminal identifiers before they can be declared to be complete. > > Likewise, you can insist on the SIP phone dialling complete, but if you want to interwork with the PSTN, then the problem will be there. > yes, but like GSM, only as an INBOUND problem. I would expect calls ORIGINATING from SIP nodes to always be en-bloc. -- 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 exim@www1.ietf.org Fri Aug 29 03:56:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24418 for ; Fri, 29 Aug 2003 03:56:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sdq1-0005KV-CV for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 03:38:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T7cTPK020476 for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 03:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19scBC-0005S5-Lx for sipping-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 01:52:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01186 for ; Fri, 29 Aug 2003 01:52:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19scB9-0001BV-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 01:52:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19scB8-0001BS-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 01:52:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sb2N-0001ji-Bc; Fri, 29 Aug 2003 00:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWqj-0004VV-SG for sipping@optimus.ietf.org; Thu, 28 Aug 2003 20:10:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02570 for ; Thu, 28 Aug 2003 20:10:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sWqh-000237-00 for sipping@ietf.org; Thu, 28 Aug 2003 20:10:43 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19sWqh-00022v-00 for sipping@ietf.org; Thu, 28 Aug 2003 20:10:43 -0400 Received: from rshockeybox.shockey.us (h-68-165-240-34.MCLNVA23.covad.net [68.165.240.34]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h7T0EfE20525; Thu, 28 Aug 2003 17:14:42 -0700 Message-Id: <5.2.0.9.2.20030828195910.0506e000@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 28 Aug 2003 20:07:21 -0400 To: "Mark Watson" , "'Henry Sinnreich'" , "'Christian Stredicke'" , "'sipping'" From: Richard Shockey Subject: RE: [Sipping] Kill Overlap Dialling In-Reply-To: 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: , At 03:32 PM 8/28/2003 +0100, Mark Watson wrote: >Henry, > >Of course, if it looks and feels like a mobile phone, there may indeed be >people who expect it to work like a mobile phone. And with mobile phones >there is a big pay-off for the user (mobility) which mitigates various >negative performance aspects (e.g. connection time, voice quality). > >But if it looks and feels like a good old-fashioned phone then (some) >people may expect it to behave like a good old fashioned phone. yes but SIP also provides ample benefits that can over some marginal problems such as a requirement full dial string. >My point is that it is not for us to decide how important these people are >but just to provide the technology which allows such potential >requirements to be met if there is market demand. > >You say these people are not important, or can be re-educated, but there >are Service Providers who feel (i) these people are important and (ii) the >technical barrier is lower/less important than the re-education barrier. Well I can speak to this based on the North American market where every single month some NPA has to go from 7 to 10 digit dialing as a result of overlay codes. Hey suprise .they get over it ..they whine a bit ..but the major suprise for many of us in the industry was New York City which went to full 10 digit dialing and guess what NO ONE CARED ..why ..they have a well known user experience in the mobile phone industry. Who among the Service Providers is whining .. Incumbent Carriers looking for an excuse not to support VoIP?? The same people whining about QoS etc. There is no rational reason to expend one more TCP/IP packet on this subject. >...Mark >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 29 08:52:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19542 for ; Fri, 29 Aug 2003 08:52:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19shMr-0001HG-F8 for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 07:24:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TBObFq004904 for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 07:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sgta-0008JH-9M for sipping-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 06:54:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10233 for ; Fri, 29 Aug 2003 06:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sgtK-00008y-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 06:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sgtJ-00008v-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 06:54:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sgU7-0007Q7-EC; Fri, 29 Aug 2003 06:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19seFz-0007Kv-GY for sipping@optimus.ietf.org; Fri, 29 Aug 2003 04:05:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25249 for ; Fri, 29 Aug 2003 04:05:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19seFw-0004J2-00 for sipping@ietf.org; Fri, 29 Aug 2003 04:05:16 -0400 Received: from natsmtp01.webmailer.de ([192.67.198.81] helo=post.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 19seFv-0004It-00 for sipping@ietf.org; Fri, 29 Aug 2003 04:05:16 -0400 Received: from sip (pD95015A3.dip.t-dialin.net [217.80.21.163]) by post.webmailer.de (8.12.9/8.8.7) with ESMTP id h7T85Ets013211; Fri, 29 Aug 2003 10:05:14 +0200 (MEST) From: "Christian Stredicke" To: "'Henry Sinnreich'" , "'Mark Watson'" , "'sipping'" Subject: AW: [Sipping] Kill Overlap Dialling Date: Fri, 29 Aug 2003 10:05:29 +0200 Message-ID: <022501c36e04$50c10f20$020ba8c0@sip> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <0HKB00B86ZX5FU@dgismtp04.wcomnet.com> Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Sorry I was a few days offline... The mobility feature allowed the call phones to have horrible features like dropping packets, bad voice quality, high prices, etc... Additionally, if you try overlap dialling on a cell phone you would be surprised on the "look and feel": while you are still looking at the handset (entering the number), the other party might be already connected. That=92s why all intelligent users put the handset as quick = as possible to the ear waiting for some tone! That is different with a "classical" phone: When you dial, you have the handset already on the ear. Hands free mode mimics that behaviour.=20 Chance that we get overlap dialling into ENUM: zero. Chance that we get all PSTN gateways to support it: almost zero.=20 It's (maybe) sad but true: overlapped dialling is dead for SIP. Christian > -----Urspr=FCngliche Nachricht----- > Von: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > Gesendet: Donnerstag, 28. August 2003 15:25 > An: 'Mark Watson'; 'Christian Stredicke'; 'sipping' > Betreff: RE: [Sipping] Kill Overlap Dialling >=20 > >You can try selling this kind of thing in Europe > >without overlap, but expect reviewers to complain about connection times. >=20 > Are they buying mobile phones nevertheless? >=20 > Henry >=20 > ________________________________________ > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > Mark Watson > Sent: Wednesday, August 27, 2003 11:13 AM > To: 'Christian Stredicke'; 'sipping' > Subject: RE: [Sipping] Kill Overlap Dialling >=20 > Pleeeeeease don't start this again ... > I don't think the reasons for overlap dialling, which we discussed for a > looooooong time, very painfully, have changed significantly. > As for end-of-dialling keys on SIP phones, I'd be surprised if anyone on > this list had not seen sipphone.com. You can try selling this kind of > thing > in Europe without overlap, but expect reviewers to complain about > connection > times. They will not always realise that most of it is the inter-digit > timer. > You can certainly change user behaviour if you explain to them that it > works > differently from an old-style phone & if there is something in it for the > user as well. But if it 'looks and feels' just like a phone there will > always be people who expect it to work just like a phone. Service > providers > & the market, not IETF, should decide how important those people are. > ...Mark > -----Original Message----- > From: Christian Stredicke [mailto:stredicke@snom.de] > Sent: 26 August 2003 06:37 > To: 'sipping' > Subject: [Sipping] Kill Overlap Dialling >=20 > Hi All, > the feedback which I received so far on overlap dialling was pretty > clear: There will be no overlap dialling support for SIP. > Arguments: > A. ENUM does not support overlap dialling. There are security concerns on > who will own the nodes of incomplete numbers and it was also reported that > the overhead for the node lookup is too much. > B. Countries with fixed-length numbers (like USA) can have a dial plan on > the phone. Other countries always need to press the dial button except for > cases where extension numbers are dialled. People calling from the US have > to press a dial key (or #) after dialling a non-US number. That is > accepted > by the customers. > C. The lack of support of 484 responses on PSTN gateways makes overlap > dialling unusable anyway. A SIP extension would be necessary, but does not > exist at this time and the probability that we reach consensus on such an > extension in time is minimal. > D. "Grandma" is not in the customer focus any more. "Grandchildren" are > used > to cell phones and press the dial button after making up their minds on > which person to call. > E. Phones without display will not be sold in large numbers any more. If > vendors should decide to make SIP phones without display, they must > include > a dial button (timeout of 5 seconds to start dialling is not feasible as > this makes printed telephone book lookup impossible). >=20 > Am I right? I this is so, we would like to stop efforts on implementing > this > in out endpoints. > Best, >=20 > Christian >=20 > _______________________________________________ > Sipping mailing list=A0 https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 29 18:43:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14062 for ; Fri, 29 Aug 2003 18:43:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19srmA-0007UQ-Ac for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 18:31:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TMVPZS028779 for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 18:31:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sotl-0008CQ-4h for sipping-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 15:27:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27128 for ; Fri, 29 Aug 2003 15:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sotj-0004bh-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 15:27:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sotj-0004be-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 15:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snxX-0005gp-6g; Fri, 29 Aug 2003 14:26:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19smZq-0001LN-On for sipping@optimus.ietf.org; Fri, 29 Aug 2003 12:58:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10662 for ; Fri, 29 Aug 2003 12:33:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sm33-00078U-00 for sipping@ietf.org; Fri, 29 Aug 2003 12:24:29 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19sm32-00078R-00 for sipping@ietf.org; Fri, 29 Aug 2003 12:24:28 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 74AB6206607 for ; Fri, 29 Aug 2003 12:22:48 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19slRp-0007ZU-Vu for ietf-announce-list@asgard.ietf.org; Fri, 29 Aug 2003 11:46:01 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19slEZ-0006iY-EW for all-ietf@asgard.ietf.org; Fri, 29 Aug 2003 11:32:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03282; Fri, 29 Aug 2003 11:32:12 -0400 (EDT) Message-Id: <200308291532.LAA03282@ietf.org> To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 29 Aug 2003 11:32:12 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+289397_8474885512240_9484709243" Subject: [Sipping] I-D ACTION:draft-jain-sipping-srtp-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+289397_8474885512240_9484709243 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using SRTP with SIP Author(s) : K. Jain, J. Albert Filename : draft-jain-sipping-srtp-00.txt Pages : 0 Date : 2003-8-29 The Secured Real Time Protocol (SRTP) is a lightweight protocol that secures voice data between two end points. The Session Initiation Protocol (SIP) is a simple and adaptive session-controlling protocol. Efforts have been underway to get these two protocols working together. Several ideas have been presented in different documents in past. This document describes one more way to accomplish this task. The proposed approach is simple and does not consume too much CPU cycles. However, some assumptions need to be made in lack of the specific SIP and SDP fields. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jain-sipping-srtp-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-jain-sipping-srtp-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-jain-sipping-srtp-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. --MIMEStream=_0+289397_8474885512240_9484709243 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+256940_39846811223698_7154361761" --MIMEStream=_1+256940_39846811223698_7154361761 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-29113616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jain-sipping-srtp-00.txt --MIMEStream=_1+256940_39846811223698_7154361761 Content-Type: Message/External-body; name="draft-jain-sipping-srtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113616.I-D@ietf.org> --MIMEStream=_1+256940_39846811223698_7154361761-- --MIMEStream=_0+289397_8474885512240_9484709243-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 29 19:33:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18163 for ; Fri, 29 Aug 2003 19:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19srnp-0007cD-CE for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 18:33:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TMX8Od029263 for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 18:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19spM0-000101-QG for sipping-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 15:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29744 for ; Fri, 29 Aug 2003 15:56:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19spLz-0005QE-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 15:56:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19spLy-0005Q9-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 15:56:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snww-0005YV-QP; Fri, 29 Aug 2003 14:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sl8X-0005yC-4L for sipping@optimus.ietf.org; Fri, 29 Aug 2003 11:26:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02634 for ; Fri, 29 Aug 2003 11:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sl8W-0005We-00 for sipping@ietf.org; Fri, 29 Aug 2003 11:26:04 -0400 Received: from natsmtp01.webmailer.de ([192.67.198.81] helo=post.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 19sl8V-0005Wb-00 for sipping@ietf.org; Fri, 29 Aug 2003 11:26:03 -0400 Received: from sip (p3E9BAA3F.dip.t-dialin.net [62.155.170.63]) by post.webmailer.de (8.12.9/8.8.7) with ESMTP id h7TFPsCf002870; Fri, 29 Aug 2003 17:25:55 +0200 (MEST) From: "Christian Stredicke" To: "'Adam Roach'" , "'Dean Willis'" Cc: "'sipping'" Subject: AW: [Sipping] Kill Overlap Dialling Date: Fri, 29 Aug 2003 17:26:10 +0200 Message-ID: <029b01c36e41$e1393c20$020ba8c0@sip> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E863CE@dyn-tx-exch-001.dynamicsoft.com> Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable I saw zero (in total, including SipIt). Maybe I am blind. CS > -----Urspr=FCngliche Nachricht----- > Von: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] Im Auftrag von > Adam Roach > Gesendet: Mittwoch, 27. August 2003 19:27 > An: 'Dean Willis'; Adam Roach > Cc: 'Christian Stredicke'; 'sipping' > Betreff: RE: [Sipping] Kill Overlap Dialling >=20 > Dean Willis [mailto:dean.willis@softarmor.com] writes: >=20 > > Good point, Adam. Can you tell us how many implementations of RFC 3578 > > were exercised at the last SIPit? >=20 > That's more of a Robert question; I wasn't there. >=20 > /a >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 exim@www1.ietf.org Fri Aug 29 19:34:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18261 for ; Fri, 29 Aug 2003 19:34:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ssDl-0008R5-6k for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 18:59:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TMxt4D032421 for sipping-archive@odin.ietf.org; Fri, 29 Aug 2003 18:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sph5-00022D-5D for sipping-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 16:18:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01451 for ; Fri, 29 Aug 2003 16:17:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sph3-0005zp-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 16:18:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sph2-0005zm-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 16:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snvy-0005T3-O1; Fri, 29 Aug 2003 14:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19slEZ-0006KX-Q1 for sipping@optimus.ietf.org; Fri, 29 Aug 2003 11:32:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03282; Fri, 29 Aug 2003 11:32:12 -0400 (EDT) Message-Id: <200308291532.LAA03282@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: Fri, 29 Aug 2003 11:32:12 -0400 Subject: [Sipping] I-D ACTION:draft-jain-sipping-srtp-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 : Using SRTP with SIP Author(s) : K. Jain, J. Albert Filename : draft-jain-sipping-srtp-00.txt Pages : 0 Date : 2003-8-29 The Secured Real Time Protocol (SRTP) is a lightweight protocol that secures voice data between two end points. The Session Initiation Protocol (SIP) is a simple and adaptive session-controlling protocol. Efforts have been underway to get these two protocols working together. Several ideas have been presented in different documents in past. This document describes one more way to accomplish this task. The proposed approach is simple and does not consume too much CPU cycles. However, some assumptions need to be made in lack of the specific SIP and SDP fields. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jain-sipping-srtp-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-jain-sipping-srtp-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-jain-sipping-srtp-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-8-29113616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jain-sipping-srtp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jain-sipping-srtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113616.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 exim@www1.ietf.org Sat Aug 30 03:08:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27360 for ; Sat, 30 Aug 2003 03:08:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sy0P-0000O2-IA for sipping-archive@odin.ietf.org; Sat, 30 Aug 2003 01:10:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U5AXcG001480 for sipping-archive@odin.ietf.org; Sat, 30 Aug 2003 01:10:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19suXk-0006qU-JG for sipping-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 21:28:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25741 for ; Fri, 29 Aug 2003 21:28:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19suXg-0007Df-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 21:28:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19suXg-0007Dc-00 for sipping-web-archive@ietf.org; Fri, 29 Aug 2003 21:28:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stm7-0004XO-Rb; Fri, 29 Aug 2003 20:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19srln-0007Rp-Au for sipping@optimus.ietf.org; Fri, 29 Aug 2003 18:31:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12938 for ; Fri, 29 Aug 2003 18:30:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19srlk-0002AJ-00 for sipping@ietf.org; Fri, 29 Aug 2003 18:31:00 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=cc26-01.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19srlj-0002A3-00 for sipping@ietf.org; Fri, 29 Aug 2003 18:30:59 -0400 Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 3D87084845; Fri, 29 Aug 2003 22:30:29 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194]) by cc26-01.idc1.level3.com (Postfix) with SMTP id C6E8C8482F; Fri, 29 Aug 2003 22:30:28 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 29 Aug 2003 16:30:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36E7D.25D2789F" Date: Fri, 29 Aug 2003 16:30:28 -0600 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC013A9A7@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sip] Proposal for 'Transfer-From' INVITE header. Thread-Index: AcNuWVg8q/cDcjUnSsy4hxqpSJhrbAAH6b7w From: "Hearty, John" To: "Greier, Tom" Cc: , , X-OriginalArrivalTime: 29 Aug 2003 22:30:28.0520 (UTC) FILETIME=[26123280:01C36E7D] Subject: [Sipping] RE: [Sip] Proposal for 'Transfer-From' INVITE header. 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_01C36E7D.25D2789F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This probably belongs on the sipping list rather than sip. If I understand your flow correctly, this attended transfer flow is covered in the cc-transfer draft section 6. By the way, this draft recently expired, what's the status Robert or Alan? =20 This statement seems to be at the heart of the issue: =20 On a PBX, the 'intent' needs to be known upfront, since the way that the call is put onhold depends on the intent of the requester (put the call onhold so another call can be made, or put the call onhold-pend-transfer to eventually dial a transfer target). =20 It is not clear to me why the transferee needs to know the intent while going on hold. The transferee certainly learns the intent of transfer upon receiving the Refer. What different actions does the transferee need to take regarding going on hold prior to transfer vs. regular hold? =20 John Hearty Level3 =20 =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Greier, Tom Sent: Friday, August 29, 2003 12:14 PM To: sip@ietf.org Cc: Greier, Tom Subject: [Sip] Proposal for 'Transfer-From' INVITE header. =20 Hello All, =20 I am usually a passive reader of this forum, but there has been an issue that my development group has been struggling with for a while. We have been using a 'proprietary' header for some time, for which I am hoping to legitimize via a draft or get information as to existing solutions. =20 On most PBX and key system digital stations, in order to perform a supervised transfer of a call, the transferee is put onhold and a new call is automatically created in the dialtone state. The transfer target is then dialed on the new dialtone call. If the transferor decides to complete the transfer, the transferor usually either hangs up or presses a transfer key to complete the transfer. =20 This scenario is a two-step transfer process: =20 1) Put transferee onhold-pend-transfer, which creates new call to be dialed on to reach transfer destination. 2) Complete transfer. =20 The two-step transfer process allows the transferor to possibly abort the transfer, drop the transfer destination and reconnect to the transferee call. =20 In implementing a PBX/SIP gateway to PBX/key systems that operate in this manner, we have a problem with Re-INVITE (hold), INVITE (new party), REFER/replaces to perform the transfer. When the gateway receives the Re-INVITE (hold) method, the gateway does not know the 'intent' of the hold request. Is it a regular 'put the call onhold', or is the requestor intending to later make another outbound call on the same line and transfer the original call. On a PBX, the 'intent' needs to be known upfront, since the way that the call is put onhold depends on the intent of the requester (put the call onhold so another call can be made, or put the call onhold-pend-transfer to eventually dial a transfer target). =20 In order to support this functionality, we have been using our own 'Transfer-From' header. The 'Transfer-From' header is placed in the INVITE that the requestor sends to dial the transfer destination. The 'Transfer-From' header specifies the call-ID of the transferee call that the gateway should put onhold-pend-transfer. The destination specified by the INVITE in the To header is then dialed as the transfer destination. If the requestor later sends a REFER/replaces specifying the transferee and the transfer target, then the gateway completes the transfer. The requestor can also send a BYE or CANCEL on the transfer target dialog to drop the transfer target and unhold the original transferee call. Media is then re-established to the original transferee call upon the gateway receiving a Re-INVITE (unhold) request. =20 I know that this is very specific to a PBX-gateway device, but is what we are doing relevant to any other interfaces/implementations? Is this header viable in any broader sense, is it worth a draft, or is there an existing standard for this type of functionality? =20 Thank you for your help. =20 Tom Greier Intel Corporation Network Building Block Division 55 Dodge Rd. Getzville, NY 14068 =20 Phone: (716) 639-3211 mailto:tom.greier@Intel.com =20 ------_=_NextPart_001_01C36E7D.25D2789F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

This probably belongs on the = sipping list rather than sip.  If I understand your flow correctly, this = attended transfer flow is covered in the cc-transfer draft section 6.  By = the way, this draft recently expired, what’s the status Robert or = Alan?

 

This statement seems to be at the = heart of the issue:

 

On a PBX, the 'intent' needs to be known upfront, = since the way that the call is put onhold depends on the intent of the requester = (put the call onhold so another call can be made, or put the call = onhold-pend-transfer to eventually dial a transfer target).

 

It is not clear to me why the = transferee needs to know the intent while going on hold. The transferee certainly = learns the intent of transfer upon receiving the Refer.  What different = actions does the transferee need to take regarding going on hold prior to = transfer vs. regular hold?

 

John Hearty

Level3

 

 

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of Greier, Tom
Sent: Friday, August 29, 2003 12:14 = PM
To: sip@ietf.org
Cc: Greier, Tom
Subject: [Sip] Proposal = for 'Transfer-From' INVITE header.

 

Hello All,

 

I am usually a passive reader of this forum, but = there has been an issue that my development group has been struggling with for a = while. We have been using a 'proprietary' header for some time, for which I am = hoping to legitimize via a draft or get information as to existing = solutions.

 

On most PBX and key system digital stations, in order = to perform a supervised transfer of a call, the transferee is put onhold = and a new call is automatically created in the dialtone state. The transfer target = is then dialed on the new dialtone call. If the transferor decides to = complete the transfer, the transferor usually either hangs up or presses a transfer = key to complete the transfer.

 

This scenario is a two-step transfer = process:

 

1) Put transferee onhold-pend-transfer, which creates = new call to be dialed on to reach transfer destination.

2) Complete transfer.

 

The two-step transfer process allows the transferor = to possibly abort the transfer, drop the transfer destination and reconnect = to the transferee call.

 

In implementing a PBX/SIP gateway to PBX/key systems = that operate in this manner, we have a problem with Re-INVITE (hold), INVITE = (new party), REFER/replaces to perform the transfer. When the gateway = receives the Re-INVITE (hold) method, the gateway does not know the 'intent' of the = hold request. Is it a regular 'put the call onhold', or is the requestor = intending to later make another outbound call on the same line and transfer the = original call. On a PBX, the 'intent' needs to be known upfront, since the way = that the call is put onhold depends on the intent of the requester (put the call = onhold so another call can be made, or put the call onhold-pend-transfer to = eventually dial a transfer target).

 

In order to support this functionality, we have been = using our own 'Transfer-From' header. The 'Transfer-From' header is placed in = the INVITE that the requestor sends to dial the transfer destination. The 'Transfer-From' header specifies the call-ID of the transferee = call that the gateway should put onhold-pend-transfer. The destination = specified by the INVITE in the To header is then dialed as the transfer destination. = If the requestor later sends a REFER/replaces specifying the transferee and the = transfer target, then the gateway completes the transfer. The requestor can also = send a BYE or CANCEL on the transfer target dialog to drop the transfer target = and unhold the original transferee call. Media is then re-established to the original transferee call upon the gateway receiving a Re-INVITE (unhold) request.

 

I know that this is very specific to a PBX-gateway = device, but is what we are doing relevant to any other = interfaces/implementations? Is this header viable in any broader sense, is it worth a draft, or is = there an existing standard for this type of functionality?

 

Thank you for your help.

 

Tom Greier

Intel Corporation
Network Building Block Division
55 Dodge Rd.

Getzville, NY 14068

 

Phone: (716) 639-3211
mailto:tom.greier@Intel.com

 

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